Mais código não significa mais entrega: onde a IA desloca o gargalo da engenharia

Nos últimos anos, boa parte dos times de engenharia passou a usar IA para gerar código: autocompletar funções, escrever primeiras versões de testes, refatorar módulos, resumir código desconhecido, revisar pull requests. O efeito mais visível é volume — mais linhas, mais commits, mais pull requests abertos por semana. O efeito menos visível, e mais relevante para quem lidera engenharia, é que esse volume nem sempre chega mais rápido à produção. Este texto é sobre esse descompasso: o que de fato ficou mais rápido, por que produção de código não é a mesma coisa que entrega, e para onde o gargalo costuma migrar quando o código deixa de ser o fator que limita o time.

Não é um texto contra IA em engenharia, nem uma lista de boas práticas genéricas. É um raciocínio sobre um problema específico: times que aumentaram a geração de código e, ao medir o que realmente importa — tempo entre ideia e produção —, não viram a mesma melhora. Entender por que isso acontece ajuda a decidir onde investir a seguir, em vez de assumir que a resposta é sempre "mais IA" ou sempre "mais gente".

O que ficou mais rápido com IA

Vale reconhecer o que de fato mudou, sem exagero e sem desconfiança automática. Ficou mais rápido escrever código repetitivo — boilerplate, integrações padronizadas, CRUDs, adaptação entre linguagens e frameworks. Ficou mais rápido produzir uma primeira versão de testes, documentação e scripts auxiliares. Ficou mais rápido entender um trecho de código desconhecido, o que ajuda em manutenção de sistemas legados. Para quem programa, isso é uma mudança real de produtividade individual em tarefas mecânicas.

O que a IA não acelera sozinha é o resto do trabalho de entregar software: entender o problema de negócio, negociar prioridades e trade-offs, conseguir que um pull request seja revisado e aprovado, coordenar uma mudança entre equipes, publicar com segurança, verificar que o comportamento em produção é o esperado. Nenhuma dessas etapas fica automaticamente mais rápida só porque o código foi gerado mais rápido.

Por que produção de código não é o mesmo que entrega

Entrega é o tempo entre uma ideia validada e ela estar em produção, gerando valor. Código produzido é apenas uma etapa desse caminho — e, em times maduros, geralmente não é a etapa mais longa. Se o resto do sistema de entrega (revisão, testes, aprovação, deploy, validação) continuar com a mesma capacidade de antes, gerar mais código mais rápido não aumenta a entrega. Aumenta o trabalho em espera em algum outro ponto da fila.

Esse raciocínio não é novo — é como qualquer sistema de filas se comporta quando a entrada acelera e a saída não. A novidade é que a IA tornou a entrada mais barata e mais rápida de acelerar do que qualquer outra etapa do fluxo, o que expõe gargalos que antes ficavam escondidos atrás de uma produção de código mais lenta.

Os lugares para onde o gargalo pode migrar

Quando a produção de código deixa de ser o fator limitante, o gargalo não desaparece — ele migra para outra parte do sistema. Em geral, para uma (ou mais de uma) destas cinco áreas: direção e priorização pouco claras, decisões e ownership concentrados em poucas pessoas, arquitetura e dependências que exigem coordenação para mudanças pequenas, fluxo de entrega com filas e lotes grandes, e qualidade — a dificuldade de verificar com confiança um volume maior de mudanças.

Decisões e revisão como filas

Revisão de código é uma fila, com tempo de espera e tempo de processamento como qualquer outra. Quando o volume de mudanças cresce e o número de revisores qualificados não cresce junto, o tempo de espera aumenta — mesmo que cada revisão individual não fique mais lenta. O problema piora quando pull requests também ficam maiores: mudanças grandes são mais caras de revisar, mais fáceis de aprovar sem atenção total e mais arriscadas de reverter.

O mesmo vale para decisões técnicas. Times que concentram decisões de arquitetura ou de domínio em duas ou três pessoas conseguem funcionar quando o volume de mudanças propostas é baixo. Quando esse volume cresce — porque é mais barato gerar uma proposta de mudança —, essas mesmas pessoas viram o novo gargalo, mesmo sendo tecnicamente competentes. O problema não é a qualidade da decisão; é a quantidade de decisões esperando pela mesma fila de atenção.

Isso sugere duas perguntas úteis para investigar, em vez de uma resposta pronta: quanto tempo uma decisão técnica típica espera até ser tomada, e quantas pessoas diferentes podem tomar cada tipo de decisão sem escalar para o mesmo nível hierárquico.

