L'agentic SDLC è lo stesso ciclo di vita del software che i team hanno sempre seguito, analisi dei requisiti, progettazione, sviluppo, test, rilascio, manutenzione, con la differenza che oggi gli agenti AI svolgono una parte consistente del lavoro dentro ogni fase, mentre resta a una persona decidere cosa costruire e cosa va in produzione.
Negli ultimi mesi mezza dozzina di vendor ha pubblicato la propria definizione del termine, techcommunity.microsoft.com, coderabbit.ai, port.io, sonarsource.com, devinterrupted.substack.com, e un dominio costruito apposta, asdlc.io. Una keyword così piccola di solito non attira tutta questa attenzione insieme. La attira adesso perché la categoria si sta ancora formando, e chi arriva primo con una definizione che regge tende a restare il riferimento. Quasi tutte quelle definizioni dicono la stessa cosa: gli agenti fanno di più, in più fasi. Nessuna dice cosa deve restare di ogni fase perché la risposta a una domanda posta più avanti nel tempo tenga ancora in piedi.
Come erano le fasi del ciclo di vita del software prima degli agenti?
Prima degli agenti, il ciclo di vita del software attraversava sei fasi, qualunque fosse la metodologia sopra: analisi e pianificazione, dove qualcuno decideva cosa costruire e perché; progettazione, dove quella decisione diventava un'architettura e un insieme di interfacce; sviluppo, dove una persona scriveva il codice seguendo quella progettazione; test e QA, dove il risultato veniva verificato contro il requisito, non solo contro se stesso; deployment e rilascio, dove la modifica arrivava in produzione sotto l'autorizzazione di qualcuno; e manutenzione, dove il team osservava cosa succedeva dopo il rilascio e correggeva quello che si rompeva. Ogni fase lasciava dietro di sé un artefatto: una specifica o un ticket, un documento di design, un diff, un test superato, un record di rilascio, un log di incidente. L'agentic SDLC mantiene tutte e sei le fasi. Quello che cambia è chi, o cosa, produce il lavoro dentro ciascuna, non la forma del ciclo, ed è esattamente la distinzione che la maggior parte delle definizioni attuali del termine salta.
Dove si inseriscono davvero gli agenti nell'SDLC?
Lo sviluppo è la fase in cui gli agenti sono più avanti, e non è nemmeno vicino: l'agentic coding, il ciclo pianifica, modifica, esegui, verifica, è già maturo abbastanza che un agente headless può portare un ticket reale dal repository a una build che passa, senza che una persona apra un editor. Il test viene subito dopo: gli agenti scrivono ed eseguono suite di test contro una modifica, anche se una suite generata vale quanto il requisito che è stata costruita per verificare. La pianificazione è più recente e cresce in fretta: Spec Kit di Microsoft trasforma un obiettivo dichiarato in requisiti, un piano e una scomposizione in task che un agente di coding esegue poi di conseguenza: la specifica può arrivare da uno strumento, non solo da una persona, e questo sposta il rischio più a monte nel ciclo invece di eliminarlo. La revisione sta nel mezzo: gli agenti riassumono un diff e segnalano problemi probabili piuttosto bene; il rischio nasce quando quel riassunto viene trattato come la revisione stessa, invece che come un input per una decisione che resta comunque a una persona.
Quali fasi sono diventate solo più rumorose, non diverse?
Deployment, revisione di sicurezza e risposta agli incidenti non sono state reinventate, sono diventate più rumorose, perché ogni settimana ci passa più cambiamento mentre il processo in quella fase gira ancora alla stessa velocità di sempre. Un sondaggio su 700 professionisti tecnologici di grandi aziende pubblicato da Harness a settembre 2026 mette un numero su questo scarto: il 74% delle organizzazioni è sicuro che i propri test intercettino i fallimenti degli agenti, ma solo il 19% ha davvero dei gate automatici che bloccano un rilascio difettoso; il 76% crede di poter disattivare un agente che si comporta male entro 15 minuti, ma solo il 33% ha un interruttore così rapido. È lo stesso scarto che si ripete due volte, nei test e nel rilascio: la fiducia è cresciuta insieme a quanto producono gli agenti, il controllo che la giustificherebbe no. Scrivere il codice non è mai stato il vero collo di bottiglia nella produzione di un team, e questi numeri mostrano che non lo è nemmeno in un agentic SDLC. Le fasi che sono sempre state questione di giudizio, non di battitura, sono esattamente dove adesso si accumula il volume non controllato.
Quale artefatto deve lasciare dietro di sé ogni fase, adesso?
Quello che conta per una data fase non è se un agente l'ha toccata. È se quella fase produce ancora qualcosa che una persona non presente in quel momento può verificare più avanti, senza dover chiedere a chi ha fatto girare l'agente di ricostruirlo a memoria.
| Fase | Cosa può fare oggi un agente | Cosa deve sopravvivere |
|---|---|---|
| Pianificazione | Trasformare un obiettivo in requisiti e una scomposizione in task | Una specifica verificabile contro quello che è stato davvero rilasciato |
| Sviluppo | Scrivere e modificare codice seguendo quella specifica | Un diff collegato all'autorizzazione che ne definiva il perimetro, non solo un messaggio di commit |
| Test | Scrivere ed eseguire la suite di test | Un test eseguito da una macchina, non il resoconto dell'agente che dice di averlo superato |
| Revisione | Riassumere un diff e segnalare problemi probabili | Una decisione registrata, accettato o respinto, presa da una persona, non solo il riassunto |
| Rilascio | Impacchettare e distribuire la modifica | Un record di rilascio firmato che nomina chi lo ha autorizzato |
| Manutenzione | Fare triage e correggere quello che si è rotto | Un log di incidente collegato alla modifica che lo ha causato |
Parte di questo è già meccanico: uno strumento come Claude Code può eseguire hook che impongono un controllo prima ancora che un commit venga accettato, così il gate esiste anche se nessuno si ricorda di farlo girare a mano. Un hook impone che il controllo giri. Non sostituisce l'artefatto che quel controllo deve lasciare dietro di sé, automatizza solo il modo per arrivarci.
Riesci ancora a spiegare questo ciclo a un cliente, fase per fase?
È questo il vero banco di prova di un agentic SDLC, non se gli agenti toccano più fasi, ma se chi si trova davanti a un cliente, a un auditor o al proprio team mesi dopo riesce a percorrere le sei fasi in ordine e indicare cosa è sopravvissuto a ognuna: la specifica, il diff con la sua autorizzazione, il test eseguito, la decisione di revisione, il rilascio firmato, l'incidente ricondotto alla sua causa. La maggior parte delle definizioni dei vendor in gara per nominare questa categoria risponde a una domanda più stretta, quanto lavoro fa oggi un agente. Detent, l'impianto di delivery end-to-end (detent-ai.com), è costruito sull'altra domanda: tiene collegati intento, contesto autorizzato, esecuzione e firma umana lungo ogni fase, dalla richiesta al rilascio, così il ciclo resta spiegabile a posteriori, non solo più veloce mentre gira.