Leading Words e Fondamentali del Software

Tesi formulata da Matt Pocock (e al centro del suo talk Software Fundamentals Still Matter a AI Engineer London, aprile 2026): anziché buttare via i principi dell'ingegneria del software tradizionale, lavorare con i Coding Agent rende i fondamentali scritti 20-30 anni fa ancora più decisivi, sia perché sono già codificati nei priors di addestramento dei modelli (attivabili tramite leading words), sia perché gli agenti non possiedono memoria a lungo termine tra le sessioni (Memento-driven development). ¹

Il punto di partenza: lo spec-driven development e l'entropia del software

Inizialmente anche Pocock aveva creduto alla narrativa "zero priors" secondo cui l'AI cambiava tutto e bisognava buttare via le pratiche passate. ¹ Sperimentando lo spec-driven development puro — l'idea resa virale da Andrej Karpathy che "l'inglese è il nuovo linguaggio di programmazione", in cui si mantiene una specifica persistente e a ogni modifica si lascia rigenerare il codice all'agente senza guardarlo — osserva però che a ogni iterazione il codice diventava peggiore, producendo risultati inferiori alla scrittura manuale e degradando i cicli di feedback (una test suite scadente dà segnali scadenti all'agente tanto quanto a un umano). ¹

Cercando una via d'uscita, apre una copia di The Pragmatic Programmer (comprata anni prima e rimasta ancora incelofanata sullo scaffale) e si imbatte nel capitolo sull'entropia del software (software entropy, la tendenza naturale dei sistemi a scivolare verso il disordine): la diagnosi immediata è che gli agenti producono entropia del software a un ritmo più alto di chiunque altro nella storia. ¹

Cosa sono le leading words e perché funzionano

Continuando a leggere The Pragmatic Programmer — pubblicato 25 anni fa — Pocock realizza che quei concetti fanno parte dei priors del modello (i dati di addestramento degli LLM includono tutta la letteratura classica di software engineering e le discussioni che la citano). ¹

Nasce così la tecnica delle leading words (che Pocock paragona a un Leitwort, termine letterario per una parola-guida ripetuta): basta ripetere un paio di volte nel prompt o in una skill un termine tecnico denso della letteratura di software engineering perché il modello inizi a ripeterlo nelle proprie tracce di ragionamento (reasoning traces) e cambi radicalmente comportamento. ¹ È lo stesso meccanismo del gergo professionale (jargon) tra specialisti umani: una singola parola compatta richiama un intero grafo di vincoli, pratiche ed errori da evitare senza doverli rispiegare da zero. ¹

I concetti attivati dai classici

Scavando nei libri fondamentali per estrarne leading words, Pocock integra nelle proprie skill tre filoni principali: ¹

1. Tracer bullets e vertical slices vs horizontal slices (The Pragmatic Programmer): lasciati a sé stessi (anche dentro un Ralph loop), gli agenti tendono a costruire per slice orizzontali — prima l'intero layer del database, poi l'intero application layer, poi tutta la libreria di componenti React — collegando i pezzi solo alla fine, quando ormai è troppo tardi per scoprire che le scelte sul database non funzionano con ciò che serve sul frontend. Inserire le leading words tracer bullets (proiettili traccianti che attraversano subito tutti gli strati lasciando una traccia funzionante end-to-end) e vertical slices (insieme a massime come don't outrun your headlights, programming by coincidence e il lavorare sempre dentro i propri feedback loops) costringe l'agente a integrare subito un percorso completo e ottenere feedback immediato. ¹
2. Deep modules (A Philosophy of Software Design di John Ousterhout): moduli con un'interfaccia semplice ma un'implementazione profonda che nasconde la complessità interna, usati come leading word per guidare la decomposizione architetturale dell'agente. ¹
3. Ubiquitous language e grill with docs (Domain-Driven Design di Eric Evans): per combattere la verbosità estrema dei modelli (come Opus) e la barriera comunicativa sul dominio applicativo, Pocock estende grill-me nella skill grill with docs (affiancata da una skill di domain modeling), che costruisce un linguaggio ubiquo di dominio durante la fase stessa di ideazione. ¹
4. L'esempio della "materialization cascade": in un'app di corsi di Pocock esistevano "ghost lessons" dentro "ghost sections" dentro "ghost courses"; quando una lezione fantasma veniva trasformata in lezione reale, dovevano diventare reali a cascata anche la sezione e il corso. Invece di rispiegare ogni volta l'interazione in tre frasi, agente e sviluppatore hanno coniato insieme il termine materialization cascade: incorporato sia nelle conversazioni sia nei nomi delle funzioni nel codice, permette all'agente di navigare il codebase e trovare i punti giusti con un semplice grep (un ritorno diretto a quando Kent Beck e Ward Cunningham tenevano un dizionario dei sinonimi sulla scrivania per dare i nomi giusti al codice). ¹

Memento-driven development: ottimizzare per un nuovo arrivato permanente

Perché i fondamentali dell'ingegneria del software diventano più importanti con l'AI anziché meno? Pocock conia la metafora del Memento-driven development (dal protagonista del film Memento): ¹

• L'agente si sveglia ogni mattina senza ricordare chi è: un essere umano può sopravvivere e lavorare anche dentro un codebase pessimo perché con il tempo sviluppa memoria (sbatte la testa contro il muro finché non impara a memoria le trappole del sistema). Un agente invece riparte da zero a ogni singola sessione, vedendo il codebase per la prima volta a ogni run. ¹
• Ottimizzare per l'onboarding continuo: lavorare con gli agenti significa ottimizzare costantemente il codebase per un new starter perpetuo — esattamente ciò che i fondamentali del software predicavano da decenni, ma che gli umani potevano permettersi di trascurare compensando con la memoria. ¹

Sul Test-Driven Development (TDD) Pocock mantiene invece una posizione sfumata: il TDD classico ottimizza per la piccola memoria di lavoro umana (lasciare un test rosso prima della pausa caffè per ricordarsi dove si era rimasti), mentre gli agenti hanno una working memory molto più ampia; tuttavia gli agenti hanno un bisogno vitale di feedback loop e tendono a barare scrivendo test tautologici (che asseriscono l'implementazione stessa o una costante). Chiedere all'agente una "TDD evidence" — la prova che il test fallisce prima della modifica e passa dopo — resta quindi uno strumento prezioso per impedirgli di imbrogliare. ¹

I tre libri consigliati

In chiusura del podcast, Pocock sintetizza la propria "grande triade" di letture essenziali per lavorare con gli agenti: ¹

1. The Pragmatic Programmer (Andy Hunt, Dave Thomas)² — per l'entropia del software, i tracer bullets e i cicli di feedback. ¹
2. A Philosophy of Software Design (John Ousterhout) — per i deep modules e la distinzione tra programmazione tattica e strategica (vedi Programmazione Strategica, Osservabilità e Ruolo del Giardiniere). ¹
3. I primi tre capitoli di Domain-Driven Design (Eric Evans) — specificamente per i concetti di ubiquitous language e domain modeling (mentre Pocock dichiara di apprezzare meno la parte successiva su come codificarli rigidamente nelle strutture del codice). ¹

Vedi anche: Apprendimento e Opzionalità nel Software, Matt Pocock, AI Skills e Grill-Me, Programmazione Strategica, Osservabilità e Ruolo del Giardiniere, Spec-Driven Development e Dark Factory Agentica, Kent Beck, Harness Engineering

Fonti e Riferimenti