Agentes de código forçam a Anthropic a reescalar sua análise de testes

Agentes de código pressionam a CI

Engenheiros da Anthropic publicam um relato interno sobre como o uso intenso de agentes de codificação sobrecarregou a infraestrutura de integração contínua (CI) da empresa. Segundo o autor, Sachin Malhotra, engenheiros da Anthropic hoje produzem em média 8 vezes mais código por trimestre do que entre 2021 e 2025, e o Claude é responsável por 80% desse código, além de atuar na revisão e aprovação de PRs. Com a escrita de código acelerada, o gargalo migrou para a CI: o volume de testes no codebase cresceu 10 vezes, poucos engenheiros foram adicionados, e o número de jobs de CI subiu 25 vezes em seis meses.

Como funciona o serviço de seleção de testes

A empresa não roda todos os testes em cada mudança. Um serviço determinístico de "test impact analysis" decide quais testes executar em cada PR com base em histórico e relevância de pacotes. Ele depende de dois componentes sincronizados: um "listener", que grava os resultados de cada execução de CI, e um "selector", que usa esse histórico para escolher os testes de cada PR. Com múltiplos jobs rodando a cada segundo, o listener passa a acumular atraso - e 20 minutos de lag podem significar dezenas de milhares de atualizações de testes não aplicadas, causando investigações desnecessárias, bloqueios por testes flaky e risco de regressões. O design original, com um único processo escritor para manter o histórico, impedia o sharding horizontal.

Três correções provisórias

Em outubro de 2025, o serviço já dava sinais de sobrecarga, com pages por dois dias seguidos. A primeira correção foi dobrar os núcleos da máquina, o que durou cerca de 70 dias. A segunda, em fevereiro, foi sharding: o autor usou uma sessão de longa duração numa versão interna do Claude Tag para monitorar o serviço - alertando quando o atraso passava de 50.000 jobs - e o Claude gerou o código para dividir o estado por pacote em shards com workers próprios; a solução durou 29 dias. A terceira, em março, foi reinício diário do processo, que atingia o limite de memória no meio da tarde; a equipe encontrou apenas quatro bugs, trocar o alocador de memória não resolveu, e reiniciar comprava menos de um dia. Quando o atraso passava de uma hora, resultados não eram gravados, o que fazia o selector usar dados obsoletos - rodando testes já falhando ou flaky. O autor esclarece que isso não significava código sem testes indo à produção.

O redesign

A equipe seguiu a recomendação do Claude e deu um banco de dados ao serviço - na prática, um armazenamento de dados em memória. Agora qualquer worker do listener processa qualquer resultado, o anexa a um journal e segue adiante sem guardar estado (stateless, portanto escalável horizontalmente); um processo consumidor separado consolida o journal em histórico por teste a cada poucos segundos. A arquitetura distribuída é mais cara de rodar, mas mais fácil de escalar e perfilar. O projeto levou três semanas para um único engenheiro - um ano antes, teria levado cerca de um trimestre. Após ajustes de dimensionamento, em grande parte feitos autonomamente pelo Claude, o serviço permaneceu estável.

Lições

O autor recomenda planejar para o crescimento exponencial: assume que jobs de CI crescem exponencialmente conforme mais agentes por engenheiro e a PRs menores e mais granulares (preferência do Claude), com agentes trabalhando também à noite e em fins de semana. Seu conselho é assumir que a arquitetura alcançará carga 25 vezes maior em dois trimestres, considerar 10 a 20 vezes a escala percebida nos designs iniciais, instrumentar serviços para que o Claude possa atuar como "olhos e ouvidos" e corrigir problemas incrementalmente, e manter o estado fora do processo desde o início, evitando serviços críticos em instância única. Ele antecipa que arquiteturas horizontais de seleção de testes devem se tornar padrão da indústria conforme mais times rodem agentes.