Spec-Driven Development e Dark Factory Agentica

Critica formulata da Kent Beck a Prodacity 2026 contro due tentazioni ricorrenti dello sviluppo software con gli agenti AI: la dark software factory (esecuzione completamente autonoma senza umano né feedback) e lo spec-driven development one-shot (scrivere una specifica esaustiva da cui il "genio" generi il sistema finito). ¹

La Dark Factory agentica va sempre fuori binario

Per dark software factory non si intende "software malvagio", ma una fabbrica a luci spente: nessun umano coinvolto, nessun feedback durante l'esecuzione. ¹

• L'esito inevitabile: ogni volta che Beck ha provato un approccio completamente agentico in stile dark factory, è andato sempre fuori binario (always goes off the rails). ¹
• Lo schianto spettacolare: l'inganno psicologico è che lo schianto è divertentissimo da guardare ("Wow, come hai fatto a produrre tutta questa roba?"), ma il risultato finale resta "completa spazzatura" (complete crap) e non ha lasciato alcun apprendimento nel team (vedi Apprendimento e Opzionalità nel Software). ¹
• Il tool genera opportunità di feedback più velocemente di quanto siamo pronti a raccoglierle e analizzarle; lasciarlo correre a tutta velocità senza cicli di consolidamento umano brucia tutte le opzionalità del progetto. Per come progettare invece loop stretti e verificatori attorno all'agente, vedi Harness Engineering e Shift Left Security. ¹

Spec-Driven Development = il Waterfall di Winston Royce (1970)

Con l'AI torna lo scontro tra sviluppo one-shot e sviluppo iterativo. La tesi dello spec-driven development è: "scrivo una specifica e il genio produce il software; se non va bene, scrivo una specifica ancora più grande e complicata finché il software non esce corretto". ¹

1. È esattamente il Waterfall: Beck osserva che esiste già un nome per questo approccio — è il Waterfall, che non ha mai funzionato. Nel paper originale di Winston Royce (1970) la pagina con il celebre diagramma a cascata afferma esplicitamente che quel modello non funziona perché le decisioni prese più tardi informano e modificano le decisioni prese prima (e la pagina seguente mostrava i cicli di feedback che risalgono), ma nella memoria collettiva è rimasta solo l'illusione seducente della prima immagine. ¹
2. Quando il one-shot basta e quando fallisce: per una piccola app isolata il one-shot può andare bene (così come nella clean-room di un software già esistente e noto, vedi Reimplementazione del software via LLM). Ma su sistemi complessi — Beck cita la virtual machine per un graph database con linguaggio embedded che sta scrivendo — o quando si hanno un miliardo di utenti in produzione, rigenerare il software one-shot da specifica è impossibile per via dei problemi di continuità del servizio e di migrazione dei dati: lì si è obbligati a procedere in modo iterativo, partendo da software che ha valore nel mondo e migliorandolo passo dopo passo. ¹

I due limiti dei metodi formali (Lean + LLM)

Rispondendo a una domanda sui metodi formali — che Beck conosce fin da quando era teaching assistant del corso di Proof of Program Correctness e che nell'ultimo anno ha sperimentato usando Lean insieme al genio — individua due ostacoli strutturali: ¹

1. Natura one-shot che frena il cambiamento: dimostrare formalmente le proprietà di una specifica richiede molto lavoro; appena si cambia un singolo elemento bisogna riavvolgere tutto. Anche se il genio accelera le dimostrazioni, resta un freno alla modificabilità, mentre Beck vuole sistemi che incoraggino il cambiamento anziché scoraggiarlo. ¹
2. Il gap tra modello matematico e implementazione: anche dopo aver dimostrato che certe proprietà valgono per una specifica formale, resta un divario non colmato nel derivarne un programma reale che gira in C, C++ o assembly ARM64/x86. ¹

Come ottenere software affidabile col genio

La buona notizia è che si possono raggiungere basse densità di difetti senza metodi formali pesanti, lavorando duramente su due leve: esempi / test automatizzati scelti con cura e foolproofing del design (rendere il design a prova di errore). Bisogna però vigilare costantemente sulle scorciatoie del genio, che tende a sovvertire l'intenzione dei test (ad esempio restituendo costanti pur di far passare il check): una dinamica speculare a quella analizzata in Checking vs Testing e Agentic Testing. ¹

Il controesperimento di Pocock (2026)

Anche Matt Pocock ha messo alla prova lo spec-driven development puro — ispirato allo slogan virale secondo cui "l'inglese è il nuovo linguaggio di programmazione" — cercando di mantenere una specifica come sorgente persistente da modificare nel tempo lasciando che l'agente rigenerasse e aggiornasse il codice di conseguenza senza mai guardare l'implementazione: ²

