Dívida Cognitiva: O Custo Invisível Que Nenhum Benchmark Mede

Martin Fowler publicou esta semana suas notas do Pragmatic Summit e do retiro da Thoughtworks sobre o futuro do desenvolvimento de software. O texto cobre território amplo — desde o papel de desenvolvedores seniores com LLMs até a evolução de IDEs. Mas as duas observações mais importantes do texto são tratadas como tópicos secundários. E é precisamente nelas que mora o problema real.

A primeira: dívida cognitiva. A segunda: intensificação do trabalho.

Fowler descreve ambas como riscos emergentes. Nós argumentamos que são sintomas de uma causa estrutural que ele não nomeia: ausência de governança.

Dívida Cognitiva Não É Dívida Técnica

Margaret-Anne Storey, pesquisadora da Universidade de Victoria, cunhou o termo “dívida cognitiva” em publicação de 9 de fevereiro de 2026 para descrever algo que muitas equipes sentem, mas poucas articulam: a perda progressiva de entendimento compartilhado sobre por que um sistema funciona como funciona.

Dívida técnica é um problema de código. Você pode medi-la, localizá-la, refatorá-la. Dívida cognitiva é um problema de pessoas. Vive na cabeça dos engenheiros — ou, mais precisamente, na ausência do que deveria estar lá.

Quando um desenvolvedor gera código via IA, o código pode estar limpo. Os testes podem passar. A funcionalidade pode estar correta. Mas se o desenvolvedor não entende as decisões de design incorporadas naquele código — por que esta arquitetura e não outra, por que este padrão e não aquele — o conhecimento institucional se fragmenta. A equipe herda código funcional e compreensão quebrada.

A distinção importa porque determina a solução. Dívida técnica se resolve com refatoração. Dívida cognitiva se resolve com governança — processos que garantem que decisões de design sejam documentadas, revisadas e compartilhadas, independentemente de quem (ou o quê) escreveu o código.

Fowler identifica o problema corretamente. Mas o trata como uma preocupação técnica entre outras. Não é. É uma preocupação organizacional de primeira ordem.

A Contradição Que Ninguém Quer Discutir

Aqui entra a evidência que torna a dívida cognitiva urgente, não apenas interessante.

Aruna Ranganathan e Xingqi Maggie Ye, da UC Berkeley, publicaram na Harvard Business Review em fevereiro de 2026 os resultados de um estudo etnográfico de oito meses com 40 trabalhadores em uma empresa de tecnologia. A conclusão contraria a narrativa dominante: IA não reduz trabalho. IA intensifica trabalho.

Os trabalhadores observados “trabalharam em ritmo mais rápido, assumiram escopo mais amplo de tarefas e estenderam o trabalho para mais horas do dia, frequentemente sem que fossem solicitados.” Burnout foi relatado por 62% dos associados, contra 38% do C-suite.

Repare na assimetria. Quem decide adotar IA (C-suite) sofre menos com suas consequências. Quem opera IA (associados) absorve a intensificação. A ferramenta que supostamente alivia carga de trabalho está, na prática, aumentando-a — e o aumento recai desproporcionalmente sobre quem tem menos poder para recusá-lo.

Agora considere essa evidência ao lado de outra que Fowler não cita. O estudo METR de julho de 2025 revelou que desenvolvedores experientes foram 19% mais lentos com assistência de IA — apesar de perceberem-se 20% mais rápidos. A percepção e a realidade divergem em direções opostas.

Junte as duas descobertas: IA faz as pessoas trabalharem mais (HBR), trabalharem mais devagar sem perceber (METR), e perderem o entendimento do que estão construindo (Storey). Isso não é um problema de ferramentas. É uma crise de governança disfarçada de ganho de produtividade.

O Problema dos Desenvolvedores Mid-Level É Mais Grave Do Que Parece

Fowler observa — e outros palestrantes do Pragmatic Summit confirmam — que desenvolvedores mid-level enfrentam o maior risco de deslocamento. Juniores se beneficiam de IA como mentora. Seniores aproveitam LLMs a partir de décadas de intuição arquitetural. Mid-level ficam no vazio: não têm a adaptabilidade do iniciante nem a profundidade do veterano.

A observação é correta. Mas o enquadramento é incompleto.

