Débito técnico em vibe coding: a conta que cada prompt deixa para depois

Um projeto que nasce num fim de semana com Lovable, Cursor ou Claude Code entrega, quase sempre, a mesma sensação: funcionou rápido demais. A tela carrega, o fluxo principal roda, e a impressão é de que construir software deixou de ser complicado. O que essa sensação esconde é uma conta que já começou a rodar desde o primeiro prompt, só que ela não aparece na tela. Ela aparece semanas depois, quando uma mudança pequena quebra três coisas que pareciam não ter relação nenhuma.

O que é débito técnico quando quem escreve é a IA

Débito técnico não é um conceito novo, mas ele muda de comportamento quando quem escreve a maior parte do código é um modelo de IA respondendo a prompts, em vez de um time humano seguindo um padrão combinado. Em desenvolvimento tradicional, o débito se acumula devagar, porque cada linha custa tempo de alguém pensando antes de escrever. Em vibe coding, o código sai rápido demais para que alguém pare em cada prompt e pergunte se aquela solução é a certa ou só a que funcionou primeiro. O resultado é o mesmo tipo de dívida, só que crescendo numa velocidade que ninguém no time está acostumado a acompanhar.

A conta, prompt a prompt

Um cenário típico, hipotético, ajuda a ver como essa conta cresce. Imagine uma empresa que decide montar, em seis semanas, um sistema interno de gestão de pedidos usando uma ferramenta de vibe coding, sem ninguém do time com histórico em engenharia de software revisando o que sai de cada prompt.

Semana 1: a conta parece zerada

O primeiro protótipo nasce em poucos dias. Cadastro de pedido, lista, status. Cada prompt novo resolve um problema visível na hora, e o custo de qualquer decisão de arquitetura errada ainda é baixo, porque existe pouco código para corrigir depois. Essa é a fase que engana: dá a impressão de que a velocidade da semana 1 é a velocidade normal do projeto, e vai continuar sendo essa daqui para frente.

Semana 3: a conta começa a aparecer

A mesma regra de negócio, como o cálculo do prazo de entrega, já foi escrita em três lugares diferentes do código, porque cada prompt que precisou dela gerou sua própria versão em vez de reaproveitar a que já existia. Não existe teste automatizado nenhum, então toda mudança precisa ser conferida na mão, clicando na tela até garantir que nada quebrou. O tempo para adicionar uma função pequena já não é o mesmo da semana 1, mas ainda é fácil não perceber, porque o time atribui a lentidão a estar ocupado, não à dívida que já está acumulada.

Semana 6: a conta chega

Um pedido de mudança simples, mudar uma regra de desconto, exige alterar código em quatro arquivos diferentes, e um deles quebra sem ninguém entender por quê, porque uma versão antiga da mesma regra continuava ativa em outro fluxo. Nesse ponto, o tempo para entregar algo pequeno já é maior do que era na semana 1, mesmo com o time mais familiarizado com a ferramenta. É o momento em que a frase mais comum na reunião vira: melhor não mexer nisso agora, porque a gente não sabe o que mais quebra junto.

Os números de tempo e de semanas aqui são ilustrativos, um cenário típico para exemplificar a curva, não uma promessa de prazo. O que se repete de projeto para projeto não é o número exato, é o formato da curva: rápido no início, mais lento a cada prompt novo, até a velocidade despencar de vez.

Os sinais de que a conta já está alta

• Uma mudança pequena quebra algo em outra parte do sistema que parecia não ter relação nenhuma com o que foi alterado.
• Ninguém no time consegue explicar, sem abrir o código, onde uma regra de negócio específica está implementada.
• A mesma lógica existe copiada em mais de um lugar, porque foi mais rápido pedir de novo do que reaproveitar o que já tinha.
• Pedir para a IA corrigir um erro cria, com frequência, um erro novo em outro ponto do sistema.
• O time evita mexer em partes do sistema que já funcionam, com medo de derrubar algo, mesmo sem saber ao certo o quê.

Por que isso acontece mais rápido quando quem constrói é a IA

Ferramentas de vibe coding são otimizadas para produzir um resultado visível rápido, não uma arquitetura correta. Cada prompt resolve o problema descrito naquele momento, sem necessariamente considerar tudo o que já existe no restante do código, porque o modelo não carrega, por padrão, um mapa completo de todas as decisões tomadas nos prompts anteriores. Isso não é falha da ferramenta, é a natureza dela: ela é boa em gerar solução pontual, não em manter coerência de longo prazo sozinha. Quando ninguém revisa com esse olhar, a coerência simplesmente não existe, e cada prompt novo aumenta a distância entre o que o sistema deveria ser e o que ele de fato é.

Como interromper a conta sem parar de construir

A resposta não é parar de usar IA para construir, nem jogar fora o que já existe. Na maioria dos casos que vemos, o código funciona e resolve o problema real, só precisa de uma fundação em volta dele antes de crescer mais. Essa fundação tem nome, harness, e não é um projeto de meses: é um conjunto pequeno de proteções mecânicas que barram o erro antes dele se acumular.

• Testes automatizados nos fluxos que não podem quebrar, para que uma mudança nova avise antes de virar incidente, não depois.
• Revisão de código antes de cada deploy em produção, mesmo que curta, para pegar a regra duplicada antes dela virar três.
• Um padrão mínimo de arquitetura documentado, para que o próximo prompt reaproveite o que já existe em vez de reinventar.
• Ambiente de teste separado do de produção, para que a dívida apareça ali antes de chegar no cliente.

Nenhuma dessas proteções exige refazer o projeto do zero. Exige alguém que já viu essa curva de perto o suficiente para saber onde ela costuma quebrar primeiro, e instalar a proteção ali antes que o time sinta o problema batendo à porta.

Se o seu time já sente que cada mudança pequena demora mais do que devia, ou já perdeu a conta de quantas vezes a mesma regra foi reescrita, vale mapear isso antes que a conta fique maior. Nosso diagnóstico gratuito do projeto de IA em /construa-com-ia dura 45 minutos com um engenheiro e devolve o mapa de onde está a dívida no seu código hoje, sem compromisso de contratar nada.