- Pubblicato il
AI e DevOps: non delegare l'attrito che costruisce competenza
- Autori
- Nome
- Alessandro Iannacone
- Profilo X
La promessa degli strumenti AI per sviluppatori e molto seducente: meno attrito, meno tempo perso, meno fatica.
Prompti, l agente scrive, tu approvi, il codice arriva in produzione.
Il problema e che nello sviluppo software, soprattutto quando parliamo di DevOps, infrastruttura e sistemi in produzione, non tutto l attrito e spreco.
Una parte dell attrito e rumore. Una parte e allenamento. Una parte e il punto esatto in cui si forma il giudizio tecnico.
Bob Belderbos lo spiega bene nel suo articolo su come mantenere istinto da developer quando l AI scrive codice: non bisogna delegare tutta la fatica, perche proprio quella fatica costruisce debugging, senso critico e capacita di decidere.
E nel lavoro DevOps questa distinzione diventa ancora piu importante.
L AI va usata, ma non per spegnere il cervello tecnico
Non c e nulla di virtuoso nel riscrivere boilerplate a mano.
Non c e valore nel perdere mezz ora su una configurazione ripetitiva, una conversione di formato, una query banale o uno script di supporto che l AI puo generare in pochi secondi.
In questi casi l AI e un ottimo acceleratore:
- scaffolding di pipeline
- script Bash o Python ripetitivi
- template Terraform/OpenTofu
- query SQL di servizio
- test di base
- documentazione tecnica iniziale
Questo attrito va eliminato o almeno ridotto.
Ma il punto critico arriva subito dopo: chi decide se quell output e corretto per il sistema reale?
L AI puo generare una pipeline. Non puo conoscere davvero il tuo rischio operativo.
Puo suggerire una configurazione Kubernetes. Non puo assumersi la responsabilita di un rollback fallito.
Puo scrivere uno script di deploy. Non puo sapere se quel deploy e sicuro dentro il tuo contesto di rete, backup, compliance e osservabilita.
I tre tipi di attrito tecnico
Nel lavoro quotidiano conviene distinguere tre categorie.
1. Attrito da eliminare
Questo e il lavoro meccanico che non costruisce grande competenza:
- CRUD standard
- boilerplate
- lookup di dipendenze
- conversioni di formato
- configurazioni ripetitive
- esempi iniziali di test
Qui usare AI ha senso. Anzi, spesso e irresponsabile non usarla se permette di risparmiare tempo e ridurre lavoro manuale inutile.
La condizione e semplice: review e test devono restare umani.
2. Attrito da mantenere
Questo e l attrito che forma il mestiere:
- leggere una diff con attenzione
- capire perche un bug succede davvero
- scegliere tra due architetture possibili
- valutare failure mode e rollback
- decidere dove mettere osservabilita
- ragionare su idempotenza, retry e consistenza
Se deleghi sempre questa parte, produci piu codice ma possiedi meno competenza.
E in DevOps questo e pericoloso, perche l errore non resta dentro una funzione: puo diventare downtime, perdita di dati, esposizione di credenziali o costo cloud fuori controllo.
3. Attrito da cercare volontariamente
Ogni tanto bisogna tornare sotto il livello dell astrazione.
Leggere il sorgente di una libreria. Scrivere a mano uno script critico. Capire davvero cosa fa un comando prima di metterlo in una pipeline. Studiare il comportamento di un sistema sotto carico invece di fidarsi del suggerimento dell agente.
Questo non rallenta la carriera. La rende piu solida.
Il rischio DevOps: automazione senza comprensione
Nel mondo DevOps il problema non e solo "l AI scrive codice sbagliato".
Il rischio piu sottile e un altro: l AI produce automazione plausibile che nessuno capisce davvero.
Esempi concreti:
- una pipeline CI/CD che passa, ma non gestisce rollback e migrazioni fallite
- un playbook Ansible che funziona in staging, ma non e idempotente in produzione
- una policy firewall generata bene in apparenza, ma troppo permissiva
- uno script di backup che copia dati, ma non verifica restore e consistenza
- una configurazione Proxmox o CloudStack che risolve il problema locale, ma crea fragilita operativa
Questi errori non sempre esplodono subito.
Spesso restano dormienti fino al primo incidente vero.
Ed e li che si vede se il team ha usato l AI come acceleratore o come stampella.
Una routine pratica per usare AI senza perdere muscolo tecnico
Il modo sano di usare agenti AI non e "meno AI".
E AI con piu disciplina ingegneristica.
Una routine semplice:
Prima di promptare, fatti un aspettativa. Scrivi mentalmente quale soluzione ti aspetti, quali file dovrebbero cambiare e quali rischi vuoi evitare.
Leggi la diff come se l avesse scritta un junior. Non approvare perche il codice sembra elegante. Cerca ipotesi nascoste, edge case, permessi troppo larghi, mancanza di test.
Chiedi all AI di criticare la propria soluzione. Domande utili: quali sono i failure mode? cosa succede se una dipendenza rallenta? quali alternative abbiamo scartato?
Usa i test come contratto. Anche quando non fai TDD puro, definisci cosa vuol dire "corretto" prima di fidarti dell output.
Tieni una quota di lavoro manuale. Una o due ore a settimana senza agenti: documentazione, codice, debug, lettura sorgente. Serve a mantenere l istinto.
Questa routine non e romanticismo da sviluppatore nostalgico. E gestione del rischio.
Il punto sui junior
Chi inizia oggi ha un vantaggio enorme: puo costruire cose funzionanti molto prima rispetto al passato.
Ma ha anche un rischio nuovo: saltare la parte scomoda che forma giudizio.
Debuggare un errore banale per due ore non e piacevole. Leggere una diff noiosa non e entusiasmante. Rifare a mano una configurazione non scala.
Pero queste esperienze costruiscono memoria tecnica.
Ti insegnano a riconoscere odori strani nel codice, output troppo perfetti, comandi pericolosi, astrazioni fragili.
Se l AI rimuove sempre quel passaggio, il junior spedisce prima ma capisce meno.
E un team che capisce meno diventa dipendente dallo strumento proprio quando dovrebbe governarlo.
La regola che uso in consulenza
Quando lavoro su automazione, infrastruttura, pipeline, PHP, Rust, Proxmox o ambienti cloud, l AI puo aiutare moltissimo.
La uso per:
- generare prime versioni di script
- confrontare alternative
- scrivere test iniziali
- documentare procedure
- trovare punti deboli in una soluzione
Ma tengo manuali alcune zone:
- comprensione del flusso end-to-end
- review delle diff
- verifica degli edge case
- scelta dei compromessi architetturali
- validazione di backup, restore, rollback e monitoraggio
Perche in produzione non basta che una soluzione "funzioni".
Deve essere spiegabile, osservabile, reversibile e sostenibile.
Conclusione
L AI deve essere un secondo ingegnere nella stanza, non il sostituto del tuo ragionamento.
Usala per accelerare. Usala per confrontarti. Usala per ridurre attrito inutile.
Ma non delegare sempre la parte difficile.
Perche quella parte difficile e spesso cio che ti permette di capire un incidente prima che diventi grave, leggere una configurazione prima che esponga un servizio, o fermare una pipeline prima che rompa la produzione.
Nel DevOps moderno la competenza non sta nel fare tutto a mano. Sta nel sapere quale attrito eliminare e quale mantenere.
Fonte
Se vuoi introdurre AI, automazione o agenti nel tuo flusso DevOps senza perdere controllo tecnico sulla produzione:
#aiengineering #devops #sre #softwarearchitecture #engineeringleadership