AI, codice e supervisione umana: il nuovo collo di bottiglia e l'approvazione

Negli ultimi mesi si parla molto di AI che scrive codice.

Claude Code, GPT, agenti dentro IDE, automazioni che aprono pull request, test generati in automatico, documentazione prodotta insieme alla feature.

La narrativa è semplice:

se l'AI produce codice più velocemente, allora il team consegna più velocemente.

È vero solo a metà.

Perché nel lavoro reale, soprattutto quando parliamo di DevOps, infrastruttura, sicurezza e produzione, il codice non finisce quando viene generato.

Finisce quando qualcuno lo legge, lo capisce, lo valida e si assume la responsabilità di approvarlo.

Il punto critico quindi non è più solo: chi scrive il codice?

La domanda più importante diventa: chi firma il rischio?

Il paradosso della velocità

L'AI aumenta la velocità di generazione.

Questo è evidente.

Una modifica che prima richiedeva ore oggi può nascere in pochi minuti. Un refactor può coinvolgere decine di file. Una suite di test può essere proposta automaticamente. Una pipeline CI/CD può essere scritta partendo da una descrizione in linguaggio naturale.

Ma più codice viene generato, più cresce anche la mole di codice da validare.

Qui nasce il paradosso:

l'AI comprime il tempo di scrittura, ma può espandere il tempo di revisione.

Se una persona apre una pull request con 40 file modificati da un agente, il problema non è solo verificare se compila.

Il problema è capire:

se la logica è corretta
se i test coprono davvero il rischio
se sono stati introdotti side effect
se le policy di sicurezza sono state rispettate
se il rollback è ancora possibile
se il comportamento in produzione resta osservabile

La generazione è diventata economica. La validazione resta costosa.

È spesso proprio lì che si gioca il valore professionale.

La velocità della demo non è la velocità della produzione

C'è un altro effetto che molti team scoprono solo dopo qualche mese di uso intenso dell'AI.

L'aumento della velocità di generazione non accelera automaticamente tutto il sistema di consegna.

Anzi, spesso espone le debolezze del delivery system.

Se l'AI produce più cambiamenti, quei cambiamenti devono comunque passare da:

review
CI
test automatici
controlli di sicurezza
ambienti di staging
procedure di deploy
osservabilità
rollback

Se questi passaggi erano già sotto stress prima, l'AI non li risolve.

Li carica di più.

Il risultato è paradossale: più output, ma più pressione sul sistema che deve assorbirlo.

Alcuni dati raccontano proprio questo effetto: chi usa intensamente l'AI può ritrovarsi con tempi di ripristino più lunghi in caso di incidente, per esempio 7,6 ore contro circa 6 ore di chi la usa solo occasionalmente.

Non perché l'AI sia inutile.

Ma perché spinge più modifiche dentro processi di review, test e rilascio che non erano stati progettati per quel volume.

A quel punto entrano in gioco gli "eroismi" dei senior: persone esperte che devono leggere diff enormi, capire incidenti generati da cambiamenti rapidi, ricostruire intenzioni poco documentate e mettere pezze su un sistema che corre più veloce della sua capacità di controllo.

Questa non è efficienza.

È debito operativo mascherato da produttività.

Una pull request scritta dall'AI non si approva da sola

Scenario pratico.

Un ingegnere apre una pull request.

Il codice è stato scritto quasi interamente da Claude Code o GPT. La PR passa i test. La descrizione è ordinata. I commit sembrano coerenti.

Domanda: l'approver dovrebbe firmare quel codice senza leggerlo?

Ovviamente no.

Perché l'AI può produrre codice sintatticamente corretto ma logicamente fragile.

Può generare test che verificano il comportamento sbagliato.

Può sistemare un bug introducendo una scorciatoia che rompe un vincolo architetturale.

Può aggiungere una permission troppo larga in una policy cloud.

