lorenzopasquali.dev

79% dos líderes dizem que o código sai mais rápido e o release não. Fui conferir a conta

· 7 min de leitura · também em English

A InfoQ noticiou em 7 de outubro uma pesquisa cujo número mais interessante não é o que vai circular. O que vai circular é "42% da semana debugando". O que merece atenção é este: 79% dos líderes de engenharia dizem que, mesmo produzindo código muito mais rápido com IA, o ciclo de release não ficou mais rápido.

Pensa no que isso diz. Durante décadas, escrever código foi a etapa que a gente achava que limitava a entrega. Se a IA deixa essa etapa barata e o release continua onde estava, então o código nunca foi o que segurava o release. Ele só estava na frente da fila, escondendo o resto.

O relatório é da Undo, publicado no começo de outubro, com 300 líderes de engenharia. Fui ler o PDF inteiro. Antes de falar do que ele sugere, uma ressalva curta sobre o quanto confiar nos números.

Os números são ordem de grandeza

As horas do relatório (9,8 escrevendo código, 9,7 debugando em desenvolvimento, 7,2 debugando problemas de produção e 13,3 em outras tarefas) somam exatamente 40,0. E a página do relatório diz que os percentuais assumem "uma semana média de 40 horas". Ou seja, o "42%" é horas dividido por 40: uma estimativa sobre um denominador assumido, não uma medição.

A amostra tem 300 gestores e nenhum desenvolvedor, 93% deles trabalham com C/C++, e a Undo vende gravação de execução para agentes, que é exatamente a solução que o relatório recomenda no fim.

Então eu trataria os números como ordem de grandeza. O que me interessa é o padrão por trás deles, porque ele aparece de forma independente em outro lugar. A Faros AI analisou telemetria de mais de 10 mil desenvolvedores (e também vende análise de engenharia, então vale o mesmo asterisco) e encontrou que times com alta adoção de IA completam 21% mais tarefas e mergeiam 98% mais pull requests, enquanto o tempo de revisão sobe 91%. Segundo análises que citam o relatório, sem correlação significativa com melhora no resultado da empresa.

Mais código sai, e o release não acompanha. Dois instrumentos diferentes, a mesma forma. Vamos ao porquê.

Escrever código era um quarto da semana

Usando a tabela do próprio relatório, escrever código é 9,8 das 40 horas: cerca de 25%.

Pela lei de Amdahl, se você acelera uma etapa que ocupa 25% do trabalho, o ganho total tem teto. Dobrar a velocidade de escrever código dá algo como 1,14x. Tornar a escrita infinitamente rápida daria, no máximo, 1,3x. São contas com estimativas, então ordem de grandeza de novo, mas o recado é claro: mesmo no melhor caso, acelerar só a geração mexe pouco no total.

E isso ainda é esforço de pessoa. Release não é esforço, é fila.

Release é fila, não esforço

Um revisor humano tem capacidade fixa. Se o número de PRs que chega para ele dobra, o tempo de espera não dobra: ele explode, porque em teoria de filas simples a espera cresce como ρ/(1−ρ), onde ρ é o quanto o revisor já está ocupado.

Ocupação do revisor Espera relativa
50% 1x
80% 4x
90% 9x
95% 19x

É um modelo, não uma medição, mas explica uma coisa que parece estranha nos números da Faros: o tempo de revisão subir 91% não exige que a carga tenha mudado absurdamente. Perto da saturação, pouca carga extra vira muita espera. E é exatamente aí que um time com revisores fixos e PRs que dobraram está.

Onde a fila está: três suspeitos

Os dados apontam para três lugares, e quem aponta tem um pouco de interesse em cada um.

Revisão. É a leitura da Faros, e o GitLab diz, no relatório de 2026 sobre responsabilidade em IA, que 85% dos respondentes concordam que a IA moveu o gargalo para a revisão. Na pesquisa da Undo, 50% dizem gastar tempo excessivo revisando a saída dos agentes comparado ao tempo que levou para gerá-la, e 46% acham difícil revisar o volume que chega. O mecanismo é simples: gerar ficou barato, entender não. E 35% do código gerado, segundo o relatório, chega à produção sem ter sido totalmente compreendido.

Lote e deploy depois da aprovação. Steve Fenton, da Octopus Deploy, argumentou em julho no The New Stack que a revisão não é o gargalo: o gargalo é a fila depois dela. Mais de 90% das equipes que ele pesquisou entregam em lotes, e metade tem de 2 a 10 mudanças por lote. O teste que ele propõe é bom: conte quantas mudanças já foram aprovadas mas ainda não estão em produção. Se for mais de uma, o gargalo está depois da revisão. Os dados dele ainda não foram publicados, e a Octopus vende ferramenta de deploy.

Defeitos e retrabalho. Na Undo, 91% dos líderes tiveram test escapes ou defeitos sérios em produção ao menos uma vez em seis meses, 81% tiveram incidente ou outage, e 55% dizem que os agentes introduzem código incorreto com frequência suficiente para atrasar a entrega. O DORA 2025 resume o mesmo desenho: a IA melhora a vazão, mas frequentemente à custa da estabilidade quando a base não é sólida.

Repare que cada fonte tende a apontar para o seu quintal: a Undo para debugging, a Lightrun para visibilidade de runtime, a Octopus para o deploy em lote. Provavelmente os três estão certos em parte, e a resposta depende de onde a fila do seu time está.

O release lento pode ser a resposta racional

Aqui está a parte que mais me interessou. O que une os três suspeitos é o tamanho do lote. Mais código por unidade de tempo significa mais mudanças por release e PRs maiores. Mais mudança por release significa mais risco por release. E a resposta de uma organização a mais risco é pôr um portão.

Segundo a VentureBeat, foi o que a Amazon fez depois de duas quedas em março que a reportagem atribui a mudanças assistidas por IA em produção sem a aprovação devida: um reset de segurança de 90 dias em 335 sistemas críticos e a exigência de que mudanças assistidas por IA sejam aprovadas por engenheiros seniores antes do deploy.

Então um release que não acelerou não é necessariamente falha de processo. Pode ser a organização reconhecendo, corretamente, que não consegue verificar na velocidade em que o código chega. A parte difícil de acelerar é a responsabilidade: ninguém consegue terceirizar para o modelo o "eu aprovo isso e respondo por isso". E essa capacidade de verificar é limitada por gente e por orçamento. Na parte do relatório que menos apareceu, 63% dos líderes dizem que o custo é proibitivo para autorizar os modelos de tier mais alto justamente no trabalho de compreender e debugar código, e 82% temem que o preço dos agentes dispare conforme os labs se preparam para abrir capital. O remédio que o relatório propõe, mais IA na verificação, esbarra no mesmo problema de custo.

O que eu mediria

Se a pergunta é onde o seu time está perdendo tempo, eu não mediria horas escrevendo ou debugando. Mediria onde a mudança espera:

Veredito

Código ficou barato. Entendimento não. O gargalo saiu do teclado e foi para a cabeça de quem aprova, e para a fila de tudo que vem depois. Quem otimiza só a geração vai ver o volume de PR subir e o release ficar parado, e vai ser tentado a achar que a IA não funciona, quando na verdade ela funcionou na etapa que já não era a limitante.

O número do relatório é frágil. O padrão que ele descreve não é.

Fontes

← Todos os posts