Il CI/CD è la pratica di automatizzare due fasi del ciclo di vita del software: l'integrazione continua (CI), che compila ed esegue i test su ogni modifica appena proposta, prima che si mescoli con il resto del codice, e la consegna o distribuzione continua (CD), che porta quella modifica, superati i controlli, verso un ambiente di staging o fino in produzione. Una pipeline CI/CD è lo strumento, spesso un servizio come GitHub Actions, GitLab CI o Jenkins, che mette in fila questi passaggi e li fa girare da solo a ogni modifica, senza bisogno di lanciarli a mano né di fidarsi della memoria di chi ha scritto il codice.
Chi cerca semplicemente "ci cd" di solito vuole capire cosa significa e come si applica al proprio lavoro, non un tool specifico. Ma il momento in cui questa definizione conta davvero è un altro: quando le modifiche che arrivano alla pipeline non le scrive più solo una persona, ma in parte anche un agente.
Cosa fa davvero una pipeline CI/CD?
Ridotta all'osso, una pipeline CI/CD fa tre cose in sequenza su ogni modifica: prende il codice, lo compila o lo prepara, e lo fa passare attraverso una serie di controlli automatici, test unitari, test di integrazione, linting, a volte una scansione di sicurezza. Se tutti i controlli passano, la CI segna la modifica come integrabile; la CD, quando è configurata, la porta avanti verso un ambiente di staging o di produzione, spesso con un passaggio di approvazione umana prima dell'ultimo salto. Il pezzo che rende utile tutto questo non è l'automazione in sé, è che ogni passaggio produce un risultato binario e tracciato: verde o rosso, con un log di cosa è stato eseguito e quando. Nessuno riscrive quel risultato a mano dopo il fatto, perché non è mai stato scritto a mano la prima volta.
Cosa cambia quando a proporre le modifiche è un agente?
Con uno sviluppatore, la pipeline è un controllo indipendente su un lavoro che una persona ha già fatto e di cui, in teoria, può rispondere. Con un agente che scrive codice per gran parte della giornata, la stessa pipeline diventa qualcosa di diverso: è il primo punto del flusso in cui una verifica indipendente incontra davvero l'output dell'agente, perché tutto quello che viene prima, il ragionamento nella sessione, il "ho eseguito i test e passano" scritto in una risposta, non è verificato da nessuno tranne dall'agente stesso. Più modifiche arrivano da una sessione agentica, più cresce il volume di codice che la pipeline deve intercettare prima che diventi un problema in produzione, e più diventa rilevante sapere se quel controllo automatico esiste davvero e cosa fa, non solo che esiste un segno verde da qualche parte.
Perché la verifica eseguita dal sistema conta più di quella dichiarata dal modello?
Un agente di coding può dire di aver eseguito i test. Può anche "crederlo", nel senso limitato in cui un modello genera quella frase perché è coerente con il resto della sessione, non perché ha una nozione di verità indipendente dal proprio output. Lo confermano gli stessi dati sull'affidabilità dell'autovalutazione: nello studio randomizzato controllato di METR del 2025, sviluppatori esperti che usavano strumenti AI su task reali sono risultati il 19% più lenti rispetto a lavorare senza, pur avendo previsto di essere il 24% più veloci e pur continuando a credere, a posteriori, di essere stati il 20% più veloci. Se l'autovalutazione di una persona esperta sulla propria produttività sbaglia di quaranta punti percentuali, un "i test passano" dichiarato da un agente dentro la stessa sessione in cui ha scritto il codice non è una verifica: è un'altra riga di output, con la stessa affidabilità di tutte le altre.
| Verifica eseguita dalla pipeline | Verifica dichiarata dal modello | |
|---|---|---|
| Chi la esegue | Un sistema terzo, fuori dalla sessione | L'agente stesso, dentro la sessione |
| Cosa garantisce | Che un comando specifico è girato con un esito specifico | Che l'agente ha scritto una frase coerente con l'esito atteso |
| Chi può manometterla | Chi ha accesso in scrittura alla configurazione della pipeline | Chiunque riformuli il prompt, o l'agente stesso in un loop successivo |
| Cosa resta dopo | Un log con comando, esito e timestamp | Una riga di testo dentro una trascrizione di chat |
Cosa conviene conservare di ogni esecuzione, e per quanto tempo?
Il segno verde da solo non basta a lungo, perché quasi nessuna piattaforma lo tiene per sempre di default. GitHub, per esempio, ha annunciato a fine agosto 2026 che dal 1° ottobre 2026 anche i check, le esecuzioni dei workflow e gli stati delle commit, non solo gli artifact e i log come già accadeva, seguiranno lo stesso periodo di conservazione configurabile: fino a 90 giorni per i repository pubblici, fino a 400 per quelli privati, di default 90 se non si cambia nulla. Prima di questo cambiamento, secondo il changelog ufficiale di GitHub, quei tre elementi restavano visibili per oltre 400 giorni a prescindere dalla configurazione. È il tipo di dettaglio che una software house scopre nel modo peggiore, mesi dopo aver promesso a un cliente di poter ricostruire una consegna specifica.
Quello che conviene portare fuori dalla pipeline prima che scada, in un registro separato che non dipende dalle impostazioni di retention della piattaforma CI, è poco ma preciso: quale commit è stato verificato, quale comando è stato eseguito, con quale esito, in che momento, e collegato a quale richiesta o task lo ha originato. Non serve esportare l'intero log grezzo di ogni esecuzione: serve quella manciata di campi, perché sono quelli a cui qualcuno chiederà conto sei mesi dopo che il segno verde è già scomparso dalla dashboard.
Come si passa dal segno verde a un registro che qualcuno può firmare?
Un segno verde risponde a "questo comando è girato con successo, in quel momento". Non risponde a "chi ha autorizzato questa modifica" né a "chi si assume la responsabilità di averla lasciata passare". Sono due domande diverse, e la pipeline CI/CD risponde solo alla prima, per costruzione: è un controllo tecnico, non un processo di autorizzazione. Un tool di code review basato su AI aggiunge un secondo controllo automatico sulla qualità del diff, ma resta comunque un controllo, non una firma: nessuno dei due strumenti produce da solo l'oggetto che lega quel risultato tecnico a una persona che ne risponde.
Lo stesso vale per gli hook di Claude Code: intercettano un evento nel momento in cui accade, dentro la sessione dell'agente, un passo prima che il codice arrivi alla pipeline. Sono un ottimo punto per catturare cosa è stato tentato. La pipeline resta il punto migliore per verificare, con un sistema indipendente, se quel tentativo ha davvero funzionato. Nessuno dei due, da solo, è il registro finale: quello nasce quando il risultato tecnico della pipeline si collega al task che l'ha richiesto e a una persona che firma prima che la modifica conti come rilasciata. Detent, l'impianto di delivery end-to-end (detent-ai.com), tiene insieme questi pezzi, dall'intento alla verifica automatica fino alla firma umana, così che il segno verde della pipeline non resti un fatto isolato ma diventi parte di una prova che qualcuno può mostrare molto dopo che quella esecuzione è finita.