"Por que \"refaz tudo do zero\" é o conselho mais caro que dão pra quem travou"

"Se entrar em 'loop' (não consegue resolver um passo), salve, feche a sessão e comece uma nova do zero... o contexto ('memória do LLM') às vezes fica 'contaminado' e não consegue avançar."

Esse conselho é de um usuário do TabNews (LLM é o modelo de IA que escreve o código; contexto é tudo que já foi dito na conversa), e ele está certo. Eu já escrevi aqui por que sessão nova é o conserto do loop: cada tentativa errada fica no histórico da conversa, e a IA passa a raciocinar em cima do próprio erro. Fechar e abrir outra conversa limpa isso.

O problema é o que acontece com esse conselho quando ele passa de boca em boca. "Começa uma sessão nova do zero" vira "começa do zero". E aí alguém que travou na terceira semana apaga o projeto, abre um novo, cola a ideia de novo e pede tudo outra vez.

É um conselho de sessão sendo usado como conselho de projeto. E, no projeto, ele é caro.

Por que a vontade de apagar faz sentido

Não é preguiça nem falta de persistência. Refazer parece limpo. O app de agora tem remendo em cima de remendo, você não sabe mais o que mexeu onde, e o primeiro dia de um projeto novo foi rápido e bonito. A lembrança é boa.

Só que o primeiro dia foi rápido porque era o primeiro. Banco vazio, um usuário só, nenhuma regra antiga pra respeitar. O mês 1 é o mais fácil da vida de qualquer app. Refazer não te devolve a um app melhor. Te devolve ao dia 1, e o dia 21 vai chegar de novo.

O que "do zero" joga fora

Os dados. Esse é o que mais dói e o que menos se vê. A documentação do Lovable é explícita sobre o que acontece quando você copia um projeto (o "remix"): "segredos e dados do banco nunca são copiados". Segredos são as chaves que ligam o app a pagamento, e-mail e outros serviços. Dados são os cadastros. Se já tem gente usando, o projeto novo nasce sem essa gente.

O histórico. A mesma página avisa que o remix não copia o histórico de versões. Todo ponto marcado, todo "funcionava aqui", some. Você perde justamente a ferramenta que resolveria o problema sem refazer nada.

As correções que você já fez. Nas últimas semanas você achou erro, pediu conserto, conferiu. Cada uma dessas correções virou uma regra dentro do código: o desconto que não pode passar de 20%, o campo que é obrigatório, o total que conta o frete. No projeto novo, a IA não lembra de nenhuma. Você vai descobrir de novo, uma por uma, provavelmente pelo cliente.

E a causa continua lá. O app quebrou porque o pedido era grande demais, ou porque não tinha ponto de retorno, ou porque ninguém conferiu antes de aceitar. Nada disso está no código. Está no jeito de pedir. Refazer com o mesmo jeito dá o mesmo app quebrado, três semanas depois.

Repara no que faz quem é pago pra consertar. Um dev brasileiro, contratado pra arrumar um sistema feito com IA que estava caindo, descreveu assim o trabalho: "organizando a arquitetura, criando testes, padronizando o código e corrigindo a base". Ele não apagou. Reformou em cima.

Antes de apagar qualquer coisa: a triagem de 30 minutos

Pega uma folha e divide em três colunas: funciona, quebrou, nunca existiu.

1. Feche a conversa e abra outra. Essa parte do conselho está certa, e vem primeiro. Mas no mesmo projeto.
2. Liste o que o app faz, em frases curtas: cadastrar conta, entrar, criar pedido, editar pedido, ver a lista, pagar. De cinco a dez linhas.
3. Teste cada linha e ponha na coluna certa. Abra o app, faça, anote. Sem consertar nada ainda. A maioria das pessoas descobre aqui que a coluna "funciona" é bem maior do que o desespero dizia.
4. Para cada item de "quebrou", ache a última versão em que ele funcionava. No Lovable, abra o histórico (botão History na barra de cima) e volte versão por versão até achar. Se o código já está com você, a lista de pontos do git faz o mesmo. Achou? Volte pra ela com Revert, e marque essa versão com o favorito (Bookmark).
5. Lembre do que a volta não desfaz. A documentação do Lovable diz que reverter restaura só o código, não os dados do banco. Se a IA mudou a estrutura de uma tabela depois daquela versão, confira o item de novo depois de voltar. (O porquê está aqui.)
6. Refaça só o que se perdeu, em fatia pequena. Um item por vez, no formato de pedido cercado, conferindo a coluna "funciona" inteira depois de cada um.

No fim, o que você refez foi o pedaço que quebrou. O resto continua, com os dados e com o histórico.

Quando refazer é a resposta certa

Existe, e eu prefiro dizer. Se a coluna "funciona" ficou vazia, o banco não tem nenhum dado de gente de verdade e o projeto tem poucos dias, refaça. Não tem nada pra proteger.

Mas refaça levando a folha. A lista do que o app precisa fazer vira o primeiro pedido, dividido em fatias. As regras que você descobriu no caminho vão escritas antes, não redescobertas depois. Refazer sem levar isso é pagar o mesmo aprendizado duas vezes.

O que essa parede tinha do lado

A triagem resolve o travamento de hoje. Mas repara no que ela usou: um histórico de versões que alguém marcou, pedidos pequenos, uma lista do que precisa funcionar e alguém conferindo antes de aceitar. Se essas peças já estivessem de pé, você nem teria pensado em apagar.

Elas têm ordem. Ponto de retorno antes da próxima mudança, fatia pequena antes de pedido grande, prova antes de aceitar. Quem monta nessa ordem trava igual, mas volta pra ontem em um minuto em vez de voltar pro dia 1.

Fontes

• Lovable — FAQ (remix: não copia histórico de versões; "segredos e dados do banco nunca são copiados"): https://docs.lovable.dev/introduction/faq
• Lovable — Revert and restore your project with version history (reverter restaura só o código, não os dados do banco; favoritos em Bookmark): https://docs.lovable.dev/features/projects/history
• As falas do usuário Oletros e do dev contratado pra consertar o sistema estão na pesquisa de dores deste blog, coletada em fóruns brasileiros (TabNews e outros) em 2025 e 2026 (são relatos de pessoas, não estatística).