O Muro dos 10%: Por Que a Produtividade com IA Estagna

A DX pesquisou 121.000 desenvolvedores em 450 empresas. 92,6% usam assistentes de codificação com IA pelo menos mensalmente. Código gerado por IA agora representa 26,9% dos merges em produção. Desenvolvedores relatam economizar aproximadamente quatro horas por semana.¹ A produtividade não passou de 10%.

Esse número se manteve estável por três trimestres consecutivos.^{1 2} A adoção cresceu. O volume de código cresceu. As ferramentas melhoraram. Os ganhos não. Laura Tacho, CTO da DX, enquadrou diretamente: “Isso é realmente um problema de gestão. O hype fez parecer que simplesmente experimentar IA traria retorno automaticamente.”³

O Relatório DORA de 2025 encontrou a divergência. Organizações com práticas de engenharia sólidas viram a IA amplificar suas forças existentes. Organizações com práticas fracas viram a IA amplificar suas disfunções existentes. Mesmas ferramentas. Resultados opostos. O relatório concluiu: “O papel principal da IA no desenvolvimento de software é o de amplificador. Ela magnifica as forças das organizações de alto desempenho e as disfunções das que estão com dificuldades.”⁴

O muro não é um problema de modelo. É um problema de infraestrutura. Modelos melhores não vão romper um muro construído com verificação ausente, contexto ausente e governança ausente. Os posts complementares a este descrevem a arquitetura: Anatomy of a Claw explica a camada de orquestração, The Fabrication Firewall explica o portão de saída, e Context Is Architecture explica o sistema de injeção de contexto. O post abaixo explica por que esses sistemas existem.

TL;DR

121.000 desenvolvedores pesquisados, 92,6% de adoção, produtividade estagnada em 10%. Três causas-raiz explicam o teto: fome de contexto (a IA adivinha sem conhecimento do projeto), vácuo de verificação (código é entregue mais rápido do que a revisão se adapta) e lacuna de governança (a IA contorna padrões que humanos aplicam). O DORA descobriu que a IA amplifica tanto forças quanto disfunções dependendo da infraestrutura ao seu redor.⁴ Romper o muro requer infraestrutura ao redor da IA, não uma IA melhor. O post documenta uma tentativa N=1 de construir essa infraestrutura, com números específicos de um sistema rodando 84 hooks, 43 skills e 19 agentes.

O que a pesquisa diz

O conjunto de dados da DX abrange 4,2 milhões de desenvolvedores observados entre novembro de 2025 e fevereiro de 2026, com um painel detalhado de 121.000 desenvolvedores em 450 empresas.¹ Os números contam duas histórias.

A história da adoção é inequívoca. Assistentes de codificação com IA atingiram penetração quase universal. A DX mediu 92,6% de adoção mensal e aproximadamente 75% de uso semanal.¹ A pesquisa de 2025 do Stack Overflow encontrou que 84% dos desenvolvedores usam ou planejam usar ferramentas de IA.⁶ A JetBrains mediu 85% de uso regular entre 24.534 desenvolvedores em 194 países.⁷ O teto de adoção está próximo.

A história da produtividade estagnou. A DX mediu uma média de quatro horas economizadas por semana, sem mudança em relação às 3,6 horas do trimestre anterior.^{1 2} Código gerado por IA subiu de 22% para 26,9% do código mergeado, mas o volume adicional não se traduziu em produção adicional.^{1 2} Laura Tacho identificou a matemática: desenvolvedores gastam aproximadamente 20% do seu tempo escrevendo código. Uma melhoria de 10% em 20% do dia de trabalho é uma melhoria de 2% no geral. “Velocidade de digitação nunca foi o gargalo.”⁸

A linha crítica é a última. O relatório DORA de 2024 pesquisou 39.000 profissionais e descobriu que para cada 25% de aumento na adoção de IA, o throughput de entrega diminuía estimadamente 1,5% e a estabilidade de entrega diminuía 7,2%.⁵ O relatório DORA de 2025 descobriu que a relação IA-throughput mudou da correlação negativa observada em 2024 para uma positiva, mas a estabilidade de entrega permaneceu negativamente associada à adoção de IA.⁴ A adoção de IA continuou a se correlacionar com instabilidade crescente mesmo com a melhora do throughput.

A divergência importa mais do que as médias. O METR estudou 16 desenvolvedores experientes de código aberto trabalhando em 246 issues reais de repositórios e descobriu que eles levaram 19% mais tempo com ferramentas de IA do que sem.⁹ O ensaio controlado randomizado do Google com 96 engenheiros encontrou uma melhoria de velocidade de 21%, mas o resultado não foi estatisticamente significativo (IC 95% cruzou zero).¹⁰

