Davvero il Software 3.0 sta distruggendo il codice tradizionale (e cosa fare ora)?

Il settore dello sviluppo software sta vivendo una trasformazione radicale. Dopo oltre settant’anni di evoluzione lineare, negli ultimi anni abbiamo assistito a due discontinuità profonde che stanno ridefinendo non solo il modo in cui il software viene scritto, ma anche la natura stessa di ciò che consideriamo “software”. Oggi siamo testimoni della nascita di una nuova era: quella del  Software 3.0. Questa fase è caratterizzata dalla centralità dei Large Language Models (LLM), da una programmazione in linguaggio naturale e da sistemi parzialmente autonomi in grado di agire come nuovi tipi di computer.

A parlarci del nuovo trend innescatosi con la presentazione dei primi moderni modelli generativi è Andrej Karpathy, informatico slovacco-canadese, membro fondatore di OpenAI nel 2015, uno dei massimi esperti mondiali di deep learning, computer vision e intelligenza artificiale, inserito tra i “35 Innovators Under 35” dal MIT Technology Review nel 2020.

Di seguito riassumiamo l’intervento di Karpathy durante Y Combinator AI Startup School 2025, aggiungendo qualche commento e considerazione.

Software 1.0, 2.0 e 3.0: una tassonomia evolutiva

Karpathy ha fatto uso del termine Software 1.0 per riferirsi al codice tradizionale. Si tratta del codice di programmazione di tipo deterministico, scritto a mano in linguaggi come C++, Python o Java. Ogni comportamento del sistema è esplicitamente codificato dallo sviluppatore.

Introdotto con la diffusione del deep learning, il Software 2.0 è invece basato su modelli addestrati, in cui la logica di funzionamento non è codificata direttamente, ma derivata dall’ottimizzazione su grandi dataset. Il codice, in questo caso, scaturisce dai pesi dei modelli neurali.

Esempi includono i riconoscitori di immagini come AlexNet. Karpathy osserva come, nell’ambito di progetti complessi come l’Autopilot di Tesla, il Software 2.0 abbia progressivamente “divorato” lo stack del Software 1.0, con la migrazione di funzionalità originariamente scritte in C++ verso l’uso di reti neurali. Hugging Face è emerso come l’equivalente di GitHub per il Software 2.0, fornendo un archivio di modelli pre-addestrati.

Il Software 3.0 introduce una nuova forma di calcolo: sistemi programmabili usando il linguaggio naturale. I LLM non sono ormai soltanto dei modelli, ma veri e propri runtime intelligenti, dotati di memoria (finestra di contesto), capacità di orchestrazione e interfacce umane.

Con gli LLM, i “prompt” in linguaggio naturale diventano i programmi che istruiscono il modello: l’aspetto più sorprendente è che ora si programmano i computer in linguaggio naturale, rendendo la programmazione accessibile a un pubblico molto più ampio.

I LLM come nuovi sistemi operativi

Secondo Karpathy, i modelli linguistici di nuova generazione stanno assumendo il ruolo che un tempo era dei sistemi operativi. Le analogie sono molteplici e, anche se a qualcuno potrebbero far storcere la bocca, l’informatico e fisico motiva la sua tesi con dovizia di particolari.

L’ecosistema si sta modellando in modo simile ai sistemi operativi tradizionali, con prodotti closed-source (come Windows/macOS) e alternative open source (come l’ecosistema Llama per gli LLM). Karpathy paragona gli LLM alla CPU, le “finestre di contesto” (context window) alla memoria, con il modello che orchestra memoria e calcolo per la risoluzione dei problemi. Si possono eseguire app LLM (come Cursor) su diversi LLM sottostanti (GPT, Claude, Gemini) in modo simile a come un’applicazione è eseguita su Windows, Linux o macOS.

