- O desenvolvimento assistido por IA faz a velocidade de produção de código superar a velocidade de compreensão humana, gerando “dívida cognitiva”
- Mesmo que o código funcione corretamente e passe nos testes, acumula-se um estado em que os próprios desenvolvedores não entendem a estrutura do código nem as razões por trás dele
- Os limites da revisão, a perda de conhecimento tácito da organização e a deficiência de aprendizado de desenvolvedores iniciantes aceleram essa dívida
- As organizações medem apenas métricas centradas em velocidade (DORA, story points etc.) e não conseguem captar a falta de compreensão
- Quanto maior a distância entre produtividade e compreensão, maior o risco de, no longo prazo, isso levar a falhas de manutenção, ruptura do conhecimento e estagnação no crescimento dos engenheiros
Defasagem de compreensão (The Comprehension Lag)
- A escrita manual de código executa ao mesmo tempo os processos de produção e assimilação, e o atrito da digitação estimula o pensamento
- Ao escrever código, formam-se naturalmente modelos mentais e intuição
- O desenvolvimento assistido por IA separa esse processo: a velocidade de saída dispara, mas a velocidade de compreensão continua limitada pelas capacidades humanas
- Essa lacuna entre saída e compreensão é justamente a dívida cognitiva e, diferente da dívida técnica, não aparece nas métricas de velocidade
- O problema se revela depois em métricas de confiabilidade, como aumento do MTTR e da taxa de falha em mudanças
O que as organizações realmente medem (What Organizations Actually Measure)
- As organizações medem apenas entregas visíveis (quantidade de funcionalidades, commits, velocidade de revisão etc.)
- No passado, entrega e compreensão estavam conectadas, então ao colocar uma funcionalidade em produção assumia-se que havia entendimento
- Porém, na era da IA, é possível entregar funcionalidades mesmo com apenas uma compreensão superficial, e essa suposição já não é mais válida
- Como as métricas organizacionais não captam a falta de compreensão, os sistemas de avaliação de desempenho e recompensa ficam distorcidos
O dilema do revisor (The Reviewer’s Dilemma)
- Com IA, um júnior pode gerar código mais rápido do que um sênior
- Revisores seniores não têm tempo para examinar em profundidade volumes tão grandes de código, então acabam sacrificando a profundidade da revisão
- Como resultado, desmorona a premissa de que “código revisado = código compreendido”
- Como a pressão organizacional prioriza velocidade, fortalece-se uma cultura focada em volume processado, e não em qualidade da revisão
O padrão de burnout (The Burnout Pattern)
- Engenheiros que usam ferramentas de IA vivenciam um cansaço em que alta produção e baixa confiança coexistem
- O código funciona, mas persiste a ansiedade de não entender completamente o sistema que eles próprios criaram
- Um sistema de avaliação centrado em velocidade transforma o tempo investido em compreensão profunda em desvantagem, acelerando a dívida cognitiva
O colapso da memória organizacional (When Organizational Memory Fails)
- O conhecimento organizacional é composto por conhecimento explícito documentado e conhecimento tácito na cabeça dos desenvolvedores
- O desenvolvimento com IA encurta o processo de formação de conhecimento tácito (a experiência de implementar diretamente), impedindo o acúmulo de conhecimento
- Como resultado, o sistema continua funcionando, mas as pessoas capazes de entendê-lo vão desaparecendo gradualmente
- Quando surge um problema, chega-se a um estado em que ninguém consegue explicar o contexto do sistema
O acúmulo da dívida cognitiva (How the Debt Compounds)
- Primeiro, quanto mais antigo o código, maior o risco — um código já compreendido de forma incompleta quando foi escrito se torna totalmente opaco
- Segundo, o tempo de recuperação em resposta a incidentes cresce drasticamente — surge a situação de depurar “uma caixa-preta criada por outra caixa-preta”
- Terceiro, a ausência de futuros engenheiros seniores — a dependência de IA elimina a curva de aprendizado e cria um vazio de liderança no longo prazo
A visão do diretor (The Director’s View)
- A liderança percebe apenas sinais positivos como ganho de produtividade, redução de prazos e maior eficiência da equipe
- Como não existem métricas que meçam “profundidade de compreensão” ou “capacidade de explicação”, a dívida cognitiva não é reportada
- Por isso, a tomada de decisão orientada por dados é racional, mas incompleta, e o risco real permanece oculto
Limites deste modelo (Where This Model Breaks)
- O conceito de dívida cognitiva não se aplica da mesma forma a todo tipo de trabalho
- Pode ser adequado para tarefas repetitivas simples ou experimentos rápidos
- No passado também havia diferenças individuais no nível de compreensão, então isso pode ser menos um fenômeno novo e mais uma mudança na distribuição
- No futuro, melhorias em ferramentas e documentação também podem reduzir essa lacuna de compreensão
O problema da medição (The Measurement Problem)
- As organizações só otimizam o que conseguem medir
- Velocidade é mensurável, mas compreensão não é
- Enquanto a compreensão não se refletir nos sistemas de avaliação, os incentivos centrados em velocidade serão mantidos
- Isso não é uma falha de indivíduos ou gestores, mas o resultado de um sistema de medição herdado de uma era passada e desalinhado com a realidade atual
- No fim, essa lacuna pode aparecer como aumento do custo de manutenção, demora na resposta a incidentes e exposição de vulnerabilidades do sistema
- O texto conclui que: “os sistemas são otimizados de acordo com o que se mede. Mas o que medimos agora já não captura o que realmente importa”
3 comentários
Tenho pensado em algo parecido ultimamente, então ontem escrevi um post no blog sobre dívida cognitiva. Parece que todo mundo está passando por preocupações parecidas.
Como devemos fazer para entender o código? Será que precisamos até criar quizzes com base no código interno para medir isso?
Comentários do Hacker News
Minha experiência dos últimos meses bate muito com o conteúdo do artigo
O projeto em que trabalho cresceu de forma constante, mas o número de engenheiros na verdade diminuiu
Aumentamos a dependência de testes e migramos para desenvolvimento baseado em simulador. Raramente validamos no sistema real, e, quando isso acontece, lidamos com as partes mais complexas
Desde o ano passado, comecei a perceber que esquecia rapidamente os detalhes até de funcionalidades em que tinha trabalhado por meses. Isso já acontecia antes mesmo de os agentes de codificação serem adotados de fato
Depois que os agentes entraram, a revisão de PR ficou muito mais implícita, então preciso me concentrar conscientemente porque o contexto não fica na cabeça. Meus colegas de equipe relataram a mesma experiência
Agora estamos tentando várias coisas, como commitar junto com o código o plano do agente. Por causa disso, o processo está se tornando mais sistemático e explícito
Ainda assim, parecia que o gerente de engenharia quase não percebia esse aumento da carga cognitiva
A premissa do texto, de que “o desenvolvedor lembra do código que escreveu há 6 meses”, está errada
Desde antes, sempre foi mais fácil entender código ao escrever do que ao ler. Joel Spolsky também disse que “ler código é mais difícil do que escrevê-lo”
O problema de “código que ninguém entende” já existia antes da IA
Por exemplo, como no caso da remoção do código do Pinball da Microsoft, já houve situações em que um código terceirizado antigo era tão complexo que ninguém conseguia entender e, no fim, a funcionalidade foi abandonada
O caso da base de código do Oracle RDBMS é parecido
A expressão “um sistema estranho que funciona normalmente” me marcou
Isso é parecido com a sensação que um desenvolvedor tem ao migrar para gerente. Quanto mais você se afasta do código, mais o entendimento fica abstrato e desconectado
A parte mais dolorosa foi: “o engenheiro que busca entender em profundidade fica para trás nas métricas de velocidade”
O mercado valoriza velocidade mais do que qualidade e, no fim, isso cria uma estrutura em que o engenheiro cuidadoso é demitido
Talvez agora estejamos entrando na era do “LGTM, LLM”
A indústria sempre corre demais para um lado antes de depois encontrar equilíbrio. O problema é a expectativa impossível de exigir 20 vezes mais produtividade e 100% de responsabilidade
No fim, ou se abre mão do entendimento, ou se aceita no máximo um ganho de produtividade de cerca de 20%
Isso me lembra a filosofia Worse Is Better, de Richard Gabriel
Código gerado por IA muitas vezes escolhe simplicidade em vez de precisão, mas a abordagem pragmática de que “se funciona, venceu” pode acabar triunfando
Uma vez que existe um sistema funcional, ele pode ser melhorado gradualmente
Nossa equipe também passou exatamente pelo fenômeno descrito no artigo nos últimos 6 meses
A frase central, de que o desenvolvimento assistido por IA rompe o acúmulo de conhecimento implícito, está certíssima
Ainda assim, esse fenômeno pode ser uma fase transitória
No longo prazo, os LLMs talvez organizem bem a estrutura do código e ofereçam valor em um nível meta, ajudando as pessoas a compreender profundamente apenas quando necessário
Quando falta documentação, a equipe de suporte ao produto também sofre bastante
Quando o cliente pergunta como o produto funciona, se nem o engenheiro conhece bem o código que escreveu, fica difícil responder
Se a velocidade das atualizações é alta, outras equipes têm dificuldade para acompanhar
Algo parecido aconteceu quando surgiram as linguagens de alto nível, e no fim deu tudo certo
Então será que tudo bem se os LLMs abstraírem também o entendimento do código?
A diferença é que compiladores são determinísticos e LLMs são probabilísticos