Você corrige o login e os pagamentos quebram. Você restaura os pagamentos e o bug do login volta. Um prompt mais longo pode não resolver esse ciclo. Antes de pedir por outra alteração, verifique se o problema está se repetindo e se o comportamento relacionado está coberto por um teste.
Não há um ponto fixo em que o código no estado de vibração deixa de funcionar. A resposta depende do produto, do seu risco e do estado do código. Os sinais que indicam a necessidade de um método de trabalho diferente são muito mais fáceis de identificar.
Avalie pelo custo da falha, não pelo número de recursos
Mockups, protótipos descartáveis e ferramentas internas usadas por uma equipe pequena podem absorver tentativa e erro. Ferramentas de IA também podem assumir grande parte de uma aplicação CRUD quando seus requisitos são claros e seu comportamento é testável.
Isso não significa que a aplicação vá se construir sozinha. Isso significa que um erro permanece reversível. A mesma aplicação CRUD se torna uma proposta diferente quando armazena dados pessoais ou atende clientes pagantes.
O risco pode superar o produto visível
Uma tela funcional não é suficiente uma vez que o produto inclui:
- Pagamentos: O servidor deve calcular valores, verificar assinaturas de webhook e evitar processamento duplicado de eventos.
- Dados pessoais: A autenticação é apenas o começo. Autorização por usuário, retenção, exclusão e resposta a incidentes também importam.
- Usuários simultâneos: Duas pessoas alterando os mesmos dados podem criar conflitos e estado inconsistente.
- Dependências operacionais: Implantação, monitoramento, backups e recuperação são disciplinas diferentes da implementação de recursos.
Serviços gerenciados reduzem o código que você precisa escrever. Eles não assumem todas as responsabilidades pelos seus dados, controle de acesso ou configuração da aplicação; a Supabase descreve isso explicitamente em seu modelo de responsabilidade compartilhada.
O último trecho não é um percentual fixo
O trabalho inicial é altamente visível: telas aparecem e o fluxo principal começa a funcionar. O trabalho posterior expõe as junções entre recursos, caminhos de erro, dados legados, testes, regras de segurança e restrições de implantação. O número de recursos visíveis pode quase não mudar enquanto o número de limites que você precisa verificar cresce rapidamente.
A quantidade de conversa e código colocada no contexto de um modelo de IA também importa. A Anthropic usa o termo “rotacao de contexto” para descrever a forma como a capacidade do modelo de recuperar informações com precisão pode declinar à medida que mais tokens entram no contexto. Não há um limiar universal de arquivos. O risco prático aumenta quando arquivos não relacionados e conversas longas enchem o contexto, ou quando a alteração pretendida está mal delimitada e decisões anteriores são mais fáceis de ignorar.
O que parece uma parede súbita perto do final muitas vezes é algo diferente: o número de conexões que exigem verificação começou a crescer mais rápido do que o número de recursos restantes para implementar.
Três sinais de que é hora de parar e pedir ajuda
As correções continuam se repetindo
Mudar A quebra B, então reparar B quebra A novamente. Congele os passos de reprodução e os testes antes de solicitar outra correção. O sinal importante não é que o bug existiu por um certo número de dias; é que cada tentativa de correção falha nas mesmas verificações de regressão.
Você não consegue dizer se o resultado está correto
Autenticação, autorização, pagamentos e recuperação de dados não podem ser julgados apenas pela interface do usuário. Se não há testes — ou logs existem, mas ninguém pode usá-los para avaliar a segurança — a lacuna de verificação é maior que a lacuna de implementação. Uma revisão de código ou segurança bem delimitada pode ajudar aqui.
Uma falha afetaria alguém mais
O produto agora lida com dinheiro real de clientes ou dados, ou uma interrupção afetaria a receita. “Entregue agora, corrija depois” agora carrega um custo diferente. Revisão pré-lançamento, backups, rollback e monitoramento agora pertencem ao escopo.
Interrompa o loop de Try to Fix antes de gastar mais créditos
Os comandos Try to Fix e Attempt Fix são úteis quando expõem e reparam um erro específico. Eles se tornam caros quando cada tentativa modifica código irrelevante e cria uma nova falha.
Use essa regra de parada:
- Após duas tentativas automáticas de correção sem sucesso para o mesmo sintoma, pare o agente.
- Salve o erro exato, os passos de reprodução e a lista de arquivos alterados.
- Restaure o último checkpoint que passou pela interação principal.
- Use o Chat ou o modo Plan para pedir a causa raiz sem editar o código.
- Aprove uma alteração limitada, depois execute a mesma verificação antes de fazer qualquer outra coisa.
Rollback não é prova de que o bug foi resolvido; ele restaura uma base conhecida. A próxima tentativa só tem sucesso quando a reprodução original para de falhar e o comportamento anteriormente funcional ainda passa.
Se a ferramenta não pode explicar uma alteração limitada, exporte ou sincronize o código e peça uma revisão limitada. Não gaste mais créditos pedindo ao mesmo agente para reescrever toda a funcionalidade novamente.
Você pode terceirizar uma revisão limitada em vez de toda a aplicação
Pause o trabalho de recursos e preserve a versão atualmente funcional. Coloque os passos de reprodução, resultado esperado, resultado real e logs relevantes em um documento. Isso dá a um agente de IA e a um desenvolvedor o mesmo ponto de partida.
Em seguida, faça a solicitação pequena:
- revisão apenas da autenticação e autorização por usuário
- revisão apenas dos pedidos de pagamento e processamento de webhooks
- revisão apenas das configurações de implantação, chaves de API e variáveis de ambiente
- escreva testes para o recurso que volta a falhar
‘Concluir meu app’ é difícil de precificar e difícil de verificar. Uma solicitação com uma área bem delimitada e critérios de aceitação facilita a comparação de propostas e resultados. Inclua a reexecução dos mesmos testes após a correção no escopo do trabalho.
Registre quatro coisas antes do próximo prompt
Mesmo que você ainda não esteja entregando o projeto, escreva:
- o caminho exato de cliques e o estado da conta que reproduz o bug
- o último commit conhecido como funcionando
- os arquivos que a IA alterou e por quê
- os testes que devem passar após a próxima alteração
Esse registro evita que a equipe repita a descoberta do problema e mostra se uma reparação silenciosamente reverte outro recurso. O limite do código no estado de vibração não é uma linha que te avisa para abandonar a ferramenta. É o ponto em que a verificação e as operações importam mais do que produzir outra correção.