L’automazione non ci ruba il lavoro: ci cambia mestiere

(…e spesso non ce ne accorgiamo)

L’automazione è diventata cultura, non solo un insieme di tool

Negli ultimi anni mi sono accorto di una cosa semplice ma poco detta:
non “usiamo” più l’automazione, viviamo dentro l’automazione.

Un tempo introdurre un nuovo script, un job schedulato o una pipeline era “fare automazione”.
Oggi, senza CI/CD, senza infrastruttura as-code, senza un minimo di osservabilità, un team non parte nemmeno dai blocchi di partenza.

L’automazione è diventata:

• un patto implicito tra dev, ops, security, prodotto;
• una forma mentis: ogni processo ripetitivo è sospetto, quindi candidabile ad essere automatizzato;
• un vincolo di qualità: se qualcosa non è automatizzabile, iniziamo a chiederci se è progettato male.

Non è solo tecnologia: è cultura organizzativa.

E quando qualcosa diventa cultura, cambia i ruoli molto più profondamente di quanto faccia una “semplice” nuova tecnologia.

Alcuni esempi concreti: CI/CD, AI copilots, monitoring predittivo

Per capire come sta cambiando il nostro mestiere, basta guardare tre aree dove l’automazione è ormai lo “sfondo” delle nostre giornate.

CI/CD: dalla pipeline come oggetto alla pipeline come ambiente

All’inizio CI/CD era il “server di build” in un angolo, gestito da due persone “smanettoni”.
Oggi, in un team sano, la pipeline è parte dell’architettura del sistema:

• governa i rilasci;
• definisce i confini tra team;
• incapsula le policy di qualità, sicurezza, conformità.

Questo cambia radicalmente il lavoro:

• per i dev, il “Done” non è più “compila e passa i test locali”, ma “passa tutta la catena automatizzata fino alla produzione (o quasi)”;
• per chi fa DevOps/SRE, il lavoro si sposta dall’“aggiustare le build rotte” al progettare sistemi di delivery robusti, autoesplicativi, con feedback chiari;
• per il CTO/tech lead, la pipeline diventa uno strumento di governance: ciò che non entra nel flusso CI/CD, sostanzialmente, non esiste nel sistema.

La produzione (build, deploy, test di regressione) è sempre più automatizzata.
Il valore umano si sposta sul design del flusso, non sull’esecuzione del passo.

AI copilots: dal “ti scrivo il codice” al “ti organizzo il ragionamento”

Molti vedono i copiloti AI come strumenti “per scrivere più codice più in fretta”.
In realtà stanno facendo una cosa più profonda: stanno comprimendo la parte meccanica del lavoro cognitivo.

• Refactoring ripetitivo? Lo fa l’AI.
• Boilerplate di integrazione? Lo fa l’AI.
• Query SQL standard su pattern ripetuti? Lo fa l’AI.

Questo non vuol dire che il dev “sparisce”, ma che:

• il valore si sposta sulla comprensione del dominio;
• sull’abilità di scomporre problemi complessi in passi chiari da dare all’AI;
• sulla validazione critica di ciò che l’AI produce.

Chi si limitava ad “eseguire specifiche” rischia di trovarsi spiazzato.
Chi invece sa ragionare in termini di architettura, trade-off, impatto sul business, trova nell’AI un amplificatore potentissimo.

Monitoring predittivo: dal “guardare le metriche” al “disegnare le soglie di allarme”

Osservabilità e monitoring stanno vivendo la stessa transizione.

Non ci limitiamo più a:

• guardare dashboard,
• mettere alert su CPU, RAM e error rate.

Stiamo andando verso:

• sistemi che prevedono derive anomale;
• alerting basato su pattern di comportamento più che su singole metriche;
• correlazione automatica tra eventi infrastrutturali, applicativi e di business.

Qui il lavoro umano si sposta da:

“Chi è di turno guarda le metriche e reagisce”

a

“Progettiamo un sistema di osservabilità che ci racconti cosa succede prima che faccia male”.

Di nuovo: meno lavoro “di produzione”, più lavoro di orchestrazione della complessità.

Cosa cambia davvero per CTO e tech lead

Se l’automazione sposta il valore umano dall’esecuzione alla progettazione della complessità, i ruoli di CTO e tech lead cambiano in modo profondo.

Dal “decidere le tecnologie” al “disegnare il sistema socio-tecnico”

Fare il CTO oggi non è (solo) scegliere se usare Kubernetes o ECS, se adottare questo framework o quell’altro.

È soprattutto:

