A IA Não Te Deixa Em Dívida Técnica. Te Deixa Em Dívida De Compreensão.

Tem uma dívida nova crescendo no seu time e ela não aparece em nenhum dashboard. Não é dívida técnica. O código compila, passa no CI, vai para produção e funciona. O problema é outro: ninguém entende mais por que funciona.

Essa é a dívida cognitiva. Ela não mora no código. Mora na cabeça das pessoas que deveriam conseguir manter o sistema, e que estão entregando mais rápido do que conseguem compreender.

Dívida técnica você refatora. Dívida cognitiva você só descobre no pior momento possível: o dia em que precisa mudar algo e percebe que ninguém no time sabe explicar o que está mudando.

---

A Dívida Que Não Aparece No Git

Dívida técnica tem rastro. Você vê o código duplicado, o TODO esquecido, o acoplamento errado, o teste que falta. Ferramentas medem. Linters apontam. Você prioriza e paga.

Dívida cognitiva é invisível por definição. Ela é a diferença entre o código que existe no repositório e o modelo mental que o time tem desse código. Quando essa diferença cresce, o sistema fica mais difícil de raciocinar, debugar e evoluir, mesmo sem nenhuma linha "ruim".

Antes da IA, essa lacuna crescia devagar. Você escrevia o código, então você entendia o código. Entender era um efeito colateral obrigatório de produzir. Não dava para entregar sem antes formar algum modelo na cabeça.

A IA quebrou esse acoplamento. Agora dá para entregar sem entender. E é exatamente isso que torna a dívida cognitiva o passivo mais perigoso de 2026: ela acumula em silêncio, no único lugar que nenhuma métrica de engenharia observa.

---

O Que É Dívida Cognitiva, De Verdade

Para entender o problema, vale voltar a uma ideia antiga. Em 1985, Peter Naur escreveu "Programming as Theory Building". A tese: um programa não é o código-fonte. Um programa é uma teoria viva na cabeça de quem o construiu, uma explicação de como a intenção virou implementação e do que acontece quando você muda cada parte.

Se essa teoria existe, manter o sistema é fácil, mesmo com código feio. Se a teoria se perde, o sistema vira arqueologia, mesmo com código limpo. Naur dizia que um programa cuja teoria morreu está praticamente morto, ainda que rode perfeitamente.

Dívida cognitiva é, no fundo, a erosão dessa teoria compartilhada. Cada vez que o time aceita um trecho que funciona sem reconstruir o "porquê", a teoria fica um pouco mais furada. O código continua lá. O entendimento, não.

A IA acelera essa erosão porque otimiza justamente a etapa em que a teoria costumava ser construída. O agente lê o domínio, decide a abordagem, escreve a solução e entrega o diff. O dev pula da intenção direto para o resultado, sem atravessar o meio. E é no meio que o modelo mental nascia.

---

O Dado Que Deveria Assustar

Isso não é só filosofia de quadro branco. Tem medição.

Em janeiro de 2026, a Anthropic rodou um experimento controlado com 52 engenheiros aprendendo uma biblioteca de programação assíncrona nova. Metade usou assistência de IA, metade não. Os dois grupos terminaram a tarefa em tempo parecido. A diferença apareceu depois, num quiz de compreensão: o grupo assistido por IA pontuou 17% menos, 50% contra 67%. A maior queda foi em capacidade de debugar.

Leia de novo: mesma tarefa, mesmo tempo, e ainda assim quem usou IA entendeu menos o que tinha acabado de construir. A entrega foi idêntica. O aprendizado, não.

É um resultado desconfortável porque contraria a sensação. Usar IA dá uma percepção forte de produtividade e domínio. Você vê código aparecendo, testes passando, problema resolvido. Mas percepção de entendimento e entendimento real são coisas diferentes, e o segundo é o que você precisa no dia da manutenção.

Esse é o tipo de custo que nunca aparece na primeira semana. Aparece quando o código já está em produção, o autor já esqueceu o contexto e alguém precisa mexer ali sob pressão.

---

O Gap De Velocidade E Compreensão

Tem uma forma simples de visualizar o problema: a velocidade de produção e a velocidade de compreensão não andam mais juntas.