A McKinsey encontrou ganhos de 35-50% em tarefas simples mas menos de 10% em tarefas de alta complexidade, e desenvolvedores juniores usando IA foram 7-10% mais lentos em um estudo com 40 de seus próprios desenvolvedores.¹¹ O padrão: a IA acelera as partes do desenvolvimento que nunca foram o gargalo.

As empresas que romperam o muro não usaram modelos melhores. Construíram infraestrutura que capturava o que os modelos deixavam passar.

Por que o muro existe

Três causas-raiz explicam o platô. Cada uma opera independentemente. Juntas formam um teto que modelos melhores não conseguem penetrar.

Fome de contexto

Assistentes de codificação com IA operam sobre o código visível no arquivo atual e qualquer contexto que caiba na janela do prompt. Eles não conhecem suas decisões de arquitetura, seus contratos de API, suas restrições de deploy ou as convenções de nomenclatura da sua equipe a menos que alguém injete essa informação.

Sem contexto específico do projeto, o modelo adivinha. Ele alucina caminhos de arquivo que seguem convenções plausíveis mas não existem. Ele gera chamadas de API para endpoints que correspondem a padrões comuns mas não aos seus padrões. Ele sugere imports de pacotes que seu projeto não usa.¹²

A Faros AI analisou telemetria de 10.000 desenvolvedores em 1.255 equipes e descobriu que pull requests assistidos por IA são 154% maiores que os não assistidos.¹² PRs maiores carregam mais área de superfície para erros dependentes de contexto. A IA gera código com confiança. O código compila. O código não leva em conta a restrição documentada em uma página do Confluence que a IA nunca viu.

O comportamento não é um problema de alucinação no sentido de segurança do modelo. O modelo está funcionando exatamente como projetado: prevendo código provável dado o contexto disponível. O problema é que o contexto disponível exclui a maior parte do que importa para a correção em um codebase específico.

Vácuo de verificação

A IA gera código mais rápido do que os processos de revisão existentes conseguem absorver. A Faros descobriu que PRs assistidos por IA levam 91% mais tempo para revisar.¹² Desenvolvedores completam 21% mais tarefas e fazem merge de 98% mais pull requests, mas o pipeline de revisão lida com produção em velocidade humana.¹²

O estudo de código inseguro de Stanford quantificou a dimensão de segurança. Pesquisadores deram a 47 desenvolvedores tarefas de codificação com e sem assistência de IA. O grupo com assistência de IA escreveu soluções inseguras com mais frequência em quatro de cinco tarefas. Na tarefa de SQL injection, 36% do grupo com IA escreveu código vulnerável contra 7% do grupo de controle. Participantes com assistência de IA eram mais propensos a acreditar que escreveram código seguro mesmo quando não tinham.¹³ A combinação de produção mais rápida e falsa confiança elevada cria uma lacuna de verificação que revisão manual não consegue fechar em escala.

A GitClear analisou 153 milhões de linhas de código alteradas e descobriu que o code churn (código reescrito dentro de duas semanas de ter sido escrito) foi projetado para dobrar em 2024 em relação às linhas de base pré-IA.¹⁴ O aumento de volume das ferramentas de IA cria retrabalho que compensa parcialmente os ganhos de produtividade. A pesquisa de 2025 do Stack Overflow confirma o atrito: 66% dos desenvolvedores relatam gastar mais tempo corrigindo código gerado por IA “quase certo”.⁶

Lacuna de governança

Código gerado por IA contorna os mecanismos de governança que desenvolvedores humanos internalizam. Um desenvolvedor sênior sabe verificar o guia de estilo, rodar o linter, atualizar o changelog e notificar o líder técnico sobre mudanças de arquitetura. Um assistente de IA gera uma solução que satisfaz o prompt. A lacuna entre “compila e passa nos testes” e “atende aos padrões organizacionais” é governança.

Os pesquisadores da McKinsey atribuíram a desaceleração dos desenvolvedores juniores à lacuna entre código gerado e contexto organizacional. Desenvolvedores juniores carecem do julgamento para avaliar se a saída da IA atende a padrões que eles ainda não internalizaram. Sem infraestrutura de governança que codifique esses padrões como verificações automatizadas, a saída da IA flui sem checagem.

