Software 3.0: il modello mentale di Karpathy per builder AI

Andrej Karpathy, ex direttore AI di Tesla, sostiene una tesi semplice e scomoda: il software sta cambiando di nuovo, e stavolta il salto porta un nome, Software 3.0. Per circa settant'anni il modo di scrivere codice è rimasto sostanzialmente lo stesso. Negli ultimi anni invece è cambiato due volte in rapida successione, lasciando aperta una quantità enorme di codice da scrivere e riscrivere. Per chi costruisce oggi questo significa una cosa precisa: il momento è raro e fertile per chi vuole entrare, perché le fondamenta sono in movimento.

I tre paradigmi: Software 1.0, 2.0 e 3.0

Karpathy distingue tre modi di programmare un computer. Il Software 1.0 è il codice tradizionale, scritto a mano per istruire la macchina. Il Software 2.0 sono i pesi delle reti neurali: qui non si scrive il codice direttamente, si curano i dataset e si lascia lavorare un ottimizzatore che produce i parametri della rete. Hugging Face, in questa lettura, diventa l'equivalente di GitHub per il Software 2.0. Il Software 3.0 è la novità che cambia tutto: gli LLM sono reti neurali diventate programmabili, e si programmano con prompt scritti in inglese. Il prompt è il nuovo programma, e il linguaggio di programmazione è la lingua naturale. I tre paradigmi convivono, e secondo Karpathy conviene padroneggiarli tutti, decidendo di volta in volta se una funzionalità va affrontata con codice esplicito, con una rete addestrata o con un LLM da interrogare. Lo stesso fenomeno visto in Tesla, dove le reti neurali avevano progressivamente "mangiato" porzioni intere di codice C++ dell'autopilot, ora si ripete su tutto lo stack.

L'LLM come nuovo sistema operativo

La parte più utile del talk è il modello mentale con cui leggere questi sistemi. Karpathy prova diverse analogie. Gli LLM hanno proprietà da utility: i laboratori spendono capitale per addestrarli (come si costruisce una rete elettrica) e poi servono l'intelligenza via API a consumo, mentre noi pretendiamo bassa latenza, qualità costante e continuità di servizio. Quando i modelli vanno giù, osserva, è come un blackout dell'intelligenza, e il pianeta diventa di colpo un po' più stupido. Hanno anche proprietà da fab, per il capitale e i segreti di ricerca concentrati nei laboratori. L'analogia più solida resta quella del sistema operativo: l'LLM è la CPU, il context window è la memoria, il modello orchestra calcolo e capacità per risolvere problemi. Scarichi un'app e la fai girare su sistemi diversi, e un'app come Cursor gira su modelli diversi con un semplice menu a tendina. Karpathy aggiunge che siamo in una fase paragonabile agli anni Sessanta dell'informatica: il calcolo è ancora costoso, quindi tutto è centralizzato nel cloud in time-sharing e la rivoluzione del personal computing per gli LLM non è ancora arrivata.

People spirits: psicologia e limiti dei modelli

Prima di usarli bene, conviene capire cosa sono. Karpathy li descrive come "people spirits": simulazioni statistiche di persone, prodotte da un transformer addestrato su tutto il testo disponibile. Da qui una psicologia stranamente umana. Hanno memoria enciclopedica, ricordano molto più di qualsiasi singola persona. Ma soffrono di deficit cognitivi precisi: allucinano, hanno una conoscenza di sé imperfetta, mostrano un'intelligenza a denti di sega (sovrumana in alcuni compiti, capace di errori che nessuno commetterebbe in altri). Soprattutto, hanno una sorta di amnesia: non consolidano l'esperienza come farebbe un nuovo collega che impara l'azienda nel tempo. Il context window è la loro memoria di lavoro, e va programmato direttamente ogni volta. A questo si aggiungono i rischi di sicurezza: suscettibilità al prompt injection e possibile fuga di dati. La conseguenza pratica è chiara: vanno usati sfruttando i superpoteri e progettando attorno ai loro difetti.

Autonomy slider e Iron Man suit: come costruire i prodotti

Da qui nascono le opportunità concrete per chi costruisce. Karpathy parla di app con autonomia parziale, prendendo come esempi Cursor per il codice e Perplexity per la ricerca. Hanno tratti comuni utili: l'app gestisce il context window, orchestra più chiamate a modelli diversi, offre una GUI dedicata e soprattutto un autonomy slider, una leva con cui chi lo usa decide quanta autonomia concedere a seconda della complessità del compito. Il punto centrale è il ciclo generazione-verifica: l'AI genera, l'umano verifica, e conviene rendere questo ciclo il più rapido possibile. Per farlo servono due cose. Accelerare la verifica, perché una GUI sfrutta la visione e rende la revisione del lavoro rapida e quasi piacevole, mentre leggere il testo è faticoso. E tenere l'AI al guinzaglio: ricevere un diff da diecimila righe non aiuta, perché l'umano resta il collo di bottiglia e deve comunque controllare bug e sicurezza. Da qui la metafora dell'Iron Man suit: oggi, con modelli ancora fallibili, conviene costruire tute che aumentano l'umano più che robot pienamente autonomi, lasciando lo slider scorrere verso più autonomia nel tempo. La lezione di Tesla rafforza il punto: il primo viaggio su un'auto a guida autonoma risale al 2013, eppure dodici anni dopo la guida autonoma non è ancora un problema risolto. Per questo Karpathy diffida di chi parla di "anno degli agent" e preferisce parlare di decennio.

Vibe coding e costruire per gli agent

L'ultima parte allarga il campo. Poiché si programma in inglese, chiunque sa programmare: è la premessa del vibe coding, termine che lo stesso Karpathy ha reso popolare quasi per caso. Costruire qualcosa di molto specifico in un pomeriggio è diventato possibile, ma raccontando la genesi di una sua piccola app racconta anche il limite: la parte di codice è la più facile, mentre rendere reale il prodotto (autenticazione, pagamenti, dominio, deploy) resta lento e fatto di clic manuali nel browser. Da qui la domanda finale: possiamo costruire direttamente per gli agent? Compare un nuovo tipo di consumatore ed elaboratore di informazione digitale, accanto agli umani con le GUI e ai computer con le API. Per servirlo, Karpathy indica direzioni concrete: documentazione in markdown invece che in HTML pieno di liste e immagini, file come llms.txt che spiegano in modo leggibile cosa fa un dominio, la sostituzione dei "clicca qui" con comandi che un agent può eseguire (Vercel e Stripe come primi a muoversi), il protocollo MCP di Anthropic, e piccoli strumenti che rendono ingeribili i contenuti, come gitingest o DeepWiki per i repository.

Per chi costruisce oggi, il valore del talk non sta nelle previsioni ma nella postura. La parte difficile non è far funzionare una demo, è renderla un prodotto affidabile e verificabile. Tre cose da tenere a mente: scegliere bene tra i paradigmi, progettare il ciclo generazione-verifica come il cuore del prodotto, dare a chi usa il sistema una leva di autonomia invece di promettere magia. Zero hype sull'automazione totale, più lavoro paziente su strumenti che aumentano davvero chi li usa.