A Armadilha da Velocidade: Por Que Codificação IA Mais Rápida Torna Sua Entrega Mais Lenta

Edsger Dijkstra escreveu décadas atrás: “Linhas de código não devem ser vistas como ‘linhas produzidas’, mas como ‘linhas gastas’.” Bill Gates disse de outro jeito: “Medir progresso de programação por linhas de código é como medir progresso de construção de aviões por peso.”

Os dois falavam do mesmo erro. Estamos cometendo de novo, em escala, com IA.

Três fontes independentes publicadas em março de 2026 convergem no mesmo diagnóstico. O autor anônimo do Antifound. Andrew Murphy. Justin Jackson. Nenhum cita o outro. Todos chegam à mesma conclusão: otimizar a velocidade de geração de código não melhora a entrega de software. Em muitos casos, piora.

Não se trata de preocupação abstrata. É um problema de dinâmica de sistemas com nome, corpo teórico e décadas de evidência. Eliyahu Goldratt chamou de Teoria das Restrições. O princípio é simples: a vazão de um sistema é determinada pelo seu gargalo. Otimizar qualquer coisa que não seja o gargalo não melhora a vazão. Aumenta o estoque intermediário.

Em entrega de software, escrever código não é o gargalo.

A Divisão 20/80

Murphy enquadra com uma pergunta que todo líder de engenharia deveria reconhecer: se uma funcionalidade leva dois meses para chegar à produção, e a codificação em si leva uma tarde, para onde foram os outros 59 dias?

A resposta são filas. Fila de revisão de código. Fila de QA. Fila de ambiente de staging. Fila de aprovação de compliance. Fila de janela de deploy. Fila de feedback de stakeholders. O código fica parado, esperando, enquanto humanos se coordenam ao redor dele.

A estimativa de Murphy é que escrever código representa cerca de 20% do ciclo de entrega. Os 80% restantes são espera, revisão, coordenação e resolução de ambiguidades. Os números variam por organização, mas a proporção é consistente com o que Goldratt observou na manufatura: a restrição quase nunca é a etapa de produção em que todos se concentram.

Como documentamos em Medindo IA no Desenvolvimento de Software, a Jellyfish descobriu que organizações com adoção plena de IA tiveram 113% mais pull requests por desenvolvedor. Mas mais PRs não significam mais funcionalidades entregues. Significam mais itens entrando na fila. Se a fila não absorve, o sistema degrada.

O Que Acontece Quando Você Acelera a Etapa Errada

A teoria de Goldratt faz uma previsão específica: quando se otimiza algo que não é o gargalo, o sistema não fica mais rápido. Fica mais congestionado.

Murphy descreve exatamente esse padrão. Desenvolvedores munidos de ferramentas de codificação IA produzem mais código, mais rápido. PRs se multiplicam. Mas o processo de revisão não acelerou. O processo de QA não acelerou. O pipeline de deploy não acelerou. O trabalho se acumula entre as estações.

O autor do Antifound gasta 60% do tempo de trabalho em planejamento, design e pesquisa. Geração de código, mesmo com uso intenso de LLM, consome a fração restante. E 75% desse código assistido por LLM exige edição significativa antes de estar pronto para produção. A velocidade de geração é quase irrelevante quando a etapa de geração já é a menor parte do cronograma.

Essa é a armadilha da velocidade. A sensação é de produtividade. Desenvolvedores relatam sentir-se mais rápidos. (O estudo do METR que cobrimos na nossa análise de métricas mostrou que desenvolvedores percebiam uma aceleração de 20% enquanto eram 19% mais lentos na prática.) Mas o sistema não está mais rápido. O sistema tem mais trabalho em andamento, filas mais longas e menos visibilidade sobre o que realmente importa.

Murphy resume sem rodeios: “Você não acelerou nada. Criou um engarrafamento e chamou de produtividade.”

O Problema do Estoque Invisível

