A IA acelerou a produção. Por que a entrega continua travada?

Capa conceitual gerada por IA; não representa instalações ou profissionais da Anthropic.

Resumo: A Anthropic relata que o aumento de alterações de código transformou sua infraestrutura em gargalo. O caso ajuda a entender por que produzir mais com IA exige reorganizar revisão, aprovação e acompanhamento do trabalho.

Uma equipe passa a usar IA para preparar propostas. Antes, produzia oito por dia; agora, consegue elaborar vinte. O painel parece anunciar uma vitória. Mas quem revisa o conteúdo continua com a mesma capacidade, e a aprovação depende das mesmas pessoas. No fim da semana, há mais material pronto e uma fila maior de decisões.

Esse exemplo fictício ajuda a interpretar uma notícia concreta. Em 13 de outubro de 2026, a Anthropic publicou um relato sobre a reconstrução de seu controle de versões. Segundo a empresa, o crescimento das alterações de código deslocou o gargalo para a infraestrutura que precisava integrá-las. A implicação ultrapassa o desenvolvimento de software: acelerar uma etapa pode transferir a pressão para outra. [1]

Como ler este artigo. O caso da Anthropic é um relato do próprio fornecedor, não uma auditoria independente de produtividade. Os estudos da METR tratam de outros ambientes e períodos. O exemplo das propostas e seus gráficos são uma demonstração matemática original, sem representar resultados de uma empresa real. Fontes consultadas em 15 de outubro de 2026.

O que aconteceu na Anthropic

A empresa informa que passou de cerca de 2.500 alterações integradas por dia, em maio de 2026, para mais de 30 mil em setembro. Integrar uma alteração significa incorporá-la à base compartilhada do código. O patamar de setembro é aproximadamente doze vezes o de maio, quatro meses depois. Alterações integradas não equivalem a funcionalidades entregues nem medem, sozinhas, qualidade ou valor. [1]

A equipe criou o Scion e migrou seu repositório principal em cinco meses. Repositórios guardam código e histórico; o Git é uma ferramenta de controle de versões. O Scion é interno, sem proposta de substituir o Git no uso geral. [1]

A restrição relatada era técnica: controle de versões, compilação — transformação do código em programa executável — e integração contínua, ou CI, com verificações automáticas. No exemplo das propostas, a restrição está nas pessoas que revisam e aprovam. A analogia trata do deslocamento do gargalo, não de uma fila de revisores na Anthropic. [1]

A lição que proponho extrair é observar o percurso inteiro. Quando fica mais fácil gerar trabalho, o restante do sistema precisa conseguir recebê-lo, avaliá-lo e transformá-lo em resultado utilizável.

Produção, revisão e entrega são medidas diferentes

Um relatório escrito ainda pode precisar de conferência. Uma aula preparada ainda precisa corresponder ao objetivo de aprendizagem. Uma alteração de código integrada ainda pode não estar disponível para o usuário.

Por isso, a pergunta “quanto a IA produziu?” deve vir acompanhada de outras: quanto foi aceito, quanto exigiu retrabalho e quanto chegou ao destino pretendido? Se a métrica termina cedo demais, uma equipe pode celebrar uma melhoria local enquanto o prazo total piora.

Chamo de gargalo a etapa cuja capacidade restringe o fluxo observado. Ele pode estar numa pessoa, numa regra de aprovação, numa ferramenta ou na falta de informação. Identificá-lo não significa procurar um culpado; significa descobrir qual restrição precisa ser tratada.

Uma conta simples mostra onde a fila aparece

Retomemos a equipe de propostas. Suponha documentos de esforço equivalente, sem rejeições nem retrabalho. A revisão comporta doze propostas por dia, e a aprovação final comporta dez. Todo o material do dia pode percorrer as etapas nesse mesmo dia, respeitando essas capacidades.

Antes da IA, entram oito propostas diárias: as oito são revisadas e aprovadas. Depois, a produção sobe para vinte, mantendo o restante igual. Em cada dia, doze passam pela revisão e dez chegam à aprovação. Sobram oito aguardando revisão e duas aguardando aprovação.

