A Anthropic publicou em 14 de setembro um artigo no blog de engenharia. O autor, Sachin Malhotra, conta como um serviço interno da empresa foi sobrecarregado e precisou ser reescrito do zero. O serviço se chama test impact analysis (análise de impacto de testes) e tem uma função bem simples: a cada alteração de código que entra, decidir quais testes precisam rodar e quais podem ser pulados. Parece um componente de bastidores, mas o motivo pelo qual ele não aguentou é bastante representativo.
Primeiro, alguns múltiplos
O primeiro conjunto de números do artigo é do lado da produção: os engenheiros da Anthropic agora entregam, em média, 8 vezes mais código por trimestre do que no período de 2021 a 2025, e 80% desse código é escrito pela Claude, que também assume boa parte da revisão e aprovação de pull requests.
O segundo conjunto de números é do lado da pressão: o total de testes na base de código cresceu 10 vezes, e o número de tarefas de CI aumentou 25 vezes em seis meses.
O terceiro conjunto de números é o que melhor mostra o ritmo da situação. Para aguentar a carga, a equipe implementou três rodadas de solução temporária, que compraram, respectivamente, 70 dias, 29 dias e menos de 1 dia de fôlego. A terceira solução foi consumida no próprio dia em que entrou no ar.
Onde o serviço antigo travava
A arquitetura antiga tinha um listener de processo único, que precisava gravar o resultado de cada teste no armazenamento em ordem sequencial. Escrita única significa que não dá para escalar horizontalmente, e assim que a velocidade de chegada de pull requests superava a capacidade de processamento, a fila começava a se acumular. A frase original do artigo é que o listener "starts to increasingly fall behind the PR queue" (começa a ficar cada vez mais atrasado em relação à fila de PRs).
O atraso trazia consequências em cadeia. O exemplo dado no artigo é que um atraso de 20 minutos correspondia a dezenas de milhares de atualizações de resultados de teste ainda não gravadas no armazenamento. Como a seleção de testes depende justamente de resultados históricos, um histórico impreciso torna o conjunto de testes escolhido pouco confiável. Para piorar, esse processo também tinha um vazamento de memória e batia no teto todas as tardes.
No que foi transformado
A ideia da reescrita foi tirar o estado de dentro do processo. A nova arquitetura introduz um armazenamento de dados em memória: qualquer worker do listener pode processar qualquer resultado, sua única função é acrescentar ao log, sem manter estado próprio, o que permite adicionar máquinas conforme necessário. Há também um processo consumidor separado que, a cada poucos segundos, condensa o log em um histórico organizado por teste individual. Quando o seletor precisa decidir, ele consulta diretamente esse histórico.
O preço disso foi um aumento de custo. O artigo reconhece isso, justificando pela escalabilidade e observabilidade obtidas — agora é possível medir separadamente qual etapa está lenta e onde exatamente. Todo o redesenho foi feito por um único engenheiro em três semanas.
A curva desse 25 vezes
Um crescimento de 25 vezes em seis meses equivale a uma taxa de crescimento composto mensal de cerca de 1,71 vezes (cálculo aproximado: raiz sexta de 25). Projetando essa inclinação para mais seis meses, chega-se a 625 vezes. A frase final do autor, "always plan for the exponential" (sempre planeje para o exponencial), não é retórica — corresponde a uma curva que já foi medida.
Essa extrapolação, claro, não é confiável — a taxa de crescimento pode mudar de direção por causa de políticas internas, cotas ou mudanças nos hábitos de engenharia. A Anthropic também não divulgou o valor absoluto da conta de CI, não disse qual proporção dos testes o novo serviço consegue filtrar, e muito menos informou a que nível a latência caiu depois da reescrita. Quanto dinheiro foi economizado é algo que não dá para deduzir a partir das informações públicas.
Ainda assim, fica claro por onde a pressão vai passando de uma etapa para outra. Em abril deste ano, o GitHub interrompeu novas assinaturas dos planos individuais pagos do Copilot, alegando que o consumo de computação das tarefas longas de agentes ultrapassava o que o plano foi projetado para suportar; antes disso, um surto de commits gerados por IA já havia levado o GitHub a falhas, chegando a fazer a Microsoft tomar emprestada capacidade da AWS por um tempo. São três episódios de formatos diferentes, mas todos apontam para a mesma coisa: a geração de código acelera primeiro, depois vem a revisão, e em seguida cada sistema dimensionado para a velocidade de programadores humanos vai sendo atingido, um a um. A análise de impacto de testes é apenas o primeiro alarme desta rodada.
Fontes: CocoLoop, blog de engenharia da Anthropic; os múltiplos de volume de código, testes e tarefas de CI, além da duração das três soluções temporárias, foram todos extraídos dos números publicados nesse artigo.