Os jobs de CI cresceram 25x em seis meses. Ninguém tinha assumido o serviço que quebrou.

A Anthropic registrou “um aumento de 25x nos jobs de CI ao longo de seis meses”. Sachin Malhotra publicou esse número em setembro de 2026, junto de outros dois que o explicam: os engenheiros da Anthropic entregam hoje, em média, 8x mais código por trimestre do que entregavam entre 2021 e 2025, e o Claude é o autor de 80% desse código. A suíte de testes acompanhou. “A quantidade de testes na nossa base cresceu 10x e adicionamos um número nominal de engenheiros.”

O quadro de pessoal ficou quase parado. A carga andou, por um fator que quase nenhum plano de capacidade contempla.

O que quebrou foi o serviço de análise de impacto de testes, a peça que decide quais testes um pull request precisa de fato rodar. Ele foi remendado três vezes. Esses remendos “duraram 70 dias, depois 29 dias e depois menos de um dia, respectivamente”. Cerca de três meses de fôlego somados, e o terceiro remendo durou menos de um dia.

A falha interessante está acima do serviço

Malhotra escreveu uma frase que sai inteiramente do domínio da seleção de testes: “Mesmo quando a tendência estava clara, a propriedade era nebulosa. Ninguém queria assumir mais um pedaço de infraestrutura.”

Essa é a parte que merece atenção. A curva estava visível. O time de engenharia sabia ler um gráfico. Minha leitura de por que o serviço degradou até precisar de uma reconstrução: nenhum time havia se comprometido a responder por ele, e sistema sem dono recebe remendo. Rearquitetar é trabalho de dono; remendar é o que se faz com o problema alheio que cai na sua semana.

Qualquer organização rodando código agêntico provavelmente já tem serviços nessa posição. Orquestração de build, seleção de testes, cache de artefatos, quarentena de testes instáveis. Eram preocupações menores quando um time pequeno abria um punhado de pull requests por semana. Com 25x de volume de jobs, eles sustentam a operação, e o organograma continua tratando esses serviços como detalhe.

A degradação foi um controle falhando em silêncio

Vale olhar o que o serviço fazia enquanto estava quebrado. Ele estava “usando dados desatualizados para decidir o que rodar e o que deixar de rodar nos PRs”. Malhotra delimita a afirmação com cuidado, e o limite importa: isso “não significa que o CI nunca rodou nesses PRs”.

As duas metades andam juntas. O seletor continuou de pé. Ele seguiu tomando decisões com entradas que já tinham deixado de refletir a base de código, uma falha mais desconfortável que uma indisponibilidade. Uma queda se anuncia sozinha. Um serviço de seleção de testes rodando com dados desatualizados devolve verde, no prazo, com o formato certo de relatório, enquanto a relação entre “esses testes passaram” e “essa mudança é segura” enfraquece em silêncio.

Pense em análise de impacto de testes como termo de governança. É o controle que decide quanta garantia uma mudança recebe antes do merge. Trate-o como o portão que ele é, com o escrutínio que um portão merece. Quando degrada, sua evidência de segurança degrada junto, e o pipeline permanece calado sobre a evidência ter ficado mais fina.

Isso conversa com compreensão como gargalo: um controle que reporta tudo verde enquanto a garantia por trás do verde afina.

Duas regras que se transferem

A arquitetura reconstruída é da Anthropic, dimensionada para o problema da Anthropic. Malhotra também diz que o novo desenho é “mais caro de operar” e em nenhum momento quantifica quanto. Copiar a arquitetura está fora do alcance da maioria dos times. Duas regras operacionais estão ao alcance.

A primeira é uma premissa de capacidade, na formulação original: “assuma que sua arquitetura estará sob carga 25x dentro de dois trimestres”. É uma postura de planejamento, com valor de decisão. Converte a pergunta de capacidade de “o que esperamos” para “o que sobrevive se erramos por uma ordem de grandeza?”. Aplicada com honestidade, ela mata muito desenho ainda no quadro branco, que é onde você quer que morram.