Um humano lê e absorve código a algo entre 20 e 40 linhas por minuto quando está realmente entendendo, não só passando o olho. Um coding agent despeja código numa ordem de grandeza acima, 140 a 200 linhas por minuto. O resultado é um descompasso de cinco a sete vezes entre o que entra no repositório e o que a equipe consegue internalizar.

Esse gap é o motor da dívida cognitiva. Cada sprint, o sistema ganha mais código do que o time consegue transformar em entendimento. A diferença não some. Ela se acumula como saldo devedor de compreensão, rendendo juros que você só vai pagar lá na frente.

E aqui está a armadilha mental: como o código funciona, parece que está tudo bem. Funcionar e ser compreensível são propriedades independentes. A IA é excelente em produzir a primeira e indiferente à segunda.

O time fica com a sensação de estar voando. Está, na verdade, acumulando uma hipoteca que ninguém registrou.

---

Por Que O Velocity Não Pega Isso

Se você mede o time por velocity, throughput ou linhas entregues, a dívida cognitiva é literalmente invisível. Pior: esses indicadores sobem justamente enquanto a dívida cresce. Você olha o painel, vê tudo verde e conclui que a IA está funcionando.

Já falei aqui sobre os limites do DORA e do rework rate na era dos agentes. Dívida cognitiva é o ponto cego que fica abaixo até dessas métricas. Rework rate pega instabilidade que vira bug e correção. Mas um sistema pode não quebrar imediatamente e, ainda assim, ficar mais difícil de manter. Esse é o caso clássico de dívida cognitiva: nada falha hoje, tudo fica mais caro amanhã.

A métrica que mais engana é a aceitação de sugestões. "Aceitamos 70% do que a IA propõe" mede uso, não entendimento. Um time pode aceitar 90% e compreender 30%. O número sobe, a teoria do sistema afunda.

Por isso o problema é traiçoeiro para liderança. Todos os sinais de curto prazo apontam para sucesso. O sinal de longo prazo, a capacidade de evoluir o sistema com segurança, não está em nenhum gráfico semanal.

---

O Paradoxo: Indivíduo Mais Rápido, Time Mais Lento

Quando você sobe do dev individual para o time, o efeito fica ainda mais claro, e mais constrangedor.

Os dados de 2025 a 2026 sobre produtividade com IA mostram um padrão que ficou conhecido como paradoxo da produtividade. O desenvolvedor individual percebe um ganho de cerca de 20% de velocidade. O time, no agregado, entrega por volta de 19% mais devagar. O ganho individual não vira ganho coletivo. Ele vira fricção sistêmica.

De onde vem essa fricção? Dos números que acompanham a adoção: muito mais PRs abertos, tempo de review crescendo de forma desproporcional, code churn subindo, e mais vulnerabilidades chegando junto. O gargalo migra da escrita para a revisão e o entendimento, que são exatamente as etapas que a IA não acelera.

Dívida cognitiva é uma das causas centrais desse paradoxo. Quando o autor de um PR não entende profundamente o que submeteu, o reviewer precisa fazer o trabalho de compreensão que não foi feito antes. A carga não desaparece. Ela se desloca para frente na fila, e geralmente para alguém mais sênior.

O time inteiro acaba pagando, em horas de review e debugging, a compreensão que foi pulada no momento da escrita.

---

Onde A Dívida Cobra Juros

A dívida cognitiva tem um momento favorito para cobrar: a primeira mudança não trivial.

Existe um caso que ilustra isso melhor que qualquer gráfico. Um time de estudantes usou IA para construir rápido e chegou a software funcionando em poucas semanas. Na semana sete, precisaram fazer uma alteração simples. O projeto travou. Ninguém conseguia explicar as decisões de design, ninguém entendia como os componentes interagiam. O código estava lá, completo e funcional. A teoria por trás dele nunca tinha existido na cabeça de ninguém.

Troque "estudantes" por "seu time" e "semana sete" por "três meses depois do release". A história é a mesma em produto real. Falhas de código gerado por IA têm o hábito de aparecer 30 a 90 dias depois do deploy, quando o contexto já evaporou e quem mexe não é quem escreveu, porque ninguém de fato "escreveu".

O sintoma não é o sistema cair. O sintoma é mais sutil: o medo de mexer. Áreas do código que ninguém quer tocar. Estimativas que incham porque "ninguém conhece aquela parte". Reuniões que viram sessões de engenharia reversa do próprio produto.