Vale um contraponto: distribuir toda decisão para reduzir a fila também tem custo. Decisões tomadas sem contexto suficiente geram inconsistência, retrabalho e, eventualmente, a mesma decisão sendo reaberta meses depois. O objetivo não é eliminar concentração de decisão — é torná-la deliberada: quais decisões realmente precisam passar por poucas pessoas, e quais podem ter um responsável mais próximo do trabalho, com contexto registrado para não depender de memória.

Arquitetura e dependências como restrição

IA é especialmente boa em fazer uma mudança funcionar dentro do código existente — inclusive quando esse código está mal encapsulado. Isso é uma vantagem de curto prazo e um risco de médio prazo: um agente (ou uma pessoa apoiada por um agente) pode alterar um comportamento tocando em vários serviços ou módulos acoplados sem que ninguém precise entender profundamente por que aquele acoplamento existe. A mudança funciona, mas o sistema fica um pouco mais difícil de mudar da próxima vez.

Um sinal prático de restrição arquitetural é quando alterações pequenas, do ponto de vista de negócio, exigem coordenação entre várias equipes ou repositórios. Isso não se resolve pedindo para a IA "refatorar" o sistema de uma vez — reescritas amplas sem entender qual é a restrição real tendem a trocar um conjunto de riscos conhecidos por outro desconhecido. O caminho mais defensável costuma ser escolher uma fronteira específica, de alto impacto, e desacoplá-la de forma incremental, com evidência de que aquela é de fato a restrição que mais atrapalha.

Verificação, qualidade e observabilidade

Se gerar código ficou mais barato, verificar se ele está correto não ficou, na mesma proporção. Revisão, testes, observabilidade e correção de regressões continuam exigindo julgamento humano, contexto de negócio e, frequentemente, tempo de execução (rodar testes, observar métricas em produção, investigar um incidente). Quando o volume de mudanças cresce mais rápido que a capacidade de verificação, o resultado observável costuma ser um destes três: revisões mais superficiais, mais retrabalho depois que o código chega à produção, ou uma sensação recorrente de que "o time não confia totalmente" nas mudanças recentes.

Isso não é argumento contra usar IA na geração de código — é argumento para tratar verificação como uma capacidade que precisa crescer junto. Guardrails claros sobre que tipos de mudança exigem revisão humana mais rigorosa, testes automatizados como pré-requisito (não como tarefa posterior), e observabilidade que permita detectar rapidamente um comportamento inesperado reduzem o custo de supervisão sem exigir revisar cada linha manualmente. O trade-off existe: guardrails demais desaceleram tudo de novo, inclusive mudanças de baixo risco. O critério prático costuma ser proporcionalidade — mais escrutínio onde o custo de errar é alto (dados, pagamentos, segurança), menos onde o custo de reverter é baixo.

O que medir além do volume de código

Número de linhas, commits ou pull requests por semana mede atividade, não entrega. Métricas mais úteis para entender se o sistema como um todo está acompanhando a geração de código incluem:

• Lead time: tempo entre o início real de um trabalho e sua chegada em produção.
• Tempo de espera por revisão, separado do tempo de revisão em si.
• Tamanho médio dos pull requests e dos itens de trabalho.
• Trabalho em andamento simultâneo, comparado ao trabalho concluído ponta a ponta.
• Taxa de retrabalho, reversões e regressões após a entrega.
• Tempo para detectar e tempo para corrigir um incidente.

O valor está menos em um número absoluto — cada sistema tem sua própria linha de base — e mais na tendência: essas métricas estão melhorando, piorando ou estáveis desde que o uso de IA aumentou no time?

Um roteiro inicial de investigação

Antes de contratar mais gente, reescrever um sistema ou expandir o uso de IA, vale um roteiro simples de investigação: escolher um fluxo de negócio crítico e medir seu lead time real, ponta a ponta; separar, dentro desse fluxo, tempo ativo de tempo de espera; conversar com algumas pessoas do time sobre onde elas sentem que o trabalho trava com mais frequência; e verificar se retrabalho, reversões ou incidentes aumentaram desde que a adoção de IA cresceu. Essas quatro observações, sozinhas, já indicam se o gargalo provável está em direção, decisões, arquitetura, fluxo ou qualidade.

Quando a investigação inicial não é suficiente — porque a decisão envolve arquitetura legada, riscos de produção ou uma escolha de investimento relevante —, o passo seguinte costuma ser uma investigação mais profunda, com acesso ao código, à infraestrutura e a um plano de ação priorizado. É esse o papel do Raio-X de Produção.