A dívida técnica nova: código que você não escreveu

Dívida técnica sempre teve uma característica que a tornava administrável: alguém, em algum momento, entendeu o código. A pessoa que tomou o atalho sabia por que tomou. Código gerado por IA em volume quebra essa premissa, e é isso que torna a dívida nova diferente da antiga.

O quadrante que explica a diferença

Martin Fowler propôs olhar dívida técnica em dois eixos: ela foi contraída de forma deliberada ou inadvertida, e de forma prudente ou imprudente. Isso dá quatro combinações, e a mais saudável é a deliberada e prudente: "sabemos que esse desenho é limitado, escolhemos entregar agora e anotamos o custo".

Geração em massa por IA tende a produzir um tipo específico: inadvertida e, pior, em escala. Ninguém decidiu contrair a dívida, porque ninguém formou o modelo mental que permitiria perceber que estava contraindo.

Dívida de compreensão

Vale nomear isso separadamente. O custo dominante não é o código estar errado, é ninguém no time saber por que ele está daquele jeito.

Sintomas típicos aparecem algumas semanas depois:

• Um bug simples leva um dia porque ninguém entende o caminho.
• A refatoração é evitada porque o risco é desconhecido.
• Perguntas de review viram "acho que o modelo fez assim porque...".

Esse custo não aparece em nenhuma métrica de cobertura ou complexidade. Aparece no tempo de resolução de defeito, meses depois, quando quem poderia explicar já mudou de time ou de empresa.

O detalhe cruel é que a dívida de compreensão cresce em silêncio. Enquanto o sistema funciona, nada sinaliza o problema, e a descoberta acontece no pior momento possível: durante um incidente, com pressa.

A lição que sistemas de ML já tinham ensinado

Em 2015, um trabalho influente do Google mostrou que sistemas de aprendizado de máquina carregam toda a manutenção de software tradicional mais um conjunto de problemas próprios, entre eles código de cola em excesso, selvas de pipeline, dívida de configuração e o fato de que mexer em qualquer coisa muda tudo.

A analogia com IA generativa em desenvolvimento é quase direta. O código que integra o modelo, trata prompt, faz parse de saída e lida com falha costuma crescer sem desenho, exatamente como o código de cola descrito ali. E ele raramente tem dono.

Onde a dívida se acumula mais rápido

Três lugares concentram o problema:

1. Tratamento de erro copiado. Blocos de captura genéricos, repetidos, que engolem a exceção e escondem a causa raiz.
2. Duplicação em vez de abstração. É mais fácil pedir de novo do que descobrir que já existe uma função para aquilo. Análises de repositórios vêm apontando aumento de duplicação e queda de reaproveitamento conforme assistentes se popularizam.
3. Testes que confirmam a implementação. Teste gerado a partir do código testa o que o código faz, não o que ele deveria fazer. Passa sempre, inclusive quando o comportamento está errado.

Como controlar sem barrar a ferramenta

O objetivo não é usar menos IA, é manter a dívida no quadrante deliberado.

Exija modelo mental na revisão. Uma pergunta padrão no template de PR resolve boa parte: "explique em duas frases por que essa solução funciona". Se quem abriu o PR não consegue, o código ainda não está pronto para entrar, independentemente de quem o escreveu.

Meça manutenibilidade, não só cobertura. A ISO/IEC 25010 decompõe qualidade em características, e manutenibilidade tem subcaracterísticas úteis para definir o que você vai acompanhar: modularidade, reusabilidade, analisabilidade, modificabilidade e testabilidade. Escolher duas e medir vale mais do que discutir qualidade em abstrato.

Anote a dívida quando ela for deliberada. Um comentário curto dizendo o que foi simplificado e por quê transforma dívida inadvertida em prudente, que é a que o time consegue pagar depois.

Revise a camada de integração com mais rigor. É ali que o código de cola se acumula, e é a parte que menos costuma ter teste.

O que isso significa para o seu time

Adicione a pergunta de explicação ao template de pull request nesta semana. É a intervenção de menor custo e maior efeito, porque ataca a dívida de compreensão na origem.

Escolha duas subcaracterísticas de manutenibilidade e comece a medir uma tendência, mesmo que grosseira: duplicação e tempo médio para resolver defeito servem bem. Compare o trimestre antes e depois da adoção.

E trate a camada que integra o modelo como código de produção de verdade: com dono, com teste e com revisão, e não como script que alguém colou para a demo funcionar.