Dívida Técnica de IA: Dois Problemas Diferentes, Não Um

Dívida Técnica de IA: Dois Problemas Diferentes, Não Um

A dívida técnica de IA não é a bagunça que você pensa que é. Não é apenas funções duplicadas e nomenclatura inconsistente que um linter consegue flagrar. Metade dela parece completamente correta no pull request, passa na revisão, é deployada, e só aparece seis semanas depois, quando ninguém da equipe consegue explicar por que uma mudança em um lugar quebrou três coisas que ninguém esperava. Essa segunda metade é a que a maioria das equipes não está medindo de jeito nenhum.

Dívida Técnica de IA: Dois Problemas Diferentes, Não Um

Pergunte a cinco engineering managers para definir dívida técnica de IA e você recebe cinco respostas, mas elas tendem a se agrupar em dois buckets muito diferentes.

O primeiro é dívida de código: duplicação, padrões inconsistentes, código que é tecnicamente correto mas adiciona superfície que ninguém pediu. Este é o bucket para o qual ferramentas de análise estática foram construídas.

O segundo é dívida cognitiva: a lacuna entre a velocidade com que código é gerado e a velocidade com que a equipe realmente constrói um modelo mental compartilhado do que ele faz. A pesquisa de desenvolvedores 2026 da Sonar encontrou que 88% dos desenvolvedores relatam pelo menos um impacto negativo da IA na dívida técnica, e 53% dizem que IA gera código que parece correto mas introduz defeitos ocultos. Isto é dívida de código. O que a pesquisa não captura totalmente é o segundo tipo, e o relatório do LeadDev sobre o conceito é o tratamento mais claro que encontramos.

Três equipes em cinco confundem os dois. Aqui está o que as outras duas fazem diferente: elas rastreiam dívida de código com ferramentas, e rastreiam dívida cognitiva com conversas.

A Parte da Dívida de Código: Código que Parece Correto e Não É

Dívida de código é o tipo familiar. Código gerado por IA tende a duplicar lógica que já existe em três arquivos mais adiante, porque o assistente não sabe que a lógica existe a menos que esteja no contexto. A pesquisa da Sonar coloca um número nisso: 40% dos desenvolvedores dizem que IA aumentou a dívida gerando código desnecessário ou duplicado.

A variante perigosa não é o código que parece errado. É o código que parece certo. Uma função passa nos seus testes, lida com o caminho feliz de forma clara, e lê como algo que um senior engineer escreveria, exceto que silenciosamente descarta um caso extremo que a implementação original tratava. Code review pega typos. Code review é muito pior em pegar uma função plausível que está sutilmente incompleta.

// Gerado por IA: passa nos testes, parece limpo
function getActiveUsers(users) {
  return users.filter(u => u.status === "active");
}

// O que o original tratava, três arquivos adiante:
function getActiveUsers(users) {
  return users.filter(u => u.status === "active" && !u.deletedAt);
}

Nada aqui lança um erro. Nada falha no CI. A lacuna só aparece quando um usuário soft-deleted reaparece em um relatório três semanas depois, e quem quer que seja paged tem que grep, blame, e perguntar por aí para descobrir qual versão está correta e por quê. Esse loop de grep-e-pergunta é o custo real, e é mensurável em horas, não em um sentimento vago de que algo está off.

Ferramentas docs-as-code que ficam ao lado do repo em vez de em um wiki separado reduzem quantas vezes esse loop acontece, porque o raciocínio por trás de uma função fica um clique longe da função em si, em vez de na memória de alguém.

A Parte da Dívida Cognitiva: Quando a Equipe Perde a Pista

Dra. Margaret-Anne Storey, professora de ciência da computação na Universidade de Victoria, cunhou "dívida cognitiva" em outubro de 2025 depois de observar seus alunos deployarem rápido com IA e depois lutarem para agir no seu próprio feedback de usuário. Seu diagnóstico: os alunos não haviam perdido o rastro do código, eles haviam perdido o rastro do que estavam construindo e por quê, e quem na equipe sabia o quê.

Esse enquadramento pega emprestado do argumento antigo de Peter Naur de que software não é realmente o código, é a teoria compartilhada nas cabeças das pessoas que o construíram. Quando código é gerado mais rápido do que a equipe consegue construir essa teoria, a teoria nunca se forma. Você pode ter uma codebase limpa e completamente testada e ainda ter dívida cognitiva significativa se as pessoas que a deployaram não conseguem explicá-la totalmente, ou se apenas uma pessoa consegue.

Esta é a parte que métricas de dívida técnica de IA padrão perdem completamente, porque dashboards rastreiam o código, não a compreensão. A pergunta que vale a pena fazer na sua próxima retro é direta: coloque um diagrama de arquitetura, e pergunte quem na equipe consegue explicar cada box. Se a resposta for "uma pessoa, e ela está de férias esta semana", você tem dívida cognitiva independentemente do que seu linter diz.

Um wiki interno vivo não resolve dívida cognitiva por si só. Dá à equipe um lugar para escrever o "por quê" antes de ele viver apenas na cabeça de uma pessoa, o que é um começo.

Por Que Code Review Não Consegue Acompanhar a Velocidade de Geração

Aqui está o problema mecânico por baixo de ambos os tipos de dívida: IA permite a um único engenheiro gerar uma semana de código antes do almoço, mas a capacidade de revisão não escalou de jeito nenhum. O gargalo se moveu de escrita para leitura, e leitura é a parte que ninguém acelerou.