O risco real não é que mid-levels sejam “substituídos” por IA. É que mid-levels são exatamente o estrato que carrega conhecimento institucional. São eles que sabem por que o sistema de pagamentos usa aquela arquitetura específica. São eles que lembram que o módulo de relatórios foi construído daquele jeito por causa de uma restrição regulatória de 2022. São eles que traduzem decisões arquiteturais de seniores em implementação concreta.

Se esse estrato se fragmenta — por deslocamento, burnout ou rotatividade acelerada — a dívida cognitiva não cresce linearmente. Ela explode. Porque o conhecimento que eles carregam não está documentado em nenhum repositório. Está nas conversas de corredor, nas revisões de código, na memória coletiva de decisões tomadas sob pressão.

Deslocar mid-levels sem resolver a dívida cognitiva é remover os portadores de conhecimento institucional e depois perguntar por que ninguém entende o sistema.

Developer Experience É Agent Experience — Mas a Implicação É Outra

Laura Tacho, CTO da DX, fez uma observação no Pragmatic Summit que Fowler reproduz: “O diagrama de Venn de Developer Experience e Agent Experience é um círculo.”

A observação é precisa. Código modular, nomenclatura clara, documentação atualizada — tudo que torna um codebase compreensível para humanos também o torna compreensível para agentes de IA.

Mas a implicação que Tacho e Fowler extraem — “invista em qualidade de código porque beneficia ambos” — para cedo demais.

Se Developer Experience e Agent Experience são o mesmo círculo, então a qualidade do seu codebase determina simultaneamente a produtividade dos seus engenheiros e a eficácia dos seus agentes de IA. Isso significa que dívida técnica não é mais apenas um problema de velocidade de desenvolvimento. É um problema de capacidade de automação. Cada atalho arquitetural, cada nome de variável obscuro, cada módulo sem documentação reduz a eficácia de qualquer agente que você implante.

A implicação real não é “invista em DX”. É: governança de código é pré-requisito para governança de IA. Organizações que negligenciaram qualidade de codebase por anos não podem simplesmente adicionar agentes de IA e esperar resultados. Primeiro, precisam resolver a dívida que torna seus sistemas incompreensíveis — para humanos e para máquinas.

O Custo Oculto da Troca de Contexto

Camille Fournier, no mesmo evento, observa que gerenciar múltiplos agentes de IA introduz fadiga de troca de contexto similar à gestão de equipes humanas. O “programador supervisor” — que delega a vários agentes e revisa seus resultados — enfrenta a mesma sobrecarga cognitiva de um gerente que faz microgestão.

Fowler trata isso como uma questão em aberto. Não deveria ser.

A pesquisa sobre troca de contexto é extensa e inequívoca. Gerald Weinberg estimou que cada projeto paralelo reduz a produtividade em 20%. Estudos de Gloria Mark na UC Irvine mostram que interrupções aumentam estresse e reduzem qualidade. A neurociência é clara: o cérebro humano não faz multitarefa — faz alternância sequencial, com custo cumulativo a cada troca.

Se agentes de IA multiplicam o número de fluxos paralelos que um desenvolvedor supervisiona, não estamos reduzindo carga de trabalho. Estamos transformando desenvolvedores em gerentes de projeto — e gerentes de projeto cognitivamente sobrecarregados produzem exatamente os tipos de erro que dívida cognitiva descreve: decisões sem compreensão, aprovações sem revisão, código aceito sem entendimento.

A troca de contexto não é um custo oculto. É o mecanismo pelo qual dívida cognitiva se acumula.

O Que Fowler Não Conecta

O texto de Fowler é valioso. Identifica problemas reais que a maioria da indústria prefere ignorar. Mas trata cada observação como um fragmento isolado — que é, de fato, o formato da publicação.

O que ele não faz é conectar os fragmentos num diagnóstico coerente:

Dívida cognitiva se acumula quando equipes perdem entendimento compartilhado (Storey)
IA intensifica trabalho em vez de reduzi-lo (Ranganathan e Ye, HBR)
Desenvolvedores experientes trabalham mais devagar com IA sem perceber (METR)
Mid-levels — portadores de conhecimento institucional — enfrentam maior risco (Pragmatic Summit)
Troca de contexto com múltiplos agentes degrada a capacidade cognitiva (Fournier)