Siamo ancora in un’era che Karpathy paragona agli anni ’60 dell’informatica: il calcolo degli LLM è costoso e centralizzato nel cloud, con i nostri sistemi che agiscono come “thin clients” attraverso la rete Internet. La rivoluzione del personal computing per gli LLM deve ancora arrivare. Interagire direttamente con un LLM tramite testo è come usare un sistema operativo tramite terminale; un’interfaccia grafica (GUI) generale per gli LLM non è ancora stata inventata.

Un aspetto unico degli LLM è che ribaltano la direzione usuale della diffusione tecnologica. Tipicamente, nuove tecnologie trasformative (elettricità, crittografia, volo) sono state adottate prima da governi e grandi aziende, e solo in seguito dai consumatori. Con gli LLM, invece, i consumatori sono i primi ad adottare la tecnologia per compiti quotidiani (es. “come bollire un uovo”), mentre governi e aziende sono in ritardo nell’adozione.

LLM: superpoteri e deficit cognitivi

Essendo addestrati su un vasto corpus di testo umano, i LLM sviluppano un “comportamento emergente” che è simile a quello umano, sostiene Karpathy. Tra i loro “superpoteri” vi sono una conoscenza enciclopedica e una memoria sovrumana, capaci di ricordare molte più informazioni di qualsiasi singolo individuo.

Tuttavia, i LLM presentano “deficit cognitivi”:

• Allucinazioni: Tendono a inventare informazioni e non hanno un modello interno sufficientemente robusto della conoscenza di sé.
• Intelligenza irregolare (Jagged Intelligence): Possono essere “sovrumani” in alcuni domini di risoluzione dei problemi, ma commettere errori basilari che nessun essere umano farebbe (ad esempio insistere che 9.11 > 9.9).
• Amnesia anterograda: A differenza degli esseri umani che consolidano la conoscenza e sviluppano esperienza nel tempo, i LLM non lo fanno nativamente. Le “finestre di contesto” sono come la memoria di lavoro, e devono essere programmate esplicitamente.
• Vulnerabilità: I LLM sono “creduloni”, suscettibili a rischi di “prompt injection” e possono far trapelare dati.

La sfida è imparare a programmare questi sistemi fallibili, aggirando i loro deficit e sfruttando i loro poteri sovrumani.

Le opportunità: applicazioni ad autonomia parziale e la sfida dell’interfaccia

Karpathy evidenzia che invece di interagire direttamente con il LLM (l’equivalente di andare direttamente al “sistema operativo”), ha molto più senso utilizzare un’applicazione dedicata. Cursor (per la codifica) e Perplexity (per la ricerca) sono esempi di successo.

Queste applicazioni condividono diverse proprietà cruciali:

• Gestione del contesto: I LLM gestiscono gran parte del contesto, come i file del progetto in Cursor.
• Orchestrazione di chiamate multiple agli LLM: Sotto il cofano, orchestrano diversi modelli.
• GUI specifica dell’applicazione: Un’interfaccia grafica è fondamentale per l’audit umano del lavoro di questi sistemi fallibili e per accelerare il flusso di lavoro. Parlando di codice di programmazione è più facile visualizzare le modifiche se sono evidenziate con dei colori (ad esempio rosso/verde).
• Autonomy Slider: Le app citate da Karpathy offrono un “cursore dell’autonomia“, permettendo all’utente di regolare il livello di autonomia concesso all’AI. Ad esempio, in Cursor si può scegliere tra completamento automatico (tasto TAB), modifica di un blocco di codice (CTRL+K), modifica di un intero file (CTRL+L) o autonomia completa sull’intero repository (CTRL+I). Allo stesso modo, Perplexity offre livelli di ricerca rapida, ricerca standard o ricerca approfondita.

Vibe Coding e programmazione naturale

La capacità di programmare in linguaggio naturale ha un impatto profondo: tutti sono implicitamente dei programmatori. Non domani, già oggi.

Karpathy introduce il concetto di “vibe coding“, una programmazione fluida e intuitiva che permette di creare prodotti personalizzati senza la necessità di anni di studio di linguaggi formali.

