Slice Sottili e Ciclo di Feedback

Approccio metodologico allo sviluppo software assistito da LLM delineato da Martin Fowler (intervistato da The Pragmatic Engineer nel novembre 2025): mentre il vibe coding funziona per prototipi ed esplorazioni usa-e-getta ma distrugge il ciclo di apprendimento (learning loop), costruire software destinato a durare richiede di procedere per slice sottilissime e rapide, trattando ogni slice come la pull request di un "collaboratore losco" e usando l'AI per ridurre il cycle time e aumentare la frequenza dei feedback, non per accumulare batch più grandi. ¹

Lavorare per slice sottili con un "collaboratore losco"

Osservando i practitioner che cercano di costruire software di buona qualità lavorando uno a uno con un LLM — strumento che Kent Beck chiama "il genio" (the genie) e che la collega di Thoughtworks Birgitta soprannomina "Dusty, l'asino antropomorfo" (accanto alle sperimentazioni di figure come Steve Yegge) — Fowler individua una convergenza netta: ¹

• Slice molto sottili e rapide (very thin, rapid slices): il lavoro va spezzato in incrementi piccolissimi e veloci. ¹
• La PR del collaboratore losco (dodgy collaborator): bisogna trattare ogni singola slice come una pull request proveniente da un collaboratore piuttosto losco — estremamente produttivo se misurato nel senso grezzo delle righe di codice, ma di cui non ci si può fidare per nulla — sottoponendo quindi ogni output a una revisione attentissima e accompagnandolo sempre con test automatizzati (come insistono anche Simon Willison e Birgitta; vedi anche Flotta di Agenti per lo stesso problema affrontato su scala multi-agente). ¹
• Speedup reale ma non miracoloso, e il nodo dei team: lavorando con questa disciplina si ottiene un'accelerazione reale e non banale, anche se lontana dalle promesse iperboliche degli entusiasti. Resta invece ancora aperto sia come modificare in sicurezza i sistemi legacy (brownfield), sia come operare al meglio con l'AI in team — perché la domanda di software non accenna a calare e, anche nell'ipotesi (a cui Fowler non crede) di un guadagno di produttività di un ordine di grandezza, servirà comunque un team di 10 persone per costruire ciò che prima ne richiedeva 100. ¹

Il vibe coding elimina il ciclo di apprendimento (e l'aneddoto dell'SVG)

Fowler riporta il termine vibe coding alla sua definizione originaria: non guardare affatto il codice prodotto dall'LLM (se non per uno sguardo fugace di curiosità), disinteressarsi di come è fatto o non avere alcuna competenza di programmazione. ¹ Nel whitepaper Google The New SDLC With Vibe Coding (maggio 2026), Addy Osmani, Shubham Saboo e Sokratis Kartakis definiscono invece il vibe coding in modo più ampio lungo uno spettro metodologico: non soltanto il non leggere il codice, ma qualunque pratica priva di verifica strutturata tramite test deterministici ed evaluation (eval) non deterministiche, a prescindere dalla sofisticazione dei prompt (vedi Spettro Vibe Coding e Agentic Engineering). ²

Il vibe coding e l'uso esplorativo degli LLM sono preziosi entro confini ben precisi — tirare su un prototipo o esplorare un'idea in un paio di giorni, creare piccoli tool usa-e-getta (throwaways, anche da parte di non sviluppatori), generare lo scheletro iniziale di un progetto o imparare a muoversi in un ambiente sconosciuto (come James Lewis che esplora C e il game engine Godot su Mac, o Fowler che chiede un comando dimenticato in R), in modo analogo al copia-incolla da Stack Overflow dopo l'epoca a pagamento di Experts Exchange (inclusi i rischi di copiare risposte popolari ma errate, come accadde per la validazione delle email, oggi amplificati "sugli steroidi" e con l'interrogativo di chi scriverà più le risposte in futuro). Ma usare il vibe coding per qualcosa che debba vivere nel lungo periodo porta al disastro per due motivi: ¹

1. L'impossibilità di ritoccare il codice (l'aneddoto dell'SVG): lavorando con il collega Unmesh Joshi a un articolo pubblicato il giorno prima dell'intervista, Unmesh aveva chiesto all'LLM di generare uno pseudo-grafico illustrativo (curve di capacità nel tempo) e lo aveva committato nel repository. Volendo avvicinare leggermente le etichette alle linee, Fowler apre il file SVG prodotto dall'LLM — per un grafico simile che in precedenza aveva scritto a mano in una dozzina di righe di XML — e si trova davanti una struttura sbalorditivamente complicata, contorta e bizzarra, impossibile da ritoccare: con il codice vibe-coded non si può fare un piccolo aggiustamento, bisogna buttarlo via e sperare di rigenerarlo. ¹
2. La rimozione del learning loop: il punto cardine dell'articolo di Unmesh Joshi è che il vibe coding rimuove il ciclo di apprendimento. Gran parte dello sviluppo software consiste nel formulare idee e metterle alla prova sul computer in un continuo avanti e indietro tra ciò che fa la macchina e il nostro pensiero: gli LLM saltano a piè pari questo processo. Se non guardi l'output non impari, e quando non impari non sai come ritoccare, modificare, far evolvere e far crescere ciò che hai prodotto: l'unica opzione rimasta è "nuclearizzarlo dall'orbita e ricominciare da capo" (nuke it from orbit and start again, vedi Apprendimento e Opzionalità nel Software). ¹