Può creare una pipeline che funziona nel caso felice, ma non gestisce rollback, migrazioni fallite o credenziali esposte nei log.

In altre parole: può produrre un output plausibile.

Ma plausibile non significa sicuro. Plausibile non significa adatto al tuo sistema. Plausibile non significa pronto per la produzione.

Per questo il controllore resta indispensabile.

Il software engineering non è solo scrivere codice

L'AI ha banalizzato il primo strato del lavoro: la produzione dell'artefatto.

Codice, test, script, documentazione, YAML, Terraform, playbook Ansible, workflow GitHub Actions.

Tutto questo oggi costa meno tempo.

Ma il software engineering non è mai stato solo scrittura.

È anche:

definizione dei vincoli
coerenza con l'architettura esistente
verifica degli edge case
gestione del rischio operativo
sicurezza
osservabilità
manutenibilità
approvazione finale

Il problema è che l'AI ha accelerato molto il primo livello e ha mandato in corto circuito l'ultimo: l'approvazione.

Prima si revisionava codice scritto lentamente da un umano.

Ora si revisionano grandi quantità di codice generate rapidamente da un sistema probabilistico.

Il ruolo dell'ingegnere si sposta quindi dal fare tutto a mano al governare il processo.

Non sparisce il lavoro. Cambia il collo di bottiglia.

Il nuovo ruolo: supervisory engineering

Nel lavoro quotidiano lo chiamo sempre più spesso supervisory engineering.

Non significa limitarsi a guardare l'AI mentre lavora.

Significa dirigere, valutare e correggere output generati da strumenti che possono essere molto veloci, ma non responsabili.

Il processo si divide in tre livelli.

1. Livello di generazione

Qui l'agente produce l'artefatto.

Può essere codice applicativo, una configurazione Kubernetes, una pipeline, una policy IAM, un test, una migrazione database o una procedura di deploy.

Questo livello è sempre più automatizzabile.

2. Livello di verifica

Qui si controlla se l'output è corretto nel contesto reale.

Non basta chiedere se il codice compila.

Bisogna verificare sicurezza, compatibilità, failure mode, idempotenza, rollback, logging, metriche, impatto sulle dipendenze e coerenza con il sistema esistente.

Questo è lavoro ingegneristico vero.

3. Livello di sign-off

Qui un essere umano accetta formalmente la proprietà del cambiamento.

Quando approvi una PR, non stai solo dicendo: "mi sembra scritta bene".

Stai dicendo: "questa modifica può entrare nel nostro sistema e mi assumo il rischio operativo di questa decisione".

Questo punto non può essere delegato completamente a un modello.

Senior, staff engineer e manager: la sfida è organizzativa

Il problema quindi non riguarda solo il singolo sviluppatore davanti alla PR.

Riguarda l'organizzazione.

I senior e gli staff engineer non devono limitarsi a chiedere: "il codice compila?".

Devono chiedere:

questa modifica appartiene davvero al sistema?
rispetta i confini architetturali esistenti?
l'autore capisce cosa ha approvato l'agente?
il cambiamento riduce o aumenta il rischio operativo?
tra sei mesi sapremo ancora perché questa scelta è stata fatta?

Questo cambia il modo di fare review.

Non basta più valutare il singolo file. Bisogna valutare l'intenzione, la proprietà e la compatibilità del cambiamento con il sistema.

Anche i manager hanno una responsabilità precisa.

Non possono misurare l'adozione dell'AI solo in base alla quantità di output generato.

Se premi solo il numero di PR, ticket chiusi o righe prodotte, stai probabilmente creando una tassa nascosta per chi deve revisionare tutto con cura.

Il manager deve progettare l'ossatura operativa:

aspettative chiare sulla review
ownership esplicita delle modifiche
regole su quando l'AI può intervenire
budget per strumenti di sicurezza, test e osservabilità
tempo riconosciuto per auditing e validazione
metriche che non premino solo volume e velocità