A lacuna de governança se acumula entre equipes. O utilitário gerado por IA de um desenvolvedor duplica o módulo existente de outro desenvolvedor. Dois endpoints gerados por IA usam formatos de erro diferentes para a mesma API. Migrações geradas por IA seguem uma convenção de nomenclatura diferente do padrão da equipe. Cada violação é pequena. O efeito cumulativo é um codebase que se distancia de suas próprias convenções mais rápido do que a revisão consegue corrigir.

Como é o outro lado

A descoberta do DORA descreve duas populações usando ferramentas idênticas. Organizações com práticas sólidas viram a IA amplificar suas forças. Organizações com práticas fracas viram a IA amplificar suas disfunções.⁴ A variável entre elas não é qual IA usam. É a infraestrutura ao redor da IA.

Cada causa-raiz mapeia para uma correção de infraestrutura. A tabela abaixo mapeia a cadeia do problema à solução, com uma implementação concreta de um sistema que construí e documentei nos posts complementares. O exemplo é uma tentativa com números específicos, não uma prescrição universal.

Injeção de contexto aborda a fome garantindo que o modelo receba informações específicas do projeto em cada prompt. Um hook dispatcher dispara nove handlers sequenciais que injetam a data atual, branch do Git, diretório de trabalho, convenções do projeto, contexto da tarefa ativa e restrições arquiteturais. O modelo recebe 200-400 tokens de contexto de ancoragem antes de processar a solicitação do usuário. Latência medida: 200ms no total para todos os nove hooks. O modelo para de adivinhar caminhos de arquivo porque recebeu os caminhos reais.¹⁵

Verificação independente aborda o vácuo removendo humanos do gargalo de verificação em checagens rotineiras. O loop de desenvolvimento autônomo (documentado em Anatomy of a Claw) gera código, roda a suíte completa de testes e submete resultados a três agentes de revisão que operam independentemente. O agente de implementação nunca revisa sua própria saída. A separação espelha a descoberta de que o grupo assistido por IA no estudo de Stanford tinha mais confiança em código inseguro: autoverificação é não confiável quer o autor seja humano ou artificial.¹³

Governança automatizada aborda a lacuna codificando padrões da equipe como verificações executáveis. O Fabrication Firewall classifica cada ação de saída como local, compartilhada ou externa, deferindo publicação externa para revisão humana. Portões de qualidade bloqueiam relatórios de conclusão que usam linguagem evasiva (“deveria funcionar”, “parece correto”) em vez de citar saída de testes e caminhos de arquivo. O sistema aplica padrões que desenvolvedores humanos aplicariam se tivessem tempo para revisar cada linha. Na velocidade de geração da IA, eles não têm.

O sistema combinado produz resultados mensuráveis em seu próprio codebase: 4.518 chunks de código indexados para busca semântica, 49.746 chunks de vault em 15.800 arquivos para memória persistente, e uma suíte de testes que roda automaticamente antes de qualquer mudança reportar conclusão.¹⁵ Esses números descrevem a infraestrutura de um desenvolvedor. Eles não podem provar que a abordagem generaliza. Podem demonstrar que o muro é permeável com as ferramentas certas do outro lado.

A proporção de governança

O sistema de hooks descrito em Anatomy of a Claw contém 84 hooks. Uma contagem verificada os separa por função: 35 hooks de julgamento que decidem se algo deve acontecer, 44 hooks de automação que executam ações predeterminadas e 5 hooks utilitários (dispatchers, gerenciamento de estado). A proporção de governança é 4:5. Começou em 1:6.¹⁵

A proporção inicial reflete o que a maioria das equipes constrói primeiro: automação. Injetar contexto. Registrar métricas. Formatar saída. Registrar uso. Esses hooks capturam os 10% que todo mundo obtém. Eles automatizam as partes mecânicas do desenvolvimento que já eram parcialmente automatizadas antes da IA. Os dados da DX confirmam isso: as quatro horas economizadas por semana vêm da geração de código e redução de boilerplate, tarefas que já eram a parte mais rápida do ciclo de desenvolvimento.¹

A mudança em direção a hooks de julgamento reflete de onde vêm os ganhos adicionais.

A pesquisa de 2025 da McKinsey com quase 300 empresas de capital aberto descobriu que os melhores desempenhos viram melhorias de produtividade de 16-30% e melhorias de qualidade de 31-45%.¹⁶ Essas organizações tinham 80-100% de adoção por desenvolvedores combinada com integração organizacional. O fator diferenciador não era a taxa de adoção (que se correlaciona com ganhos de 10% em geral) mas a infraestrutura e os processos construídos ao redor dessa adoção.

