Nel mondo dell’intelligenza artificiale, dove la distinzione tra ciò che è scritto da una mente umana e ciò che è generato da una macchina diventa sempre più sottile, è affascinante quando una figura di rilievo come Andrej Karpathy afferma con decisione che il suo nuovo progetto, nanochat, è “interamente scritto a mano” — ovvero, nessun ricorso a codici prodotti da agenti AI, nessun “vibe coding” occulto.
Karpathy, noto per il suo coinvolgimento con OpenAI e per iniziative come nanoGPT, ha presentato nanochat come un framework open source completo: una pipeline “end-to-end” per l’addestramento e l’inferenza di un modello in stile ChatGPT. Secondo le sue parole, il repository conta circa 8.000 righe di codice che coprono l’intero flusso operativo.
Quando un utente gli ha chiesto quanto del codice fosse stato scritto manualmente, Karpathy ha risposto con schiettezza: “praticamente tutto scritto a mano (con l’aiuto dell’autocompletamento dei tab)”. Ha ammesso di aver sperimentato strumenti come Claude o Codex per assisterlo, ma ha dichiarato che questi non si sono rivelati utili: “sono risultati per nulla efficaci e tendenti a essere inutili, probabilmente perché il mio repo è troppo distante dalla loro distribuzione dati”.
Questa dichiarazione ha stimolato riflessioni e anche critiche nella comunità di ricerca. Lo studioso Gary Marcus ha colto l’occasione per evidenziare un paradosso: Karpathy — coautore del concetto di “vibe coding” — che rifiuta di utilizzarlo e insiste nel codice scritto a mano. Marcus ha scritto che questo “conferma ancora una volta” le difficoltà attuali dell’intelligenza artificiale nell’affrontare lo shift di distribuzione, ossia il trasferimento di conoscenza da un dominio all’altro. In altre parole, per Marcus il problema fondamentale è che gli strumenti di AI tendono a lavorare bene proprio quando i dati sono simili a quelli di addestramento; quando la realtà si discosta, la generalizzazione fallisce.
Ma cosa vuol dire, concretamente, che un progetto come nanochat sia “scritta a mano” in un contesto dove esistono sempre più strumenti che generano codice? Significa che ogni funzione, ogni modulo, ogni dettaglio è stato progettato, codificato e raffinato da Karpathy stesso, piuttosto che delegato a un programma che scrive il codice in funzione di prompt o di esempi. Questo atto rivendica — con forza quasi simbolica — l’autonomia progettuale umana in un’era in cui l’uso di agenti che generano codice è sempre più diffuso.
Il termine “vibe coding” è interessante nel contesto: Karpathy ha contribuito a diffondere l’idea che i modelli generativi possono “sentire un vibe” del codice desiderato e produrlo di conseguenza. Ma qui, affermare che nanochat non è realizzato con vibe coding serve a riaffermare che c’è del valore nella programmabilità consapevole, nella comprensione profonda della logica, nella coerenza architetturale e nel controllo manuale — tutti elementi che, secondo lui, avrebbero perso qualità se affidati a strumenti automatici troppo generici.
Certo, la discussione non si limita a posizioni contrastanti: apre domande più profonde su come intendiamo l’“automazione” nel software e su quanto ci fidiamo degli strumenti che essi stessi generano. Quando si delega al codice generativo, si perde parte della trasparenza, della prevedibilità, della capacità di debug preciso. Ma contemporaneamente si guadagna in rapidità, iterazione e — in alcuni casi — in creatività emergente.
Alla fine, la posizione di Karpathy non è un rifiuto ideologico dell’IA applicata al codice, ma una scelta progettuale. Vuole dimostrare che — almeno per quel progetto — un approccio tradizionale può ancora prevalere sulla tentazione di “far scrivere il codice all’AI”. E forse, implicitamente, suggerisce che ci sono contesti in cui la precisione, la coesione e la visione architetturale richiedono ancora l’intervento umano diretto.