Aqui é onde a comparação de ferramentas realmente importa, e vale a pena ser específico em vez de vago. Copilot e Cursor são rápidos em gerar código dentro do arquivo que você já tem aberto, o que é exatamente por que eles são bons em produzir mais código do que uma equipe consegue revisar. Cody e Continue.dev se apoiam mais na recuperação em todo o repo antes de gerar, o que ajuda a evitar o problema de duplicação acima, mas nenhum deles substitui o passo humano de decidir se novo código se encaixa em como o sistema deve funcionar. Nenhum deles diz se a pessoa merging o PR realmente entende o que mudou, o que é uma pergunta diferente se o diff está sintaticamente correto.

Ferramentas que perguntam-sua-codebase existem por causa dessa lacuna especificamente: a forma mais rápida de revisar código gerado por IA bem é poder perguntar, em linguagem clara, "onde mais esse padrão existe" ou "o que já trata esse caso", antes de você fazer merge no PR. Essa pergunta costumava levar vinte minutos de um senior engineer fazendo grep e blame. Não deveria.

Há também um efeito de tamanho de repo que vale a pena nomear. Em um serviço de 5.000 linhas, um reviewer consegue manter a maioria do sistema em sua cabeça, então uma função plausível se destaca porque não bate com o modelo mental do reviewer. Em um monorepo de 80.000 linhas tocado por seis equipes, nenhum reviewer único tem esse modelo mental mais, então código plausível passa por apenas porque ninguém na sala tem o contexto para notar que está errado. Quanto maior o repo, mais o gargalo de revisão depende de ferramentas em vez da memória de um senior engineer.

Juniors Pagam Essa Dívida Primeiro, e Mais Rápido

Anthropic rodou um estudo controlado em janeiro de 2026, um ensaio randomizado com 52 junior developers, e encontrou que aqueles que usaram assistentes de IA tiveram 17% menos pontos em testes de compreensão de código, mais ou menos duas letras de nota. A equipe de engenharia interna da Infobip, rodando um programa de internship desde 2022 em 225 interns, viu o mesmo padrão em dados longitudinais reais: coortes pré-IA cresceram em média 2,50 pontos em skill técnico auto-avaliado durante um internship; coortes era-IA cresceram 1,56.

O mecanismo não é uso de IA em si. Dois interns na coorte mais recente da Infobip usaram IA na mesma frequência, com resultados opostos. Um perguntou questões de follow-up e conseguiu explicar totalmente o que a IA produziu; seu crescimento foi o mais alto da coorte. O outro aceitou output com revisão mínima, tratou como uma caixa preta, e cresceu por zero. A ferramenta era idêntica. A relação com ela não era.

Gravar sessões de pairing e walkthroughs de arquitetura, e torná-los pesquisáveis depois, dá aos juniors algo para voltar em vez de re-perguntar a mesma questão para quem quer que esteja livre. Não vai substituir um mentor, mas reduz o custo de perguntar duas vezes.

Pule a Recomendação "Bane IA para Juniors"

Todo roundup sobre este tópico termina na mesma recomendação eventualmente: restrinja acesso a IA para junior engineers até que eles "tenham ganhado". Pule aquela. Não bate com o que equipes que realmente mediram o problema encontraram, e ela troca um modo de falha para outro; juniors que não conseguem usar as ferramentas que sua equipe ships com caem atrás de uma forma diferente, igualmente real.

O que funcionou para a Infobip em vez disso foi sequencing, não banning: tente o problema primeiro, verifique com IA segundo, então o hábito de pensamento independente se forma antes de IA se tornar o movimento padrão. Eles adicionaram checkpoints livres de IA, não como punição mas como calibração, então tanto intern quanto mentor sabem onde skill realmente está. Mentores também mudaram de revisar pull requests para rastrear processo: quem perguntou o quê, quem ficou preso onde, quem explicou sua própria mudança sem ajuda.

Scores de satisfação subiram o tempo todo enquanto crescimento de skill estava caindo, o que é o aviso real em seus dados: se você está apenas rastreando como as pessoas se sentem sobre as ferramentas, você não vai ver isto vindo. Vinte por cento dos interns na coorte mais recente da Infobip não sabiam o que era esperado de um junior engineer no seu nível em primeiro lugar, o que torna auto-avaliação próxima a sem sentido. Você não consegue medir uma lacuna contra um ponto de referência que ninguém escreveu.

O Que Nós Realmente Mudaríamos Neste Sprint

Comece com a pergunta retro acima: quem consegue explicar cada parte do sistema, em voz alta, agora. Essa pergunta única superficializa mais dívida cognitiva em dez minutos do que qualquer dashboard vai.

Para dívida de código, mantenha análise estática no loop. A pesquisa de desenvolvedores 2026 da Sonar mostra 70% dos desenvolvedores já usam, e equipes rodando isso relatam outcomes significativamente melhores em custo de rework do que equipes que pulam. Isso não é uma recomendação controversa, é apenas uma que equipes pulam quando estão se movendo rápido porque o output de IA parecia pronto.

O toil que IA remove da escrita de código não desaparece. Sonar chama isto o "grande shift de toil": ele reaparece downstream, em gerenciar dívida e corrigir output de IA. Automatizar as partes recorrentes desse triage, flagging de PRs stale, roteando pedidos de revisão, perseguindo follow-ups, liberta tempo sênior para a parte que realmente requer um humano: decidir se a equipe entende o que ela acabou de fazer deploy.

Meça trajetória, não satisfação. Uma equipe que se sente bem sobre IA e não consegue explicar sua própria arquitetura em seis meses não economizou tempo. Ela o pegou emprestado, a uma taxa que ninguém escreveu.