A IA acelerou o desenvolvedor. Não o time.
O ganho da IA por desenvolvedor é real. E é justamente por isso que ele engana.
Todo desenvolvedor que adotou IA vai dizer, com razão, que ele ficou mais rápido. E o painel vai concordar: mais atividade, mais entregas, mais velocidade. Ainda assim, quando a liderança medir o que de fato chegou à produção, do commit ao deploy, a entrega do time anda quase no mesmo ritmo de um ano atrás.
Essa distância entre a aceleração que se sente e a entrega que não se move é um dos assuntos mais mal compreendidos da engenharia neste momento: velocidade local, o ganho do desenvolvedor sozinho, não é a mesma coisa que velocidade sistêmica, o ganho no fluxo de entrega do time inteiro. A primeira subiu, e muito. A segunda, quase nada. Entender esse fenômeno é determinante para transformar a adoção de IA em resultado.
O ganho é real, e mais estreito do que parece
Vale começar reconhecendo: o ganho existe, e é grande onde as condições ajudam. Analisando dezenas de milhares de engenheiros, a pesquisa citada pelo DORA de 2026 encontrou de 35 a 40% de ganho de produtividade em tarefas greenfield, código novo e simples. O problema é o outro lado do mesmo dado: em base legada e complexa, o ganho desaba para 10% ou menos. E é na base legada que mora a maior parte do trabalho real de praticamente todo time maduro.
Há aí um detalhe contra-intuitivo que diz muito sobre a natureza do ganho. Os desenvolvedores mais experientes tendem a extrair mais da IA que os juniores, não menos. Isso diz muito sobre capacidade de julgamento: saber o que pedir, reconhecer quando a resposta está errada, onde encaixar o trecho gerado num sistema que já existe. Ou seja, a parte que a IA acelera de verdade nunca foi escrever código, foi o entorno. E é exatamente no entorno que o ganho individual começa a se perder antes de chegar ao time.
No caminho até a entrega, o ganho evapora
O DORA descreve bem o primeiro motivo de perda: a fricção não desaparece, ela muda de lugar. O esforço que você economiza deixando a IA escrever o boilerplate reaparece como esforço de auditar um código que se parece muito com um código correto sem necessariamente ser. É o que o relatório chama de verification tax. Ler e validar com rigor algo plausível cansa mais que escrever do zero, porque o erro não salta aos olhos, ele se esconde.
A expectativa natural é que esse custo diminua à medida que o time ganha experiência com a ferramenta. Os dados mostram o contrário. Quando a Anthropic mediu como as pessoas de fato supervisionam agentes de IA no dia a dia, encontrou um padrão que, à primeira vista, parece paradoxal: quanto mais experiente o usuário, mais ele passa a aprovar automaticamente as ações e, ao mesmo tempo, com mais frequência ele interrompe o agente. A supervisão não some com a maturidade. Ela muda de forma: de aprovar cada passo para monitorar e intervir no ponto correto. A Anthropic lê isso como supervisão saudável. Mas é a mesma moeda pela outra face: supervisão eficaz tem preço, e é esse preço que o verification tax nomeia. O custo de verificar não desaparece porque o time amadureceu. Ele deixa de aparecer como aprovação manual e passa a se manifestar como atenção contínua.
O segundo motivo de perda que o DORA apresenta está associado ao throughput: o time passa a gerar código mais depressa do que as etapas seguintes conseguem absorver: revisão, teste, aprovação de mudança, deploy. O ganho individual chega à esteira, forma fila e quem paga essa conta é o fluxo inteiro. Cada desenvolvedor acelerou a vazão individual, mas o gargalo virou o pipeline. Velocidade local vira estoque parado, não entrega mais rápida.
Por trás desses dois motivos que levam à perda dos ganhos da adoção de IA, há uma crença de fundo que alimenta os dois: a de que engenharia de software seria o terreno seguro para delegar à IA, porque o resultado é verificável, bastando rodar o código e ver se funciona. É algo que a própria pesquisa da Anthropic reflete, ao tratar a testabilidade do software como aquilo que torna mais fácil a confiança no agente nessa área do que em outras, como direito, medicina ou finanças.
O DORA complica esse raciocínio, e é uma complicação que reconhecemos na prática. “Passar no teste” não é “estar estruturalmente correto”. Um código gerado por IA pode compilar, passar no CI e ainda assim falhar em arquitetura, manutenção ou integração com o resto da base. O teste verde é o disfarce perfeito: dá a sensação de que a tarefa está concluída, e o verification tax passa sem ser notado. Ou seja, a verificabilidade que supostamente torna o software seguro para delegar é precisamente onde o custo se esconde.
O custo que ninguém orçou
Perder o ganho no caminho já seria problema suficiente. Mas há um efeito pior: parte do que foi produzido volta como custo. Quando o DORA mediu o efeito da IA sobre dez dimensões de engenharia, o maior avanço veio, como se esperava, na efetividade individual. Mas o efeito sobre o throughput do time, a vazão real de entrega, foi quase nulo. E o segundo maior efeito de todos foi negativo: aumento de instabilidade. Mais falha em produção, mais tempo consertando.
É o que se pode chamar de instability tax. O sistema ficou mais rápido para produzir e, na mesma medida, mais rápido para quebrar. Com isso, o tempo gasto estabilizando toma de volta parte do ganho que cada desenvolvedor jurava ter entregue. Some verification tax, fila no pipeline e instabilidade, e você tem a anatomia completa de como um ganho individual de 35% chega perto de zero na conta do time.
O que muda para quem lidera
A primeira consequência prática dessa leitura é parar de tratar velocidade local como se fosse velocidade sistêmica. Tempo economizado por desenvolvedor, sugestões aceitas, PRs por semana, tudo isso é sinal local, e sobe mesmo quando a entrega do time não anda. A pergunta que interessa é outra: o fluxo inteiro, do commit à produção, ficou mais rápido sem ficar mais instável?
A segunda é contar com a queda antes da subida. A adoção de IA costuma desenhar uma curva J: uma perda temporária de produtividade enquanto o time aprende a ferramenta, ajusta o pipeline e paga o verification tax, seguida de recuperação. No modelo do DORA, o vale dura algo como três meses. Esse vale é o custo de matrícula da transformação, não o veredito dela. Quem lê o vale como fracasso corta o investimento pouco antes da virada e, aí sim, garante o fracasso.
Mas há uma armadilha: a subida da curva J não é automática. Costuma-se vender como promessa: desce e sobe. Não é. A recuperação depende inteiramente do sistema em que o vale acontece.
Num sistema maduro, o vale vira recuperação e o ganho individual finalmente se converte em velocidade de time. Num sistema caótico, o mesmo vale pode nunca virar subida. A linha pode seguir descendo, com a IA apenas acelerando a deterioração. A curva J não é um direito adquirido de quem adota IA. É o resultado que só um sistema saudável entrega.
O que nos leva ao achado mais honesto do DORA: a IA não gera valor, ela amplifica o sistema em que cai. Um sistema maduro transforma o ganho individual em velocidade de time. Um sistema caótico transforma o mesmo ganho em caos mais rápido.
E não é só o DORA que aponta para lá. A Anthropic chegou a uma conclusão parecida por outro caminho: ao medir como a autonomia dos agentes cresce na prática, encontrou que ela sobe de forma gradual e não acompanha os saltos de capacidade dos modelos. Quem determina a autonomia não é o modelo, é o sistema em que ele opera.
Duas pesquisas, por caminhos opostos, uma medindo entrega e outra medindo autonomia, chegam ao mesmo destino: o que decide o resultado não é a ferramenta, é o sistema que a cerca.
Descobrir em qual dos dois sistemas você está não se faz olhando o desenvolvedor. Se faz medindo o sistema. É esse o trabalho ao qual nos dedicamos no WeLuvCode.