Ao fim de cinco dias, o sistema acumula quarenta propostas antes da revisão e dez antes da aprovação: cinquenta pendentes. A produção cresceu 150%, de oito para vinte; a entrega cresceu 25%, de oito para dez. A entrega até cresce, mas a fila faz cada novo item demorar mais para chegar ao destino.

A capacidade adicional permitiu entregar mais, mas também criou uma entrada maior do que o sistema consegue concluir. O exemplo supõe trabalho homogêneo e ignora imprevistos. Na prática, complexidade, correções e urgências precisam entrar na análise.

O prazo torna a consequência mais concreta. Mantendo a ordem de chegada nas duas etapas, a primeira proposta produzida no sexto dia tem cinquenta pendências à frente. A dez aprovações diárias, esse estoque consome cinco dias úteis de capacidade. Ela será entregue no décimo primeiro dia, cinco dias úteis depois do que ocorreria sem a fila. É uma conta deste cenário determinístico, não uma previsão para qualquer equipe.

O que a ciência das filas ajuda a enxergar

John D. C. Little demonstrou, em 1961, uma relação conhecida como Lei de Little: em condições adequadas de estabilidade e médias bem definidas, o número médio de itens no sistema é igual à taxa média de passagem multiplicada pelo tempo médio de permanência. [4]

A relação ajuda a conectar quantidade de trabalho e tempo de atravessamento. Não autoriza transformar a fotografia de uma fila em prazo garantido. No exemplo anterior, a entrada supera continuamente a saída; a fila cresce, e não devemos fingir que o sistema já opera em equilíbrio.

Na gestão cotidiana, uma aplicação útil é acompanhar o trabalho iniciado e ainda não concluído, conhecido como WIP, sigla inglesa de work in progress. O Kanban Guide, de maio de 2025, inclui seu controle, além do acompanhamento de entregas por período, idade dos itens e tempo de ciclo. Este último mede o intervalo entre início e término definidos no fluxo. [5]

Nem o entusiasmo nem a desconfiança substituem a medição

Há evidência independente de que a percepção de ganho pode divergir da medição. Em estudo publicado em julho de 2025, Joel Becker, Nate Rush, Beth Barnes e David Rein, da METR, acompanharam dezesseis desenvolvedores experientes em 246 tarefas de seus próprios projetos. Com acesso às ferramentas de IA avaliadas, eles levaram, em média, 19% mais tempo. Antes do experimento, esperavam que a IA os deixasse 24% mais rápidos. Depois, mesmo tendo levado mais tempo, ainda estimavam uma aceleração de 20%. Essa diferença entre percepção e medição dá conteúdo ao painel que parece anunciar uma vitória. O resultado vale para aquele recorte e suas ferramentas do início de 2025; não estabelece o desempenho dos sistemas de outubro de 2026. [2]

A atualização de fevereiro de 2026 traz estimativas brutas que os próprios autores consideram pouco confiáveis: pessoas e tarefas ficaram de fora quando participantes recusaram trabalhar sem IA, e o uso de vários agentes em paralelo dificultava medir o tempo. Esses limites desaconselham concluir que a IA continuaria atrasando o trabalho. As estimativas apontaram redução de 18% no tempo para participantes da rodada original e de 4% para recém-recrutados. Os intervalos de confiança — faixas que expressam a incerteza estatística — foram, respectivamente, de −38% a +9% e de −15% a +9% na variação do tempo. Valores negativos indicam menos tempo; positivos, mais. Ambos os intervalos incluem ausência de efeito. [3]

Os autores consideram provável que o ganho tenha aumentado desde 2025, mas classificam seus dados como evidência muito fraca desse aumento. [3]

Esses trabalhos não medem o Scion nem refutam seu relato. Mostram por que uma comparação precisa registrar quem participou, quais tarefas entraram, qual ferramenta foi usada e o que foi contado como conclusão. Um número sem essas condições pode responder a outra pergunta.

Como reorganizar o trabalho sem apenas cobrar mais revisão

Uma reação comum seria pedir que os revisores acompanhassem a nova velocidade. Eu começaria por um diagnóstico: o que faz os itens esperar? Falta capacidade, chegam propostas incompletas ou a mesma pessoa precisa aprovar assuntos de riscos muito diferentes?

