A integração contínua (CI) tornou-se um novo ponto de estrangulamento com a expansão do uso de agentes de programação. Essa conclusão baseia-se em experiências apresentadas por equipes de engenharia da Anthropic, da Linear e da Depot durante setembro, e não no anúncio de uma única ferramenta. O volume de jobs de CI na Anthropic aumentou 25 vezes em seis meses, enquanto seus engenheiros passaram a enviar, por trimestre, uma quantidade de código cerca de oito vezes maior do que enviavam entre 2021 e 2025. Na Linear, o volume do conjunto de testes aproximou-se de quatro vezes o nível registrado desde janeiro, enquanto os agentes passaram a escrever a maioria dos testes.
A Anthropic respondeu usando análise de impacto de testes para executar apenas os testes que provavelmente seriam afetados pela alteração, e a Linear redesenhou quase completamente seu pipeline. Essas medidas reduzem o tempo de espera, mas tratam apenas uma camada do problema: a velocidade de verificação do repositório.
Por que a velocidade do CI já não é suficiente?
Historicamente, o CI foi projetado segundo um padrão de trabalho humano: o desenvolvedor abre um número limitado de pull requests por semana e, em seguida, espera o resultado do pipeline enquanto passa para outra tarefa. Já o agente pode criar código, testes e pull requests em paralelo, elevando o número de operações de CI de forma multiplicada. O artigo afirma que a Blacksmith, uma empresa que vende executores de CI, observou um crescimento semanal entre 5% e 10% no número de jobs executados.
O segundo problema é o momento da verificação. O agente escreve a alteração e depois espera o resultado após criar o pull request. Quando o resultado chega 20 minutos depois, ele pode ter perdido o contexto da tarefa, enquanto cada problema implica um novo ciclo de espera.
O repositório não é o sistema
Em aplicações independentes, o teste do repositório pode oferecer uma imagem próxima do comportamento do sistema. Porém, em um ambiente cloud-native, o repositório representa um serviço dentro de um ecossistema que pode incluir dezenas de serviços, enquanto o restante do sistema costuma ser representado por interfaces simuladas ou dados de teste.
Por isso, uma alteração pode passar nos testes unitários, atravessar o CI e funcionar em um ambiente isolado, mas falhar na primeira solicitação real que atravesse as fronteiras entre serviços. Exemplos incluem alterar o nome de um campo do qual outro serviço depende, reduzir um timeout e provocar uma cadeia de novas tentativas, modificar um esquema e causar o bloqueio de uma tabela no ambiente de teste ou criar um endpoint que se comporta de maneira diferente quando é chamado pelo serviço consumidor real.
O artigo cita dados da DevOps Research and Assessment (DORA), que associam o aumento da adoção de inteligência artificial tanto a uma maior frequência de entrega de software quanto à instabilidade nas entregas. Em outras palavras, produzir código mais rapidamente não garante uma verificação melhor.
O que muda na prática?
A solução proposta não é eliminar o CI nem desacelerar os agentes, mas transferir parte da verificação para um momento mais cedo dentro do ciclo de trabalho do agente, de modo que a alteração seja testada contra o sistema real, e não apenas contra uma versão do repositório. Ferramentas como o Cursor usam ambientes de nuvem isolados; mais de 30% dos pull requests integrados pelo Cursor vêm de agentes que trabalham dessa maneira. Outras ferramentas, incluindo o GitHub Copilot cloud agent, o Codex, o Devin e o Greptile, também oferecem diferentes formas de executar código dentro de ambientes temporários.
Contudo, esses ambientes normalmente contêm o branch e suas configurações e aquilo que o script de inicialização pode instalar, mas não os outros serviços, a fila de mensagens real nem um banco de dados semelhante ao de produção. Por isso, o artigo considera que o ciclo é fechado, mas pode estar sendo fechado em torno da coisa errada.
Ambientes compartilhados e verificação controlada
O artigo propõe executar uma versão estável compartilhada dos serviços dentro de um cluster Kubernetes, criando ambientes de teste leves que implantem apenas o serviço alterado. As solicitações marcadas são direcionadas a esse serviço, enquanto os demais fluxos se conectam às versões estáveis compartilhadas. Assim, um grande número de agentes pode compartilhar o ambiente, em vez de copiar todo o sistema para cada agente; o artigo estima que o custo do ambiente pode se aproximar do custo de um único contêiner e que sua inicialização leva segundos, mas a fonte não apresenta medições independentes que comprovem essas estimativas em todos os ambientes.
O ambiente, por si só, não é suficiente. As equipes de plataforma precisam de procedimentos aprovados que definam quais solicitações serão enviadas, quais registros serão coletados e quais contratos deverão ser comprovados. Também é necessário registrar os serviços tocados pelo teste e seus resultados, para que o histórico possa ser lido por ferramentas de revisão e portas de integração. O autor enfatiza que a governança é necessária para impedir que os agentes executem ações inseguras dentro de um cluster compartilhado.
Do ponto de vista da certi.news, a verdadeira mudança não é simplesmente acelerar o CI, mas redefinir o que deve significar «sucesso» na verificação. O teste do repositório continua sendo importante, mas não é suficiente por si só para os sistemas distribuídos que os agentes produzem em velocidade maior. As questões de custo, isolamento, segurança dos dados e medição da precisão da verificação continuam em aberto, e o material apresenta uma tese analítica, não um padrão comprovado ou um produto específico.