La fatica delle code review e la specifica minima

Con l'adozione diffusa degli strumenti AI, la quantità di codice prodotto aumenta vertiginosamente e con essa il carico di code review: il rischio concreto (sperimentato dagli stessi ingegneri) è che a un certo punto subentri la stanchezza e si lasci correre (let it go) (vedi anche Visibilità della Flotta sulla necessità di vedere cosa fanno gli agenti e sul limite dell'attenzione umana nelle review). ¹

Per mantenere alta la vigilanza e continuare a imparare senza annegare nel codice generato, Fowler indica tre presidi: ¹

• Co-costruire un linguaggio rigoroso con l'LLM: seguire l'approccio di Unmesh Joshi creando insieme all'LLM un linguaggio specializzato per comunicargli in modo più preciso e controllato cosa si vuole ottenere (vedi Non Determinismo del Software). ¹
• Capire, rifattorizzare e testare: non c'è nulla di male nel provare uno snippet generato dall'LLM per vedere se funziona, ma subito dopo bisogna capire perché funziona, chiedersi se è strutturato come vorremmo, non aver paura di rifattorizzarlo e blindarlo con un test automatizzato. ¹
• La specifica minima contro il Waterfall: nello Spec-Driven Development, scrivere una specifica enorme senza guardare il codice equivale a ricadere nel Waterfall. La regola di Fowler (condivisa da Birgitta) è scrivere la quantità più piccola possibile di specifica che consenta un passo avanti, e poi ciclare subito con build, test e messa in produzione su slice sottili, con l'umano sempre nel loop a verificare ogni passo. ¹

L'eredità dell'Agile e il cycle time come leva nell'era AI

Ripensando alla nascita del Manifesto Agile nel 2001 (vedi Martin Fowler), Fowler ricorda che nel 2000 i clienti di Thoughtworks consideravano un anatema lavorare per piccoli incrementi con test e build automatizzate: la saggezza convenzionale imponeva piani quinquennali con due anni di design upfront, un anno di implementazione e il testing solo alla fine, mentre Thoughtworks implorava di fare l'intero ciclo su un sottoinsieme di requisiti in un mese (volendo in realtà farlo in una settimana). Il vero successo dell'Agile — pur rimasto un'"ombra pallida" di ciò che i 17 firmatari desideravano — è aver reso accettabile lavorare in modo incrementale anche nelle grandi enterprise. ¹

Di fronte all'AI e alla pressione per avere qualità fin da subito, Fowler ribadisce che la scommessa vincente resta la stessa: ¹

1. Slice più frequenti, non slice più grosse: l'AI deve permetterci di fare le slice più velocemente, non di stipare più cose dentro la stessa slice. I guadagni maggiori vengono sempre dall'aumentare la frequenza del ciclo: fare la metà delle cose nella metà del tempo. ¹
2. Tagliare le code e ridurre il cycle time: la leva principale resta migliorare costantemente il cycle time — guardare dove si formano le code (queues) nel proprio flusso e tagliarle per dimezzare il tempo che passa tra un'idea e il codice funzionante in produzione (da due settimane a una settimana, e così via; vedi anche Tirannia delle Metriche, Legge di Goodhart e Leadership). ¹
3. L'esempio dei 20 prototipi interattivi in due giorni: a dimostrazione di quanto si possano stringere i loop di feedback per accelerare l'apprendimento, nell'intervista viene citato Boris, uno dei creatori di Claude Code in Anthropic, che per progettare la progress bar dei task ha realizzato e provato 20 diversi prototipi interattivi funzionanti in soli due giorni (registrando in video prompt e output e raccogliendo feedback dai colleghi prima di scegliere quale direzione seguire), comprimendo in 48 ore un lavoro di esplorazione che in passato avrebbe richiesto una o due settimane anche solo per prototipi su carta. ¹

Vedi anche: Spec-Driven Development e Dark Factory Agentica, Martin Fowler, Tirannia delle Metriche, Legge di Goodhart e Leadership, Apprendimento e Opzionalità nel Software, Non Determinismo del Software, Refactoring nell'Era AI, Kent Beck

Fonti e Riferimenti