Quando o time começa a tratar o próprio código como legado de terceiros, a dívida cognitiva já está vencida e rendendo juros compostos.

---

Não É Problema Do Modelo, É Do Processo

Aqui vale uma honestidade que falta em boa parte do debate: o problema não é a IA gerar código. O problema é o processo deixar o entendimento opcional.

A mesma ferramenta pode reduzir ou aumentar dívida cognitiva, dependendo de como o time a usa. Um agente que escreve a solução e o dev que cola sem ler aumenta a dívida. O mesmo agente usado para explicar uma área desconhecida, propor alternativas e ser interrogado sobre trade-offs pode até reduzir a dívida, acelerando a construção do modelo mental.

A diferença está no fluxo, não no modelo. Time com bom review, testes fortes e cultura de entender antes de aprovar tende a absorver a velocidade da IA sem perder a teoria do sistema. Time que trata aprovação como carimbo transforma cada sprint em mais saldo devedor.

Isso conecta com algo que já defendi sobre context engineering: o que entra no contexto do agente molda o comportamento dele. O mesmo vale para o humano. O que o seu processo exige que a pessoa entenda molda o quanto de teoria sobrevive. Se entender não é exigido em lugar nenhum do fluxo, ele simplesmente não acontece.

Ou seja: dívida cognitiva é uma escolha de processo disfarçada de consequência inevitável da tecnologia. Dá para decidir diferente.

---

Revisar Para Entender, Não Só Para Aprovar

A primeira linha de defesa é o code review, e ela está sendo usada errada na maioria dos times.

Review de código gerado por IA não pode ser review de estilo. Verificar formatação, nomes e convenções é o que o agente já faz sozinho. O que importa no review de código de agente é intenção, escopo e validação. Por que essa abordagem? O diff resolve o problema certo? O que essa mudança quebra que não está visível aqui?

Um bom teste é a regra do "explique sem o autor". Se o reviewer não consegue explicar o que o PR faz e por quê, sem o autor presente, o PR não está pronto para aprovar, está pronto para uma conversa. Aprovar nesse estado é assinar embaixo de uma dívida que você não leu.

Outra prática que ajuda é exigir do autor, não do reviewer, o resumo do raciocínio. Não "o que o código faz", que dá para ler. Mas "por que esse caminho e não outro", "o que considerei e descartei", "onde isso pode dar errado". Se o autor não consegue escrever isso, é sinal de que ele também não entendeu, e a dívida está nascendo ali.

Review existe para transferir teoria entre cabeças, não para liberar merge. Quando a IA entra no fluxo, esse propósito original do review fica mais importante, não menos.

---

Práticas Para Conter A Dívida

Além do review, dá para construir defesas no resto do fluxo. Nenhuma é nova. Todas voltaram a importar.

Use a IA como professora, não só como produtora. Antes de aceitar uma solução numa área que você não domina, peça ao agente para explicar a abordagem, listar alternativas e justificar trade-offs. Interrogue o resultado. O objetivo é sair da interação com modelo mental, não só com código. A mesma ferramenta que cria a dívida pode ajudar a pagá-la, se você pedir.

Registre o porquê, não só o quê. Decisões de arquitetura precisam de rationale escrito, em ADRs ou docs versionados junto do código. A IA é ótima em gerar a implementação e péssima em preservar a intenção. Se a teoria não vira texto, ela morre com o esquecimento do autor.

Limite o tamanho do diff de agente. PR gigante é impossível de compreender de verdade, com ou sem IA. Quanto maior o diff gerado, maior a tentação de aprovar no susto. Diff menor é mais barato de transformar em entendimento.

Mantenha pessoas no caminho crítico das áreas sensíveis. Nem tudo precisa de compreensão profunda, mas o núcleo do sistema precisa. Decida conscientemente onde a teoria não pode se perder e proteja essas áreas de aprovação automática.

E preserve momentos de construção manual. Parte do time precisa continuar escrevendo código nas partes que definem o produto, justamente para manter viva a teoria de como ele funciona.

---

O Papel Do Tech Lead

Para quem lidera, a mudança de mentalidade é a parte difícil. Você vai precisar segurar velocidade aparente em nome de saúde invisível, e isso é impopular.

