Tremila sviluppatori hanno riempito una conferenza a San Francisco per sentirsi dire che il loro mestiere sta diventando qualcosa d’altro, e sono usciti entusiasti. Questo dice qualcosa sul momento del futuro sviluppo software, e sulla differenza tra cambiamento reale e narrativa ben confezionata.

La conferenza era AI Dev 26 x SF, organizzata da DeepLearning.AI di Andrew Ng con oltre 3.000 partecipanti. Il messaggio centrale era uno: il collo di bottiglia nello sviluppo software non è più scrivere codice. È la nostra capacità di immaginare cosa costruire. Gli agenti AI scrivono il 100% del codice. I team si riducono. I generalisti orchestrano.

È una tesi provocatoria. Su alcuni punti regge. Su altri nasconde qualcosa di scomodo che nessuno alla conferenza aveva interesse a nominare.

Il futuro sviluppo software secondo Andrew Ng: l’immaginazione come bottleneck

Jonathan Heyne, COO di DeepLearning.AI, ha detto che “il bottleneck è la nostra immaginazione”. L’affermazione funziona se intende che prima la limitazione era l’esecuzione tecnica. Ma il problema di priorità non sparisce quando deleghi l’implementazione agli agenti: si amplifica.

Adesso puoi costruire qualsiasi cosa in una frazione del tempo precedente. La tentazione di fare troppe cose, fare le cose sbagliate, accumulare complessità senza valore reale diventa proporzionalmente più forte. Decidere cosa costruire, in quale ordine, con quali trade-off, richiede contestualizzazione organizzativa e capacità di dire no a cose buone per fare cose migliori. Nessun agente AI risolve questo. Nessun modello linguistico decide per te quale feature conta davvero per il tuo business.

I team che usano già agenti per sviluppare più velocemente lo stanno scoprendo: il costo si è spostato dalla scrittura del codice alla revisione, al testing, al mantenimento a lungo termine. Il lavoro non sparisce. Si trasforma, spesso in forme meno prevedibili.

C’è anche un dettaglio che Thomas Claburn ha notato nel suo articolo su The Register: chi era scettico sulla direzione dell’AI nello sviluppo software probabilmente non era presente alla conferenza. I tremila partecipanti, in modo diretto o indiretto, guadagnano dal prevalere di quella narrativa. È un campione distorto per definizione.

Spec-driven development: il contributo che richiedeva più disciplina, non meno

Marc Brooker di AWS ha portato il contributo più operativo della giornata. La sua proposta: lo “spec-driven development”, dove le specifiche tecniche diventano la guida che i modelli AI seguono per generare codice verificabile e controllabile. L’attenzione si sposta dalla produzione di funzionalità alla riduzione sistematica dei difetti.

Questo inverte la logica del vibe coding. Invece di generare codice e sperare che funzioni, si scrive prima la specifica in modo preciso, poi si lascia al modello l’implementazione. Richiede più rigore tecnico, non meno: una specifica vaga produce codice imprevedibile, e il problema si scopre in produzione, non in sviluppo.

Ne ho scritto parlando del codice AI come debito di sicurezza: il problema centrale non è che l’AI scriva codice: è chi capisce quel codice quando va in produzione. Lo spec-driven development è uno dei pochi approcci che affronta questa domanda prima di crearla.

Nessuno degli altri panelist, tra cui rappresentanti di Oracle, Replit e LandingAI, ha portato proposte altrettanto operative. Le valutazioni ottimistiche sul futuro dello sviluppo software, tra 7 e 10 su una scala di dieci, erano lì. La discussione su cosa succederebbe quando quei sistemi falliscono non c’era.

Il take di TechMonk: tre cose che la conferenza non ha nominato

Chi risponde quando il codice crasha alle 3 di notte?

Andrew Ng immagina piccoli team di generalisti che supervisionano agenti che scrivono il 100% del codice. Il termine chiave è “supervisione”. Supervisionare codice che non hai scritto, in un sistema che non hai costruito, su specifiche che hai descritto ad alto livello, non è sviluppo software: è fiducia delegata a catena.

Quando quel sistema va giù in produzione, la differenza tra risolverlo in dieci minuti o in quattro ore dipende da chi capisce come funziona davvero. Un generalista che ha orchestrato agenti non ha quella comprensione, non perché sia meno capace, ma perché non è mai stato costretto ad acquisirla. La comprensione profonda di un sistema si costruisce scrivendo il sistema, facendo errori al suo interno, debuggando quelli di altri.

Il costo di questa lacuna è invisibile finché non si manifesta. E si manifesta sempre nel momento peggiore.

Il bottleneck è la priorità, e non scompare con l’AI

Un’architettura che produce codice molto più velocemente amplifica ogni errore di priorità. Il team che ieri non riusciva a costruire tutte le feature in roadmap adesso le costruisce in una settimana, e si ritrova con dieci volte la complessità da mantenere. La velocità di esecuzione senza miglior giudizio su cosa eseguire è un acceleratore di debito tecnico, non una riduzione.

Secondo il Developer Survey di Stack Overflow 2025, il 65% degli sviluppatori usa strumenti AI almeno ogni settimana. Ma la produttività percepita e quella reale divergono significativamente su progetti con timeline superiori a sei mesi. Più velocità di produzione, più complessità accumulata, più tempo speso a capire cosa il codice fa davvero.

Dire che “il bottleneck è l’immaginazione” è utile come slogan per una conferenza. Come mappa del problema, è incompleta: ignora il costo di tutto quello che immaginiamo in più.

Il mestiere che stiamo cedendo senza nominarlo

I tremila a San Francisco erano entusiasti. La conferenza presentava un futuro in cui il lavoro noioso sparisce e rimane solo quello creativo. Ma scrivere codice non era noioso per molti di loro. Era la parte che capivano meglio, che controllavano, che dava soddisfazione verificabile e immediata.

“Less development” non è una liberazione neutra. È la rimozione di una competenza che si costruisce in anni di pratica, che genera intuizione su cosa può andare storto, che crea sviluppatori con visione sistemica. Un developer che non scrive codice da due anni smette progressivamente di capire i suoi stessi sistemi. Diventa un interprete tra il business e la macchina, senza padronanza tecnica reale su nessuno dei due livelli.

Non è detto che questo sia un male nel lungo periodo del settore. Ma presentarlo come un’evoluzione puramente positiva, davanti a tremila persone a cui conviene credere che lo sia, non è onestà intellettuale.

La domanda non è se l’AI cambierà lo sviluppo software. È già cambiato. La domanda è se i team che smettono di scrivere codice continueranno a capire cosa stanno costruendo, o se se ne accorgeranno solo quando sarà troppo tardi per recuperare quella comprensione.