Novo estudo da Anthropic revela o risco invisível da IA no código — a dívida de compreensão que nenhuma métrica captura

Você usa IA para escrever código todo dia. Produtividade lá em cima, entrega mais rápida do que nunca. Mas deixa eu te fazer uma pergunta: você realmente entende o código que está entregando?

Um estudo recente da Anthropic com 52 engenheiros mostrou o seguinte: quem usou IA para gerar código acertou 17% menos nas perguntas sobre o próprio código. A IA está te deixando com memória de peixe — e o pior é que o código sempre parece super bacana: lindo, organizado, testes passando, time achando que está tudo indo bem.

Trabalho com cybersegurança há 18+ anos, hoje como Senior Cybersecurity Lead na Microsoft com foco em IA aplicada. Eu vejo esse problema de um ângulo diferente — e é por isso que esse artigo me preocupa tanto. Vou destrinchar o que os pesquisadores encontraram, por que suas métricas não capturam esse risco, e o que você precisa fazer a partir de agora.

Dívida técnica vs. dívida de compreensão

Todo mundo em tecnologia conhece dívida técnica — quando você resolve um problema do jeito mais rápido possível e deixa a bagunça para depois. "Ah, depois eu vejo isso." Você sente a dívida técnica: o build fica mais lento, o projeto trava, ninguém quer mexer naquela parte do código porque "se botar a mão ali, vai dar pau."

O que o estudo da Anthropic identifica é algo diferente. Eles chamam de comprehension debt — dívida de compreensão. É o espaço crescente entre o quanto de código existe no seu sistema e o quanto o seu time realmente entende esse código.

A diferença fundamental: dívida técnica avisa. Dívida de compreensão não.

O código parece super organizado — porque realmente está, a IA deixa tudo bem formatado. Todos os testes passam — porque a própria IA os escreveu. Mas essa bomba-relógio estoura quando você menos espera. Na pesquisa, os times chegaram à sétima semana de um projeto e não conseguiam mais fazer uma mudança pequena sem quebrar algo do outro lado. Não porque o código era bagunçado — mas porque ninguém conseguia explicar por que as coisas tinham sido feitas daquele jeito.

O problema da velocidade

Aqui está o ponto que a maioria das empresas não percebe: a IA gera código muito mais rápido do que uma pessoa consegue revisar. Isso é óbvio, mas as consequências são enormes.

Antes, um desenvolvedor escrevia código e a revisão tinha um ritmo humano. Esse ritmo era importante — forçava você a entender o que a outra pessoa escreveu, pegava problemas escondidos, distribuía conhecimento pelo time (o chamado tribal knowledge). A IA quebra esse ciclo.

O volume que entra para revisão agora é grande demais. O resultado parece 100% correto: bem formatado, organizado, nenhum erro de sintaxe. E são exatamente esses sinais que fazem o revisor humano clicar em "Aprovar" — confesso que já fiz muito disso. Mas o que parece correto por fora não é o mesmo que estar certo por dentro.

A virada que preocupa: antes, um engenheiro sênior fazia a revisão mais rápido do que um júnior conseguia escrever. Com IA, um iniciante gera mais código, mais rápido do que um sênior consegue revisar. O que era controle de qualidade virou um problema de quantidade.

Por que testes não salvam?

Você pode estar pensando: "Gustavo, eu tenho cobertura de 80–90%, está tudo verde." Ótimo — continue fazendo isso. Mas nos dias atuais, é insuficiente.

O motivo é simples: você não consegue escrever um teste para algo que não imaginou que podia acontecer. Ninguém vai escrever um teste dizendo "o item arrastado não pode ficar transparente" se ninguém nunca imaginou que isso pudesse acontecer. Esse tipo de erro passa por tudo — não porque o teste foi mal feito, mas porque ninguém pensou em olhar para lá.

Tem uma situação específica que merece atenção: quando a IA muda o comportamento do código e atualiza centenas de testes para bater com o comportamento novo. A pergunta muda. Você para de perguntar "esse código está certo?" e começa a perguntar "tenho cobertura suficiente para pegar o que eu nem imaginei?" Nenhum teste responde isso — só entender o código de verdade responde.