Comece tornando a dívida cognitiva discutível. Ela não tem um número limpo, mas tem sinais qualitativos claros: reviews ficando mais longos, as mesmas dúvidas se repetindo, complexidade subindo, documentação desalinhada, e o tal medo de mexer em certas áreas. Traga esses sinais para a retrospectiva como você traz lead time. O que não se nomeia, não se gerencia.

Combine sinais. DORA e rework rate mostram instabilidade que já virou problema. Some a isso indicadores de compreensão: quantas áreas do código têm um único dono que entende, quanto tempo um dev novo leva para se virar sozinho, quantos PRs precisam do autor presente para serem revisados. Isso aproxima a conversa do passivo real.

Proteja a segurança psicológica do time. Dev precisa se sentir à vontade para dizer "não entendi o que esse agente fez" sem parecer menos competente. Se admitir falta de entendimento vira sinal de fraqueza, todo mundo vai aprovar no escuro, e a dívida vira política de silêncio.

A maturidade em IA, em 2026, é menos sobre usar mais e mais sobre entender o que se usa. O tech lead é quem segura essa régua quando o resto da organização só quer ver o gráfico subir.

---

Quando A Dívida É Aceitável

Seria desonesto pregar que todo código precisa ser compreendido a fundo. Não precisa, e fingir o contrário só queima energia onde não importa.

Protótipo descartável, spike de exploração, script que roda uma vez, projeto de fim de semana: nesses casos, velocidade sem compreensão é uma troca perfeitamente racional. A dívida cognitiva só é problema quando o código precisa viver, ser mantido e evoluir por um time ao longo do tempo. Para o que vai ser jogado fora, deixe a IA voar.

O erro é não decidir conscientemente em que regime você está. O time entra em modo protótipo "só para validar", o protótipo dá certo, e de repente ele está em produção sem nunca ter passado pela etapa de construir teoria. A dívida foi contraída sem ninguém perceber que tinha mudado de contexto.

A disciplina, então, é menos "sempre entenda tudo" e mais "saiba quando entender importa, e nessas horas, não pule a etapa". Tratar todo código como descartável é tão ingênuo quanto tratar todo código como sagrado.

A pergunta certa antes de aceitar código sem entender é simples: alguém vai precisar manter isso? Se a resposta é sim, a compreensão não é luxo, é parte do trabalho.

---

Principais Aprendizados

• Dívida cognitiva não é dívida técnica: o código funciona, mas o time não entende mais por quê.
• A IA quebrou o acoplamento entre entregar e entender, e o entendimento virou opcional.
• O dado é concreto: estudo controlado mostrou 17% menos compreensão com assistência de IA, mesmo com entrega idêntica.
• Velocity, throughput e taxa de aceitação sobem enquanto a dívida cresce; ela é invisível aos painéis usuais.
• O paradoxo da produtividade nasce daí: indivíduo mais rápido, time mais lento, fricção empurrada para o review.
• O problema é de processo, não do modelo: review para entender, rationale escrito, diff pequeno e IA como professora contêm a dívida.
• Nem todo código precisa ser compreendido; a disciplina é saber quando importa e, aí, não pular a etapa.

---

Conclusão

A promessa da IA no desenvolvimento é entregar mais rápido. Ela cumpre. O que ela não cumpre, e nem promete, é manter viva a teoria do sistema na cabeça das pessoas. Esse trabalho continua sendo humano, e continua sendo caro.

Dívida técnica você vê e prioriza. Dívida cognitiva você só sente, e quase sempre tarde demais, no dia em que precisa mudar algo e descobre que o código virou estranho dentro de casa. O custo escondido da IA não está no que ela escreve. Está no que o time deixou de entender enquanto ela escrevia.

Velocidade sem compreensão não é produtividade. É empréstimo. E, como todo empréstimo, uma hora vence.

---

Fontes e Referências

• Peter Naur — Programming as Theory Building (1985)
• Cognitive Debt: The AI Risk Nobody's Measuring — Michelle Pellon
• Cognitive Debt: AI Coding Agents Outpace Comprehension 5-7x — byteiota
• Cognitive Debt: The Real Cost of AI-Generated Code — DEV Community
• From Technical Debt to Cognitive and Intent Debt — arXiv
• The AI Coding Productivity Paradox — exceeds.ai
• Developer Productivity Metrics 2026: Beyond DORA — byteiota
• Combat AI cognitive debt with engineering fundamentals — Thoughtworks