Lidos em conjunto, esses fragmentos contam uma história diferente da narrativa dominante. A história não é “IA está transformando o desenvolvimento de software”. É: IA está introduzindo um novo tipo de risco organizacional que se acumula silenciosamente, não aparece em métricas convencionais de produtividade e se manifesta como crise quando já é tarde para corrigir sem custo significativo.

Esse risco tem nome. Chamamos de dívida cognitiva organizacional. E, diferente da dívida técnica, não se resolve com refatoração. Resolve-se com governança.

O Que Falta na Análise

Há uma ausência notável nas reflexões de Fowler: segurança.

A Veracode reporta que 45% do código gerado por IA contém vulnerabilidades. Se equipes estão gerando mais código, com menos compreensão, e revisando sob fadiga de troca de contexto — a superfície de ataque se expande silenciosamente.

Dívida cognitiva não é apenas um risco de produtividade. É um vetor de risco de segurança. Código que ninguém entende completamente é código que ninguém pode auditar completamente.

Governança Como Resposta Estrutural

A resposta para dívida cognitiva não é “treinar melhor os desenvolvedores” ou “escolher melhores ferramentas de IA”. Essas são respostas individuais para um problema sistêmico.

A resposta é governança — mas não governança como burocracia. Governança como arquitetura organizacional.

Na prática, isso significa:

Decisões de design documentadas por padrão. Não como exercício opcional, mas como requisito do processo. Se um agente de IA gerou uma decisão arquitetural, a razão precisa estar registrada — pelo humano que aceitou a decisão, não pela IA que a sugeriu.

Revisão calibrada por risco. Nem todo código gerado por IA precisa da mesma profundidade de revisão. Mas código que afeta segurança, conformidade ou decisões de negócio precisa de revisão humana que demonstre compreensão, não apenas aprovação.

Métricas de compreensão, não apenas de produção. Medir quantas linhas de código uma equipe produz é fácil. Medir se a equipe entende o que produziu é difícil — e necessário. Testes de conhecimento sobre o próprio sistema, rotação deliberada de responsabilidades, sessões de design review que exigem explicação: são mecanismos que detectam dívida cognitiva antes que ela se torne crise.

Proteção deliberada do estrato mid-level. Se mid-levels carregam conhecimento institucional, sua retenção e desenvolvimento não são apenas questões de RH. São questões de governança de conhecimento. Organizações que tratam mid-levels como custo a ser otimizado estão liquidando um ativo que não sabem precificar.

A Pergunta Que Importa

A indústria de tecnologia está obcecada com uma pergunta: “Quanto mais produtivos podemos ser com IA?”

A pergunta certa é outra: “Quanto do que produzimos nós realmente entendemos?”

Se a resposta é “cada vez menos” — e a evidência sugere que é — então velocidade de produção é uma métrica enganosa. Estamos produzindo mais e compreendendo menos. Estamos gerando código e acumulando dívida. Estamos ganhando velocidade e perdendo controle.

Fowler, com a honestidade intelectual que o caracteriza, documenta os sintomas. O diagnóstico — e a resposta — exigem ir além de fragmentos.

Fontes

Margaret-Anne Storey. “Cognitive Debt in Software Development.” Publicação de 9 de fevereiro de 2026.
Aruna Ranganathan e Xingqi Maggie Ye. Estudo etnográfico sobre intensificação do trabalho com IA. Harvard Business Review, fevereiro de 2026. Amostra: 40 trabalhadores, 8 meses (abril-dezembro de 2025).
METR. Estudo sobre produtividade de desenvolvedores com IA. Julho de 2025. Resultado: desenvolvedores experientes 19% mais lentos com assistência de IA.
Laura Tacho. “Developer Experience Is Agent Experience.” Pragmatic Summit, 11 de fevereiro de 2026, São Francisco.
Camille Fournier. Observações sobre troca de contexto em fluxos multi-agente. Pragmatic Summit, 2026.
Martin Fowler. “Fragments: February 13.” martinfowler.com, 13 de fevereiro de 2026.
Veracode. Relatório sobre vulnerabilidades em código gerado por IA: taxa de 45%.

No Victorino Group, ajudamos organizações a construir governança que transforma capacidade de IA em resultado confiável — sem acumular a dívida cognitiva que ninguém mede até que seja tarde demais. Se esse tema importa para sua organização, vamos conversar.