CI/CD

O pipeline de CI/CD foi um dos primeiros lugares onde os agentes de IA entraram, e não por acaso: é um ambiente cercado de texto estruturado (logs de build, arquivos YAML de pipeline, diffs de código) e com um sinal de sucesso ou fracasso claro a cada execução. Entre 2024 e 2026 o uso saiu da geração do trecho de YAML que você ia escrever de qualquer jeito e avançou para diagnosticar builds quebrados, consertar testes flaky e, no limite, verificar deploys e disparar rollback.

A mesma assimetria que organiza IaC organiza aqui. Gerar um pipeline ou sugerir uma correção é barato e reversível; deixar um agente aprovar um deploy ou reverter produção sozinho não é. É por isso que quase tudo que já é produto se acomoda do lado seguro dessa linha, e quase tudo que ainda é promessa mora do outro.

Gerar e manter o pipeline

A suíte mais ampla entre os fornecedores avaliados é a da Harness. O DevOps Agent gera e edita pipelines multi-módulo (CI, CD, gestão de IaC, plataforma interna, segurança da cadeia de suprimentos) a partir do contexto do projeto, que ele acessa via MCP, e monta stages de deploy já com estratégia de rollout, aprovações e targeting de ambiente, além de operar sync de GitOps por comando em linguagem natural. O Architect Mode complementa isso com a criação conversacional de pipeline, conduzindo o usuário como faria um engenheiro de DevOps experiente e incorporando práticas de segurança e compliance no desenho.

Do lado do GitLab, a Duo Agent Platform (em disponibilidade geral a partir do GitLab 18.8, com a plataforma GA em janeiro de 2026) traz dois fluxos que valem nota pela especificidade. O “Fix CI/CD Pipeline” diagnostica a causa raiz de um pipeline quebrado lendo logs, mensagens de erro, exit codes, as mudanças do merge request e o conteúdo do repositório, e entrega a correção como um novo merge request. O “Convert to GitLab CI/CD” migra automaticamente uma configuração de pipeline (hoje escopado a Jenkins) para o formato YAML do GitLab, também via MR. Os limites desses fluxos são informativos sobre o estado real da tecnologia: a conversão é específica de Jenkins e semi-autônoma, exigindo revisão humana, e o gateway de IA só processa os últimos 150 KiB de log, um lembrete concreto de que a janela de contexto ainda é um recurso escasso quando o build despeja megabytes de saída.

Consertar o que quebrou

A automação da correção de builds é onde a distância entre a demonstração e a confiabilidade fica mais visível, e o melhor lugar para medir essa distância são os testes flaky, aqueles que falham de forma intermitente sem que o código tenha mudado.

A abordagem mais difundida hoje nem é agêntica. A Trunk.io detecta e coloca testes flaky em quarentena automaticamente, sobrescrevendo seus exit codes para que continuem rodando sem quebrar a branch principal, sem tocar no código do teste. É um paliativo deliberado: a quarentena mantém o CI verde enquanto a correção de causa raiz (dados de teste estáveis, tratamento de assincronia, ambientes isolados) continua sendo trabalho manual de engenharia. O detalhe revelador é que a própria Trunk abandonou seu agente standalone de auto-fix, resumindo a lição em uma frase que diz muito sobre o momento: “não construa agentes, construa enriquecimento de contexto”. O conserto real passou a ser feito por ferramentas externas dirigidas pelo desenvolvedor, com a Trunk apenas fornecendo o contexto via MCP.

O Datadog vai um passo além com o Bits AI Dev Agent (em preview para otimização de testes), que gera autonomamente uma correção empacotada como pull request e a valida antes do merge, re-executando a lógica de CI existente contra o histórico de flakiness do teste, sem nunca fazer auto-merge. A Harness, com o Autonomous Code Maintenance, faz algo parecido para builds quebrados: disparado por um PR, analisa a falha, gera uma correção candidata e abre um novo branch com ela, além de limpar feature flags obsoletas e melhorar cobertura de testes.