• decidere come i team interagiscono con gli strumenti di automazione;
• definire chi possiede cosa: chi è owner della pipeline, chi del monitoring, chi delle policy di sicurezza;
• progettare interfacce tra team (API, contratti, accordi su SLO, flussi di handover).

In altre parole: il CTO non governa più solo il sistema tecnico, ma il sistema socio-tecnico.

L’automazione rende il sistema più potente, ma anche più sensibile:
se sbagli i confini di responsabilità, un singolo script può bloccare mezzo business.

Tech lead: da “senior che aiuta a smanettare” a “curatore del flusso”

Il tech lead non è più solo quello che “sa dove mettere le mani quando tutto va a fuoco”.

Il suo valore sta nel:

• curare la qualità del flusso: come una feature passa da idea a produzione;
• promuovere pratiche sane: testing, code review, feature flags, release progressive;
• aiutare il team a usare bene automazione e AI, non a bypassarle.

In pratica, il tech lead diventa una sorta di direttore d’orchestra:

• non suona ogni strumento,
• ma si assicura che la partitura (processo) sia chiara,
• che gli strumenti (tool) siano accordati,
• e che ogni musicista (dev, ops, QA, data…) sappia quando entrare e uscire.

Come mantenere senso e motivazione nel team in questo contesto

Qui arriva il punto delicato:
se togli al team gran parte del lavoro “di produzione” (scrivere codice, lanciare release, monitorare manualmente), come eviti che le persone si sentano inutili?

Alcune idee che sto vedendo funzionare:

Rendere visibile l’impatto, non la fatica

Molte metriche interne misurano ancora la quantità di output (storie chiuse, righe di codice, ticket risolti).

In un contesto automatizzato ha molto più senso misurare:

• riduzione del lead time (da idea a produzione);
• aumento della stabilità (meno incident, MTTR più basso);
• miglioramento di SLO che contano per il business (tasso di errore per transazione critica, tempo medio risposta API core, ecc.).

Quando colleghi il lavoro delle persone a questi numeri, non al “numero di cose fatte a mano”,
diventa più facile far percepire che disegnare una pipeline buona vale più che “fare dieci deploy manuali”.

Premiare chi semplifica, non chi complica

In molte culture tecniche (specie quelle con una forte storia “artigianale”) c’è quasi un orgoglio nel mantenere sistemi complessi, difficili, pieni di trucchi.

L’automazione ha bisogno dell’opposto:

• processi semplici da capire,
• path di deploy lineari e standardizzati,
• policy chiare e codificate.

Se vuoi che il team abbracci davvero automazione e AI, devi iniziare a riconoscere valore a chi:

• toglie complessità inutile;
• riduce i passaggi manuali;
• rende il sistema più “noioso” (in senso buono).

La motivazione nasce anche dal messaggio implicito:

“Il tuo valore non è nel tenere in piedi il caos, ma nel far sì che il caos non serva.”

Coltivare le competenze meta: dominio, comunicazione, decision making

Se script e AI riducono il lavoro di routine, diventa centrale tutto ciò che automatizzare è molto difficile:

• capire il dominio meglio del cliente stesso;
• comunicare trade-off tecnici in modo comprensibile al business;
• prendere decisioni in condizioni di incertezza;
• saper dire “no” a richieste che rovinerebbero architettura e processi.

Un team motivato in un contesto altamente automatizzato è un team che sa che:

• non è pagato per “scrivere codice a n ore al giorno”,
• ma per prendere decisioni tecniche che tengono in piedi il business nel tempo.

Conclusione: verso un nuovo artigianato digitale

L’idea che mi porto a casa è questa:

L’automazione non elimina il valore umano, lo sposta dalla produzione all’orchestrazione della complessità.

Siamo meno “operai del codice” e più artigiani del sistema:

• disegniamo flussi di delivery;
• codifichiamo regole in pipeline, policy-as-code, infrastructure-as-code;
• usiamo AI e automazione come levette di leverage, non come parcheggio cerebrale.

È un nuovo artigianato digitale perché:

• richiede ancora gusto, esperienza, sensibilità;
• non è riducibile a check-list;
• vive al confine tra tecnica, organizzazione e business.

Chi si ostina a misurare il proprio valore sul “quanto” produce (righe di codice, ticket, patch manuali) si sentirà minacciato dall’automazione.

Chi invece accetta di spostarsi sul “come” e sul “perché”:

• come orchestriamo sistemi complessi,
• perché scegliamo una soluzione invece di un’altra,
• come mettiamo il team nella condizione di fare meno fatica e più impatto,

scoprirà che l’automazione non ruba il lavoro, lo promuove di categoria.

E secondo me, è lì che vale la pena stare.