Dívida Cognitiva: o custo invisível de construir sem entender

Tenho visto times entregarem mais rápido enquanto entendem menos o que constroem.

Não é exagero. É o que observo, semana após semana, em consultorias com empresas de diferentes portes e maturidades. O código compila. Os testes passam. O deploy acontece. Mas quando pergunto “por que vocês fizeram assim?”, o silêncio é ensurdecedor.

Esse silêncio tem nome: dívida cognitiva.

E ele está se tornando o problema mais urgente, e mais ignorado, da engenharia de software na era da IA.

O conceito

Em 1985, Peter Naur escreveu um paper que deveria ser leitura obrigatória de todo arquiteto de software: “Programming as Theory Building”. A tese dele é simples e devastadora: um programa não é seu código-fonte. Um programa é uma teoria que vive na mente dos desenvolvedores. O que o programa faz, por que ele é assim, como ele pode ser mudado de forma coerente.

Quando essa teoria se perde, o programa continua rodando. Mas não pode mais ser verdadeiramente evoluído. Toda modificação vira um tiro no escuro.

Quatro décadas depois, Margaret-Anne Storey deu a esse fenômeno o enquadramento que faltava:

“Technical debt lives in the code; cognitive debt lives in developers’ minds.”

Dívida técnica mora no código. Dívida cognitiva mora nas mentes das pessoas.

Storey não é uma influenciadora de LinkedIn. É professora na University of Victoria, Canada Research Chair, co-criadora do SPACE framework e do conceito de DevEx. Quando ela formaliza algo, vale prestar atenção.

O caso que ela conta é iluminador. Em um curso de empreendedorismo, um time de estudantes estava construindo um produto ao longo do semestre. Entregas rápidas. Features novas. Pressão por marcos. Tudo indo bem. Até a semana sete. De repente, o time travou. Mudanças simples quebravam coisas inesperadas. A reação instintiva foi culpar dívida técnica: código bagunçado, arquitetura apressada.

Mas o problema era outro. Ninguém conseguia explicar por que certas decisões tinham sido tomadas. Ninguém sabia como as partes se conectavam. O código rodava. A teoria do sistema tinha desaparecido.

Nas palavras de Storey: “They had accumulated cognitive debt faster than technical debt, and it paralyzed them.”

Paralisou.

Dívida Cognitiva não é Dívida Técnica

É tentador tratar dívida cognitiva como “mais um tipo” de dívida técnica. Não é. São fenômenos diferentes que vivem em lugares diferentes e se pagam de formas diferentes.

Martin Fowler fez uma distinção que clarifica tudo. Ele separa cruft (a sujeira: nomes ruins, módulos mal definidos, atalhos) de debt (o custo acumulado de conviver com essa sujeira). No plano técnico, cruft é código ruim e debt é o preço que você paga por não resolver.

No plano cognitivo, a lógica é a mesma, mas o cruft muda de natureza:

“The equivalent of cruft is ignorance, both of the code and the domain the code is supporting.”

Cruft cognitivo é ignorância. Ignorância do domínio. Do código. Das decisões passadas. Das premissas que sustentam a arquitetura. A dívida aparece quando deixamos essa ignorância crescer sem pagar. Ou pagamos juros (cada nova funcionalidade exige mais energia mental, mais alinhamento, mais medo) ou investimos deliberadamente para reconstruir entendimento.

O Quadrante de Fowler, adaptado

Fowler tem um quadrante famoso para classificar dívida técnica: Deliberada/Inadvertida × Prudente/Imprudente. Adaptei para o plano cognitivo:

O quadrante inadvertido-imprudente é o mais perigoso. E é exatamente o mais comum na era da IA generativa. O time nem sabe que não sabe. Ninguém percebe que a teoria está se evaporando. Até o dia que alguém precisa fazer uma mudança significativa e descobre que está no escuro.

Dívida Cognitiva não é Carga Cognitiva

Aqui está uma confusão que preciso desfazer. Se você já trabalhou com Team Topologies (e eu uso o modelo extensivamente nas minhas consultorias), conhece o conceito de carga cognitiva (cognitive load). A ideia de Skelton e Pais, baseada no trabalho de John Sweller, é que times têm capacidade cognitiva limitada e que a arquitetura organizacional deve respeitar isso.

Carga cognitiva e dívida cognitiva não são a mesma coisa.

A distinção fundamental é temporal:

• Carga cognitiva é um snapshot. Quanto peso o time precisa segurar na cabeça agora para fazer seu trabalho. É uma fotografia.
• Dívida cognitiva é um acúmulo. Quanto entendimento o time deixou de construir ao longo do tempo. É uma tendência.

