388 pull requests. 180 deles mergeados. Cada linha escrita por uma IA. Boris Cherny, cocriador do Claude, publicou esses números de um experimento que roda dentro da Anthropic há semanas: um canal do Slack chamado proj-claude-maintains-apps, onde o Claude aparece todos os dias, encontra problemas, corrigi-os, abre PRs — e espera um humano apertar o botão de merge. O trabalho restante dos engenheiros é um único botão.
Isto não é uma demonstração. É um sinal estrutural: o gargalo na engenharia de software migrou de escrever código para revisá-lo. Os dados por trás dessa mudança valem ser analisados antes que alguém diga que é hype.
O que o Claude realmente fez: onze tarefas rotineiras, zero funcionalidades novas
Cherny atribuiu ao Claude uma rotina de manutenção em seis superfícies — iOS, Android, desktop, web, CLI e Agent SDK. Onze tipos de tarefa, e nenhum deles é “construir algo novo”:
- Patrulha de crashes. Abrir o app real em um simulador, cutucá-lo até quebrar, localizar a causa, abrir um PR de correção com passos de reprodução e uma tabela-verdade. As instruções originais de Cherny proíbem explicitamente fingir isso com um app substituto.
- Fusão de abstrações duplicadas. Escanear o codebase em busca de implementações parecidas e colapsá-las em uma só.
- Limpeza de código morto. Deletar imediatamente o que a análise estática prova ser inalcançável; para código morto “suspeito”, adicionar logging, observar por um dia e deletar no dia seguinte se ninguém passou por ali.
- Correção de vazamentos de abstração, remoção de testes que sempre passam, triagem de testes instáveis, remoção de feature flags, descontinuação gradual baseada em uso de funcionalidades internas esquecidas.
Essa disciplina de “registrar por um dia, depois deletar” é o instinto de um engenheiro sênior. O Claude está sendo pago em tokens para fazer o trabalho que ninguém quer fazer e pelo qual ninguém é promovido.
O gargalo se inverteu: gerar é barato, revisar é caro
O próprio anúncio de março da Anthropic sobre Code Review deu o primeiro número: a produção de código por pessoa cresceu 200% ano após ano, e a revisão de código virou o gargalo.
A evidência independente é mais forte. O relatório de 2026 da Faros AI, The Acceleration Whiplash, construído sobre dois anos de telemetria de 22.000 desenvolvedores e mais de 4.000 equipes, constatou que, em alta adoção de IA:
- Épicos concluídos por pessoa: +66,2%. Throughput de tarefas: +33,7%. Taxa de merge de PRs: +16,2%.
- Mas deploys semanais: −11,7%. Bugs por desenvolvedor: +54%. Incidentes por PR: +242,7%.
- Código mergeado e depois deletado: +861%. Tamanho médio do PR: +51,3%.
- Tempo mediano esperando por um revisor: +441,5% — e 31% mais PRs mergeados sem nunca terem sido revisados.
Mais merges, menos entregas. A fila está travada na revisão. O dia humano agora é assim: cinco minutos para gerar mil linhas, e uma tarde inteira para lê-las. A IA ficou com a escrita; os humanos ficaram com a leitura.
Os números do Code Review da Anthropic explicam o porquê: antes do lançamento, apenas 16% dos PRs recebiam revisão substantiva; depois, 54%. PRs com mais de 1.000 linhas têm 84% dos seus problemas detectados (7,5 em média); PRs com menos de 50 linhas, 0,5. Uma revisão custa cerca de 20 minutos e US$ 15–25 em tokens. O sistema nunca aprova nada — a aprovação continua humana. O limite é explícito: a IA pode encontrar, corrigir e propor sem permissão; fazer merge e entregar exige uma pessoa.
Como o sistema é construído: corrija a rotina, não o resultado
Quatro camadas: o Claude Tag vive no Slack como ponto de entrada (atualizado em 13 de agosto para ler todo o contexto do canal antes de agir). As Routines são a camada de execução — lançadas em 14 de abril, agrupam prompts, repositórios e conectores, acionadas por agendamento, chamadas de API ou eventos do GitHub, rodando na infraestrutura em nuvem do Claude Code. O Claude Code Review é a camada de revisão. Os humanos são a camada de aprovação.
A lição mais transferível é o método de ajuste do Cherny: quando uma classe de PRs continua falhando, ele não corrige os PRs um a um — ele edita a Routine que os gerou e observa os próximos dias de output. Prompts deixam de ser entradas de uso único e se tornam ativos de longa duração que precisam de operação: escrever, publicar, observar, iterar, exatamente como um serviço de produção. Cada correção se acumula no conjunto de regras, de modo que o lote de PRs de amanhã contém menos erros por construção.
O que isso significa para a indústria
- Uma economia de revisão está se formando. Se gerar código é praticamente de graça, a habilidade escassa é ler código de forma rápida e precisa. A Anthropic já precifica revisão como produto pago; espere que ferramentas de revisão, review-as-a-service e papéis de “concierge de merge” se multipliquem.
- As políticas estão alcançando a realidade. O projeto Rust adotou uma política de LLM no início de agosto: contribuições geradas por IA devem ser declaradas, mantidas longe de caminhos críticos e bem testadas — e os mantenedores explicitamente não são obrigados a revisar PRs de IA. “Podemos fechar” é o novo piso de governança.
- O valor do engenheiro está sendo redefinido. O sinal salarial está mudando de quão rápido você escreve para quão rápido e confiável você julga. Quem prospera são as pessoas capazes de triar 388 PRs sem se esgotar.
Isso se conecta a duas threads que cobrimos recentemente: por que arquivos de instrução de agentes crescem sem controle e como múltiplos agentes colidem em um mesmo codebase. O output dos agentes não é mais a restrição — a governança é.
O que você pode fazer hoje
- Delegue primeiro as tarefas verificáveis. Tarefas com verificações claras de passar/falhar — reprodução de crashes, detecção de duplicatas, código morto — são onde os agentes já são confiáveis. Quando a decisão depende de gosto (“essa abstração está sobre-engenheirada?”), os agentes ainda falham.
- Invista em testes antes de investir em agentes. Um gargalo de revisão é um problema de cobertura de testes disfarçado. Quanto mais segura a sua suíte de testes, mais barato é confiar nos PRs da IA.
- Trate prompts como ativos de produção. Escreva-os como serviços: versione, observe, itere. Corrija a regra, não o resultado.
- Repense seu próprio fluxo de revisão. Se a fila de PRs da sua equipe cresce mais rápido que o ritmo de deploys, a solução não é gerar mais — é revisar mais rápido e mais barato.
