Quando o vibe coding deixa de compensar: uma regra prática para parar

Você corrige o login e os pagamentos param de funcionar. Corrige os pagamentos, e o erro de login volta. Um prompt mais longo pode não quebrar esse ciclo. Antes de pedir outra alteração, verifique se a falha está se repetindo e se o comportamento relacionado está coberto por testes.

Não há um ponto fixo em que o Vibe Coding 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 uma pessoa conseguirá necessariamente construir o aplicativo inteiro sozinha. Significa apenas que os erros continuam reversíveis. A mesma aplicação CRUD muda de categoria 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 é muito visível: as telas aparecem e o fluxo principal começa a funcionar. Nas etapas seguintes, surgem as conexões entre recursos, os caminhos de erro, os dados legados, os testes, as regras de segurança e as restrições de implantação. A quantidade de recursos visíveis pode quase não mudar enquanto o número de limites a verificar cresce rapidamente.

A quantidade de conversas e código colocados no contexto de um modelo de IA também importa. A Anthropic usa o termo 'degradação do contexto' para descrever a forma como a capacidade do modelo de recuperar informações com precisão pode diminuir à 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 é mal delimitada e decisões anteriores são mais fáceis de ignorar.

O que parece uma parede súbita perto do fim 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 buscar ajuda

As correções entram em um ciclo

Alterar A quebra B, e ao reparar B, A quebra novamente. Congele os passos de reprodução e os testes antes de solicitar outra correção. O sinal importante não é que o bug tenha existido 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 com base na interface. Se não há testes — ou se existem logs, mas ninguém pode usá-los para avaliar a segurança — a lacuna de verificação é maior do que a lacuna de implementação. Uma revisão de código ou segurança focada 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. 'Entregar agora, corrigir depois' agora carrega um custo diferente. Revisão pré-lançamento, backups, rollback e monitoramento agora pertencem ao escopo.

Contrate uma revisão pontual, não o desenvolvimento inteiro

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 uma ferramenta de IA e a um desenvolvedor o mesmo ponto de partida.

Em seguida, delimite bem o pedido:

• revise apenas a autenticação e a autorização por usuário
• revise apenas as solicitações de pagamento e o processamento de webhooks
• revise apenas as configurações de implantação, as chaves de API e as variáveis de ambiente
• escreva testes para o recurso que sempre volta a falhar

“Concluir meu app” é um pedido difícil de orçar e de verificar. Quando a área afetada e os critérios de aceitação estão bem definidos, fica mais fácil comparar propostas e resultados. Inclua no escopo a repetição dos mesmos testes depois da correção.

Registre quatro coisas antes do próximo prompt

Mesmo que você ainda não esteja entregando o projeto, escreva:

1. o caminho exato de clique e o estado da conta que reproduz o bug
2. o último commit que funcionava corretamente
3. os arquivos que a IA alterou e por quê
4. os testes que devem passar após a próxima alteração

Esse registro evita que a equipe redescubra o mesmo problema e revela se uma correção reverteu silenciosamente outro recurso. O limite do vibe coding não é uma linha que manda abandonar a ferramenta. É o ponto em que verificação e operação passam a importar mais do que gerar outro patch.