O enquadramento de Laura Tacho se aplica aqui: “Sou cética quanto à promessa de qualquer tecnologia de melhorar o desempenho sem abordar essas restrições subjacentes.”³ As restrições subjacentes são restrições de julgamento. Este código atende aos nossos padrões? Esta mudança quebra algo downstream? Esta saída contém uma fabricação? Hooks de automação não conseguem responder essas perguntas. Hooks de julgamento conseguem, imperfeitamente, codificando os critérios que desenvolvedores experientes aplicam mentalmente.

A proporção ainda não atingiu paridade. O sistema ainda automatiza mais do que governa. O desequilíbrio é ele próprio um diagnóstico: qualquer camada de orquestração onde hooks de automação superam hooks de julgamento tem espaço para melhorar.

O que você realmente precisa construir

O sistema descrito nos posts complementares tem 84 hooks, 43 skills, 19 agentes e 15.000 linhas de infraestrutura.¹⁵ Você não precisa de 15.000 linhas. Você precisa de três coisas.

Um hook de injeção de contexto. Cinco linhas de bash que injetam a data atual, branch e diretório de trabalho em cada prompt de IA. A injeção elimina uma categoria inteira de alucinação: o modelo para de inventar caminhos de arquivo e nomes de branch porque tem os reais.

#!/bin/bash
# inject-context.sh — minimum viable context injection
echo "Date: $(date +%Y-%m-%d)"
echo "Branch: $(git branch --show-current 2>/dev/null || echo 'not a git repo')"
echo "Directory: $(pwd)"

Um portão de qualidade. Quinze linhas que fazem grep em relatórios de conclusão por linguagem evasiva. Se o agente diz “deveria funcionar” em vez de citar saída de testes, o portão bloqueia. O portão aborda o vácuo de verificação no ponto de entrada mais barato possível.¹⁵

#!/bin/bash
# quality-gate.sh — minimum viable verification
INPUT=$(cat)
HEDGES=$(echo "$INPUT" | grep -ciE '\bshould (work|pass|be fine)\b|\bprobably\b|\blooks correct\b')
if [ "$HEDGES" -gt 0 ]; then
  echo '{"decision":"block","reason":"Hedging language detected. Cite test output instead."}'
else
  echo '{"decision":"allow"}'
fi

Um test runner independente. Um hook que roda a suíte de testes do projeto após cada mudança de código e falha ruidosamente se testes quebram. A implementação varia por projeto. O princípio não: o agente que escreve código não deve ser o único juiz desse código.

Comece com o que mais quebra no seu fluxo de trabalho. Se sua IA alucina caminhos de arquivo, construa o hook de contexto primeiro. Se sua IA entrega código não testado, construa o test runner primeiro. Se sua IA escreve “pronto” sem evidência, construa o portão de qualidade primeiro.

Karpathy descreveu a evolução de vibe coding para engenharia agêntica: “orquestrando agentes que fazem [o trabalho] e atuando como supervisão.”¹⁷ Os três hooks acima são a supervisão mínima viável. Eles não vão produzir ganhos de 30%. Vão mover você de 10% para 15%, e cada um que você adicionar revela a próxima restrição que vale a pena abordar.

O muro é real. Também é específico. Fome de contexto, vácuo de verificação e lacuna de governança são problemas de engenharia com soluções de engenharia. Os modelos vão continuar melhorando. O muro vai permanecer em 10% para cada equipe que trata IA como um gerador de código em vez de um sistema que requer infraestrutura para governar sua saída.

Principais conclusões

Para desenvolvedores individuais. Comece com um hook de injeção de contexto. Cinco linhas de bash que injetam data, branch e diretório de trabalho eliminam uma categoria inteira de alucinação da IA. O muro começa a quebrar quando o modelo conhece seus caminhos de arquivo reais em vez de adivinhá-los.

Para líderes de equipe. Meça sua proporção de governança: quantos dos seus hooks de IA verificam saída versus automatizam tarefas. Se hooks de automação superam hooks de julgamento, sua equipe captura apenas os primeiros 10%. Os dados da DX confirmam que as quatro horas economizadas por semana vêm da geração de código, tarefas que já eram a parte mais rápida do ciclo de desenvolvimento.¹

Para engenheiros de plataforma. Construa a camada de verificação antes de escalar a adoção de IA. O DORA descobriu que organizações implantando IA sem infraestrutura de engenharia viram a instabilidade aumentar com a adoção.^{4 5} As três causas-raiz mapeiam para três correções de infraestrutura. Comece com aquela que causa mais atrito no seu pipeline.

Fontes