Matt Pocock sale sul palco con una domanda in tasca che brucia. Non è una domanda tecnica: è una domanda esistenziale per chiunque abbia passato anni a imparare a scrivere codice bene. Vale ancora qualcosa quello che so fare? La risposta che porta non è rassicurante nel senso banale del termine — non è "non preoccuparti, l'AI non ti sostituirà". È qualcosa di più preciso, e per questo più utile: le basi del software contano più adesso di quanto non abbiano mai contato prima. Non meno. Di più.
Il ragionamento parte da un'osservazione concreta. Negli ultimi anni è emerso un movimento chiamato specs to code: scrivi una specifica in linguaggio naturale, l'AI la trasforma in codice, se qualcosa va storto torni alla specifica e rilanci il compilatore. Il codice diventa un artefatto secondario, quasi un effetto collaterale. Non devi capirlo, non devi progettarlo — basta rigenerarlo.
Pocock ha provato. Come tutti. E ha visto quello che vedono tutti: la prima iterazione produce codice passabile, la seconda produce codice peggiore, la terza è già un disastro. Ogni lancio del compilatore degrada il sistema. Non è un bug del tool — è fisica del software. Il Pragmatic Programmer lo chiama software entropy: ogni modifica fatta senza pensare al design globale aumenta il disordine. L'AI, lasciata sola a gestire se stessa, accelera questo processo invece di fermarlo.
C'è uno slogan che circola nei circoli entusiasti dell'AI: code is cheap. Pocock lo smonta senza pietà. Il codice cattivo non è mai stato così costoso. Non perché scrivere codice costi fatica — l'AI lo genera a velocità industriale — ma perché una codebase difficile da modificare è una codebase che non riesce a sfruttare quello che l'AI offre. L'AI funziona bene in sistemi ben progettati. In sistemi caotici produce caos. La qualità del codice è diventata il moltiplicatore dell'intelligenza artificiale.
John Ousterhout, nel suo A Philosophy of Software Design, definisce la complessità del software come tutto ciò che rende un sistema difficile da capire e modificare. Una codebase cattiva è semplicemente una codebase difficile da cambiare. Una codebase buona è facile da cambiare. E una codebase facile da cambiare è quella in cui l'AI rende di più.
La struttura del talk di Pocock è pratica: sei failure mode ricorrenti, sei rimedi derivati dalla letteratura classica del software. Non sono trucchi. Sono fondamentali applicati a un contesto nuovo.
Il primo fallimento è il più comune: l'AI non fa quello che volevi. Hai in testa un'idea, le dai istruzioni, esce qualcosa di diverso. Frederick P. Brooks, nel Design of Design, chiama questo il problema del design concept: quando due persone costruiscono qualcosa insieme, esiste tra loro un'idea condivisa e invisibile di cosa si sta costruendo. Se quell'idea non è condivisa, il risultato diverge. Con l'AI il problema si amplifica perché lei non sa cosa non sa.
La soluzione di Pocock è una skill che ha chiamato Grill Me: un'istruzione che dice all'AI di intervistarti senza pietà su ogni aspetto del piano, esplorando ogni ramo dell'albero delle decisioni, finché non raggiunge una comprensione condivisa. Il risultato è che l'AI ti fa quaranta, sessanta, a volte cento domande prima di essere soddisfatta. Il documento che emerge — un PRD, una lista di issue — è radicalmente più preciso di qualsiasi specifica scritta a freddo.
Il secondo fallimento è la verbosità: l'AI usa troppi termini, parla una lingua diversa dalla tua, le traduzioni si perdono. Pocock trova il rimedio nel Domain-Driven Design e nel concetto di ubiquitous language: un vocabolario comune tra sviluppatori, esperti di dominio e intelligenza artificiale. Un file markdown con tutti i termini chiave del progetto, costruito scansionando la codebase e rendendolo esplicito.
Il terzo fallimento: l'AI costruisce la cosa giusta ma non funziona. Il problema non è l'AI in sé — è che l'AI, per default, fa troppo in una volta sola. Il Pragmatic Programmer chiama questo outrunning your headlights: guidare più veloci di quanto il buio ti permetta di vedere. La velocità del feedback è il tuo limite di velocità. La risposta è il TDD — test-driven development — perché forza l'AI a procedere a piccoli passi.
I failure mode quattro e cinque convergono sullo stesso punto: l'AI non riesce a navigare la codebase. Non perché sia stupida — ma perché la codebase è strutturata in modo da essere difficile da navigare per chiunque, umano o macchina.
Ousterhout distingue tra deep modules e shallow modules. Un modulo profondo nasconde molta complessità dietro un'interfaccia semplice. Un modulo superficiale espone poca funzionalità attraverso un'interfaccia complicata. Le codebase piene di moduli superficiali assomigliano a una nuvola di piccoli blob — l'AI li esplora, non capisce le dipendenze, produce codice che non si integra. Le codebase con moduli profondi hanno confini netti, interfacce chiare, implementazioni nascoste.
Il principio operativo è semplice: design the interface, delegate the implementation. Disegna tu l'interfaccia — quella è la parte strategica. L'implementazione interna, per i moduli non critici, puoi lasciarla all'AI. Lei è brava a riempire lo spazio definito da confini chiari.
Il sesto fallimento è meno tecnico ma altrettanto reale: il tuo cervello non regge il ritmo. Lavori più velocemente che mai ma esci dalle sessioni esaurito. La risposta è strutturale: i moduli profondi si comportano come gray boxes. Non devi capire come funzionano dentro — devi capire cosa fanno fuori. Questo risparmia il budget cognitivo che prima spendevi a tenere in testa ogni dettaglio implementativo.
Kent Beck ha scritto che bisogna investire nel design del sistema ogni giorno. Il movimento specs to code fa esattamente il contrario: disinveste nel design, lo delega, lo tratta come un costo da minimizzare.
L'AI è un ottimo programmatore tattico — il sergente sul campo che esegue le modifiche al codice. Ma qualcuno deve pensare a livello strategico: disegnare le interfacce, costruire il vocabolario condiviso, scegliere dove tracciare i confini tra i moduli, decidere cosa testare e come. Quel qualcuno sei tu. E farlo bene richiede esattamente le competenze accumulate negli ultimi vent'anni — Ousterhout, Brooks, il Pragmatic Programmer, Kent Beck. Non sono obsoleti. Sono più rilevanti che mai.
La promessa dell'AI non è che puoi smettere di capire il software. È che se capisci il software — davvero — puoi muoverti a una velocità che prima era impossibile. La qualità della codebase è il moltiplicatore. E i fondamentali sono il modo in cui costruisci quella qualità.