• La specifica cambia, il codice peggiora: a ogni giro del loop (modifica la specifica → guarda il codice cambiare) il risultato era peggiore di quanto avrebbe scritto a mano e continuava a degradare a ogni iterazione successiva, accumulando entropia e degradando la test suite da cui l'agente stesso dipende per i propri cicli di feedback (vedi Leading Words e Fondamentali del Software). ²
• Replica alla critica "questo è Waterfall" e prototipazione aggressiva: a chi obietta che generare specifiche e mappe prima di implementare (con skill come to-spec e wayfinder, vedi AI Skills e Grill-Me) sia un ritorno al Waterfall degli anni '70, Gergely Orosz e Pocock oppongono due argomenti: ²
• La precisazione di Grady Booch sui mini-waterfall: come ricordato da Booch, il problema storico del Waterfall non è mai stato pianificare su cicli brevi di una settimana o di un mese — le grandi aziende tech (Amazon, Microsoft, Google, Meta) fanno da sempre dei mini-waterfall (pianifica → accordati → costruisci → rilascia in 2-12 settimane) — bensì pianificare per un anno intero e implementare per tre anni, scoprendo quattro anni dopo di aver costruito la cosa sbagliata. ²
• Prototipare 3-4 versioni prima della specifica: poiché gli agenti permettono di sfornare codice usa-e-getta (slop) a costo quasi zero, prima di cristallizzare una specifica Pocock pratica una prototipazione aggressiva upfront, facendo generare 3 o 4 versioni diverse per capire come dovrebbe apparire la soluzione, scegliendo la migliore e iterando — un lusso che prima dell'AI era troppo costoso. ²
• La regola operativa di Pocock (quando fare grill e quando allinearsi dopo): non bisogna usare la pianificazione upfront per tutto. Si usa grill-me (o wayfinder su più sessioni) per i lavori grandi e difficili da disfare, in cui se l'agente imbocca la strada sbagliata il codice errato inquina la finestra di contesto e riallineare a posteriori diventa costosissimo; per le modifiche piccole e facilmente reversibili (un bug fix di cinque righe o spostare un bottone di tre pixel) conviene invece fare shift right e allinearsi a posteriori direttamente sul codice prodotto e revisionato da un agente di review. ²

Il controcanto: spec testata, non waterfall (2026)

L'Elephant-Goldfish Model (EGM) di Dave Rensin si distingue radicalmente dallo spec-driven development criticato qui sopra: EGM non pianifica a lungo in anticipo e non produce codice rigenerandolo alla cieca da una specifica persistente. ³

• Dall'interrogatorio al test a memoria zero: in EGM la specifica viene scritta a valle di un grilling serrato (la sessione Elefante con regola "No Code", sfida alla spirale adulatoria e prima proposta tecnica chiesta al modello), viene poi messa alla prova da sessioni nuove a memoria zero (Pesce Rosso) su tre livelli — test di comprensione (se un agente privo di contesto non sa spiegare il sistema leggendo solo il doc e i file che referenzia, il documento è incompleto), critica tecnica (~30% di rilievi ad alto valore fino a esaurire i nit pick) e prontezza all'implementazione — passa per la revisione umana e solo dopo genera codice su guardrail stretti che elencano ogni singolo file creato o modificato e le alternative scartate. ³
• Cambia il ruolo del documento: la critica di Beck e Booch al Waterfall resta pienamente valida (nessuno pianifica per un anno intero), ma in EGM il design document non è l'input opaco di un generatore one-shot, bensì un test di comprensione e il luogo in cui i giudizi di design si spostano a sinistra (Design come Nuovo Codice) prima che il codice diventi opaco, permettendo inoltre di ripartire in 30 secondi dopo un crash senza affogare il progetto nello slop. ³

La spec minima di Fowler (2025)

Interrogato sullo spec-driven development (esplorato in Thoughtworks anche dalla collega Birgitta), Martin Fowler distingue nettamente tra la deriva in stile Waterfall e l'uso delle specifiche dentro cicli di feedback strettissimi: ⁴

• Il déjà-vu del Waterfall: la somiglianza con il Waterfall si manifesta quando si cerca di creare una grande quantità di specifica in anticipo prestando poca attenzione al codice. ⁴
• La regola della specifica più piccola possibile: per evitare la trappola del Waterfall non bisogna costruire l'intera specifica prima, ma scrivere la quantità più piccola possibile di specifica che consenta di fare un passo avanti, e poi ciclare immediatamente con quella — costruirla, testarla, portarla in produzione se possibile — procedendo per slice sottili. Che lo si chiami o meno spec-driven development, ciò che conta davvero sono i loop stretti (tight loops) e le slice sottili, con l'umano sempre nel loop a verificare ogni singolo passo (punto su cui anche Birgitta concorda pienamente). ⁴
• La specifica come luogo per linguaggi rigorosi e ubiquitous language: l'aspetto davvero promettente dello spec-driven development si ricollega alla co-costruzione di astrazioni con l'LLM (come sperimentato da Unmesh Joshi, vedi Non Determinismo del Software) e ai Domain-Specific Languages (DSL): usare l'LLM per esprimere astrazioni in una forma leggermente più fluida e flessibile rispetto al solo codice, senza però mai farle divergere dal codebase. L'obiettivo resta preservare l'ubiquitous language (vedi Leading Words e Fondamentali del Software): avere nella testa e nella specifica gli stessi nomi e una struttura chiaramente parallela a quella del codice, sfumando il confine tra specifica e implementazione in modo che anche gli esperti di dominio non programmatori possano leggere la logica di business e segnalare cosa c'è di sbagliato. ⁴

Vedi anche: Kent Beck, Martin Fowler, Matt Pocock, Dave Rensin, Slice Sottili e Ciclo di Feedback, Non Determinismo del Software, Elephant-Goldfish Model, Design come Nuovo Codice, AI Skills e Grill-Me, Leading Words e Fondamentali del Software, Programmazione Strategica, Osservabilità e Ruolo del Giardiniere, Apprendimento e Opzionalità nel Software, Harness Engineering, Shift Left Security, Reimplementazione del software via LLM, Checking vs Testing, Agentic Testing, Coding Agent, Agentic Harness, Plausibilità vs Validità Logica

Fonti e Riferimenti