Karpathy Non Scrive Codice da Dicembre. 16 Ore al Giorno con gli Agenti.

Andrej Karpathy non scrive codice da dicembre. Non una riga. Non una funzione. Niente.

"I don't think I've typed like a line of code probably since December basically." Lo dice con la naturalezza di chi constata un fatto, non di chi lancia una provocazione. E Karpathy non e' un commentatore da Twitter. E' l'ex direttore AI di Tesla, co-fondatore di OpenAI, uno che ha costruito da zero l'infrastruttura di guida autonoma che muove milioni di veicoli.

Nell'intervista al podcast No Priors con Sarah Guo, registrata a marzo 2026, racconta cosa succede quando uno dei massimi esperti al mondo di deep learning si butta a tempo pieno nell'agent coding. E il quadro che emerge e' insieme esaltante e inquietante.

L'AI psychosis: 16 ore al giorno nella macchina

Karpathy non usa gli agenti AI come un tool in piu'. Li usa come metodo di lavoro esclusivo. E lo fa con un'intensita' che lui stesso definisce patologica.

"I kind of feel like I was just in this perpetual state of AI psychosis... there was a huge unlock in what you can achieve as a person as an individual."

Sedici ore al giorno. Non e' un numero buttato li' per effetto. E' il racconto di un ricercatore che ha capito che il suo output non e' piu' limitato da quante righe scrive, ma da quanti agenti riesce a orchestrare in parallelo. E il tempo per orchestrare agenti si dilata, perche' non c'e' fatica fisica. Non stai battendo sulla tastiera. Stai dirigendo.

Il parallelo che fa e' illuminante: prende Peter Steinberger come modello. Monitor pieno di agenti Codex, 20 minuti ciascuno, tutti in parallelo. Non e' piu' un developer che scrive codice. E' un direttore d'orchestra con strumenti che suonano da soli.

Il flip 80/20: da una riga di codice a macro actions

Fino a qualche mese fa, il rapporto era 80/20: l'80% del codice lo scriveva Karpathy, il 20% lo delegava agli agenti. Oggi e' invertito — 20/80, forse di piu'.

Ma il cambio non e' solo quantitativo. E' qualitativo. Il livello di astrazione a cui operi cambia radicalmente.

Non e' piu' "scrivi una funzione". E' "ecco una nuova funzionalita', delegala all'agente 1, questa all'agente 2, poi review". Karpathy le chiama "macro actions" — non dai istruzioni riga per riga, dai obiettivi di alto livello e lasci che l'agente si arrangi con l'implementazione.

E' lo stesso salto concettuale di cui abbiamo parlato nell'articolo sull'agentic engineering: non stai costruendo il software, stai costruendo la fabbrica che costruisce il software. Solo che adesso c'e' qualcuno che lo sta facendo per davvero, 16 ore al giorno, e ci racconta com'e'.

Skill issue: il nuovo collo di bottiglia sei tu

Questa e' forse la dichiarazione piu' scomoda dell'intera intervista.

"Everything feels like skill issue. It's not that the capability is not there. It's that you just haven't found a way to string it together... I didn't give good enough instructions in the agents MD file."

Leggila due volte. Karpathy sta dicendo che quando l'agente AI fallisce, il problema non e' l'agente. E' lui. E' il prompt. E' il file AGENTS.md. E' il contesto che gli hai dato. E' come hai strutturato il task.

Questo ribalta completamente la narrativa dominante. La maggior parte dei developer dice "l'AI non funziona" dopo averle chiesto qualcosa di vago e aver ottenuto un risultato mediocre. Karpathy dice: la capability c'e', sei tu che non sai usarla.

E' duro da accettare. Ma se ci pensi, e' anche la cosa piu' ottimistica che si possa dire. Perche' se il collo di bottiglia sei tu, allora puoi migliorare. Non devi aspettare il prossimo modello. Devi scrivere un AGENTS.md migliore.

Qui torna un concetto che abbiamo gia' esplorato: il context engineering non e' un accessorio. E' la competenza core. Sapere dare all'agente tutto cio' di cui ha bisogno per risolvere il problema — questo e' il lavoro adesso.

Auto Research: quando l'agente batte due decenni di esperienza

Il momento piu' sorprendente dell'intervista e' questo.

Karpathy ha lasciato girare un loop di auto-ricerca overnight sul suo repository personale di training di modelli. Un repo che conosce a memoria, costruito su due decenni di esperienza nel training di neural network. Un repo dove ogni decisione architetturale l'ha presa lui.

L'agente ha trovato ottimizzazioni che lui non vedeva.

"I forgot the weight decay on the value embeddings and my Adam betas were not sufficiently tuned."

Due decenni di esperienza nel training di modelli. Parametri che Karpathy — Karpathy — non aveva ottimizzato. E un agente AI, lasciato girare una notte, li ha trovati.

