Resumo em 30 segundos. A IA acelerou a etapa de escrever código. Revisar, decidir e assumir responsabilidade continuam na mesma velocidade de antes. O resultado é mais código gerado sem mais entrega, porque a fila só andou de lugar. Medir ganho de IA por volume de commit ou de PR fechado é medir a etapa que deixou de ser a restrição. Este texto explica onde o gargalo está agora e o que passa a valer a pena medir.
A cena se repete em quase todo time que adotou IA de código nos últimos meses. O board aprovou a ferramenta, o Copilot ou o Cursor está rodando em toda máquina, o número de pull request por semana subiu visivelmente. Só que a data de entrega do próximo release não mudou. E ninguém no time sabe apontar exatamente por quê.
O gargalo da IA na engenharia de software não desapareceu. Mudou de lugar. Ele saiu de escrever código, a etapa que a IA de fato acelerou, e foi parar em revisar, decidir e assumir responsabilidade pelo que vai para produção. Essas três etapas continuam correndo na velocidade de antes. E são elas, não a escrita, que sempre determinaram quando o software chega ao cliente.
Mais pull request, mesma entrega
O padrão é sempre parecido. Mais diff por semana, mais código passando por revisão, mais commit fechado. E o prazo do próximo release continua exatamente onde estava antes da IA entrar.
Pensa na fila de um caixa de supermercado. Não importa quão rápido o cliente enche o carrinho se o caixa continua escaneando item por item no mesmo ritmo de sempre. A fila não anda mais rápido. Ela só fica maior antes do caixa.
É a mesma lógica na engenharia. A IA encheu o carrinho mais rápido: gerou mais código, sugeriu mais função, resolveu mais bug pequeno em menos tempo. O caixa continua no mesmo ritmo, revisão, decisão de arquitetura, aprovação para produção. O diff represado esperando revisor é o carrinho parado esperando o caixa.
Metade do gargalo: revisão não acelera no ritmo do código
A metade mais visível do novo gargalo é a revisão de código, o code review. Escrever ficou mais rápido. Ler, entender e aprovar o que foi escrito não ficou, pelo motivo mais simples que existe: revisão é trabalho de atenção humana, e atenção não escala com licença de ferramenta.
Um revisor sênior lê o mesmo tanto de código por hora hoje que lia antes da IA aparecer. Só que a fila na porta dele cresceu, porque quem escreve, com IA, produz mais e mais rápido do que a capacidade de revisão do time consegue absorver.
Quando a fila de PR aumenta, duas coisas acontecem, e as duas custam caro. A revisão vira superficial, porque ninguém examina linha por linha uma fila daquele tamanho, ou a fila simplesmente não anda, e o código fica parado esperando aprovação. Nenhuma das duas é "entregar mais rápido".
A outra metade do gargalo: decisão técnica é julgamento, não tarefa
A segunda metade é menos falada e mais cara: decisão técnica. Que arquitetura usar, o que vale reescrever, o que é dívida técnica aceitável, o que assinar como pronto para produção.
A IA sugere código. Não assume a decisão de colocá-lo em produção, e não deveria. Essa decisão continua sendo de uma pessoa, com nome, que responde pelo que acontece depois do deploy. Gerar mais opção de código mais rápido não acelera esse julgamento. Só aumenta o volume de coisa que precisa ser julgada.
Isso tem nome: teoria das restrições
Quem estuda operação e logística já tem um nome para esse fenômeno: teoria das restrições, formulada por Eliyahu Goldratt. A tese central é simples e incômoda. A vazão de qualquer sistema inteiro é limitada pela etapa mais lenta, nunca pela mais rápida.
Acelerar uma etapa que não é a restrição não aumenta a vazão do sistema. Só empurra o acúmulo para a etapa seguinte. É exatamente o que a IA de código fez com o fluxo de entrega de software: acelerou a etapa que nunca foi a mais lenta, e empurrou o acúmulo para revisão e decisão, que sempre foram.
Isso não é falha de ferramenta. A IA está funcionando como anunciado, escreve código mais rápido. O problema é medir o ganho dela na etapa errada.
A objeção honesta: "mas eu vejo o time mais rápido"
Essa é a objeção que todo CTO carrega quando lê um texto como este, e ela é honesta. O time está visivelmente mais rápido, dá pra ver nos PRs, no volume de commit, na sensação geral do dia a dia.
Está certo. Na escrita, o time está mesmo mais rápido. Velocidade de escrita e velocidade de entrega são coisas diferentes, e só a segunda aparece no roadmap, no board e na data que o cliente cobra.
Confundir as duas é o erro mais caro que dá pra cometer com IA de código agora. Um time pode escrever visivelmente mais rápido e entregar exatamente no mesmo prazo de antes, porque o gargalo real nunca esteve na escrita.
O que passa a ser medido
Se a etapa que acelerou não é a que importa, a pergunta muda: o que vale medir agora?
Quatro sinais dizem mais sobre o gargalo atual do que qualquer contagem de linha de código ou de PR fechado:
- Quanto tempo um pull request fica parado esperando revisor, sem ninguém mexer nele. Isso mostra fila, não esforço.
- Quanto tempo passa entre o primeiro commit e o código rodando de verdade para o usuário. É a métrica que fecha o ciclo inteiro, não só a parte que a IA acelerou.
- Quanto do que foi aprovado precisou ser revisto, corrigido ou revertido depois do merge. Revela se a revisão está sendo rigorosa ou só carimbando fila.
- Que proporção das mudanças quebra algo em produção. Mostra se o julgamento sobre o que está pronto acompanha o volume que a IA gera.
Quem trabalha com engenharia reconhece essa família de métrica de produtividade: é próxima do que frameworks como DORA e SPACE tentam capturar há anos, bem antes de existir IA de código. A diferença agora é que elas contam uma história que o board precisa ouvir: não quanto código o time produz, mas quanto desse código vira entrega de verdade, e em quanto tempo.
O que muda na rotina de quem lidera
Quando a restrição muda de lugar, a atenção de quem lidera também precisa mudar.
Contratar mais gente para escrever código deixa de ser a alavanca óbvia, porque escrever não é mais o que represa a fila. A alavanca está em quem revisa e em quem decide: dar tempo protegido de agenda para revisão, em vez de tratar isso como intervalo entre reunião. Definir com clareza quem tem autoridade para aprovar o quê, para a decisão não virar gargalo por indefinição de papel. E, principalmente, resistir à tentação de comprar mais licença de IA de código como resposta a um problema que não está na escrita.
Isso conecta com algo que já escrevi sobre o valor do desenvolvedor mudando de lugar, de escrever código para comunicar com clareza o que precisa ser construído. O mesmo movimento que vale para o indivíduo vale para o time: o trabalho que sobra depois da IA escrever é o trabalho que sempre exigiu julgamento, não digitação.
Três perguntas para o comitê
Antes de aprovar mais uma licença de IA de código, leve três perguntas de negócio para a próxima reunião de comitê.
Primeira: nosso lead time do commit até produção mudou desde que a IA entrou, ou só o volume de commit mudou? Segunda: onde está a fila hoje, revisão, decisão de arquitetura ou aprovação para deploy, e quem é o dono dela? Terceira: se dobrássemos o número de licenças amanhã, a entrega dobraria junto, ou só a fila em revisão ficaria maior?
Nenhuma dessas perguntas é sobre a ferramenta. Todas são sobre onde a restrição do seu time está agora.
Se você chegou até aqui e não tem uma resposta segura para nenhuma das três, dá pra conversar sobre isso. Numa chamada de diagnóstico, eu olho com você onde a fila do seu time está hoje antes de qualquer decisão sobre ferramenta ou licença. Chamar no WhatsApp.
A fila que ninguém está olhando
O time que mede ganho de IA contando linha de código ou PR fechado está de olho na etapa errada. É a etapa mais visível, a que aparece no dashboard, a que qualquer um aponta numa reunião. E é justamente por isso que ela deixou de importar.
Acelerar a etapa que não é o gargalo não aumenta a vazão. Só move a fila para o próximo ponto. O trabalho de quem lidera agora é achar onde essa fila está de verdade, e parar de comemorar a etapa que já não é mais a restrição.
Perguntas frequentes
Por que a produtividade da engenharia não aumenta mesmo com IA no time? Porque a IA acelera a etapa de escrever código, que raramente foi a etapa mais lenta do fluxo de entrega. Revisão, decisão de arquitetura e aprovação para produção continuam no mesmo ritmo de antes. Produtividade de time se mede pela vazão do sistema inteiro, não pela velocidade da etapa mais rápida.
Onde está o gargalo real da IA nos times de engenharia? Está em revisão e em decisão, não em escrita. Revisão exige atenção humana, que não escala com licença de ferramenta. Decisão exige alguém que responda pelo que vai para produção, e isso continua sendo trabalho de julgamento, não de geração de código.
Code review virou o gargalo da entrega com IA? Em muitos times, sim, junto com a decisão técnica. A IA aumenta o volume de código chegando para revisão sem aumentar a capacidade de quem revisa. Se o time não ajustar como e quanto tempo dedica à revisão, a fila de pull request cresce mais rápido do que a entrega.
Como medir se a IA está acelerando a engenharia de verdade (e não só a escrita de código)? Olhando o ciclo inteiro, não só a etapa de escrita. Tempo parado em revisão, lead time do commit até produção, retrabalho depois do merge e proporção de mudanças que quebram algo em produção contam essa história melhor do que contagem de linha de código ou de PR fechado.
A IA ajuda mais escrevendo código ou revisando e decidindo? Hoje, ajuda muito mais escrevendo. As ferramentas de IA de código são maduras para gerar e sugerir código, e bem menos maduras para substituir o julgamento humano sobre o que aprovar e o que colocar em produção. Por isso o gargalo migrou para onde a IA ainda não chega.
Fontes: Eliyahu M. Goldratt, "A Meta" (1984) — teoria das restrições, aplicada aqui ao fluxo de entrega de software. DORA e SPACE citados como nome de framework reconhecido no mercado de engenharia, sem estatística específica atribuída a nenhum dos dois neste texto. Este artigo não usa dado numérico de fonte externa nova; nenhuma estatística entrou sem aprovação prévia.
É o mesmo padrão de raciocínio de Por que projetos de IA morrem no terceiro mês: a peça vistosa raramente é onde está a restrição real. Lá, a restrição invisível era o dado do projeto. Aqui, é o fluxo de entrega do time.