Os dados da pesquisa confirmam:

• Quem usa IA como atalho ("faz aí pra mim") tirou abaixo de 40% nos testes de compreensão da própria aplicação
• Quem usa IA para aprender, questionar e melhorar o código tirou acima de 65%

A mesma ferramenta pode te prejudicar ou te evoluir — depende de como você usa.

O ângulo de cybersegurança

Trabalhando com segurança em empresas parceiras na Microsoft, eu vejo esse problema de um ângulo diferente. Pensa em código feito por IA rodando numa rede hospitalar, num banco, em infraestrutura financeira, no governo.

Se a IA escreveu o código e não foi revisado direito, isso não segura um relatório de incidente quando algo grave acontecer. Em sistema hospitalar, estamos falando de vidas em jogo. Em sistema financeiro, de muito dinheiro. Por mais que a IA pareça a solução para tudo — especialmente com líderes empurrando para aumento de produtividade — os profissionais precisam ter entendimento amplo da aplicação.

O custo de produzir código despencou. A velocidade dos times disparou. Gestão fica mais simples com times mais enxutos. Mas a necessidade de alguém entender de verdade o que o sistema está fazendo não muda. E na minha opinião, essa é a parte que a maioria das pessoas ainda não viu: quanto mais IA o time usa, mais valioso fica o engenheiro que realmente entende o sistema.

O profissional que olha para uma mudança de código e fala "isso vai dar problema", que lembra a decisão que foi tomada meses atrás e por que está causando o problema de hoje — esse profissional vai se tornar um dos recursos mais escassos e valiosos dentro de qualquer time operando com IA.

O problema não aparece em nenhuma métrica

Esse é o motivo dessa dívida ser perigosa. Olha os números que você acompanha:

• Velocidade do time — aumentando ✅
• Tempo de entrega — diminuindo ✅
• PRs aprovados — subindo ✅
• Cobertura de código — tudo verde ✅

Nenhum desses números captura se o time entende o que está construindo. É isso que torna esse problema diferente de dívida técnica normal. Dívida técnica você sabe onde está, pode escolher pagar depois — sai caro, mas pode pagar. Dívida de compreensão se acumula em silêncio, centena de revisões "OK" empilhadas, e quando estoura, ninguém sabe explicar o que aconteceu.

5 dicas práticas para lidar com isso

Vendo isso acontecer na prática com muitos clientes, aqui vai o que recomendo:

1. Seja claro com a intenção, não só o resultado

Antes de escrever código com IA, explicite as mudanças que você quer fazer e por quê — não apenas o que quer que saia.

2. Trate testes como o piso, não o teto

Testes são a entrada, não a última palavra. Eles validam o que você pensou — não o que você não imaginou.

3. Mantenha um modelo mental do sistema

Entenda como as partes se conectam. Se você não consegue explicar o fluxo sem olhar o código, tem um problema.

4. Diferencie "passou no teste" de "eu entendo o que isso faz"

Esse é o ponto que você precisa alcançar. "Os testes da IA passaram" não é o mesmo que "eu sei por que essa decisão foi tomada e o que acontece se mudar."

5. Questione as decisões do agente

O papel do humano nesse loop de desenvolvimento com IA é saber questionar, entender riscos por trás de cada escolha. Isso é usar IA como ferramenta para multiplicar sua capacidade — não para substituir seu entendimento.

A pergunta que importa

A IA vai continuar gerando código — não tem mais o que falar sobre isso. A pergunta que você precisa levar deste artigo não é "como a gente gera mais código?" É: quem vai entender o que foi gerado?

Quem treina essa habilidade é quem vai estar um passo à frente, em qualquer time, em qualquer empresa.

Este artigo foi baseado no meu vídeo no YouTube analisando o estudo da Anthropic sobre dívida de compreensão em desenvolvimento com IA. Assista a versão completa para ver os gráficos do paper original e a discussão estendida.