Dívida Técnica de IA (Dívida técnica do código generativo)

1. Visão geral do conceito e problema sistêmico

O termo "dívida técnica", cunhado por Ward Cunningham, descrevia originalmente um trade-off: lançar uma feature mais rápido hoje para obter feedback de negócio, e amanhã voltar para reescrever o código com qualidade.

Na era da codificação generativa, a conceituação sofreu uma mutação. AI Technical Debt (Dívida Técnica de IA) não é um trade-off consciente de um engenheiro experiente, mas sim uma acumulação incontrolada de código cuja modelagem mental completa não é mantida por nenhum ser humano vivo na equipe.

Quando uma startup ou equipe enterprise se encanta com a velocidade inicial extremamente alta ("nós escrevemos o backend em um fim de semana!"), elas assumem um crédito de juros altos:

• Velocidade dos primeiros releases: 10x.
• Velocidade de desenvolvimento após seis meses: 0.1x.
• Qualquer tentativa de atualizar a versão de uma biblioteca ou adicionar uma nova regra de negócio transforma-se em uma cascata de falhas incompreensíveis em cantos desconectados do repositório.

Trajetória da velocidade de desenvolvimento:
Velocidade
   ^
   |       /--- Cultura de engenharia saudável (Velocidade estável)
   |      /
   |  /\ /
   | /  X
   |/    \
   |      \___ Dívida técnica descontrolada por IA (Início rápido -> Paralisia arquitetural)
   +----------------------------------------------------> Tempo (meses)

2. Taxonomia arquitetural e modelo mental

A anatomia da dívida técnica generativa inclui quatro níveis:

1. Dívida Cognitiva (Cognitive / Comprehension Debt):
   • O código funciona, mas ninguém na equipe entende a mecânica interna do algoritmo.
   • Os desenvolvedores têm medo de tocar no código e, quando surgem bugs, simplesmente alimentam o arquivo à modelo com um prompt "conserte isso", aprofundando ainda mais a dívida.
2. Dívida pela Ausência de Fonte Única da Verdade (Single Source of Truth Decay):
   • O modelo não lembra que a validação de número de telefone já está implementada no pacote @shared/validation, e cria sua própria implementação no módulo de autorização, enquanto outro modelo faz o mesmo no módulo de pedidos.
   • As regras de negócio começam a divergir.
3. Dívida por Invariantes Fracos ou Ausentes:
   • Uso de tipos fracos (any, unknown, Record<string, any>), ignorando condições de corrida (Race Conditions) e bloqueios de transações no banco de dados.
4. Dívida por Dependências Excessivas (Dependency Creep):
   • Adição de bibliotecas externas pesadas para executar operações elementares, que poderiam ser resolvidas com 3 linhas de código nativo da versão atual da plataforma.

3. Pipeline técnico e mecânica interna

Tabela comparativa de sintomas da dívida técnica

Pipeline arquitetural de proteção contra dívida

[O agente propõe alterações]
         |
         v
[Passo 1: Análise AST da complexidade ciclomática (ESLint/Biome)]
         |
         v
[Passo 2: Verificação de fronteiras arquiteturais (Dependency Cruiser)]
         |
         v
[Passo 3: Checagem de tipos com tsc --noEmit e a flag noImplicitAny]
         |
         v
[Passo 4: Execução de testes de mutação (Stryker Mutator)]
         |
         v
[Passo 5: Auditoria arquitetural manual: é possível resolver isso removendo código?]

4. Cenários práticos de engenharia em produção

01. Liquidação da dívida cognitiva via refatoração "Delete-First"

Uma equipe enfrenta um microsserviço de cálculo de descontos com 2500 linhas, escrito por um agente durante um hackathon. O serviço contém dezenas de ramificações que nunca são executadas. O arquiteto registra os requisitos de negócio em 15 testes de integração concisos, apaga completamente o arquivo antigo e obriga o agente a gerar uma função de tabela pura (Lookup Table) com 120 linhas, liquidando 95% do código desnecessário.

02. Detecção de dependências circulares usando dependency-cruiser

Devido às recomendações caóticas dos agentes, os módulos do projeto tornaram-se emaranhados em imports circulares (A -> B -> C -> A), causando erros espontâneos de undefined durante a inicialização do ambiente em produção. Os engenheiros configuram a regra no-circular no CI, corrigem a estrutura para uma Arquitetura em Camadas (Layered Architecture) e bloqueiam tentativas futuras dos agentes de criar conexões cruzadas.

03. Auditoria de contratos de microsserviços via Zod / OpenAPI

Os agentes geravam chamadas de cliente ao backend com versões antigas dos campos. A implementação de um esquema Zod rigoroso na entrada de cada endpoint de API e a geração automática de tipos TypeScript para o frontend eliminam bugs ocultos de divergência de dados, garantindo que nenhuma alteração quebre a aplicação cliente.

5. Armadilhas, erros comuns e segurança

1. "Fixing Slop with More Slop" (Tratando lixo com mais lixo): Quando ocorre um erro no código gerado, a pior coisa a fazer é enviar o erro ao modelo com as palavras "corrija". O modelo simplesmente adicionará outro if ou try-catch, criando um "band-aid cru" sobre uma arquitetura podre. Pare, investigue a causa raiz (Root Cause) e simplifique o design original.
2. Ignorar vazamentos de recursos em processos em segundo plano: Scripts gerados frequentemente esquecem de fechar conexões com o banco de dados, descritores de arquivos ou pools de threads. Na máquina local, isso passa despercebido, mas sob alta carga o servidor esgota os limites de arquivos abertos (Too many open files) e cai.
3. Avaliação incorreta da produtividade da equipe: Se a gestão avalia os desenvolvedores pela velocidade de fechamento de tarefas ou pelo número de commits, os engenheiros recorrem à geração incontrolada de código por IA. Meça a estabilidade dos releases, o número de regressões e a facilidade de modificação do sistema, e não o volume bruto de texto escrito.