Senza questa ossatura, l'AI aumenta la produzione ma scarica il rischio sugli ultimi anelli della catena.

E spesso quegli ultimi anelli sono proprio le persone più competenti del team.

Il caso più insidioso: test generati per confermare l'errore

Uno dei rischi più sottovalutati è la relazione tra AI e test.

Molti dicono: "nessun problema, facciamo scrivere anche i test all'AI".

Va bene.

Ma chi verifica che quei test stiano proteggendo il comportamento giusto?

Se l'AI introduce un bug e poi scrive un test che conferma quel comportamento sbagliato, la pipeline diventa un falso segnale di sicurezza.

Hai una build verde. Hai una PR ordinata. Hai copertura aumentata.

Ma hai anche formalizzato un errore.

In ambito DevOps questo rischio è concreto.

Un test può verificare che uno script esegua un comando, ma non che quel comando sia sicuro in produzione.

Può verificare che una policy venga applicata, ma non che sia a privilegio minimo.

Può verificare che un backup parta, ma non che il restore sia consistente.

Può verificare che una pipeline arrivi al deploy, ma non che il rollback sia praticabile.

Il test generato dall'AI è utile.

Ma non sostituisce il giudizio sul contratto che il test dovrebbe rappresentare.

La mente umana ha un limite di review

C'è un punto scomodo da ammettere.

Gli esseri umani non sono bravi a revisionare enormi quantità di codice in modo continuo e perfetto.

Dopo un certo numero di file, l'attenzione cala. Dopo molte PR generate bene, si abbassano le difese. Dopo tante modifiche "perfette", si inizia ad approvare per pattern, non per comprensione.

Questo è pericoloso.

Perché gli output AI spesso sono ordinati, coerenti nello stile, ben commentati e convincenti.

Proprio questa qualità apparente può diventare un problema: se tutto sembra professionale, il revisore tende a fidarsi prima.

Ma la qualità formale non garantisce qualità sostanziale.

E in produzione la differenza conta.

Un diff elegante può contenere una falla logica. Una suite di test pulita può ignorare il caso critico. Una configurazione ben formattata può aprire una porta inutile.

La competenza non è il prompting

Il prompting conta.

Saper descrivere bene un obiettivo aiuta.

Ma non è la vera priorità.

La competenza decisiva è un'altra: rendere il risultato verificabile da un essere umano.

Nel mio lavoro di consulenza questo significa impostare guardrail prima della generazione.

Esempi pratici:

PR piccole e leggibili
diff separati per logica, refactor e formattazione
checklist di review per sicurezza e operatività
test legati a requisiti espliciti, non solo al codice prodotto
policy chiare su segreti, permessi e logging
rollback documentato prima del deploy
metriche e alert definiti insieme alla modifica

Il punto non è chiedere all'AI "scrivi meglio".

Il punto è costruire un processo in cui il risultato sia leggibile, verificabile e approvabile.

Perché se una PR è troppo grande per essere capita, non è pronta per essere approvata.

Anche se l'ha scritta l'AI.

Anche se passa tutti i test.

Come costruire un sign-off sano

L'approvazione non deve diventare una formalità.

Se una PR è stata generata o pesantemente assistita dall'AI, il processo deve renderlo visibile e gestibile.

Alcune regole pratiche aiutano molto.

1. Attribuzione chiara

Segnalare dove l'AI è intervenuta.

Non per colpevolizzare chi la usa, ma per dare contesto al revisore.

Un tag come Assisted-by: Claude Code o Assisted-by: GPT nella descrizione della PR può bastare.

Il punto è semplice: se so che una modifica è stata generata da un agente, la leggo con un'attenzione diversa.

2. Patch più piccole

Il codice AI-assisted deve essere diviso in blocchi revisionabili.

Una PR enorme non diventa più accettabile solo perché l'ha prodotta un agente in pochi minuti.