L’informatico sottolinea tuttavia che mentre la programmazione con il “vibe coding” della funzionalità è generalmente rapido (poche ore), per rendere l’app “reale” è necessario gestire cose come l’autenticazione, i pagamenti, il deployment. Queste operazioni possono richiedere molto più tempo ma non sono ricollegabili alla programmazione in senso stretto. Sono piuttosto attività DevOps. E ciò evidenzia che gran parte dell’infrastruttura software esistente non è progettata per essere utilizzata direttamente dagli agenti AI.

L’era degli agenti AI: una nuova infrastruttura digitale

Karpathy conclude sottolineando la necessità di adeguare gli attuali sistemi informatici alle abilità degli agenti AI, riconoscendo che sono una nuova categoria “consumatori” delle informazioni digitali. Andando sul concreto, l’informatico ex OpenAI, ex Tesla mette sul tavolo diverse possibili interventi:

• Utilizzo di un file llms.txt sul Web. Simile robots.txt, fornisce istruzioni dirette ai LLM su come comportarsi all’interno di un dominio, molto più leggibile di un HTML complesso.
• Documentazione per LLM. Gran parte della documentazione attuale è scritta per gli umani (liste, grassetto, immagini). Servizi come Vercel e Stripe stanno già adattando la loro documentazione al formato Markdown, facile da comprendere per i LLM. Inoltre, istruzioni come “clicca qui” devono essere sostituite con equivalenti comandi curl che un agente LLM può eseguire.
• Strumenti per l’accessibilità dei dati. Karpathy cita meccanismi già esistenti come “get.ingest” (che converte un repository GitHub in un unico testo strutturato) e Deep Wiki (che genera documentazione per repository) come esempi di tool che rendono i dati facilmente accessibili e “digeribili” dai LLM.

Anche se in futuro i LLM potrebbero essere in grado di “cliccare” autonomamente, Karpathy sostiene che vale la pena “incontrare a metà strada” gli LLM, rendendo l’accesso alle informazioni più semplice e meno costoso.

Tre strade per il futuro del software: Karpathy, Lamport e Kernighan a confronto

Nel dibattito sull’evoluzione della programmazione, le visioni di Andrej Karpathy, Leslie Lamport e Brian Kernighan tracciano percorsi distinti, spesso percepiti come antitetici ma in realtà complementari nel definire i confini della programmazione moderna.

Karpathy, con la sua idea di Software 3.0, propone una rottura concettuale: il codice come lo conosciamo non è più al centro dell’attività ingegneristica. Al suo posto, entrano in gioco modelli linguistici programmabili in linguaggio naturale, interfacce neurali e strumenti di orchestrazione semi-autonoma. Qui, il programmatore non è più colui che scrive ogni riga, ma chi dialoga con un’intelligenza artificiale, la guida, la verifica e la affina.

Questa visione entra in tensione con la posizione di Leslie Lamport, secondo cui “scrivere codice non è programmare“. Per Lamport, la progettazione formale, la logica e la precisione nella modellazione dei sistemi sono fondamentali e non possono essere sostituite da prompt in linguaggio naturale. Il rischio, secondo lui, è costruire sistemi opachi e fragili, difficili da verificare, soprattutto in ambiti dove l’affidabilità è critica. Karpathy, al contrario, scommette sul fatto che i LLM possano diventare runtime affidabili, purché guidati e contenuti tramite GUI, strutture di audit e strategie di progettazione nuove.

Brian Kernighan si colloca su un altro piano: pragmatico, radicato nell’esperienza, sostiene che gli LLM siano validi strumenti di supporto, ma la competenza nel codice resta centrale. Per lui, la programmazione tradizionale è viva, anche se affiancata da assistenti intelligenti. A differenza di Karpathy, non vede nel linguaggio naturale un sostituto del codice, ma un potenziamento dell’attività umana, che però richiede sempre il controllo dell’esperto.

In definitiva, Karpathy guarda avanti con ottimismo verso un futuro prompt-driven, Lamport richiama all’importanza del pensiero formale, mentre Kernighan tiene saldo il legame con la concretezza della programmazione tradizionale.