Na manufatura, estoque entre estações é visível. Caixas se empilham no chão da fábrica. Alguém percebe.

Em software, o estoque é invisível. Vive em filas de pull request, boards do Jira e threads do Slack. Ninguém passa por uma pilha de PRs não revisados e pensa “temos um problema de estoque”. Pensam “o time está ocupado”.

Quando desenvolvedores assistidos por IA produzem mais código, esse estoque invisível cresce. Murphy identifica três consequências.

Primeiro, a troca de contexto aumenta. Mais PRs em revisão significam mais interrupções para os revisores. Cada troca de contexto tem custo cognitivo. A vazão do revisor cai à medida que a fila cresce.

Segundo, conflitos de merge se multiplicam. Código parado na fila diverge da branch principal. Quanto mais espera, maior a chance de conflitar com outro trabalho na fila. Resolver conflitos é retrabalho que não existiria se a fila fosse mais curta.

Terceiro, os ciclos de feedback se alongam. Um desenvolvedor que abre um PR na segunda e recebe feedback na quinta perdeu três dias de contexto. Já seguiu para outro trabalho. Voltar ao PR original exige recarregar contexto, o que é lento e propenso a erros. Como exploramos em Dívida Cognitiva: O Custo Invisível, essa sobrecarga cognitiva se acumula entre equipes.

As três consequências reduzem a vazão efetiva. O sistema produz mais código e entrega menos valor.

Mais Código, Menos Compreensão

O autor do Antifound levanta uma preocupação mais profunda que a teoria de filas. Quando desenvolvedores geram código com LLMs, frequentemente entendem menos do que código escrito manualmente.

Não é especulação. O autor documenta que gasta 75% das interações com LLM em geração de código, com edição pesada depois. A edição é onde a compreensão se desenvolve. Mas quando o volume de código gerado excede a capacidade do desenvolvedor de editar com cuidado, a compreensão degrada.

Murphy conecta isso a um risco sistêmico: “Mais código, menos compreensão. Isso não é ganho de produtividade. É uma bomba-relógio com um dashboard mais bonito.”

O custo de verificação não desaparece porque a geração foi rápida. Como cobrimos em Código Barato, Qualidade Cara, gerar código caiu para quase zero enquanto verificar qualidade permaneceu caro. Geração mais rápida sem verificação mais rápida significa mais código não verificado no sistema. A pesquisa sobre Dívida de Verificação de IA mostra que 96% dos desenvolvedores desconfiam de código gerado por IA, com 48% verificando ativamente cada output. Esse trabalho de verificação é manual, lento e não escala com a velocidade de geração.

O Multiplicador da Confusão de Papéis

Justin Jackson adiciona outra dimensão à armadilha da velocidade. Quando a IA torna a codificação acessível a não-engenheiros, o problema de filas se agrava.

Product managers escrevem protótipos. Designers entregam componentes. Todo mundo produz código porque a barreira caiu. Mas os processos de revisão, integração e deploy não foram desenhados para esse volume nem para essa variedade de contribuidores. O protótipo de um PM entra na mesma fila de revisão que a feature branch de um engenheiro, consumindo a mesma atenção escassa do revisor.

Como analisamos em O Impasse Mexicano, essa expansão de papéis cria sobrecarga de coordenação que anula ganhos individuais de produtividade. A observação de Kent Beck se aplica aqui: quando o valor das habilidades de implementação cai para quase zero, o gargalo se desloca inteiramente para julgamento, coordenação e design de sistemas. Essas são as competências que permanecem escassas, e inundar o sistema com mais código gerado não faz nada para expandir a oferta delas.

O Que Goldratt Diria ao Seu Time de Engenharia

Se Goldratt fosse consultor de uma organização de software adotando ferramentas de codificação IA, seu conselho seria previsível porque seu framework é determinístico.

