Cloudflare vuole sostituire lo SDLC con un ciclo di vita per agenti (ADLC)
Cloudflare propone l'ADLC al posto dello SDLC: sette proprietà richieste a una software factory e una tabella che mappa ogni fase sulle sue primitive.
Cloudflare ha pubblicato un post, «The Agent Development Lifecycle has arrived on Cloudflare» e la tesi è che lo Software Development Lifecycle, la sequenza di fasi nata dal rapporto RAND del 1975 e oggi sedimentata nelle pipeline CI/CD, non regga più il volume di codice che gli agenti producono.
Al suo posto viene proposto l'ADLC, l'Agent Development Lifecycle, e una tabella che mappa ogni fase su primitive di uno stack tecnologico.
Il punto non è solo il nome.
La fase un tempo più lenta e costosa, l'implementazione, è diventata la più veloce ed economica, e che il costo si è spostato a valle: manutentori open source travolti dalle pull request, ingegneri di produzione che difendono i sistemi mentre la velocità di consegna cresce. La distinzione è: lo SDLC è per i team di software, l'ADLC è per le software factory. Non un team che usa agenti dentro le fasi esistenti, ma un sistema che prende un input e costruisce, distribuisce e manutiene software da solo.
Il post come descrizione di stack
L'ADLC non nasce da uno standard né da una spec: nasce da un patchwork di prodotti. È utile leggerlo come quello che è, cioè una descrizione di stack, e verificare cosa copre e cosa lascia fuori.
Le fasi dello SDLC richiamate sono sette: pianificazione, progettazione, implementazione, test, distribuzione, manutenzione, dismissione.
Una software factory deve soddisfare le stesse fasi ma ogni step che prima dipendeva da una persona deve diventare programmabile, scalabile orizzontalmente, riproducibile, real-time e push, atomico, con permessi e auto-migliorante.
È quindi più una lista di requisiti per la piattaforma, non un elenco di funzionalità.
Le fasi dello SDLC vengono proposte accoppiate a prodotti: pianificazione, progettazione e implementazione condividono la toolchain (Vite, Rolldown e Oxc), l'ambiente locale con Local Explorer e Local Traces, i remote bindings e le Preview URL per ogni pull request; i test passano da Browser Run e Vitest nel runtime Workers; la distribuzione da Flagship, che assegna un feature flag a ogni modifica, e dalle Gradual Deployments; manutenzione e dismissione condividono Workers Logs, Agent Traces, il server MCP con Code Mode e Dynamic Workers, e Analytics Engine su ClickHouse.
Il punto di ingresso è @cloudflare/ci, nato per far girare CI/CD su milioni di repository, con Workflows come orchestratore e Artifacts come strato di storage del codice.
Una pipeline CI/CD è solo un Workflow.
Al posto di un file YAML, il processo diventa codice TypeScript che può generare container, browser e altri agenti. La stessa pagina mostra un Workflow che lancia un agente di revisione e ne legge il risultato, e un esempio di CI che si auto-ripara.
Il paragone è quello dell'auto a guida autonoma. Una macchina arriva all'80% della bravura di un guidatore umano già da un decennio, ma l'asticella da superare non è l'80%: è qualche nove oltre il 99%, ed è per questo che le auto a guida autonoma hanno sensori e calcolo che un'auto normale non ha.
La software factory si trova davanti allo stesso salto: non basta funzionare quattro volte su cinque, serve una affidabilità superiore all'80%.
La pipeline diventa un Workflow
Non è una semplificazione: è un cambio di paradigma.
Quando un processo costruito per essere letto da una persona diventa un programma eseguito da una macchina, il controllo si sposta dal file di configurazione, che il team versiona e ispeziona, all'agent che lo esegue, che ha retry, persistenza e osservabilità sue.
Per un team che oggi vive su GitHub Actions, il costo di migrazione non è la riscrittura in TypeScript. È che il Workflow diventa l'unità di orchestrazione dell'ADLC, e la modifica di un comportamento della pipeline può avvenire nella pipeline stessa. La revisione automatica, il self-healing, l'osservabilità dei passi non sono più step che il team scrive e controlla nello stesso modo in cui controllava un job di linter.
Se l’implementazione è ormai la fase più economica, la fase più costosa diventa la verifica, che oggi è distribuita e composta da ambienti che si moltiplicano e proliferano. Risorse che si attivano e comporteranno un costo infrastrutturale non trascurabile.
Il rischio è che, senza spegnere ciò che non serve dopo l’uso, il costo di una software factory aumenti in modo esponenziale con il numero di repository ospitati, indipendentemente dal valore generato dal lavoro effettivamente svolto.
Further Reading
Brendan Irvine-Broque
André Venceslau
Olimpiu Pop
Nevi Shah
