Em 2019, entrei numa empresa remota e encontrei os desenvolvedores subindo arquivo direto no servidor de produção. Sem staging, sem pull request, arquivo sobrescrito no meio do deploy. Arrumar aquele pipeline cortou os erros de deploy pela metade e me ensinou a cara que a dívida técnica tem quando finalmente chega a hora de pagar.
O vibe coding produz a mesma dívida, mais rápido, e com um agravante: desta vez ninguém entende o código, porque ninguém escreveu. Esse é o problema central, e a solução é disciplina de processo, chata mesmo, aplicada antes de o código virar sítio arqueológico.
O que é dívida técnica em vibe coding?
Dívida técnica em vibe coding é o custo acumulado de colocar em produção código gerado por IA que funciona, mas que ninguém do time entende. Tirando o barulho, vibe coding é pedir as coisas a um assistente de IA, aceitar o resultado que roda e seguir em frente sem conferir como aquilo se encaixa no resto do sistema. A dívida aparece como lógica duplicada espalhada em vários arquivos, testes que cobrem só o caminho feliz que o modelo resolveu escrever e funcionalidades que ninguém consegue alterar com segurança.
A dívida técnica clássica era uma troca consciente. O desenvolvedor sabia que o atalho era feio, pegava mesmo assim pra cumprir o prazo e conseguia apontar pra ele depois. A dívida do vibe coding cresce invisível, num código que parece limpo, passa no CI e não carrega nenhuma memória da empresa.
Digo isso como alguém que põe código gerado por IA em produção toda semana. Documentei os meus próprios experimentos com vibe coding neste site, e eles funcionam. Funcionam porque um humano com 25 anos de cicatriz revisa cada linha antes do merge. Tire essa etapa e as mesmas ferramentas produzem um resultado bem diferente.
Quão ruim é? Os números de 2026
Os dados deixaram de ser ambíguos faz tempo. A pesquisa "Maintainability Gap" de 2026 da GitClear, que analisou mais de 600 milhões de commits, encontrou a duplicação de blocos de código 81% acima de 2023, as linhas movidas em refatoração 70% abaixo e a manutenção de código antigo 74% abaixo. Hoje um desenvolvedor tem umas cinco vezes mais chance de colar um bloco redundante do que de consolidar um. Em 2022, antes de os assistentes de IA dominarem, a preferência era de dois pra um no sentido contrário.
A pesquisa DORA do Google já apontava pro mesmo lado antes: cada aumento de 25% na adoção de IA veio junto com uma queda de 7,2% na estabilidade das entregas. Pesquisadores da Carnegie Mellon acompanharam 807 repositórios open source depois da adoção do Cursor e encontraram a complexidade uns 41% maior e os avisos de análise estática cerca de 30% maiores, enquanto os ganhos de velocidade do começo sumiam.
O meu achado preferido é o psicológico. A Sonar entrevistou 1.149 desenvolvedores em 2026: 96% disseram que não confiam totalmente em código gerado por IA, mas só 48% sempre conferem antes do commit.
Ou seja: metade da indústria está fazendo merge de código em que não confia e que não leu.
Por que dívida de compreensão é pior que a clássica
A dívida do vibe coding é dívida de compreensão, e compreensão é a única coisa que não dá pra recuperar depois com refatoração. Quando uma pessoa escreve código, acontece algo junto com a digitação: ela simula os casos extremos e lembra por que a última tentativa falhou. É esse modelo mental que permite ao time manter o sistema no segundo ano.
A geração por IA pula a construção desse modelo por inteiro. Você recebe um resultado sintaticamente correto e cego pro contexto. O modelo nunca ouviu falar da sua API interna descontinuada nem do motivo de o módulo de pagamentos ter aquela estrutura. Então ele escreve a quinta implementação de uma função que já existe em quatro lugares, e todo mundo que revisa acha que "está ótimo".
Seis meses depois alguma coisa quebra, e o time está escavando uma caixa-preta que, tecnicamente, ele mesmo colocou em produção. Já escrevi sobre por que demos de IA falham em produção, e esta é a versão da mesma falha no nível do código. A demo foi o merge. Produção é tudo o que vem depois.
Como evitar dívida técnica no vibe coding
A solução é processo, e o processo é simples de propósito. Um punhado de práticas segura a maior parte do estrago.
Dê contexto real à IA antes de ela gerar. Um modelo com acesso aos seus módulos, aos seus padrões de código, ao histórico da arquitetura e à lista do que foi descontinuado produz código que se encaixa. Na prática, isso quer dizer um CLAUDE.md (ou equivalente) bem mantido, com as instruções e apontando pros módulos que já resolvem o problema. Dez minutos de contexto economizam horas caçando duplicação. O meu post de fluxos de WordPress com Claude Code mostra como eu estruturo isso em trabalho com plugins e temas.
Revise sempre como se fosse o PR de um dev júnior. Trate toda mudança gerada como o pull request de um júnior talentoso que digita rápido e nunca viu o seu código. Isso quer dizer ler o diff de verdade e recusar a versão de 500 linhas do que deveria ter sido uma mudança de 80. Se o volume de código gerado passa da sua capacidade de revisar de verdade, o certo é gerar menos, por mais impopular que isso soe num planejamento de sprint.
Dê um dono humano a toda funcionalidade gerada. Alguém com nome e sobrenome, que consiga explicar o código numa reunião sem abrir o arquivo e que responda quando aquilo quebrar de madrugada. Se ninguém no time topa ser dono de um pedaço de código gerado, esse código não tem nada que fazer em produção. Essa regra sozinha mata a maior parte da dívida do vibe coding antes de ela nascer.
As ferramentas que você já tem cobrem tudo isso.
Onde entra um consultor
A maioria dos pedidos de consultoria de CTO fracionado que eu recebo em 2026 cai em dois grupos, e os dois são dívida de vibe coding com roupas diferentes.
O primeiro é o MVP herdado. Um fundador fez o produto no vibe coding, ganhou tração, e agora clientes de verdade dependem de um código que ninguém consegue estender. O trabalho de auditoria é mapear a duplicação e montar um plano de pagamento com prioridades, em vez da reescrita desesperada que o time acha que precisa.
O segundo é a agência ou o time que adotou ferramentas de IA há seis meses e está vendo a estabilidade se corroer exatamente como o DORA previu. Ali o trabalho é de processo, o mesmo raciocínio de pipeline que eu apliquei na Green Hat: ambientes separados, etapas de revisão, regras de responsabilidade e infraestrutura de contexto, pra que as ferramentas de IA parem de gerar código incoerente com o resto do sistema. Quando o problema é mais fundo que uma fila de revisão, costuma ser sinal de que o time precisa de um CTO fracionado, e não de mais uma contratação sênior que vai herdar o mesmo processo quebrado.
A árvore de decisão é curta. Se o seu time entende o próprio código, continue entregando e aplique as práticas acima. Se não entende, pare de aumentar a velocidade de geração e resolva a compreensão primeiro, com ou sem ajuda de fora.
Se você está diante de um código feito no vibe coding que funciona e que ninguém do seu time consegue explicar, esse trabalho de auditoria e de pagamento da dívida costuma rodar como um projeto de CTO fracionado. Traz o repositório, que eu levo as perguntas.