Lovable em loop e sem corrigir o erro: o que fazer
Quando o Lovable ou o Bolt corrige uma coisa e quebra outra, pare de pedir a mesma correção. Volte à última versão que funcionava, isole o erro, leia o log e investigue num modo que não mexe no código. Se o erro volta mesmo assim, leve o código para o GitHub e peça a alguém que leia o código.
Recomendação da Heartscale: depois de duas tentativas sem resultado, reverta para a última versão boa, marque-a no histórico e ligue o GitHub antes de pedir outra correção. Se o erro envolve login, pagamento ou dados do banco, peça a alguém que leia o código antes da próxima mudança.
Cada tentativa custa crédito, e repetir o mesmo pedido raramente muda o resultado. Os passos abaixo usam os recursos que as próprias plataformas documentam.
Por que a IA entra em loop
Quatro causas costumam aparecer juntas.
A memória da IA tem limite. A documentação do Bolt chama isso de janela de contexto: a memória de trabalho que reúne os arquivos do projeto e tudo o que você mandou no chat (Managing project context). Quando ela enche, o Bolt mantém só as mensagens recentes e pode esquecer as antigas. A doc avisa que um contexto grande demais pode gerar erros, respostas mais lentas e resultados piores.
Código repetido. Em vez de corrigir uma função, a IA às vezes escreve uma segunda versão dela em outro arquivo. A correção entra numa cópia, e o erro continua na outra. O Bolt recomenda apagar arquivos sem uso e quebrar arquivos com mais de umas 700 linhas, testando a cada mudança.
Falta de testes. Sem teste automatizado, nada avisa que a correção de hoje quebrou a tela de ontem. Você só descobre clicando, e a IA também.
A causa está fora do código que a IA mexe. Um segredo faltando, uma política do banco que bloqueia a gravação ou um serviço externo fora do ar geram erro na tela. A IA reescreve a tela, e o erro continua. O erro “new row violates row-level security policy” é um exemplo comum. O guia RLS no Supabase explica como resolver.
Passo 1: pare na segunda tentativa
Se a mesma correção falhou duas vezes, a terceira tende a repetir o caminho. Conte o custo antes de insistir:
- Lovable: o botão Try to fix aparece no cartão de atividade quando há erro de build. A conta tem 10 correções grátis, compartilhadas com as da área de segurança, e cada uma volta 24 horas depois do uso. Depois disso, o Try to fix consome créditos (Troubleshooting).
- Bolt: cada tentativa automática gasta tokens. O Bolt orienta a não clicar em Attempt fix várias vezes e a investigar o erro quando as correções automáticas não resolvem (Maximizing token efficiency).
Passo 2: volte à última versão que funcionava
O Bolt recomenda usar o histórico em vez de pedir à IA que desfaça uma mudança. No Lovable, o caminho é o mesmo.
No Lovable (Version history):
- Clique em History na barra superior, ou no menu ao lado da caixa de mensagem, em Project → History.
- Clique numa versão para ver como ela estava, sem alterar o projeto. Back to latest volta para a atual.
- Ache a última que funcionava e clique em Revert. Confirme.
Há atalhos no chat (Chat). Undo latest edit, abaixo da última resposta, desfaz a mudança mais recente. Edit message, numa mensagem sua, abre Revert and resend: o projeto volta ao estado antes daquela mensagem e roda o pedido reescrito.
Três avisos da documentação:
- reverter restaura o código e publica de novo as Edge Functions, mas não desfaz dados do banco. Registros criados e migrações rodadas depois daquela versão continuam lá;
- reverter não devolve créditos;
- versões muito antigas mostram “Cannot revert this far back in history”.
Quando chegar a uma versão boa, marque com Bookmark in history. Ela vira o seu ponto seguro.
No Bolt (Rollback and backup): abra Version history (ícone de relógio), clique na versão, depois em Restore this version e confirme em Restore version. A doc diz que restaurar não muda os bancos do Bolt nem do Supabase, e que o histórico restaura sem gastar tokens.
Passo 3: investigue sem deixar a IA mexer no código
Os dois construtores têm modos que conversam sem alterar arquivos.
Lovable: no seletor ao lado da caixa de mensagem (ou com Alt+P), escolha:
- Chat, para discutir o app. Cada mensagem custa em geral uma fração de crédito e usa primeiro a cota diária de chat;
- Plan, para investigar e escrever um plano que você aprova antes de qualquer código. Cada mensagem custa um crédito, mais a pesquisa que ele fizer, e a doc diz que o Plan nunca altera o código (Plan mode).
Bolt: clique em Plan, no canto inferior direito da caixa de mensagem. Quando o plano estiver certo, Implement this plan passa para o modo de construção (Plan Mode). Se o Bolt travar ou parar de responder, digite /clear e clique em Clear context. Isso limpa a memória da conversa e mantém os arquivos.
Uma pergunta útil nesses modos: “Liste os arquivos que tratam disso e diga se há código duplicado”. Ela expõe a causa do loop antes de qualquer mudança.
Passo 4: isole o erro e leia o log
A IA corrige melhor quando recebe o erro exato. Antes do próximo pedido, junte:
- O texto do erro, copiado, sem resumo.
- Os passos para fazer o erro aparecer: qual tela, qual botão, qual usuário.
- O esperado e o que aconteceu.
- Desde quando: a primeira versão do histórico em que o erro aparece.
Onde achar o log:
- Console do navegador: CTRL+SHIFT+I no Windows ou CMD+OPTION+J no macOS, na aba Console. O Bolt sugere pedir à IA que acrescente logs de depuração, reproduzir o erro numa aba separada e colar o resultado no chat (Troubleshooting).
- Lovable Cloud: no menu More da barra do projeto, abra Logs (Lovable Cloud).
- Imagem: no Lovable, Take a screenshot e Draw marcam o ponto exato na tela.
Trate um problema por vez, descrito numa mensagem completa. O Lovable recomenda juntar num só pedido o que seriam várias mensagens rápidas seguidas.
Passo 5: leve o código para o GitHub
Com o código no GitHub, cada mudança da IA vira um commit com o que mudou, linha a linha. Você sabe o que mudou entre a versão boa e a quebrada, e outra pessoa consegue ler e rodar o projeto fora da plataforma.
- Lovable: Project settings → Git → GitHub, depois Connect. O Lovable cria um repositório novo, privado por padrão, e sincroniza nos dois sentidos, um branch por vez (GitHub).
- Bolt: clique no ícone do GitHub no canto superior direito, em Log in to GitHub e em Install & Authorize. O Bolt faz commit das mudanças e busca alterações do GitHub a cada 30 segundos (GitHub).
Ligue o GitHub antes do próximo erro. Ele guarda a história que o chat não mostra.
Na nossa revisão, abrimos no GitHub a diferença entre a última versão boa e a primeira com o erro. Nesse trecho procuramos função duplicada, segredo faltando e política do banco que bloqueia a gravação.
Quando chamar quem revisa código
Se os passos acima não resolverem, chame alguém para ler o código. Os sinais:
- o erro volta depois de reverter e pedir de novo, com o erro exato;
- a falha envolve login, pagamento ou dados pessoais;
- a correção exige mudar o banco, e reverter não desfaz dados;
- ninguém sabe mais o que cada parte do código faz.
Se o problema parece estar na própria plataforma, o Lovable indica o suporte em lovable.dev/support para planos pagos. Para o código do seu app, o caminho é uma revisão. Veja também O Lovable é seguro? para os riscos que costumam aparecer junto.
Fazer sozinho ou contratar?
Você pode seguir os passos 1 a 5 sem ajuda técnica. A tabela resume quando vale chamar uma equipe.
| Situação | Caminho |
|---|---|
| Erro novo, numa tela, e a volta para a versão boa resolve | Siga os passos 1 a 5 e marque essa versão no histórico |
| O mesmo erro volta depois de reverter e pedir de novo com o texto exato | Chame alguém para revisar o código no GitHub |
| A falha envolve login, pagamento ou dados pessoais | Pare de insistir no chat e peça uma revisão antes da próxima publicação |
| O app tem usuários reais, a correção mexe no banco e ninguém do time lê o código | Peça o diagnóstico da Heartscale |
Peça o diagnóstico da Heartscale
A IA levou o seu app até onde pôde. Nossa equipe lê o código no GitHub, acha a causa do loop e lista o que precisa mudar, por gravidade e com o preço de cada correção. Veja o serviço de revisão de código gerado por IA. Não prometemos prazo antes de ler o código.
O diagnóstico de lançamento custa R$ 99 (de R$ 398) e é abatido se você fechar a correção. Só trabalhamos em app de quem prova ser dono.