Addy Osmani alertou para a dívida de compreensão na geração de código com AI em escala

Addy Osmani descreveu um novo problema da era da programação com IA: equipes podem lançar mais código do que realmente conseguem entender. Na superfície, tudo parece normal — testes verdes, pull requests fecham rapidamente — mas internamente acumula uma dívida de compreensão, que depois afeta a qualidade e a velocidade das mudanças.

De Onde Vem a Dívida de Compreensão

Osmani define este termo como o custo oculto da dependência de geradores de código. Se antes o gargalo era o próprio desenvolvimento, agora torna-se a revisão humana: o modelo escreve rápido, o engenheiro lê devagar. Por causa disso, as equipes começam a aceitar mudanças baseadas em sinais de precisão externa — formatação, sintaxe limpa, testes passando — embora o significado arquitetônico da solução permaneça mal compreendido.

O código parece seguro, mas o conhecimento coletivo sobre por que o sistema é estruturado exatamente assim se dissolve gradualmente. O artigo apresenta um exemplo de uma equipe de estudantes que, após algumas semanas, já não conseguia fazer alterações simples sem causar efeitos colaterais. O problema não era desordem no repositório, mas perda de relação de causalidade: ninguém conseguia explicar por que decisões-chave foram tomadas e como os módulos devem interagir entre si.

Quando este mapa mental desaparece, até código bem formatado torna-se território desconhecido. É por isso que a dívida de compreensão é mais perigosa que a dívida técnica ordinária: não faz barulho de antemão e se mascara de produtividade.

Velocidade vs. Compreensão

Esta ideia é parcialmente confirmada por pesquisa da Anthropic que Osmani cita. No experimento, 52 desenvolvedores estudaram uma nova biblioteca: o grupo com assistência de IA completou em aproximadamente o mesmo tempo que o grupo controle, mas mostrou compreensão mais fraca do material em um teste subsequente — 50% versus 67%. A queda mais notável apareceu em tarefas de depuração. A conclusão não é que a IA seja prejudicial em si, mas que o modo de uso passivo prejudica significativamente a aprendizagem.

Em uma equipe real, isso se manifesta em vários lugares ao mesmo tempo:

• um desenvolvedor junior pode gerar mais código do que um senior consegue revisar criticamente
• pull requests crescem mais rápido do que a equipe consegue recuperar o contexto arquitetônico
• aprovar mudanças se transforma de análise em procedimento formal
• métricas de velocidade melhoram, mesmo que a compreensão real do sistema caia

Por Que Testes Não São Suficientes

Osmani argumenta separadamente contra a ideia popular de que o problema pode ser resolvido com testes e especificações detalhadas. Sim, verificação automatizada é necessária, especialmente quando agentes geram código. Mas testes apenas respondem às perguntas que alguém pensou em fazer com antecedência.

Eles não detectam comportamento inesperado, não explicam compromissos ocultos e não mostram se a mudança realmente se alinha com a intenção de design do sistema. Se a IA muda a implementação e reescreve centenas de testes no processo, um pipeline verde ainda não significa que tudo está bem. O mesmo se aplica a especificações.

Qualquer função não-trivial contém muitas decisões implícitas: manipulação de erros, tratamento de casos extremos, compromissos de desempenho, escolhas de estruturas de dados. Uma especificação completamente redigida rapidamente se torna quase o próprio programa, apenas em uma linguagem não-executável. Então a pergunta principal muda: não como gerar mais código, mas como manter a capacidade da equipe de compreendê-lo no nível de comportamento e arquitetura.

A compreensão ainda terá que ser paga, e os juros dessa dívida crescem

rapidamente.

O Que Isso Significa

Para equipes que já estão construindo produtos com programação com IA, isso é um sinal para reconsiderar os próprios critérios de qualidade. Velocidade de merge, volume de código gerado e cobertura de testes não funcionam mais como seguro completo. O mais valioso torna-se o engenheiro que consegue rapidamente identificar risco sistêmico, explicar a lógica da solução e impedir código bonito mas mal compreendido antes da produção — especialmente onde o custo do erro ultrapassa um único lançamento.