Os trabalhos de CI da Anthropic cresceram 25x em seis meses. O aviso estava na rapidez com que cada correção deixava de resultar
By Surya Pratap
16 de setembro de 2026
12 min de leitura
IA e tecnologia
16 de setembro de 2026
12 min de leitura
A meia-vida de uma correçãoHover to exploreA Anthropic publicou os seus números de integração contínua a 14 de setembro de 2026, num artigo de engenharia de Sachin Malhotra sobre a reconstrução do serviço que decide que testes executar. Os números de destaque circularam depressa, e com razão. Mas o mais útil do artigo é um pormenor que quase ninguém repetiu.
Seis meses de código agêntico, medidos por dentro
A própria organização de engenharia da Anthropic, não um caso de cliente
Leia-os em conjunto e não isoladamente. A relação interessante não é nenhum múltiplo solto — é que 8x mais código produziu 10x mais testes e 25x mais trabalhos de CI. A carga não escalou com o código. Escalou com o código vezes os testes vezes o número de vezes que alguém pergunta se aquilo continua verde.
A formulação de Malhotra é a parte que vale a pena citar literalmente, porque é mais precisa do que a paráfrase habitual:
Escrever código já não é a restrição e, assim que a revisão de PR acelera, o CI começa a sentir a pressão.
Isto é uma sequência, não um slogan. Três estações, por ordem: escrever, rever, verificar. O código agêntico eliminou a primeira restrição. Acelerar a revisão eliminou a segunda. Nenhuma delas criou capacidade — deslocaram a fila para o que estivesse a seguir e não tivesse folga.
É isto que eu quereria que um fundador levasse do artigo, à frente de qualquer número nele contido. Eliminar um estrangulamento não produz débito. Produz um estrangulamento novo, uma estação a jusante, que chega mais depressa do que o anterior e normalmente num sistema para o qual ninguém olha há dois anos.
Para a maioria das equipas pequenas, as estações a seguir a "escrever o código" são a revisão, o CI, os ambientes de staging, os deploys de pré-visualização e depois — em silêncio, por último e de forma mais cara — as pessoas que têm de perceber o que foi para produção.
A Anthropic corrigiu o serviço de test impact analysis três vezes antes de o reconstruir. Todas as correções eram sensatas. Eis quanto tempo durou cada uma:
Setenta, vinte e nove, um.
Nenhuma decisão isolada foi errada. Duplicar núcleos quando um serviço está lento é correto. Repartir quando um único worker satura é correto. Reiniciar um serviço que acumula atraso é uma coisa normal de se fazer a uma terça-feira. Cada correção era proporcional ao sintoma que tinha à frente.
A falha foi que ninguém media o intervalo entre correções como sinal próprio — e esse intervalo estava a reduzir-se para cerca de metade de cada vez.
O diagnóstico que vale a pena copiar
Quando cada correção sucessiva do mesmo sistema compra menos tempo do que a anterior, está a aplicar remédios lineares a carga exponencial, e a pista que lhe resta é mais curta do que parece. Os números absolutos dizem-lhe quão mau é o dia de hoje. A proporção entre eles diz-lhe quanto tempo tem. Um patch que aguenta 70 dias seguido de outro que aguenta 29 não são dois incidentes. É uma tendência com dois pontos, e o terceiro já é previsível.
O serviço tinha duas metades: um listener que regista o resultado de cada teste de cada execução de CI, e um selector que decide de que testes um dado pull request precisa realmente.
A restrição era o listener ser um singleton. Um único escritor tinha de manter o histórico acumulado por teste, o que impedia escalar na horizontal — as únicas jogadas disponíveis eram uma máquina maior, depois um conjunto de máquinas particionado, depois reiniciar a máquina. As três correções não foram falta de imaginação. Eram o conjunto completo de opções que aquela arquitetura permitia.
O redesenho — um projeto de três semanas — separou as responsabilidades tirando o estado de dentro do processo:
O que substituiu o singleton
Workers sem estado sobre estado partilhado, em vez de workers com estado que o possuem
Depois da transição, a contagem de eventos de resultados em fila por processar manteve-se plana, quando antes crescia semana após semana. Essa linha plana é a entrega verdadeira. Não mais rápido — sem acumulação, que é uma propriedade diferente e a única que sobrevive a mais um 25x.
A recomendação de Malhotra é desenhar os sistemas iniciais para 10-20x a escala percebida, quando o orçamento o permitir, e assumir que a carga puxada pela IA pode chegar a 25x em dois trimestres.
Leve a última oração a sério — quando o orçamento o permitir está a fazer trabalho real nessa frase. A Anthropic descreve a sua própria infraestrutura interna, num laboratório de fronteira cujo código é escrito pelo modelo que vende. Uma equipa em fase seed que copie "construa para 20x" à letra vai sobredimensionar um produto que ainda não encontrou ninguém que o queira, e esse modo de falha já matou mais startups do que o atraso do CI alguma vez matará.
A versão transferível é mais estreita e mais barata:
As restantes lições enunciadas generalizam bem e não custam nada: evite que um caminho crítico seja um singleton, instrumente os serviços para que um agente os possa investigar de forma autónoma, e confirme que o volume que entra numa fila corresponde ao que sai. Este último ponto é como se deteta que um sistema está a ficar para trás antes de um humano reparar que está desatualizado.
A Anthropic publicou contagens de trabalhos. Não publicou o que esses trabalhos custam e, para um fundador, essa omissão é a história toda, porque o CI é medido e faturado.
Um aumento de 25x nos trabalhos de CI é um aumento de 25x em minutos de computação na fatura dos runners, modulado apenas pela qualidade da seleção de testes — que é precisamente o serviço que estava a cair. Se a sua equipa adotar código agêntico e não fizer mais nada, a sequência observável é: a velocidade sobe, toda a gente fica contente e, cerca de dois meses depois, alguém pergunta porque é que a linha do CI na fatura de infraestrutura se tornou em silêncio uma das maiores rubricas.
É a mesma aritmética do imposto de contexto, deslocada um sistema para a esquerda. O custo do desenvolvimento agêntico não é só a inferência que compra. É a carga de verificação que o código gerado cria a jusante — testes para executar, ambientes para levantar, artefactos para construir, revisões para sustentar — e essa carga cresce mais depressa do que o código.
O número para pôr num painel esta semana
Não os minutos de CI. Minutos de CI por pull request integrado, acompanhados semanalmente. Os minutos totais subirem é esperado e saudável — significa que está a entregar. Os minutos por integração subirem significa que cada unidade de trabalho está a ficar mais cara de verificar, e esse é o indicador avançado que chega meses antes da fatura.
O artigo complementar descreve a Anthropic a apontar o Claude às falhas de CI/CD como primeiro interveniente automático — a vigiar alertas, a investigar em Grafana, arquivos de logs, PagerDuty, GitHub e Kubernetes, e a propor correções. Os números publicados: uma mediana de 14 minutos até à primeira análise, os casos mais rápidos em menos de 4 minutos, e um exemplo resolvido em 3 minutos desde a recomendação até à verificação. Num caso, identificou 44 testes que uma alteração de feature flag tinha deixado de executar em silêncio.
A leitura honesta é simétrica. É uma resposta genuína à metade operacional do problema — e são também agentes destacados para absorver carga que os agentes criaram. Esse ciclo não é necessariamente mau; quase toda a automação é uma resposta a volume produzido por automação anterior. Mas vale a pena nomeá-lo, porque define o sentido da viagem: o custo do código agêntico paga-se cada vez mais em sistemas que vigiam os sistemas, e esses têm um custo de operação próprio.
Uma semana de trabalho, não um trimestre
Ordenado por custo de fazer face ao custo de ter saltado
"O Claude escreve 80% do nosso código" não é uma estatística transferível. Descreve um laboratório de fronteira com ferramentas invulgares, um repositório invulgar e um incentivo invulgar para demonstrar a afirmação. Veja-a como prova de que o tecto é alto, não como um objetivo relativamente ao qual a sua equipa está atrasada.
8x de código entregue não é 8x de valor entregue. A métrica é volume de código por trimestre. Nada no artigo afirma oito vezes mais resultados de produto, e o volume de código é uma medida que as ferramentas agênticas inflacionam quase por construção.
O calendário da Anthropic é o extremo agressivo da distribuição. Dois trimestres até 25x é o que acontece quando uma empresa é ao mesmo tempo o utilizador mais intensivo e o fornecedor. A sua curva será provavelmente mais plana. O que se transfere é a forma, não o declive.
Isto é um problema resolvido, e a solução é antiga. Workers sem estado sobre um diário partilhado não é arquitetura nova; é prática corrente de sistemas distribuídos que uma ferramenta interna de crescimento rápido saltou, como as ferramentas internas de crescimento rápido fazem. Não há aqui nenhuma técnica inédita para adquirir — apenas uma corrente para aplicar mais cedo do que parece necessário.
O artigo de CI da Anthropic é um bom documento precisamente por não ter glamour: um serviço interno ficou maior do que o seu desenho, três correções competentes compraram cada vez menos tempo, e uma reconstrução de três semanas resolveu-o em condições. Tudo isso já aconteceu em todas as empresas que alguma vez cresceram depressa.
O que o código agêntico mudou foi o relógio. Um sistema que historicamente teria levado três anos a ficar maior do que a sua arquitetura fá-lo agora em dois trimestres, e os sinais de aviso chegam pela mesma ordem de sempre — só que comprimidos ao ponto em que o instinto habitual, "remendo agora e resolvo em condições no próximo trimestre", fica sem trimestres seguintes.
Se está a entregar mais código do que há seis meses, a restrição já se deslocou para jusante de si. A única questão é se dá por isso através de um painel ou de uma fatura.
Fontes: Anthropic, "Agentic coding is straining CI. Here's how we scaled test impact analysis at Anthropic" de Sachin Malhotra, publicado a 14 de setembro de 2026 · Anthropic, "How Claude Tag serves as Anthropic's first responder for CI/CD failures" · Analytics India Magazine, "Anthropic's CI Jobs Grew 25x in 6 Months as Claude Wrote 80% of Code" · VentureBeat, "Anthropic says 80% of its new production code is now authored by Claude". Os números de 8x, 80%, 10x e 25x, as três durações das correções, a descrição do redesenho e a recomendação de desenhar para 10-20x são da Anthropic, tal como publicados no artigo de engenharia; os tempos do primeiro interveniente vêm do artigo complementar. A Anthropic não publicou os custos de CI — a secção sobre a fatura é uma inferência a partir das contagens de trabalhos, e está assinalada como tal. O enquadramento pela meia-vida dos patches, a leitura do estrangulamento como algo que se desloca em vez de se resolver, e todas as recomendações são meus. Para a estação anterior da mesma linha, veja contratar o revisor antes do programador.
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.