No exemplo, reduzir a liberação para dez propostas por dia impediria o crescimento do total pendente sob as hipóteses adotadas. As cinquenta pendências já acumuladas continuariam no sistema. Para esvaziá-las, seria preciso manter a entrada abaixo de dez por algum tempo ou elevar a capacidade de saída, verificando também a revisão. Isso não significa abandonar a capacidade da IA. O tempo disponível pode ajudar a melhorar evidências, conferir cálculos ou eliminar trabalho desnecessário antes de enviar para revisão.

Outra possibilidade é reduzir o esforço de conferência: um formato consistente, referências localizáveis e uma indicação clara do que mudou podem facilitar a análise. Se houver revisão automática, sua qualidade também precisa ser verificada. Trocar uma fila visível por erros que aparecem depois não constitui melhoria.

Há um exemplo concreto no desenvolvimento do próprio Scion: a equipe relata continuar revisando cada solicitação de mudança, concentrando-se na intenção em vez de ler linha por linha. Isso descreve aquele sistema, não uma prática comprovada para toda a empresa ou qualquer contexto. [1]

Na educação, o paralelo é direto. Gerar trinta atividades rapidamente não garante que o professor consiga avaliar sua adequação nem que os estudantes recebam devolutivas úteis. A unidade de resultado deve corresponder ao objetivo: uma atividade aplicada e analisada, por exemplo, em vez de apenas um arquivo produzido.

Uma competência profissional: saber o que deixar de iniciar

Quando produzir custa menos esforço, escolher passa a exigir mais atenção. A tentação é começar novas demandas sempre que surge uma ideia. Uma competência valiosa é reconhecer quando o próximo ganho depende de terminar algo que já está aberto.

Para quem coordena uma equipe, isso exige tornar as escolhas explícitas: qual entrega tem prioridade, quem resolve um bloqueio e o que justifica uma urgência? Para quem executa, exige registrar a pendência com clareza, em vez de ocultá-la sob novas tarefas concluídas pela metade.

A IA pode ajudar a organizar essas informações. A responsabilidade de estabelecer prioridades, negociar capacidade e conferir o resultado continua precisando de pessoas com conhecimento do contexto.

Um piloto que mede o percurso completo

Antes de ampliar a automação, proponho observar um conjunto pequeno de demandas comparáveis, com critérios definidos previamente:

• Entrada e saída: quantos itens começaram e quantos foram aceitos no período?
• Espera: onde cada item ficou parado, por quanto tempo e por qual motivo?
• Qualidade: quais foram devolvidos e quanto retrabalho exigiram?
• Capacidade: revisão e aprovação acompanharam a entrada sem ampliar excessivamente o trabalho em curso?
• Resultado: o usuário recebeu algo utilizável mais cedo, com qualidade suficiente?

Separe demandas simples e complexas; registre mudanças de equipe e de ferramentas. Uma comparação curta não prova um ganho universal, mas ajuda a decidir onde investigar antes de expandir.

A entrega pode continuar travada depois que a IA acelera a produção porque o sistema não termina na geração do conteúdo. O caso da Anthropic mostra uma organização redesenhando sua infraestrutura diante dessa pressão. Em outras equipes, a resposta pode ser mais simples: limitar a entrada, esclarecer critérios e retirar obstáculos da etapa seguinte. O ganho que importa aparece quando o trabalho chega ao destino.

Referências

1. NICK G. e equipe de controle de versões. Redesigning source control at Anthropic. Anthropic, 13/10/2026. Relato do fornecedor; dados internos de maio a setembro de 2026.
2. BECKER, Joel; RUSH, Nate; BARNES, Beth; REIN, David. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR, 10/07/2025.
3. BECKER, Joel; RUSH, Nate; CUNNINGHAM, Tom; REIN, David; MAHAMUD, Khalid. We are Changing our Developer Productivity Experiment Design. METR, 24/02/2026.
4. LITTLE, John D. C. A Proof for the Queuing Formula: L = λW. Operations Research, v. 9, n. 3, p. 383–387, 1961. DOI: 10.1287/opre.9.3.383.
5. KANBAN GUIDES. The Kanban Guide. Edição de maio de 2025. Definições e métricas de fluxo.