O Mito do Pipeline 'Self-Healing' Sem Humanos: Leitura Crítica desde DevOps

Cada doze meses volta o mesmo paper. Desta vez é AI-Driven DevOps for Intelligent Automation in Continuous Software Delivery Pipelines (Kiran Raj K M et al., ICECMSN 2025), publicado no IEEE em fevereiro de 2026. A tese é a mesma que líamos em 2019, só atualizada com LLMs e reinforcement learning na nomenclatura:

"...emerging technologies such as generative AI enable fully automated pipeline capable of code generation, error detection, deployment, and performance monitoring with minimal human intervention. ... a future where software systems evolve into self managing, self improving ecosystems driven by continuous learning and intelligent automation."

É uma visão, não um paper empírico. E como toda visão, é útil lê-la pelo que assume mais do que pelo que conclui. Vou fazê-lo desde onde me toca: levo anos a fazer DevOps em produção numa empresa com operações complexas e a escala suficiente para saber onde a IA encaixa no pipeline e, sobretudo, onde não encaixou ainda apesar de seis anos de promessas muito semelhantes.

A palavra que faz todo o trabalho retórico: "minimal"

"Minimal human intervention" é a frase que carrega toda a promessa do paper e da categoria inteira. Se a leres como CTO, a pergunta operativa é: minimal respeito de quê? Comparado com um pipeline manual de 2012, qualquer pipeline moderno com GitHub Actions, Argo CD, Terraform e um test runner já é "minimal human intervention" — o humano só toca o sistema para os cambios de intencionalidade (o que construímos, que política, como priorizamos) e para os incidentes.

Por isso a pergunta não é se reduzes a intervenção humana — o pipeline moderno já a reduziu. A pergunta é se reduzes o ownership humano sobre o sistema. E a resposta empírica, que os papers de visão sistematicamente evitam, é: não.

Onde a IA sim empurrou o pipeline

Sê justo com o paper. Há áreas onde a adição de IA ao CI/CD deu resultados reais e mensuráveis em 2024–2026. Estas implemento e recomendo:

Geração e revisão de código nos PRs. Copilot/Claude/Cursor aportam produtividade ao autor do PR e leveza ao revisor em comentários triviais (estilo, naming, caso óbvio de null). O paper tem razão nesta camada.

Deteção de anomalias em métricas e logs. Os modelos de séries temporais e clustering baseado em embeddings são claramente melhores do que os thresholds estáticos que dominavam o AIOps de 2018. A deteção de anomalias é a faixa do pipeline onde AIOps brilha mais — bem estruturada, baixo blast radius, fácil de validar.

Triagem inicial de alertas. Aqui a IA pode fazer uma primeira classificação, agrupar alertas correlacionados, e baixar o ruído que chega ao engenheiro de on-call. É uma camada estruturalmente defensiva — se se equivoca, o alerta ainda passa.

Geração de runbooks e documentação pós-incidente. Converter post-mortems narrados em documentação estruturada é um caso de uso quase ideal: humano no loop ao final, baixo custo de erro.

Otimização de configuração. Tuning de parâmetros de scheduler, autoscaling, tamanho de pools — pequenos espaços de busca onde RL faz sentido e o erro é reversível.

Tudo isto é real e compatível com a minha tese. A IA aumenta o pipeline. Nenhuma destas coisas elimina engenheiros. Todas aumentam a alavanca do engenheiro.

Onde a promessa do paper romperia contra a realidade operacional

Há quatro afirmações do paper que é preciso olhar de frente, não porque sejam tecnicamente impossíveis, mas porque operacionalmente são ingénuas.

1. "Code generation com mínima intervenção humana"

O primeiro meio minuto de um PR gerado por IA pode estar bem. O que a IA não resolve — porque estruturalmente não tem o contexto — é a parte que ocupa 80% do tempo real de uma mudança séria: entender por que o sistema é como é, que invariantes não escritas dependem desta função, que equipa será afetada upstream, o que acontece se isto se desplega numa sexta às 17:00. A geração de código é a parte fácil. O contexto e a negociação são a parte difícil, e não se resolveram.

A evidência empírica que tenho, e que qualquer head de engenharia que esteja a medir pode validar: a curva de tempo total entre PR aberto e PR mergeado não se está a dobrar tão rápido como a curva de tempo entre tarefa recebida e PR aberto. Quer dizer que a IA acelerou uma parte do ciclo, não o ciclo. A parte lenta deslocou-se de "escrever" para "rever e acomodar a produção".

2. "Error detection com mínima intervenção humana"

O AIOps é bom a detetar anomalias. É notoriamente fraco a decidir o que fazer com elas. A distinção é exatamente a que vemos no paper de ActionNex que lia em paralelo a este: precision de 71%, recall de 53% sobre a mesma decisão que o paper IEEE descreve como "minimal intervention". O sistema vê que algo vai mal; metade das vezes, não propõe a ação correta. Essa é a fronteira. A IA já é bastante melhor do que um humano a detetar — e pior do que um humano a decidir, especialmente sobre situações novas.

3. "Deployment com mínima intervenção humana"

Aqui é onde a promessa se rompe mais facilmente. Os deploys complexos não falham porque alguém não clicou o botão certo. Falham porque:

• Uma migração de schema é incompatível com o rolling deploy.
• Uma feature flag está num estado inconsistente entre regiões.
• Uma dependência externa tem rate limiting que só se manifesta em produção.
• Uma mudança de configuração interage de forma não documentada com um job de cron de há cinco anos.