Passo 1: Identifique a restrição. Mapeie seu pipeline de entrega, do pedido de funcionalidade ao deploy em produção. Meça onde o trabalho espera mais tempo. Na maioria das organizações, a restrição não é codificação. É revisão, teste ou aprovação de deploy.

Passo 2: Explore a restrição. Antes de adicionar capacidade, garanta que o gargalo opera em eficiência máxima. Se revisão de código é a restrição, os revisores gastam 100% do tempo de revisão realmente revisando? Ou estão em reuniões, escrevendo código próprio, respondendo no Slack? Proteja o tempo do gargalo.

Passo 3: Subordine tudo à restrição. Este é o passo contraintuitivo. Significa deliberadamente desacelerar as etapas que não são gargalo para igualar a capacidade do gargalo. Se seu processo de revisão absorve 10 PRs por dia, produzir 25 PRs por dia não é produtivo. É desperdício. Limite o trabalho em andamento ao que o sistema consegue absorver.

Passo 4: Eleve a restrição. Somente após os passos 1 a 3, invista em expandir o gargalo. Pode significar revisão de código assistida por IA, testes automatizados ou aprovações de deploy simplificadas. Aplique IA na restrição, não na etapa que já era rápida o suficiente.

Passo 5: Repita. Quando você alivia um gargalo, outro aparece. A vazão do sistema é sempre determinada pela restrição atual, onde quer que ela esteja.

A maioria das organizações adotando ferramentas de codificação IA pulou direto para acelerar o Passo 0 (escrever código) sem executar o Passo 1 (identificar onde a restrição real está). O resultado é previsível.

A Métrica Que Importa

Se linhas de código é a métrica errada, qual é a certa?

Tempo de ciclo. O tempo decorrido entre “trabalho iniciado” e “valor entregue aos usuários”. Não tempo de criação de PR. Não tempo de codificação. Tempo de ciclo ponta a ponta.

Uma organização onde ferramentas de codificação IA reduzem o tempo de ciclo é genuinamente mais produtiva. Uma organização onde ferramentas de codificação IA aumentam o volume de PRs enquanto o tempo de ciclo permanece igual (ou cresce) caiu na armadilha da velocidade.

O desafio de Murphy é direto: meça quanto tempo uma funcionalidade leva da concepção à produção. Se a resposta ainda é dois meses, suas ferramentas de codificação IA não melhoraram a entrega. Melhoraram uma tarde dentro de um processo de dois meses.

A alocação de tempo do autor do Antifound conta a mesma história pela perspectiva individual. Quando 60% do seu tempo vai para planejamento e design, acelerar os 40% restantes em até 50% economiza no máximo 20% do tempo total. E isso assume que o código gerado não precisa de edição. Precisa.

A Conclusão Desconfortável

As três fontes convergem em uma conclusão que os fornecedores de ferramentas de IA não vão colocar em seus materiais de marketing.

Geração de código mais rápida, aplicada a um sistema onde escrever código não é o gargalo, piora a entrega. Não mantém igual. Piora. Porque aumenta o estoque intermediário, alonga filas, multiplica trocas de contexto e cria a ilusão de produtividade onde não existe nenhuma.

As organizações que mais se beneficiarão de ferramentas de codificação IA são aquelas que primeiro entendem seu sistema de entrega bem o suficiente para saber onde a restrição realmente está. E então aplicam IA ali.

Dijkstra estava certo. Linhas de código são linhas gastas, não linhas produzidas. Gastá-las mais rápido, sem entender no que se está gastando, não é progresso. É aceleração na direção errada.

Fontes

“Codegen Is Not Productivity.” Antifound, março 2026.
Murphy, Andrew. “If You Thought Speed Was Your Problem, You Have Bigger Problems.” Março 2026.
Jackson, Justin. “Will Claude Code Ruin Our Team?” Março 2026.

A Victorino ajuda empresas a medir o que realmente importa no desenvolvimento assistido por IA — não linhas de código, mas resultados de entrega: contato@victorino.com.br | www.victorino.com.br