Na maioria das equipes que adotam a programação com agentes de IA, o gargalo passa da geração para a revisão. Sem corrigir esse ciclo, o ganho líquido de velocidade fica próximo de zero.
Em ambientes de CI de grande escala — com milhões de testes noturnos e centenas de engenheiros —, a tarefa de maior valor para um agente é encaminhar problemas aos responsáveis e fazer a triagem, não gerar código.
Um resultado útil do agente resiste a análises rigorosas e explica a causalidade, em vez de apenas identificar padrões.
Projetar a camada de coleta de evidências e composição de contexto é mais importante do que projetar a camada de geração.
Grande parte das discussões sobre programação com agentes de IA ainda começa com uma promessa simples: escrever mais código, com mais rapidez.
Às vezes, isso se amplia para uma visão mais ambiciosa, na qual agentes planejam o trabalho, abrem PRs e entregam mudanças com o mínimo de intervenção humana. Mas, para a maioria das equipes de engenharia, o valor mais evidente no curto prazo é mais específico. Trata-se de reduzir o custo da iteração.
Entregar software não se resume a gerar código. Escrever código é apenas uma etapa de um ciclo mais longo, que inclui revisão, testes, implantação e investigação quando algo dá errado. A maioria das equipes que adota a programação com agentes de IA sem reformular o ciclo de revisão apenas transfere o gargalo para uma etapa posterior.
Acelerar apenas a geração não torna uma equipe automaticamente mais rápida. Isso pode apenas transferir mais esforço para revisão, verificação e construção de confiança.
Em muitos ambientes de engenharia, a parte mais dispendiosa não é produzir uma primeira versão, mas alcançar um nível suficiente de confiança.
A mudança realmente corrigiu o problema ou melhorou o sistema? Ela introduziu alguma regressão em outra parte? A falha está no código, no ambiente, nos testes ou em uma dependência? A correção proposta trata a causa ou apenas o sintoma visível?
Os agentes podem ajudar nesse ponto, não porque substituem engenheiros, mas porque conseguem fazer uma primeira análise estruturada de evidências desorganizadas: inspecionar logs, comparar mudanças recentes, resumir sinais relevantes, rastrear causas prováveis, executar verificações e apresentar algo que uma pessoa possa examinar.
Em muitas equipes, o uso de maior impacto para um agente não é gerar código do zero. É reduzir o espaço de busca em torno de um problema antes que uma pessoa passe horas fazendo isso manualmente.
Isso fica especialmente claro em fluxos de depuração de grande escala. Imagine uma CI noturna que execute milhões de testes em bases de código modificadas por centenas de engenheiros — uma realidade para um de nossos clientes. Quando algo falha, é difícil encaminhar o problema para os responsáveis. O problema pode estar no código da aplicação, em uma dependência, no harness de testes ou em algum outro ponto da pilha. Os logs podem chegar a gigabytes, e a primeira equipe a identificar o problema nem sempre é a responsável por ele.
Esse tipo de fluxo não pede naturalmente que um único agente escreva a correção. Ele é ideal para um sistema que reduza rapidamente o espaço do problema.
Um pipeline útil poderia buscar logs, selecionar as evidências relevantes, resumir o que importa, inspecionar o código em um sandbox e produzir uma análise estruturada da causa raiz, com pontuação de confiança, rastreabilidade e sugestões para as próximas etapas. Para gerar uma pontuação de confiança, um especialista no assunto avalia o resultado inicial do agente. Essa avaliação é então fornecida a um LLM usado como juiz para automatizar as pontuações futuras, mantendo o alinhamento com o julgamento humano.
O objetivo não é eliminar o julgamento da engenharia, mas oferecer aos revisores um ponto de partida mais sólido. Triagem de regressões, revisão de PRs, correção de testes, validação de versões e investigação pós-implantação seguem o mesmo padrão. São atividades repletas de evidências, revisões e ambiguidades. Elas não exigem que um agente substitua o processo de engenharia, apenas que ajude a fazê-lo avançar.
É também por isso que as equipes devem avaliar esses sistemas com cuidado.
A pergunta errada é se um agente consegue produzir algo impressionante de forma isolada. A pergunta mais adequada é se ele melhora um fluxo de trabalho real sem criar obstáculos em outro ponto.
Isso significa avaliar se o resultado é específico o bastante para ser verificado, se explica a causalidade em vez de apenas identificar padrões e se facilita a revisão em vez de dificultá-la. Uma resposta plausível não é necessariamente útil. Na prática, as equipes confiam no resultado de um agente quando ele resiste a análises rigorosas e oferece algo concreto para verificar.
A lição mais profunda é que sistemas úteis com agentes de IA dependem de mais do que geração. Eles dependem de como as evidências são coletadas, como o contexto é composto, como os resultados são verificados e como as incertezas são apresentadas ao revisor.
É por isso que dificilmente o futuro próximo da engenharia com agentes de IA será um único grande salto rumo à autonomia total. É mais provável que seja um conjunto de ciclos cuidadosamente projetados, nos quais agentes ajudem as equipes a inspecionar, revisar, verificar e refinar o trabalho, com menos esforço desperdiçado entre as etapas.
Isso pode ser menos impactante do que a narrativa mais ampla sobre autonomia, mas está muito mais próximo de como sistemas úteis são realmente adotados.