A segunda é uma verificação de conservação: “garanta que o mesmo número de jobs de CI que entra seja o mesmo que sai”. Uma invariante de uma linha. Jobs que entram igual a jobs que saem. Se os dois números divergem, alguma coisa está sendo descartada em silêncio.

Essa segunda regra é a que eu implementaria primeiro, porque é barata e torna a falha cara barulhenta. Verifique se o seu pipeline tem uma. Painel de duração e check verde, que é o que os pipelines que vejo expõem, são cegos para um job que deixou de ser agendado.

O que a PostHog acrescenta, e o que ela qualifica

A PostHog publicou os próprios números em setembro de 2026. Ian Vanagas relatou que a empresa “passou de 1.441 PRs mesclados em janeiro para 4.869 em agosto, crescendo apenas 10% o quadro de engenharia”, e que os PRs abertos por agentes foram “de cerca de 20% dos PRs do nosso monorepo abertos por agentes para 70%” ao longo de quatro meses. Isso dá aproximadamente 3,4x de alta em PRs mesclados contra 10% de aumento de pessoas.

Seria conveniente arquivar isso como segundo dado sobre pressão em CI. O encaixe é mais frouxo. A restrição nomeada pela PostHog é capacidade de revisão e julgamento, a habilidade humana de avaliar o que os agentes produziram. A infraestrutura que constrói e testa fica em segundo plano no relato deles. Isso qualifica a tese de infraestrutura em vez de confirmá-la. Duas empresas com volume em alta acentuada nomearam coisas diferentes como restrição dominante, um aviso útil contra supor que você já sabe onde o seu próprio throughput vai travar.

Sean Goedecke argumenta, em registro de previsão, que “chamadas de ferramenta rápidas serão a diferença entre uma resposta quase instantânea e ter que esperar vários minutos”. Ele não apresenta nenhuma medição organizacional para isso. Trate como hipótese sobre onde o custo de latência aparece em seguida, separada de evidência de custo realizado.

Uma coisa que nenhuma dessas fontes afirma: que o quadro de pessoal encolhe. A PostHog cresceu engenharia em 10%. A Anthropic “adicionou um número nominal de engenheiros”. O custo permaneceu dentro da organização. Ele migrou para uma infraestrutura que ninguém tinha aceitado assumir, um padrão que já rastreamos pelo lado do engenheiro individual em o custo real da IA em 2026 e pelo lado da interação em a economia do uso de computador.

Faça isto agora

Pegue seu pipeline de build e teste e responda três perguntas por escrito.

Quem é dono da lógica de seleção de testes? Vá além de “quem escreveu”. Quem responde quando degrada, quem é acionado e qual roadmap absorve a reconstrução. Se a resposta honesta é que pertence a quem tocou por último, você reproduziu a precondição da Anthropic antes de reproduzir o volume.

Jobs que entram são iguais aos que saem? Instrumente nesta sprint. Conte os jobs que o pipeline deveria ter rodado, conte os que ele rodou de fato, alerte na diferença. Se você é incapaz de produzir esses dois números hoje, a classe de falha que três remendos não resolveram está invisível para você agora.

O que sua arquitetura faz com 25x? Pule o 2x. Tome o número 25x como premissa de estresse e leve um pipeline até lá. Onde ele cair primeiro é o seu próximo serviço com dono. Nomear um dono agora custa uma conversa. Nomear depois custa uma reconstrução.

O volume é a parte fácil de enxergar. A propriedade é a parte que fica nebulosa até o gráfico forçar a decisão, e a essa altura você já está remendando.

Fontes

Anthropic (Sachin Malhotra). “Agentic coding is straining CI. Here’s how we scaled test impact analysis at Anthropic.” Setembro de 2026.
PostHog (Ian Vanagas). “What happens to engineers when AI writes all the code?.” Setembro de 2026.
Sean Goedecke. “Slow developer experience will bottleneck fast models.” Setembro de 2026.

A Victorino ajuda organizações de engenharia a atribuir propriedade e instrumentação à infraestrutura de build e teste que o código agêntico coloca sob carga: contato@victorino.com.br | www.victorino.com.br