Il punto non e' che l'AI e' piu' brava di Karpathy. Il punto e' che l'AI non si stanca, non ha bias di conferma, non da' per scontato cio' che "ha sempre funzionato". Esplora lo spazio delle soluzioni senza le scorciatoie cognitive che due decenni di esperienza inevitabilmente creano.

E' un dato che dovrebbe far riflettere chiunque dica "conosco il mio codice meglio di qualsiasi AI". Probabilmente si'. Ma lo conosci anche troppo bene. E questo e' un limite, non solo un vantaggio.

La jaggedness: PhD brillante e bambino di 10 anni

Karpathy non e' un evangelista cieco. La sua descrizione dei modelli attuali e' tra le piu' oneste che abbia mai sentito.

"I simultaneously feel like I'm talking to an extremely brilliant PhD student who's been a systems programmer for their entire life and a 10-year-old."

Brillante e stupido nello stesso momento. Un PhD che sa scrivere codice systems-level impeccabile — e un bambino che non riesce a fare una barzelletta nuova. Letteralmente: chiedi una barzelletta a ChatGPT e ti da' la stessa da quattro anni.

Questa "jaggedness" — questa irregolarita' nelle capacita' — e' il motivo per cui lavorare con gli agenti AI non e' semplicemente "delega e vai". Devi sapere dove sono brillanti e dove sono stupidi. Devi compensare. Devi verificare.

Ed e' anche il motivo per cui i senior ne traggono piu' beneficio: hanno l'esperienza per riconoscere quando il PhD sta parlando e quando e' il bambino di 10 anni. Un junior non ha questo metro di giudizio. Ne abbiamo parlato a lungo nell'analisi sul deskilling — e i dati sono preoccupanti.

Token throughput: la nuova GPU utilization

C'e' un passaggio nell'intervista che rivela quanto profondamente Karpathy ha interiorizzato questo nuovo modo di lavorare.

"I feel nervous when I have subscription left over... that just means I haven't maximized my token throughput."

Subscription lasciata inutilizzata = token sprecati = lavoro non fatto. Lo paragona a come i dottorandi si sentivano in colpa per le GPU idle. Hai risorse computazionali a disposizione e non le stai usando? E' un problema.

E' un cambio di mindset radicale. Non pensi piu' in termini di "quante ore ho lavorato" o "quante righe ho scritto". Pensi in termini di token throughput. Quanti token hanno processato i miei agenti oggi? Quanti task hanno completato in parallelo? Qual e' il mio "GPU utilization"?

Per chi viene dal mondo del machine learning, la metafora e' perfetta. Per chi viene dallo sviluppo software tradizionale, e' aliena. Ma e' dove sta andando il mestiere.

Il program MD come organizzazione di ricerca

Forse il passaggio piu' visionario e' questo. Karpathy paragona i file Markdown di configurazione degli agenti a un'organizzazione di ricerca.

"A research organization is a set of markdown files that describe all the roles and how the whole thing connects."

Pensaci. Un'organizzazione di ricerca ha ruoli definiti, responsabilita', processi, interfacce tra team. Tutto questo puo' essere descritto in file Markdown. E se i file Markdown descrivono l'organizzazione, allora puoi ottimizzare l'organizzazione ottimizzando i Markdown.

Non e' una metafora. E' letteralmente quello che Karpathy fa. Ottimizza i suoi AGENTS.md come un engineering manager ottimizza i processi del suo team. Solo che il "team" sono agenti AI, e i "processi" sono prompt strutturati.

E si possono ottimizzare i markdown files stessi. Con gli agenti. Meta-ottimizzazione. L'agente migliora le istruzioni che lo guidano. E' ricorsivo, ed e' potentissimo.

Jevons Paradox: piu' software, non meno sviluppatori

Arriviamo alla domanda che tutti si fanno: se l'AI scrive il codice, servono ancora gli sviluppatori?

Karpathy risponde con un concetto economico del 1865: il paradosso di Jevons. Quando il carbone divenne piu' efficiente da usare, il consumo di carbone non calo'. Esplose. La maggiore efficienza creo' nuova domanda.

L'analogia con il software e' diretta. Se produrre software costa 10 volte meno, la domanda di software non cala. Cresce. Ci sono milioni di problemi che oggi non vengono risolti con il software perche' costa troppo. Se il costo crolla, quei problemi diventano risolvibili.

E fa un esempio concreto: le ATM. Quando sono arrivati i bancomat, tutti dicevano che i cassieri di banca sarebbero spariti. Invece sono aumentati. Perche'? Perche' le ATM hanno reso piu' economico aprire nuove filiali, e ogni filiale aveva bisogno di personale.

Per gli sviluppatori, questo significa una cosa: il lavoro non sparisce. Cambia. Drasticamente.

