Dá para aproveitar ou tem que refazer? Como avaliar um projeto de vibe coding antes de levar para produção

Você abriu o gerador, descreveu o que queria e em duas horas tinha algo funcionando. Depois veio a segunda semana. Cada correção criava um erro novo, o crédito foi embora e o projeto parou num lugar em que ele não está pronto nem para morrer.

A pergunta que trava tudo nesse ponto é sempre a mesma: começo de novo ou salvo o que tem?

Este artigo é o critério que a gente usa para responder isso. Ele serve para projeto feito em Lovable, Base44, Bolt, v0 ou qualquer outro, porque o problema não é a ferramenta.

O que realmente se aproveita de um projeto de gerador?

Raramente o código. Quase sempre o resto.

Um projeto parado num gerador costuma ter quatro camadas, e elas envelhecem de formas diferentes:

Camada	Costuma aproveitar?	Por quê
Desenho do produto	Quase sempre	Você já descobriu quais telas existem e o que elas fazem
Regras de negócio	Quase sempre	Estão descritas, mesmo que implementadas errado
Dados em produção	Sempre	Migrar dado é trabalho conhecido, não risco
Código	Raramente inteiro	É onde o gerador acumula inconsistência

Isso muda a conversa. “Refazer do zero” dá a impressão de perder tudo, e não é o caso: você perde a implementação e mantém o aprendizado, que é a parte cara de descobrir.

Uma auditoria técnica da SoftDesign em dois projetos Lovable levados para produção pontuou ambos entre 2,0 e 2,5 numa escala até 5,0, com padrões de problema que se repetiam de forma quase idêntica nos dois. Isso sugere característica da ferramenta, não azar de um projeto.

Os sete critérios

Avalie cada um com sim ou não. Eles não têm o mesmo peso, e os três primeiros valem mais que os outros quatro somados.

1. Tem gente usando em produção agora?

Se tem, a decisão muda de natureza. Não se reescreve sistema com usuário dentro sem um plano de transição, e isso é trabalho à parte do desenvolvimento.

2. Tem autenticação, pagamento ou dado pessoal?

Essas três áreas são onde código gerado falha de um jeito que não aparece em teste manual. Permissão mal configurada não quebra a tela: ela deixa um usuário ler o dado de outro, em silêncio, até alguém descobrir.

Se a resposta for sim, o projeto precisa de auditoria antes de qualquer decisão de aproveitar ou refazer.

3. Você consegue subir o projeto num ambiente novo?

Pegue o repositório, clone numa máquina limpa e rode. Se não sobe sem uma sequência de ajustes que só você conhece, não existe projeto: existe uma configuração viva na sua máquina.

4. Existe alguma coisa que ninguém sabe explicar?

Todo projeto de gerador tem um trecho que apareceu, funcionou e ninguém entende. Um é normal. Quando são vários, e eles se cruzam, o custo de mexer cresce mais rápido que o de reescrever.

5. As regras de negócio estão espalhadas ou concentradas?

Abra o cálculo mais importante do sistema — preço, comissão, saldo, o que for. Se ele aparece em três lugares com variações, cada mudança futura vai exigir caçar as três.

6. O quanto o projeto depende de uma ferramenta só?

Alguns geradores acoplam o projeto à infraestrutura deles. Isso é confortável enquanto o projeto é pequeno e vira um problema no dia em que você precisa de algo que a plataforma não oferece.

7. Quanto crédito você já queimou tentando destravar?

Esse é o critério econômico, e ele costuma ser o mais ignorado. Some o que foi gasto nas últimas quatro semanas e compare com a entrega desse mesmo período. Se o gasto sobe e a entrega não anda, o problema não é a próxima tentativa.

Como ler o resultado

• Nenhum ou um “sim” nos critérios 1 e 2, e o projeto sobe em máquina limpa. Reestruturação direta. O código existente serve de referência e boa parte das telas é reaproveitável.
• Sim nos critérios 1 ou 2. Auditoria primeiro. Decidir sem saber o estado de permissão e de dado é decidir no escuro.
• Quatro ou mais “sim” nos critérios 4, 5 e 6. Reescrita do núcleo, mantendo desenho e regras. Tende a sair mais barato que consertar.

Isso quer dizer que gerador de código não presta?

Não. Quer dizer que ele resolve um problema e não resolve outro.

Gerador é excelente para descobrir o que construir. Em dois dias você sai de uma ideia para algo que dá para mostrar a um cliente, e isso é real. O que ele não faz é sustentar o que já está de pé, com gente dentro e dinheiro passando.

São duas etapas diferentes de um projeto, e a segunda nunca foi problema de ferramenta.

Por onde começar se o projeto travou

1. Pare de gerar. Cada tentativa nova acrescenta código ao que já está difícil de entender.
2. Clone o repositório numa máquina limpa e tente subir. Anote tudo que faltou.
3. Rode os sete critérios acima e escreva a resposta de cada um.
4. Se houver usuário, autenticação ou pagamento em produção, trate auditoria como primeiro passo, não como etapa do projeto.
5. Só então decida entre reestruturar e reescrever. A essa altura a decisão costuma ser óbvia.

Nota de transparência. Os critérios acima vêm da prática, mas este artigo ainda não traz a estatística que a gente gostaria de publicar: de quantos projetos avaliados, quantos foram reestruturados e quantos foram reescritos. Quando essa base estiver consolidada, ela entra aqui e a data de atualização muda.