O código que ninguém entende: a dívida que não aparece no painel
Quem só manda a IA gerar entende menos: 50% contra 67% no teste de compreensão. É a dívida de compreensão — não aparece em teste, cobertura ou painel.
No terceiro texto desta série, eu falei da dívida que mora no código. Aquela a gente consegue mostrar: está no repositório, no arquivo, no diff. Dá para abrir e apontar com o dedo. A dívida de que eu quero falar hoje é outra, e é a mais cara das duas: ela mora na cabeça do time. Não tem arquivo, não tem diff, não tem teste que pegue. E é justamente por isso que ela não aparece em painel nenhum.
Pensa num prédio já entregue. As luzes acendem, o elevador funciona, tem gente morando. Só que a planta do edifício ninguém tem. Cada parede foi levantada no dia em que deu, o desenho final nunca foi fechado. No dia em que você precisar furar uma parede, ninguém sabe por onde passa o cano.
É esse o estado de muito código que a IA escreve. A coisa funciona — e ninguém consegue desenhar a planta.
Já existiu um tempo em que o dono do mapa era o dev sênior. Ele tinha escrito aquilo, carregava a história na cabeça, e o time inteiro ia até ele quando precisava entender. O que mudou não é que as pessoas ficaram piores. É que ninguém escreveu o código. Quando a IA produz a maior parte das linhas, aquele mapa que nascia junto com o trabalho de escrever simplesmente não nasce. Ele deixa de ser um subproduto automático do serviço e passa a ser um serviço à parte, que alguém tem que fazer de propósito.
Em janeiro de 2026, Shen e Tamkin publicaram um ensaio randomizado com 52 engenheiros aprendendo uma biblioteca de programação nova. Quem usou IA entregou a tarefa no mesmo tempo de quem programou na mão. Mas no teste de compreensão os números foram outros: 50% de acerto no grupo que usou IA, 67% no grupo manual. E a maior queda foi exatamente onde mais dói: depurar. Reconhecer o erro e corrigir o erro que estava ali na frente.
Dezessete pontos de diferença no que o time entende, com o mesmo tempo gasto e a mesma entrega feita.
Segura uma coisa antes de continuar: eu não estou dizendo que quem usa IA ficou pior, nem que o time de desenvolvimento desaprendeu a trabalhar. Os dois estudos mais fortes que eu vou trazer aqui são de formação de habilidade — gente aprendendo uma biblioteca nova, gente começando na profissão. O que eles medem é outra coisa, e é essa a frase que eu quero que você guarde: a capacidade de entender o que a IA produziu virou o recurso escasso. Produzir ficou barato. Entender não ficou.
Agora olha o que acontece quando esse código chega no portão de entrada. A LinearB analisou 8.109.244 pull requests de 4.813 times em 42 países. Pull request de humano entra na main em 84,4% dos casos. Pull request de IA, em 32,7%. E o PR feito por agente fica 5,3 vezes mais tempo esperando revisor: 1.055 minutos ociosos contra 201 minutos do PR humano, na faixa do P75.
A própria LinearB escreveu onde está o nó. A maior barreira para mergear um PR de IA não é a correção do código. É o contexto. O revisor não aprova o que ele não consegue entender — e ele não consegue entender o que ninguém explicou.
Repara no que isso significa. Não é um time de revisores ruins. É uma fila de código que funciona e que ninguém sabe explicar. O que trava o portão não é o defeito: é a ausência de um mapa.
E tem uma diferença que importa nessa fila. O revisor de antes herdava contexto de quem escreveu: perguntava, discutia, entendia junto com o autor. Com código de IA, esse par não existe. Não tem autor para perguntar. Tem um resultado — e um prompt que ninguém guardou.
Em 2026, o Sankaranarayanan levou isso para um experimento controlado com 78 pessoas. Quem usou IA para gerar código sem nenhum freio teve 77% de falha em uma tarefa de manutenção feita depois, com a IA desligada, em 30 minutos. O grupo que tinha um andaime de IA — alguém precisava explicar o que mudou antes de integrar — errou 39%. E os dois grupos com IA foram melhores que o grupo manual na parte de fazer funcionar (p<0,001).
Lê esse último ponto de novo. Os dois grupos com IA foram melhores em fazer funcionar. O ganho era real. A compreensão não veio junto.
Esse é o ponto deste artigo. A IA não é o problema, e ela não escreve pior. Ela funciona antes e trava depois — porque depois ela não está mais lá, e é aí que alguém precisa entender o que ela deixou dentro do sistema.
E se você quer saber onde essa dívida cobra, ela cobra nos lugares que não têm painel. No onboarding, quando a pessoa nova pergunta por que o sistema faz aquilo e ninguém sabe responder. No incidente de sexta às 18h, quando o plantão precisa mexer num trecho que ninguém escreveu. E na saída de alguém do time, quando vai embora a única pessoa que segurava aquele contexto na cabeça. Nada disso aparece em cobertura de teste. Tudo isso aparece na entrega.
O Google mediu esse custo por dentro. Uma análise qualitativa de 1.110 respostas abertas de engenheiros da empresa, no terceiro trimestre de 2025, registrou duas coisas que vale ler devagar. A primeira eles chamaram de imposto da verificação: o tempo que você economiza escrevendo, você gasta auditando. A segunda é o paradoxo da expertise: a IA pode levar a um aprendizado superficial e a uma degradação de habilidade no longo prazo.
Cuidado com o escopo: não é uma amostra representativa do mercado. É o que os engenheiros do Google escreveram quando alguém pediu para eles contarem. Mas é sinal de quem tem dado na mão todos os dias.
Em março de 2026, a Storey organizou o conceito em três dívidas: a técnica, que está no código; a cognitiva, que está na cabeça do time; e a de intenção, que é o porquê que ninguém escreveu em lugar nenhum. Para este texto, serve um ponto só: a dívida cognitiva não é detectável por análise estática nem por teste automatizado.
Ela não aparece no painel por um motivo simples: não tem artefato. Teste verde não é sinal de saúde — é sinal de que os testes passaram. Cobertura alta não é sinal de saúde — é sinal de que aquela linha foi executada. Painel só mostra o que alguém decidiu medir, e compreensão ninguém decidiu medir.
O caso mais claro disso que eu já li é do Osmani. Quando a IA muda um comportamento do sistema e ajusta centenas de testes para combinar com a mudança, todos ficam verdes. Você não tem um teste vermelho para olhar. O único instrumento que responderia é a compreensão de alguém que sabe o que aquele sistema fazia antes — e essa pessoa, muitas vezes, não está mais na sala.
É por isso que eu digo que o gargalo mudou de novo. No texto anterior, ele estava no fluxo: a fila de conferência. Aqui ele está um passo antes. Não adianta acelerar quem confere se quem confere não entende o que está conferindo.
Agora a parte boa, porque ela existe e é boa de verdade. No mesmo ensaio com os 52 engenheiros, a diferença não estava em usar ou não usar IA. Estava em como. Quem usou a IA para perguntar e entender — consulta conceitual, “me explica isso”, “por que funciona assim” — ficou acima de 65% no teste de compreensão. Quem só mandou gerar ficou abaixo de 40%.
Escreve esse número de outro jeito. Quem usa a IA para entender fica melhor do que quem não usou IA nenhuma. Quem usa a IA para terceirizar o entendimento fica pior. Mesma ferramenta, dois resultados opostos.
Por isso eu afirmo, sem medo de errar: compreensão é treinável. Não é dom, não é tempo de casa, não é senioridade. É hábito. Pedir a explicação antes de aceitar o código. Explicar em voz alta o que mudou antes de integrar. Escrever o porquê no lugar onde a próxima pessoa vai procurar.
Aliás, isso já tem número. No experimento do Sankaranarayanan, o grupo com o portão de explicação derrubou a falha de 77% para 39%. O remédio não foi revisar mais. Foi entender antes.
Eu quero ser honesto sobre onde a evidência é fina. Os dois estudos mais fortes deste texto medem quem está formando habilidade agora: 52 engenheiros diante de uma biblioteca nova e 78 pessoas aprendendo a mexer num sistema com IA do lado. Para o sênior com dez anos de casa, entregando em produção todo dia, não existe uma medição equivalente que eu possa te mostrar. O que existe é o sinal do Google e o achado da LinearB — e os dois apontam para o mesmo lado. Então eu prefiro dizer só o que dá para sustentar: o efeito está medido em quem está aprendendo hoje, e quem está aprendendo hoje é quem vai manter o seu sistema em cinco anos.
Vale olhar a série inteira para entender por que isso é uma mudança de era. Cada camada ficou visível quando a camada de cima ficou barata: primeiro o dado, depois o papel do time, depois a dívida no código, depois o fluxo. Agora a cabeça. Escrever código barateou. Explicar, ensinar, documentar e manter o modelo mental do sistema na sala não barateou nada.
Então a pergunta que eu devolvo para você não é se o seu time usa IA. Essa já está respondida. É outra: das últimas dez mudanças que entraram no seu sistema, quantas alguém do seu time consegue explicar sem abrir o código? Se a resposta for “poucas”, o gargalo não está no editor. Está na cabeça. E esse, ao contrário do que parece, dá para resolver. Me conta nos comentários. Eu leio e respondo.
Este é o quinto texto da série Agilidade com Dados. O quarto, sobre o gargalo que mudou de lugar, está aqui: Err@r rápido na era da GenAI.