Dobby the Elf e l'overhang digitale

Un dettaglio delizioso dell'intervista: Karpathy ha un agente chiamato "Dobby" (come l'elfo domestico di Harry Potter) che gestisce la sua casa via WhatsApp. Luci, HVAC, Sonos, tapparelle, piscina, sicurezza. Configurare il Sonos? Tre prompt e basta.

Ma il punto interessante e' il contrasto che Karpathy traccia tra il mondo digitale e quello fisico. L'overhang — il potenziale inespresso dell'AI — si scarichera' prima nel digitale. Perche' i bit sono facili. Gli atomi sono "un milione di volte piu' difficili".

Scrivere codice, analizzare dati, generare contenuti — tutto cio' che vive nei bit verra' trasformato rapidamente. Costruire robot, gestire supply chain fisiche, operare nel mondo reale — ci vorra' molto piu' tempo. E' una distinzione importante per chi sta decidendo dove investire le proprie competenze.

Open source: 6-8 mesi dietro, ma necessario

Karpathy tocca anche un punto politico. I modelli open source sono 6-8 mesi dietro quelli closed. Ma questo non significa che non contano.

"I'm a little bit hesitant of having intelligences that are closed and that's it. Centralization has a very poor track record."

E' una posizione netta, soprattutto per uno che viene da OpenAI. La centralizzazione dell'intelligenza non ha un buon track record storico. Le intelligenze chiuse, controllate da poche aziende, sono un rischio. L'open source e' un contrappeso necessario, anche se imperfetto.

Per noi sviluppatori, il messaggio e' pratico: non legatevi a un solo provider. I modelli open source miglioreranno. E avere alternative e' sempre meglio che dipendere da un'unica API.

L'educazione cambia: spiegare agli agenti, non alle persone

L'ultimo punto e' forse il piu' provocatorio. Karpathy ha creato MicroGPT — un'implementazione di GPT in 200 righe. L'obiettivo originale era spiegare il funzionamento alle persone.

Ora dice qualcosa di diverso.

"I'm not explaining to people anymore. I'm explaining it to agents. If agents get it, then agents can be the router."

Se gli agenti capiscono il concetto, possono fare da intermediari per le persone. Non serve piu' che ogni singolo sviluppatore capisca ogni singolo dettaglio dell'implementazione. Serve che l'agente lo capisca, e che lo sviluppatore sappia dirigere l'agente.

E' un cambio di paradigma nell'educazione tecnica. Non studi per sapere fare — studi per sapere dirigere chi fa. Non impari a scrivere CUDA kernel — impari a spiegare a un agente quando e come usarli.

Fa impressione. Ma se ci pensi, e' esattamente quello che e' successo con ogni livello di astrazione nella storia dell'informatica. Non scriviamo assembly. Non gestiamo la memoria manualmente (nella maggior parte dei casi). Non ottimizziamo i registri della CPU. Ogni generazione delega il livello sottostante e si concentra su quello sopra.

Cosa significa per chi sviluppa

Tiriamo le fila. Cosa ci dice questa intervista, concretamente?

Il file AGENTS.md e' il tuo asset piu' importante. Non il codice. Non l'architettura. Il file che dice all'agente cosa fare e come farlo. Investi tempo a ottimizzarlo. Trattalo come codice di produzione, non come un appunto.

Il throughput conta piu' del tempo alla tastiera. Il valore che produci non si misura piu' in righe scritte. Si misura in task completati, in agenti orchestrati, in cicli di review fatti bene. Se hai tempo di subscription inutilizzato, stai lasciando valore sul tavolo.

I tuoi anni di esperienza hanno un punto cieco. Conosci il codice troppo bene. Ci sono ottimizzazioni che non vedi perche' dai per scontato che "funziona cosi'". Un agente non ha quel bias. Usalo.

La jaggedness e' reale, ed e' il tuo lavoro gestirla. L'agente e' un PhD e un bambino di 10 anni nello stesso momento. La tua competenza sta nel sapere quando e' quale. Se non hai i fondamentali per distinguere, sei nei guai.

Quando l'agente fallisce, il primo sospetto sei tu. Non il modello, non il provider, non la capability. Tu. Il tuo prompt. Il tuo contesto. Le tue istruzioni. E' scomodo, ma e' anche l'unica variabile che controlli.

Karpathy non e' un profeta. E' un data point — estremo, privilegiato, non generalizzabile a tutti. Ma i data point estremi sono quelli che ti dicono dove sta andando la curva. E questa curva dice una cosa chiara: tra un anno, chi non avra' imparato a orchestrare agenti sara' nella stessa posizione di chi non sapeva usare Git nel 2015.

Non impossibilitato a lavorare. Solo, progressivamente, irrilevante.

Fonti: