Vai al contenuto

AI Agent in DevOps

L'integrazione di AI agent nei workflow DevOps: un agent è un LLM a cui si dà accesso a tool (shell, Terraform, API) per eseguire comandi al posto dell'operatore, con MCP come protocollo per descrivere quei tool. L'Agentic Harness diventa parte della pipeline. 1

Chat contro agent

L'esempio di Nirmal Mehta (principal specialist solution architect in AWS, che parla a titolo personale) nel primo episodio del podcast Agentic DevOps di Bret Fisher: chiedendo a un chatbot un cluster EKS di produzione con Terraform, l'LLM scrive il codice e i comandi, ma è l'umano a copiarli, verificarli ed eseguirli. Con un agent si definisce invece un set di tool (per esempio "Terraform" o "shell") descritti in linguaggio naturale: l'LLM ragiona sull'obiettivo, sceglie il tool, genera codice e comando e chiede conferma prima di eseguire terraform apply. L'umano non esegue più i comandi, si fida entro certi limiti e fornisce i guardrail. Fisher lo definisce automazione che decide in tempo reale cosa automatizzare, invece di ripetere passi deterministici in un runner CI/CD. 1

Fisher e Mehta paragonano il momento ai primi giorni di Docker nel 2013: un cambio di piattaforma nel modo di lavorare, che non sostituisce infrastruttura o container. 1

Aree di applicazione

Testing

  • Agent che scrivono, mantengono e diagnosticano test → vedi Agentic Testing, Checking vs Testing 2
  • Rischio: l'agent decide come risolvere un fail senza supervisione umana 2
  • Beneficio: test che non verrebbero mai scritti a mano, ed exploratory testing che trova cosa manca alla suite 2

CI/CD e infrastruttura

  • Agent che generano IaC, individuano problemi di performance, fanno rollback dei deployment, capiscono cosa è andato storto e rideployano 3
  • KubeCon London (aprile 2025): secondo Bret Fisher quasi nessuno parlava ancora di AI agent per fare il lavoro di DevOps/platform engineering (un solo talk in tutta la settimana); il podcast Agentic DevOps nasce lì 1
  • Gli agent reintroducono non-determinismo in un mondo (container, cloud, API) costruito per eliminarlo; Mehta riconosce l'obiezione di chi ha già API deterministiche e non vede perché aggiungere uno strato che sembra un'API ma non lo è 1
  • Fisher ipotizza agent con personas diverse (builder, tester, validator) messi l'uno contro l'altro, che secondo lui funzionano meglio di un agent solo; parte del suo linguaggio viene dai talk di Solomon Hykes su Dagger 1
  • I carichi agentici cambiano anche la rete: MCP non si comporta come una normale connessione HTTP, e compaiono MCP gateway (Solo) e AI gateway (Istio) 1
  • Per la governance delle modifiche infrastrutturali generate da agent vedi Infrastructure Governance

Security

  • L'automazione non elimina il rischio, lo cambia e a volte lo aumenta: security e compliance restano competenze chiave 3
  • Rischio: agent che eseguono comandi sulla macchina → serve un set di tool con guardrail e solo i permessi che si vuole concedere 1
  • Nei SOC gli agent fanno triage e investigazione per difendersi da attaccanti che usano l'AI; gli agent stessi vanno scoperti, dotati di identità e permessi minimi e monitorati → vedi Agentic SOC 4

Monitoring

  • Monitoring e alerting di base, riavvio di servizi e cluster auto-healing sono tra i compiti più facili da automatizzare con AI 3

Impatto sui ruoli

Secondo Neil Davis (Digital Cloud Training), i ruoli più a rischio sono junior DevOps, manual QA, sysadmin di basso livello e operatori che monitorano e riavviano servizi; il DevOps engineer passa dal fare i task a supervisionare e migliorare l'automazione che li fa. Per Davis "DevOps non è morto" ma cambia in fretta, e l'asticella d'ingresso si alza perché i ruoli junior vengono sostituiti da pipeline di automazione. 3

Le competenze che Davis indica come durature: architettura cloud e design dell'infrastruttura, integrazione di agent AI nei workflow cloud, security e compliance, comunicazione e leadership, formazione continua. Docker, Kubernetes e Terraform restano da imparare perché sono la base su cui si costruirà l'automazione. 3

Bret Fisher riporta che diversi analisti incontrati a KubeCon si aspettano meno personale nell'infrastruttura grazie all'AI. La sua tesi: ogni grande cambio degli ultimi 30 anni ha portato riduzione dei costi, velocità o entrambe; se gli sviluppatori produrranno molto più codice con l'AI e l'ops non accelera con gli agent, ci sarà più "shadow ops". L'adozione però va "a velocità umana": un'organizzazione non adotta l'AI finché le persone non imparano a usarla. Mehta la tratta come un'ipotesi ancora da verificare. 1

Il pattern emergente

La pipeline tradizionale (design → build → check → test drive umano) sta cambiando: la parte centrale (pipeline + check) ha iniziato a mangiare la parte finale (test drive). Resta il design: decidere cosa il software dovrebbe fare. 2

"Deciding what the software is for isn't a job. Nobody's title says it. It's a duty." 2

Vedi anche: Agentic Testing, Checking vs Testing, Agentic SOC, Agentic Harness, ArgoCD

Fonti e Riferimenti

  1. Fonte: Is AI ready for DevOps? -- Agentic DevOps Podcast Ep. 1 (Bret Fisher) ↗ ↩↩↩↩↩↩↩↩↩

  2. Fonte: End-to-End Testing With AI Agents: What I Built, Broke, and Learned (DevOps & AI Toolkit) ↗ ↩↩↩↩↩

  3. Fonte: Is DevOps Dead? These Roles Will Be Obsolete in 2026 (Digital Cloud Training) ↗ ↩↩↩↩↩

  4. Fonte: You need to learn Splunk in 2026 (4 million open jobs) (David Bombal Emerging Technologies Podcast) ↗ ↩