Agentes em DevOps

Entre 2024 e 2026, “agente de IA em DevOps” deixou de ser slide de conferência e virou recurso embarcado nos produtos que as equipes já usam. A pergunta deixou de ser se LLMs entrariam no ciclo de vida do software (entraram) e passou a ser onde, com quanta autonomia, e com qual confiabilidade. Este conjunto de notas mapeia esse estado da arte em quatro frentes, e o mais interessante não está dentro de cada uma isoladamente, mas no padrão que se repete entre todas.

As quatro frentes são as seguintes. CI/CD e pipelines, onde os agentes geram e mantêm pipelines, consertam builds quebrados e reparam testes flaky. SRE e resposta a incidentes, onde fazem triagem de alertas, análise de causa-raiz e chegam a redigir o fix. Infraestrutura como código, onde geram, descobrem e reconciliam infraestrutura. E observabilidade e segurança, onde investigam logs e métricas e propõem correções de vulnerabilidade. Cada uma tem seu próprio documento; o que segue aqui é o fio que as costura.

O mesmo formato em toda parte: investigar é autônomo, agir é supervisionado

Olhando as quatro frentes lado a lado, salta aos olhos que elas convergiram para o mesmo desenho, e não por coordenação, mas porque o desenho responde à mesma assimetria de risco. Em todas, a parte de ler, correlacionar, diagnosticar e propor é autônoma; a parte de agir com efeito irreversível continua atrás de uma aprovação humana. O PagerDuty SRE Agent executa a remediação só após aprovação. O Pulumi Neo previa cada ação e mantém approval gates. As GitHub Agentic Workflows rodam read-only por padrão. A razão é sempre a mesma: gerar uma sugestão é barato e reversível, enquanto um terraform apply, um deploy ou um merge contra produção não é. A linha que separa o que já é produto do que ainda é promessa coincide quase perfeitamente com essa fronteira do irreversível.

Disso decorre o segundo padrão, que é a forma concreta que essa fronteira assume na prática: o pull request virou a eclusa universal entre o agente e a produção. Repare como a mesma solução reaparece em contextos que não conversam entre si. Em CI/CD, o Datadog gera a correção de teste flaky como um PR; a Harness abre um PR para o build quebrado. Em SRE, o incident.io tem um botão “Code it up” que redige o fix e abre um PR a partir do Slack. Em IaC, o agente de drift da Firefly entrega a remediação como PR. Em segurança, o Copilot Autofix propõe a correção como sugestão a revisar. O pull request é elegante para esse papel porque já era, antes da IA, o ponto onde uma mudança espera revisão humana antes de virar realidade. Os agentes simplesmente herdaram a eclusa que a engenharia de software já tinha construído.

Há ainda um terceiro fio, mais técnico, costurando as frentes por baixo: o MCP como tecido conectivo. É via MCP que o DevOps Agent da Harness lê o contexto do projeto, que o env0 leva o estado vivo da nuvem para dentro do IDE, e que a Trunk decidiu entregar contexto de flakiness a ferramentas externas em vez de construir o próprio agente. O padrão emergente não é cada produto embutindo seu LLM, e sim cada produto expondo seu estado e suas ações por um protocolo que qualquer agente possa consumir.

A distância entre a capacidade anunciada e a confiabilidade medida

Se há uma lição que atravessa as quatro pesquisas que sustentam estas notas, é uma de método, sobre como ler o que se afirma neste campo. Quase toda a evidência sobre os produtos vem de fontes primárias dos próprios fornecedores: páginas de marketing, blogs de lançamento, documentação. Essas fontes são autoridade legítima para uma afirmação (“a feature existe e funciona assim”) e autoridade nenhuma para outra (“a feature tem acurácia tal”). Nenhum fornecedor, em nenhuma das quatro frentes, publica métricas independentemente benchmarkadas de acurácia, taxa de falso-positivo ou modos de falha.

Os poucos números medidos de forma independente são justamente os que recomendam cautela. O FlakyGuard, da Uber, repara 47,6% dos testes flaky reprodutíveis, com pouco mais da metade das correções aceitas, e isso é o estado da arte acadêmico. A detecção de vulnerabilidades por LLM compra cobertura ao preço de taxas de falso-positivo que passam de 60%. Onde a indústria fala em autonomia, a medição independente fala em automação parcial. Não é que as ferramentas não funcionem; é que a distância entre “demonstra bem” e “é confiável em produção” raramente está quantificada, e quando está, é menor do que o marketing sugere.

Por isso a fronteira real, em todas as frentes, é a confiabilidade, não a capacidade. A capacidade de gerar um pipeline, diagnosticar um incidente, codificar uma infraestrutura ou propor uma correção de segurança já existe e é demonstrável. O que ainda não existe, ou não está medido, é a confiança que permitiria tirar o humano da eclusa. Em SRE, os próprios fornecedores hedgeiam com “pull request provável” e confidence scores. Em observabilidade, a Grafana e a New Relic escrevem, com todas as letras, que esperam que o modelo erre e que um humano deve verificar antes de agir. Em IaC, a AWS adverte que o código gerado precisa ser validado antes de produção. A leitura mais útil deste panorama, para quem decide o que adotar, é tratar a lista de capacidades como real e a promessa de autonomia plena como ainda não cumprida, reservando o ceticismo exatamente para os pontos onde a afirmação é mais conveniente ao vendedor: segurança, ausência de falsos positivos, e prontidão para agir sem supervisão.

Como ler estas notas

Cada documento das quatro frentes equilibra dois eixos: o que já é produto que você pode usar hoje, com nomes concretos, e o que ainda é promessa, com as lacunas nomeadas. Onde há um número medido por terceiros, ele aparece; onde só há alegação de fornecedor, isso é dito. As datas, versões e modelos citados são um retrato de meados de 2026, num campo que se move rápido o bastante para que valha reverificar antes de tomar qualquer decisão sobre o estado atual de um produto específico.

Palavras-chave

Conceitos: agentes de IA, DevOps, human-in-the-loop, pull request como eclusa, autonomia supervisionada, fronteira do irreversível, capacidade vs confiabilidade Frentes: CI/CD, SRE, IaC, observabilidade, segurança Protocolos: MCP Produtos: PagerDuty SRE Agent, Pulumi Neo, GitHub Agentic Workflows