Team Topologies mede o peso agora. Dívida cognitiva mede o que não foi aprendido.

E aqui está o paradoxo mais perigoso da era dos agentes de IA: um time pode ter baixa carga cognitiva e alta dívida cognitiva ao mesmo tempo. A IA faz tudo. O trabalho parece leve. Ninguém está sobrecarregado. Mas ninguém entende o que foi construído. A carga está baixa justamente porque o pensamento foi terceirizado.

Não é coincidência que Storey esteja na interseção desses dois mundos. Ela co-criou o SPACE framework, que mede produtividade de desenvolvedores incluindo dimensões como satisfação, eficiência e flow. Agora ela está formalizando dívida cognitiva. É uma evolução natural: primeiro medimos como os devs se sentem e performam; agora precisamos medir o que eles realmente entendem.

IA como acelerador de dívida cognitiva

Vamos ser diretos: a IA generativa é a maior aceleradora de dívida cognitiva que a engenharia de software já viu.

Não porque a IA seja ruim. Porque ela é boa demais em produzir código sem produzir entendimento.

O código compila. Os testes passam. O PR é aberto. Ninguém entende o que aconteceu.

O nível de risco varia conforme o modo de uso:

Coding agents assíncronos, como o GitHub Copilot Coding Agent que pega uma issue, escreve código, roda testes e abre pull requests, representam o cenário de risco máximo. O humano só vê o resultado final. A teoria do programa nunca é construída. Nasce morta.

Velocidade sem compreensão é adiantamento de problema.

E não sou só eu dizendo. O MIT Media Lab publicou um estudo (“Your Brain on ChatGPT”) usando EEG em 54 participantes divididos em três grupos: um usando LLMs, outro usando buscadores, outro sem ferramentas externas. O resultado? O grupo que usou LLMs consistentemente mostrou as redes neurais mais fracas e menos distribuídas. Quando foram forçados a trabalhar sem IA na quarta sessão, mostraram conectividade cerebral reduzida. Sub-engajamento cognitivo.

Em outras palavras: o cérebro desaprende a pensar quando delega demais.

No Thoughtworks Future of Software Development Retreat, realizado em fevereiro de 2026 em Utah, um evento com cerca de 50 pessoas incluindo Fowler, Storey e outros nomes de peso, alguém cunhou uma frase que ficou na minha cabeça:

“LLMs are drug dealers. They give us stuff, but don’t care about the resulting system or the humans that develop and use it.”

É provocativo. Mas é preciso.

Quem sofre mais

Fowler fez uma observação no retreat que merece atenção de quem lidera times. Desenvolvedores mid-level são os mais vulneráveis à dívida cognitiva. Formaram a carreira sem LLMs, mas ainda não ganharam a experiência profunda que permite usar a IA como ferramenta de alavancagem (como os seniores fazem). Não têm a familiaridade natural dos júniors com a ferramenta, nem o julgamento dos seniores para saber quando desconfiar.

Júniors são um caso diferente. São os mais otimistas, os mais fluentes com LLMs. O risco deles é outro: construir uma carreira inteira sem nunca desenvolver compreensão profunda. Usar a IA como muleta desde o primeiro dia. Funciona no curto prazo. Implode no médio.

Seniores, por outro lado, tendem a usar LLMs como navegadores, para explorar bases de código desconhecidas, buscar padrões, acelerar tarefas operacionais. Mas mantêm o julgamento arquitetural. Como disse Fowler:

“Fully trusting the answer an LLM gives you is foolishness, but it’s wise to use an LLM to help navigate the way to the answer.”

Outra observação importante do retreat veio de Laura Tacho: “The Venn Diagram of Developer Experience and Agent Experience is a circle.” O que é bom para desenvolvedores é bom para agentes. Código modular, nomes descritivos, interfaces claras. Isso ajuda tanto humanos quanto LLMs a entender e evoluir o sistema. DevEx e AgentEx convergem. E quando convergem, reduzem dívida cognitiva dos dois lados.

As consequências

Dívida cognitiva não é um conceito abstrato. Ela se manifesta em sintomas muito concretos que eu vejo em praticamente toda consultoria:

O time paralisa. Alguém diz “não mexe nisso” e todo mundo obedece. Existe um módulo que ninguém ousa modificar. Não porque o código seja ruim. Às vezes é até bem escrito. Mas porque ninguém sabe por que ele é assim. A teoria se perdeu. Qualquer mudança é um risco inaceitável.