Todos estes casos requerem judgment sobre o sistema, não execução do runbook. A IA pode acelerar o runbook quando o runbook é correto. Não deteta quando o runbook é incorreto para esta combinação concreta. O engenheiro sim, porque conhece a história do sistema. E a história do sistema não está treinada no modelo.

4. "Self-improving ecosystems"

Esta é a parte da visão que requer mais atenção crítica. "Self-improving" em sentido estrito só funciona quando tens um sinal de reward bem definido, decisão fixa, e um loop de melhoria rápido. O CI/CD não é isso. A "qualidade" de um pipeline não é uma métrica univariada — é um trade-off entre velocidade, fiabilidade, custo, satisfação dos programadores, conformidade, blast radius dos deploys, etc. Estes trade-offs são decididos pela direção de engenharia, não se descobrem autonomamente.

Um sistema que "se auto-melhora" sobre uma função de reward que não representa corretamente estes trade-offs não é um sistema que melhora. É um sistema que otimiza um proxy até que o proxy se rompe. Vi suficientes projetos de auto-tuning para saber que a parte difícil nunca é o algoritmo; é sempre definir a função objetivo de modo que não colapse num local optimum desagradável.

O custo oculto de apostar pelo "self-managing"

Há um custo de carreira que os CTOs jovens às vezes não veem e que os seus diretores financeiros sim veem dezoito meses depois. Se a tua liderança operacional é "automatizemos e o sistema decidirá", ao cabo de dezoito meses não tens ninguém na organização que entenda por que o sistema decide o que decide.

Todos os que geriram uma equipa de operações sabem esta dinâmica: quando uma camada se automatiza, o expertise sobre essa camada erode-se. Se o sistema funciona, ninguém o precisa. Quando o sistema deixa de funcionar — e acontecerá —, não tens ninguém que saiba repará-lo desde primeiros princípios. A dependência do fornecedor de IA torna-se um risco estrutural.

Esta é uma conversa diferente de "a IA substituirá os engenheiros". A pergunta é: que perfil de engenheiro precisas manter para usar bem a IA? E a resposta não é menos senior; muitas vezes é mais senior. Os juniores podem delegar trabalho à IA e obter output decente. Os seniores são os que podem detetar quando o output decente é estruturalmente incorreto. Esse discernimento é exatamente o que o "self-managing" assume como resolvido — e não está.

O que recomendaria a um CTO que lê o paper

Três tomadas práticas que faria com a equipa executiva:

Primeiro: separa o discurso do produto. Os teus fornecedores de ferramentas de pipeline vão vender-te "self-managing" como feature. Lê-o como "augmentação com interface mais limpa". Não atribuas orçamento baseado na promessa; atribui orçamento baseado na augmentação concreta que mides (tempo de PR, MTTR, custo por deploy, satisfação do developer). Se a métrica não se move, a promessa não se está a cumprir.

Segundo: mantém o ownership do sistema em humanos, sempre. O agente IA pode sugerir, executar ações reversíveis, gerar drafts. A decisão sobre mudanças com blast radius grande (deploys de major version, migrações, mudanças de autenticação, políticas de segurança) requer aprovação humana por defeito. Essa política escreve-se, não se assume.

Terceiro: investe em seniority, não em headcount. A alavanca da IA é assimétrica — um engenheiro senior com IA produz significativamente mais do que um junior com IA. Se tens de escolher entre uma equipa de 12 com seniority mista e uma equipa de 8 com seniority alta mais uma boa pilha de ferramentas IA, a segunda será mais fiável para sistemas com consequência real. A IA aplaina a parte baixa da curva; não aplaina a parte alta.

A linha que defendo

A IA é implementável em todo o pipeline. Implementei-a e implementarei mais. Não é substitutiva dos engenheiros, porque a parte do pipeline que importa mais — o judgment sobre mudanças com blast radius grande, o ownership dos incidentes, a negociação entre velocidade e risco — não é a parte que os modelos atuais sabem fazer. E não parece que o saibam fazer cedo, porque o gargalo não é o tamanho do modelo; é a representação do contexto operacional.

Os papers de visão como o do IEEE servem uma função: dão-nos um norte aspiracional e fazem-nos articular por que a nossa realidade empírica ainda não está lá. Mas se o teu plano operativo de 2026 se baseia em retirar engenheiros porque o "pipeline será self-managing", a leitura crítica do mesmo paper e do da Microsoft sobre ActionNex deveriam fazer-te recalibrar. Há um futuro de augmentação muito forte. Não há ainda um futuro de autonomia, e pretender o contrário é orçamental, não técnico.

O engenheiro continua a ser a peça que não se pode entregar a um fornecedor.

---

Fontes:

• Kiran Raj K M, Karthik K Poojary, Abhay, Aishwarya R S, Lathesh Kumar S R. AI-Driven DevOps for Intelligent Automation in Continuous Software Delivery Pipelines. ICECMSN 2025, IEEE Xplore (fevereiro 2026). DOI:10.1109/ICECMSN68058.2025.11382867
• Lin, Z., Hu, H., Hao, M., et al. ActionNex: A Virtual Outage Manager for Cloud Computing. arXiv:2604.03512 (2026). arxiv.org/abs/2604.03512

Tens um pipeline CI/CD que queres alavancar com IA sem perder o expertise senior que o mantém fiável? Fala com um CTO sobre desplegar um squad nearshore com a combinação adequada de seniority e tooling moderno.