Agenti AI nel dev: efficienza e rischi, perché servono gate tecnici e regole di revisione

Novanta minuti di push non voluti e una coda CI da 1.100 job bastano per capire la tesi: gli agenti AI possono accelerare, ma senza gate tecnici amplificano errori noti. Anche chi guida progetti critici lo sa. Linus Torvalds adotta strumenti di intelligenza artificiale, ma rifiuta patch “drive-by” generate automaticamente: l’AI entra nel flusso, non decide da sola cosa finisce a valle¹.

1. Adozione e avvertimenti: strumenti AI sì, patch automatiche no

L’indicazione di Torvalds è netta: niente patch mandate come passaggi estemporanei generati da modelli. Nella discussione compaiono accuse pesanti, da “slop” a “pubblicità”, firmate da nomi come Roy Schestowitz e David Gerard, fino all’utente “LordVile” che parla di “flip-flop” e di presunte pressioni della Linux Foundation. L’analisi che riporta le reazioni respinge la tesi del decadimento degli standard e definisce “ridicola” l’idea di un Torvalds eterodiretto. Sul fondo resta un punto tecnico: il “model collapse”, quando i modelli apprendono da output di altri modelli, con effetti sulla qualità del codice generato¹.

Il messaggio che emerge è operativo, non ideologico. Gli strumenti AI possono aiutare, ma le patch automatiche non hanno cittadinanza senza una verifica rigorosa. Il rischio non è teorico. Si riflette subito nella catena di build e rilascio.

2. Governance e neutralità: il tentativo di separare strumenti e vendor

Agentic AI Foundation assume in stewardship quattro progetti per agenti AI donati da vendor: OpenSandbox da Alibaba, Agent Skills da Anthropic, OpenEnv da Hugging Face, Open Responses da OpenAI. Il portafoglio sale a dieci iniziative. L’obiettivo dichiarato è offrire strumenti neutrali rispetto ai fornitori, con maggiore prevedibilità nella costruzione e messa in produzione di agenti².

La fondazione nasce a dicembre 2025 sotto l’egida della Linux Foundation con un mandato esplicito: separare gli strumenti dai piani dei singoli vendor e diventare punto di riferimento comunitario per questi componenti. All’avvio supervisionava tre iniziative, Model Context Protocol, goose e AGENTS.md. Le nuove adozioni fanno crescere il catalogo fino a dieci progetti. Il perimetro resta lo stesso: componenti riutilizzabili per chi sviluppa agenti².

Questo spostamento di governance punta a limitare dipendenze e frammentazione. La neutralità del contenitore non elimina però i rischi che emergono quando un agente modifica codice, tocca segreti o innesca pipeline. Per quelli servono pratiche di consegna e controllo.

3. Incidenti pratici che anticipano i guasti degli agenti

Due errori recenti mostrano dove casca l’automazione quando incontra sistemi reali. Primo: un tag mobile in una GitHub Action non puntava a uno SHA. some-org/setup-toolchain@v1 è cambiato, la nuova versione ha eseguito uno script post-install, ha letto $GITHUB_TOKEN e ha fatto push remoto su un branch poco seguito. Un reviewer ha notato un nome di step diverso e ha fermato tutto dopo novanta minuti. Molti team non hanno quel margine³.

Secondo: una matrice CI lanciava run per ogni push su un branch di pull request. Nessuna run veniva cancellata. Un contributore ha avviato un loop di force-push notturno. La coda è salita a 1.100 job. In sei ore sono evaporate settimane di minuti runner Linux, con build verdi. Nessun test rosso ha segnalato il disastro³.

Questi incidenti non compaiono nei workflow di esempio. Esplodono quando la CI tocca sistemi reali e catene di fiducia implicite. Qui il collegamento con gli agenti è diretto: senza un gate credibile, automazioni che propongono e spingono modifiche possono riprodurre gli stessi guasti su scala. Le patch “drive-by” non sono solo un problema di qualità del codice. Sono un moltiplicatore di impatti operativi e di sicurezza già osservati^1,3.

4. Metodologie di controllo: l’esempio di agent-doctrine

Una risposta operativa arriva da Sisig.ai con agent-doctrine. È una metodologia open source che impone un ciclo in otto fasi sempre uguale: scout, gate, plan, implement, review, consolidate, verify, ship. L’agente con cui si dialoga fa da lead: pianifica, delega, coordina. Scrive codice a mano solo su istruzione esplicita. Il cardine è il gate. Prima di qualsiasi edit, il lead deve rispondere nel transcript a quindici domande tratte da TENETS.md e portare evidenze. Domande concrete: qual è la modifica minima corretta. Qual è il blast radius. Come proverai la modifica su dati reali. Se non sa rispondere, non passa all’implementazione⁴.

La dottrina definisce ruoli distinti. Lo scout legge il codebase prima della pianificazione. L’implementer esegue istruzioni chiare. Review e verifica sono fasi esplicite e tracciate. L’idea è rendere verificabili i passaggi critici, con artefatti utili alla revisione umana. Questo blocca le patch “drive-by” e costringe l’agente a dimostrare di aver compreso contesto, rischi e prova finale prima di toccare il repository⁴.

Qui c’è un punto di contatto con l’avvertimento di Torvalds. L’AI può restare nel ciclo come strumento. Ma la consegna in upstream richiede prove, non promesse. Il transcript diventa parte della documentazione della modifica. Il gate trasforma un output generato in un oggetto revisionabile^1,4.

5. La traiettoria comune: limiti chiari, strumenti neutri, prove prima del merge

I casi messi in fila indicano un asse condiviso. Chi mantiene un progetto di base rifiuta patch generate e spedite senza responsabilità umane¹. Un’organizzazione di governance sposta progetti per agenti in un perimetro dichiarato neutrale rispetto ai vendor, con l’obiettivo di offrire componenti riutilizzabili e con maggiore prevedibilità². Incidenti in CI mostrano che automazioni banali possono leggere token, fare push e saturare runner senza che i test lo segnalino, se la configurazione lo consente³. Una metodologia introduce un gate con domande vincolanti e prove nel transcript prima di ogni edit⁴.

Il filo non chiede meno AI. Richiede che l’AI lasci tracce verificabili e si fermi se non ha risposte e prove. La neutralità di piattaforme e fondazioni crea spazio comune. La qualità della consegna dipende da regole esplicite sul modo in cui gli agenti entrano nella catena di sviluppo e rilascio. È il punto su cui convergono avvertimenti, governance e pratiche: prima di toccare codice e pipeline, servono logiche di gate che mostrino cosa l’agente sa, cosa non sa e come lo dimostra^1,2,4.