Bus factor 1 em componentes críticos. Apenas uma pessoa entende o módulo de pagamentos. Ou o pipeline de dados. Ou a integração com o parceiro X. Se essa pessoa sai de férias, de licença, da empresa, o time fica cego. Isso não é risco teórico. Acontece o tempo todo.

Onboarding fica cada vez mais lento. Um novo desenvolvedor entra no time e leva meses para ser produtivo. Não porque o domínio seja complexo (é complexo, mas não justifica seis meses). O problema é que o conhecimento está na cabeça de três pessoas e em lugar nenhum mais. E nessas três cabeças, está fragmentado.

Change failure rate sobe sem aumento de complexidade técnica. As métricas DORA pioram e ninguém entende por quê. O código não ficou mais complexo. As ferramentas são as mesmas. Mas o entendimento sobre o sistema diminuiu, e cada mudança tem mais chance de causar efeitos colaterais inesperados.

Decisões arquiteturais sem contexto. “Ninguém sabe por que é assim.” Uso esse banco por quê? Essa separação de serviços foi decisão de quem? Qual era o tradeoff? Quando o contexto se perde, o time toma novas decisões sem entender as premissas das decisões anteriores. É construir sobre areia.

Eu preciso ser direto: isso não é problema individual. É problema de liderança.

Se o time não consegue explicar o sistema, falhou a governança técnica. Se ninguém pergunta “vocês entendem o que estão construindo?”, a liderança está medindo as coisas erradas. Velocidade de entrega não é suficiente. Precisamos medir compreensão.

Por que precisamos de um framework

Quando pesquisei o tema a fundo, encontrei algo revelador: ninguém tem um framework integrado para gestão de dívida cognitiva. As peças existem, isoladas:

• Team Topologies mede carga cognitiva, mas é snapshot, não tendência.
• CodeScene faz knowledge maps e bus factor, mas mede ownership de código, não compreensão.
• ADRs preservam contexto de decisões, mas são prática, não framework.
• DORA mede performance de delivery, mas ignora completamente a dimensão de entendimento.
• SPACE tangencia cognição via satisfação e eficiência, mas não é específica para dívida.

Cada uma cobre um pedaço. Nenhuma cobre o todo. E nenhuma foi pensada para o cenário de IA generativa.

Storey reconhece explicitamente esse gap. No final do seu post, ela pede que a comunidade pesquise: “How do we measure cognitive debt? What practices are most effective at preventing or reducing it in AI-augmented development environments?”

É uma pergunta que resolvi enfrentar.

Um framework para gestão de dívida cognitiva

Na eximia.co, estamos desenvolvendo um framework de gestão de dívida cognitiva. É trabalho em andamento, mas já tem estrutura suficiente para compartilhar as ideias centrais.

O modelo se organiza em quatro dimensões:

1. Profundidade de Entendimento

Quão bem o time entende o sistema que construiu? Não basta saber o que o código faz. É preciso saber por que ele é assim e como pode ser mudado.

Criei uma escala simples: do superficial (“sei que tem um serviço de pagamentos”) ao teórico (“sei como modificar isso sem quebrar as premissas”). Na era da IA, código gerado por agentes frequentemente deixa o time no nível superficial ou operacional. Sabe que funciona, não sabe por quê.

2. Distribuição de Conhecimento

Quantas pessoas entendem cada parte crítica do sistema? Um bus factor de 1 em componentes críticos é dívida cognitiva concentrada. O risco não é apenas operacional. É a perda total da teoria do programa quando essa pessoa sai.

3. Preservação de Contexto

As decisões e seu contexto estão registrados de forma acessível? ADRs, design docs, testes expressivos, código auto-documentado. O que não está registrado será perdido. Não é questão de se, é questão de quando.

Aqui entra uma evolução que considero importante: AI Decision Records. ADRs tradicionais registram decisões arquiteturais com contexto. AI Decision Records estendem isso para decisões assistidas por IA: qual ferramenta gerou, qual prompt foi usado, quais alternativas o humano considerou, quem validou a compreensão. Na era dos agentes, precisamos de um registro que capture não apenas o que foi decidido, mas quem realmente entendeu a decisão. Se é que alguém entendeu.

4. Velocidade de Erosão

Quão rápido o time está perdendo entendimento? IA em modo autopilot, rotatividade alta, code reviews superficiais, pressão contínua por velocidade. Tudo acelera a erosão. Pair programming, ADRs, sessões de compartilhamento. Tudo desacelera.

O assessment