Anzi, proprio perché è stata generata velocemente, deve essere spezzata meglio.

Refactor, logica, test, configurazione e formattazione dovrebbero stare separati quando possibile.

3. Logica spiegata da umani

La descrizione della PR non dovrebbe limitarsi a un riassunto generato dall'AI.

Serve una spiegazione sintetica dell'autore:

perché è stato scelto questo approccio?

Questa frase è importante.

Non chiede cosa è cambiato. Chiede perché.

Se l'autore non sa spiegarlo, probabilmente non è pronto a firmare quel cambiamento.

4. Checkpoint obbligatori

Alcune modifiche non devono poter passare per distrazione.

Esempi:

pagamenti
autenticazione
permessi cloud
configurazioni di produzione
backup e restore
migrazioni database
cancellazioni o trasformazioni massive di dati

Su questi punti servono checkpoint espliciti: review aggiuntive, approvazioni CODEOWNERS, controlli CI bloccanti, policy di sicurezza, dry-run obbligatori o finestre di rilascio controllate.

Il principio è pragmatico: se una modifica può fare danni seri, non deve dipendere solo dall'attenzione del revisore in quel momento.

Auditing: il lavoro che torna centrale

Con l'AI l'auditing non diventa meno importante.

Diventa più importante.

Se chiunque può generare un documento strategico di 20 pagine, il valore non sta nella generazione del documento.

Sta in chi lo legge, lo smonta, trova le assunzioni deboli e decide se può essere firmato.

Lo stesso vale per il codice.

Se chiunque può generare una feature, il valore si sposta su chi sa rispondere a domande come:

questa modifica rispetta il modello di sicurezza?
quali failure mode introduce?
cosa succede se una dipendenza rallenta?
quali dati possono essere persi o duplicati?
il rollback è testato o solo dichiarato?
chi riceve un alert se qualcosa degrada?
questa soluzione sarà comprensibile tra sei mesi?

Queste non sono domande da prompt engineer.

Sono domande da ingegnere responsabile di un sistema.

Cosa guardo in una review AI-assisted

Quando mi trovo davanti a codice prodotto o assistito da AI, cerco di non farmi distrarre dalla forma.

Guardo prima il rischio.

Una checklist minima:

Il diff è abbastanza piccolo da essere compreso davvero?
La modifica risolve il problema richiesto o anche altro?
I test verificano il requisito o semplicemente il comportamento implementato?
Sono stati modificati permessi, segreti, logging o configurazioni runtime?
Esiste un rollback realistico?
Gli errori vengono gestiti o solo nascosti?
Le metriche permettono di vedere un degrado prima dell'incidente?
Il codice è coerente con il sistema esistente o introduce un nuovo stile locale?

Questa è la parte che spesso fa la differenza tra usare l'AI bene e usarla come moltiplicatore di caos.

Conclusione

L'AI ha spostato il collo di bottiglia.

Prima il limite era spesso scrivere codice abbastanza velocemente.

Ora il limite diventa valutare abbastanza bene ciò che viene prodotto.

Nel DevOps moderno questo cambio è enorme.

Perché una pipeline sbagliata, una policy troppo larga, un backup non ripristinabile o un deploy senza rollback non sono dettagli tecnici.

Sono rischi operativi.

Il futuro dello sviluppatore non è stare fermo a guardare l'AI.

È diventare supervisore tecnico del processo: definire vincoli, leggere diff, pretendere verifiche, impostare guardrail e firmare solo ciò che capisce davvero.

La produzione inizia con l'AI.

Ma la responsabilità inizia con la validazione umana.

Il lavoro dell'ingegnere nell'era dell'AI è rendere ciò che le macchine producono leggibile, tracciabile e sicuro, così che un altro essere umano possa assumersene la responsabilità senza affidarsi alla fiducia cieca.

Ed è lì che, oggi più che mai, serve ingegneria.