O número mais honesto deste documento inteiro vem daqui, e vem da pesquisa, não do marketing. O FlakyGuard, da Uber, publicado na ASE 2025, repara 47,6% dos testes flaky reprodutíveis de repositórios industriais reais, com 51,8% das correções aceitas pelos desenvolvedores, superando as abordagens anteriores baseadas em LLM em pelo menos 22% na taxa de sucesso. Repare no que esses números dizem: mesmo o estado da arte acadêmico deixa mais da metade dos casos sem reparo ou com a correção rejeitada. Essa é a régua realista contra a qual ler qualquer alegação de fornecedor que não venha acompanhada de uma métrica medida.

Release notes, governança e o pull request como eclusa

Para release notes, o GitHub mantém o github/copilot-release-notes (Action verificada, v1.0.1 de abril de 2026), que gera as notas a partir dos PRs mesclados entre dois refs de git usando o Copilot CLI como backend. Mais interessante que a geração em si é o modelo de segurança das GitHub Agentic Workflows que a cercam: os workflows rodam com permissões read-only por padrão, qualquer escrita exige aprovação através de “safe outputs” pré-aprovados, e pull requests não são mesclados automaticamente sem revisão humana. Vale a precisão: esse “nunca sem revisão” é o default, não um limite técnico absoluto, já que existe um safe output experimental que pode mesclar um PR quando as políticas configuradas (status checks, decisão de review, labels) passam.

Esse desenho expõe o padrão que se repete em toda a indústria de agentes de DevOps: o pull request virou a eclusa entre o agente e a produção. O agente investiga, raciocina e escreve a mudança autonomamente, mas deposita o resultado em um PR que um humano (ou uma política explícita) precisa abrir. É a forma de capturar quase todo o valor da autonomia sem ceder a parte irreversível da decisão.

Verificar o deploy e o que ainda trava a autonomia

O ponto mais ambicioso da oferta comercial é a verificação de deploy com rollback dirigido por IA. A Harness comercializa um agente que se conecta às plataformas de observabilidade (Datadog, Prometheus, Splunk), descobre as métricas e queries de log relevantes para o serviço, monta um perfil de saúde e dispara rollback automático para a última versão boa conhecida ao detectar uma regressão. Convém ler isso com a ressalva que a própria verificação adversarial desta pesquisa registrou: a capacidade existe e é vendida como autônoma, mas não há taxas de falso-positivo nem métricas de acurácia publicadas, então o que se sustenta é que ela é oferecida, não que opera de forma confiável.

E é exatamente aí que mora a fronteira do Eixo B. O deploy verdadeiramente autônomo, sem o humano na eclusa, continua sendo promessa. Há um dado de transparência que ilustra bem o risco de acreditar nos números de marketing: a alegação de que o Copilot Autofix remedia mais de dois terços dos alertas de segurança com pouca ou nenhuma edição não sobreviveu à verificação independente, então a magnitude real dessa automação não está estabelecida. Some-se a isso duas lacunas que nenhuma fonte verificada resolve. A primeira é segurança: o modelo de read-only por padrão mais safe outputs é o padrão emergente, mas falta avaliação adversarial pública de injeção de prompt e exfiltração de credenciais em workflows de CI/CD agênticos, e um agente com acesso a pipeline é um agente com acesso a segredos. A segunda é custo: ninguém endereça a economia de rodar esses agentes em escala de CI, onde um pipeline dispara milhares de vezes ao dia e cada disparo agêntico consome tokens, deixando em aberto onde fica o ponto de equilíbrio contra a automação determinística tradicional.

Fontes

Palavras-chave

Conceitos: CI/CD, pipelines, testes flaky, quarentena, build quebrado, verificação de deploy, rollback, release notes, pull request como eclusa, read-only por padrão, safe outputs Produtos: Harness DevOps Agent, GitLab Duo, Datadog Bits AI, Trunk.io, GitHub Copilot, Copilot Autofix Pesquisa: FlakyGuard, Uber, ASE 2025 Protocolos: MCP