Desenvolvemos um instrumento com 20 perguntas cobrindo as quatro dimensões. Cinco por dimensão, escala de 1 a 5. Não vou detalhar todas aqui, mas posso dar uma amostra:

• “Qualquer membro do time pode explicar a arquitetura geral do sistema em 15 minutos?”
• “Quando código é gerado por IA, pelo menos uma pessoa revisa com profundidade suficiente para explicá-lo?”
• “Nenhum componente crítico depende de uma única pessoa para ser entendido?”
• “Code reviews incluem discussão substantiva, não apenas LGTM (looks good to me)?”

A pontuação geral indica a saúde cognitiva do time. Abaixo de 40 (de 100), o risco é alto. Acima de 80, o time está saudável. Mas o número absoluto importa menos que a tendência: está melhorando ou piorando sprint a sprint?

Níveis de maturidade

Identificamos cinco níveis:

1. Inconsciente. O time nem sabe que tem dívida cognitiva. “Funciona” é o único critério.
2. Consciente. Reconhece que tem áreas cegas, mas não mede nem trata.
3. Medindo. Tem métricas, sabe onde a dívida está.
4. Gerenciando. Toma decisões conscientes sobre quando aceitar e quando pagar.
5. Otimizando. Gestão de dívida cognitiva é parte da cultura. Novos membros são produtivos rápido. Nenhum componente tem bus factor 1.

A maioria dos times que encontro está entre 1 e 2. Alguns poucos chegam a 3.

O Cognitive Debt Index

Estamos trabalhando em uma métrica composta, o Cognitive Debt Index (CDI), que combina o score do assessment (40%), bus factor médio (20%), cobertura de ADRs (15%), tendência de onboarding time (10%) e tendência de change failure rate (15%). A ideia é ter um número único que seja rastreável ao longo do tempo. Não é perfeito. Nenhuma métrica composta é. Mas dá direção.

Princípios orientadores

Dois princípios que considero não-negociáveis:

“IA como par, não como piloto.” Em modo par, a IA sugere e o humano decide, entende e aprende. Em modo piloto, a IA executa e o humano supervisiona, acumulando dívida. Para cada bloco significativo de código gerado, alguém deve poder explicar: o que faz, por que essa abordagem, quais os edge cases, como modificar se os requisitos mudarem. Se ninguém pode responder as quatro perguntas, a dívida acabou de aumentar.

“Compreensão antes do merge.” Nenhum PR é mergeado sem que pelo menos uma pessoa, além do autor ou da IA, demonstre compreensão substantiva da mudança. Não é “LGTM”. É “eu entendi o que isso faz e por quê”. Parece burocrático? Menos do que descobrir três meses depois que ninguém no time sabe como o módulo funciona.

Por onde começar

Se você leu até aqui e se identificou, se reconheceu seu time em alguma dessas descrições, aqui estão quatro coisas que você pode fazer na próxima semana:

4. Identifique as zonas proibidas. Pergunte ao time: “Quais partes do sistema vocês evitam modificar?” As respostas vão revelar onde a dívida cognitiva está concentrada.
5. Calcule o bus factor dos 5 componentes mais críticos. Se algum deles tem bus factor 1, você tem um problema urgente. Use git-blame ou simplesmente pergunte: “Se fulano sair, quem mais sabe como isso funciona?”
6. Escreva 3 ADRs retroativos. Pegue as três decisões arquiteturais mais importantes do último trimestre e documente o contexto. Por que foi feito assim? Quais eram as alternativas? Quem decidiu? Se a IA participou, registre isso também.
7. Institua uma sessão mensal de “explique no quadro branco.” Um membro do time apresenta um componente para os outros. O objetivo não é a apresentação. É a discussão. É ali que a teoria do programa se reconstrói.

Se quiser ir mais fundo (assessment completo, definição de práticas por dimensão, implementação de AI Decision Records, acompanhamento do CDI), é o tipo de trabalho que fazemos na eximia.co. Converse comigo.

Conclusão

Comecei falando de times que entregam mais rápido enquanto entendem menos. Esse é o sintoma.

A causa é que estamos tratando IA como piloto quando deveria ser par. Estamos medindo velocidade de entrega e ignorando velocidade de erosão do entendimento. Estamos otimizando para o sprint e acumulando dívida para o trimestre.

Arquitetura sempre foi sobre julgamento. Sobre entender tradeoffs, sobre saber quando dizer não, sobre manter a coerência do sistema ao longo do tempo. Gestão de dívida cognitiva agora é parte central desse julgamento.

Porque dívida cognitiva não quebra o build.

Quebra a capacidade do time de pensar.