Vibe coding virou dívida técnica? Como identificar antes que chegue à produção

Um tópico no r/ExperiencedDevs sobre o que o autor chamou de "martelo do vibe coding" — a impressão de que toda mudança agora vira geração em massa de código — passou de 700 comentários. Outro, sobre profissionais contratados especificamente para limpar o que a IA deixou para trás, passou de 140 (vibe-coding hammer, AI cleanup).

O volume de comentários importa menos que o padrão. Não é uma discussão sobre se a IA escreve código bom. É sobre o que acontece quando código nasce sem contrato, sem dono e sem revisão estrutural — e é promovido a produção porque rodou sem erro na primeira tentativa.

Vibe coding não é o problema. A ausência de ciclo de vida é

Vibe coding descreve um fluxo: você descreve o que quer, a IA gera, você verifica se "parece certo" e commita. Como técnica de exploração, isso é legítimo e muitas vezes mais rápido que qualquer alternativa. O erro está em tratá-lo como técnica de entrega.

A régua é simples. Três perguntas decidem de que lado você está:

1. Esse código vai sobreviver ao próximo trimestre? Protótipo descartável tem prazo. Sistema em produção não tem.
2. Alguém além de quem gerou vai mexer nisso? Se sim, o código precisa ser legível por outra pessoa, não só executável.
3. Se esse trecho errar, alguém perde dinheiro, dado ou segurança? Se sim, ele precisa de evidência de controle — teste, contrato, dono.

Se as três respostas forem "não", você está em terreno seguro: script local, spike para responder uma dúvida técnica, automação pessoal, exploração de biblioteca, geração de boilerplate seguida de revisão. Se qualquer uma for "sim", você deixou de fazer exploração e passou a fazer engenharia sem os instrumentos da engenharia.

Cinco sintomas que aparecem antes do incidente

1. Código sem dono

Não é código sem autor no git. É código que ninguém além de quem gerou consegue explicar. O sintoma clássico é um módulo com churn alto, autoria concentrada em uma pessoa e ausência de teste ou de documentação mínima. Quando essa pessoa sai de férias, o módulo congela.

2. Regra de negócio implícita

if (status === 7), limiar hardcoded, multiplicador mágico no meio do cálculo. A regra existe, produz efeito financeiro ou regulatório, e não está em nenhum PRD, nenhuma story, nenhum documento de decisão. Ela só vive no código — e foi inventada ali, sem que ninguém tenha aprovado.

3. Duplicação que ninguém junta

Cada tela nova reimplementa a mesma validação. Cada endpoint novo reescreve o mesmo mapeamento. A duplicação exata aparece em densidade mensurável, e o custo não está no tamanho: está em descobrir, seis meses depois, que a regra foi corrigida em três lugares e esquecida em dois.

4. Dependência inventada

Nome de pacote próximo de um popular, instalado sem conferência. É o vetor que a literatura chama de slopsquatting: o modelo alucina um nome plausível, alguém publica um pacote malicioso com esse nome, o build puxa. O sintoma é a distância de edição suspeita entre o nome instalado e o pacote real.

5. Manutenção inexplicável

Erro engolido, catch vazio, teste que executa o caminho mas não afirma nada. Esse último merece nome: test theater. A suíte passa, o relatório fica verde e a cobertura real do comportamento é zero. Foi assim que muita coisa chegou a produção "testada".

A lista de evidências que um diagnóstico precisa procurar

Sintoma sem evidência é opinião. Cada um dos itens acima deixa rastro verificável:

Sintoma	Evidência observável	Onde ela aparece
Código sem dono	churn alto com autoria concentrada; bus factor por arquivo	histórico do repositório
Regra implícita	valor mágico repetido em pontos distintos; regra no código e ausente em documentos	código + documentação vinculada
Duplicação	densidade de clones exatos; LoC redundante	análise estrutural do código
Dependência sósia	nome de pacote próximo de um popular por distância de edição	arquivos de manifesto
Manutenção inexplicável	catch vazio, erro engolido, teste sem asserção	análise estática
Regressão silenciosa	cobertura por imports de teste cruzada com módulos de churn alto	cobertura + histórico
Segredo exposto	chave ou credencial hardcoded, sem valor retido no relatório	varredura de segurança
Migração irreversível	operação destrutiva em DDL, migration sem rollback	schema e migrations

Repare no que essa lista não inclui: uma acusação de autoria. Você não consegue provar que um trecho foi escrito por IA a partir de sinais estruturais — e não precisa. O que importa é se o artefato tem dono, contrato e cobertura. Código escrito à mão com as mesmas características é igualmente perigoso.

O custo chega depois, e chega concentrado

A conta da vibe coding sem ciclo de vida aparece em levantamentos recentes. Uma análise publicada no início de 2026 estimou que, das cerca de 10 mil startups que usaram ferramentas de IA para construir aplicações de produção até o fim de 2025, mais de 8 mil precisaram de reconstrução parcial ou engenharia de resgate até meados de 2026, com custo médio entre US$ 50 mil e US$ 500 mil dependendo do quanto o produto cresceu sobre a base original (Creatr).

Em segurança, a Cloud Security Alliance reportou que 62% das soluções de código gerado por IA analisadas em sua própria pesquisa apresentavam falhas de design ou vulnerabilidades conhecidas, mesmo com modelos de ponta (CSA). A avaliação independente da Checkmarx citada no mesmo estudo colocou a taxa de insegurança ainda mais alta, chegando a 70%. Os modos de falha se repetem: padrões inseguros herdados do treino, atalhos perigosos como eval(), ausência de controle de acesso.

O termo "ressaca do vibe coding" já circulava na imprensa de tecnologia em setembro de 2025, descrevendo o mesmo padrão (Wikipedia). Nada disso é argumento contra a ferramenta. É argumento contra promover exploração a produção sem instrumentos.

O que fazer antes que chegue à produção

Quatro medidas resolvem a maior parte dos casos:

• Prazo de validade explícito para código de exploração. Marque um diretório, um nome e uma data. Código de spike que não vira decisão é apagado, não promovido.
• Contrato mínimo antes do merge em caminho de produção. Um teste que falha se a regra mudar, um dono nomeado no CODEOWNERS, uma linha registrando a decisão. Nada mais que isso.
• Portão de dependências. Nome inventado não entra sem conferência de origem do pacote. Esse é o portão mais barato e o de maior retorno.
• Leitura estrutural periódica. Cobertura, duplicação, churn e complexidade mudam devagar — até não mudarem mais. Uma leitura por trimestre pega o desvio enquanto ele ainda é barato.

Se você precisa responder "esse sistema aguenta o próximo ano?", a pergunta não é filosófica. Ela é respondível com evidência. É o que um diagnóstico de risco associado a código assistido por IA entrega: clones, churn, dependências alucinadas, segredos, test theater e erros engolidos medidos sobre o repositório, cada achado ancorado a arquivo e linha — sem acusar autoria, porque autoria não é o problema. O laudo aponta onde dói e o Kit SDD transforma as prioridades em especificação executável para a equipe corrigir.

Acelerar e entender não são opostos

Vibe coding é uma técnica. Como toda técnica, ela tem um domínio onde funciona e um domínio onde cobra caro. O que separa os dois não é a ferramenta nem o entusiasmo de quem usa: é a existência de dono, contrato e evidência antes do deploy.

A pergunta útil não é "posso usar IA para escrever isso?". É "o que me diz que esse código está sob controle?". Se a resposta for "ele roda", você ainda não tem resposta.