Guida ad AutoResearch di Andrej Karpathy: automatizzare il ML con agenti AI

AutoResearch di Andrej Karpathy è uno strumento open source che esegue esperimenti di ML in un loop, mantenendo solo le modifiche che battono il miglior risultato attuale. Descrivi le direzioni di ricerca in un file markdown, punti un agente AI per il coding al repo e ti allontani. Al mattino, hai una cronologia git di miglioramenti convalidati e un log di tutto ciò che l'agente ha provato.

Rilasciato il 7 marzo 2026, il progetto ha raccolto oltre 21.000 stelle su GitHub e 8,6 milioni di visualizzazioni all'annuncio di Karpathy in pochi giorni. Questo articolo spiega come funziona l'architettura a tre file, cosa fa il loop a cricchetto durante quelle esecuzioni notturne, quali risultati ha prodotto finora AutoResearch e dove l'approccio incontra i suoi limiti.

Che cos'è AutoResearch?

AutoResearch è uno strumento Python open source che consente a un agente AI di eseguire esperimenti di ML su una singola GPU senza intervento umano. Esegue cicli di proposta–addestramento–valutazione, mantenendo solo le modifiche che migliorano la validation loss. Il progetto è distribuito con licenza MIT.

Questo non è tuning degli iperparametri. Strumenti come Optuna o Ray Tune cercano in uno spazio di parametri predefinito. AutoResearch dà all'agente la libertà di modificare codice arbitrario. Lo spazio di ricerca è tutto ciò che l'LLM riesce a concepire, e questo lo rende una categoria diversa da qualsiasi cosa attualmente disponibile.

I framework AutoML e NAS (Neural Architecture Search) esplorano architetture o iperparametri usando algoritmi strutturati, precisi ma vincolati al loro spazio di ricerca definito.

AlphaEvolve (Google DeepMind) va oltre con un approccio evolutivo e modelli Gemini per la scoperta di algoritmi, ma è closed source e non accessibile alla maggior parte dei team. Gli agenti generici per il coding come SWE-Agent, OpenHands e Aider sanno scrivere codice arbitrario ma non sono progettati per il ciclo sperimenta–valuta–mantieni/ripristina di cui la ricerca in ML ha realmente bisogno.

AutoResearch punta sulla conoscenza generale dell'LLM per proporre buoni esperimenti, invece di vincolare lo spazio di ricerca per avere garanzie matematiche.

Dal vibe coding al consulente di ricerca

Karpathy inquadra questo come una progressione naturale nel modo in cui gli ingegneri lavorano con l'AI. Nel febbraio 2026, ha coniato il termine "agentic engineering": "Non stai scrivendo il codice direttamente per il 99% del tempo. Stai orchestrando agenti che lo fanno e agisci come supervisione." AutoResearch fa il passo successivo. L'umano non orchestra nemmeno. Descrive cosa sia una buona ricerca in un file markdown e si allontana.

La progressione è: vibe coding (l'umano dà prompt, l'AI scrive il codice, l'umano rivede) poi agentic engineering (l'umano orchestra gli agenti in tempo reale) fino alla ricerca completamente indipendente (l'umano imposta la direzione, l'agente procede da solo). 

Ogni passo riduce il ruolo dell'umano da autore a regista fino a, nella cornice di Karpathy, consulente di ricerca.

In un post successivo, ha descritto il prossimo passo: "L'obiettivo non è emulare un singolo dottorando, ma emulare una comunità di dottorandi", facendo riferimento a una collaborazione distribuita di agenti in stile SETI@home.

Il modo in cui il sistema realizza quella visione si riduce a tre file.

L'architettura a tre file di AutoResearch

Il design di AutoResearch si basa su un contratto tra tre file, ciascuno con regole rigorose su chi può toccarlo.

prepare.py

prepare.py gestisce la preparazione dei dati e la valutazione. Costruisce un tokenizer BPE (Byte Pair Encoding) con un vocabolario di 8.192 token, elabora il corpus di addestramento e definisce la metrica di validazione: val_bpb (bits per byte in validazione). 

Questo file è immutabile: né l'umano né l'agente lo modificano, il che garantisce che ogni esperimento sia misurato con lo stesso metro.

train.py

train.py è il sandbox dell'agente: 630 righe che contengono l'architettura del modello GPT, l'ottimizzatore Muon+AdamW e l'intero training loop. L'agente può riscrivere qualsiasi cosa qui (scambiare funzioni di attivazione, ristrutturare le teste di attenzione, cambiare i programmi del learning rate, modificare l'inizializzazione dei pesi) finché il codice modificato si addestra e produce un punteggio val_bpb.

program.md

program.md è scritto in semplice markdown ed è l'unico file che tocca l'autore umano. Dice all'agente quali direzioni di ricerca seguire, cosa evitare e come affrontare gli esperimenti.

Cosa controlla program.md

Il file è più specifico di quanto la maggior parte si aspetti. Codifica i valori di baseline così che l'agente sappia cosa superare (val_bpb: 0,997900, VRAM di picco (memoria video): 45 GB). 

Specifica i comandi esatti per eseguire gli esperimenti ed estrarre i risultati. Dice all'agente come gestire i fallimenti: correggere i typo e rieseguire, saltare idee che sono rotte alla radice, uccidere qualsiasi cosa che superi i 10 minuti. 

E include la direttiva che fa funzionare l'intero sistema: "NON FERMARE MAI. Una volta iniziato il loop di esperimenti, NON mettere in pausa per chiedere all'umano se devi continuare."

C'è anche un vincolo di design che modella ogni esperimento: "A parità di condizioni, più semplice è meglio. Un piccolo miglioramento che aggiunge brutta complessità non vale la pena." Questo allontana l'agente da soluzioni sovraingegnerizzate e lo orienta verso modifiche pulite che un revisore umano approverebbe.

La divisione del lavoro è netta. L'umano imposta la direzione della ricerca tramite program.md, l'agente esegue modificando train.py e prepare.py funge da giudice neutrale che nessuna delle due parti può toccare. Con quel contratto in atto, l'agente esegue il loop di esperimenti in modo continuo senza fermarsi.

Il loop a cricchetto di AutoResearch

Il cuore di AutoResearch è un ciclo di esperimenti che gira senza input umano. Ecco come funziona una singola iterazione, seguendo il loop in 9 passaggi definito in program.md:

1. L'agente legge program.md per capire le priorità e i vincoli di ricerca attuali.
2. Esamina l'attuale train.py e i risultati recenti in results.tsv.
3. Propone un'ipotesi: una modifica all'architettura, un aggiustamento dell'ottimizzatore o una modifica dell'addestramento.
4. Modifica train.py per implementare la modifica proposta.
5. Esegue il commit della modifica su un branch git.
6. Esegue l'addestramento per esattamente 5 minuti (budget fisso di wall clock).
7. Se l'addestramento va in crash, registra il fallimento, ripristina il commit e riprova.
8. Valuta il risultato usando val_bpb e registra l'esito in results.tsv.
9. Se val_bpb è migliorato: il commit resta. Altrimenti: git reset HEAD~1 ripristina la versione precedente.

Poi ricomincia dal passo 1.

Ogni esperimento ha lo stesso budget di 5 minuti di wall clock, rendendo i risultati direttamente confrontabili. Una modifica che addestra più velocemente e una che converge più in basso sono valutate sullo stesso piano. 

A 5 minuti per esperimento, il sistema esegue circa 12 esperimenti l'ora.

Il nome "cricchetto" viene dalla cronologia git. Ogni esperimento riuscito aggiunge un commit; ogni fallimento viene ripristinato. La base di codice può solo andare avanti, mai indietro, accumulando miglioramenti convalidati uno alla volta.

Git come memoria della ricerca

Questo ricorda gli algoritmi evolutivi nella struttura, ma AutoResearch mantiene una singola linea piuttosto che una popolazione. Invece di crossover e mutazione tra candidati, l'LLM funge sia da operatore di mutazione (proponendo modifiche) sia da pressione di selezione (scegliendo cosa provare in base ai risultati passati). 

Legge la propria cronologia git e results.tsv per costruire su tutto ciò che ha mostrato promesse.

Il file results.tsv traccia ogni esperimento: hash del commit, punteggio val_bpb, uso della memoria GPU, stato pass/fail e una descrizione di ciò che l'agente ha provato. 

Hai una chiara traccia di audit da rivedere al mattino e l'agente usa lo stesso log per calibrare cosa provare dopo. Gli esperimenti iniziali tendono a essere ampi (test di diverse configurazioni dell'ottimizzatore), mentre quelli successivi si concentrano nella direzione che i dati hanno convalidato.

Iniziare con AutoResearch

Per eseguire AutoResearch serve una macchina con una GPU NVIDIA (la configurazione predefinita è pensata per GPU moderne con oltre 20 GB di VRAM), Python 3.10+, uv e un agente per il coding (Claude Code, Cursor o simili).

Clona il repo, installa le dipendenze e prepara il dataset:

git clone https://github.com/karpathy/autoresearch.git
cd autoresearch
uv sync
uv run prepare.pyOfferto da

Non c'è uno script di orchestrazione. Niente run.py, niente pipeline, niente framework. 

Il README dice di "semplicemente avviare il tuo Claude/Codex o quello che vuoi in questo repo." 

Apri un agente per il coding nella directory del progetto, chiedigli di leggere program.md e l'agente eseguirà il loop di esperimenti da solo. 

L'LLM è lo strato di automazione. Monitora i progressi facendo tail di results.tsv o controllando il log di git per nuovi commit.

La configurazione predefinita addestra un modello GPT sul dataset FineWeb-Edu, che richiede una GPU decente e diverse ore per mostrare i risultati. Per un primo test su hardware più piccolo, Karpathy consiglia di passare al dataset TinyStories e ridimensionare il modello riducendo la dimensione del vocabolario a 256 e la profondità a 4. 

Queste modifiche riducono i requisiti di VRAM e accorciano ogni esperimento a sufficienza per vedere il cricchetto in azione nel giro di un paio d'ore.

Configurare la tua prima esecuzione

Leggi il program.md predefinito prima di avviare un'esecuzione notturna. Definisce l'agenda di ricerca che l'agente seguirà, ed è modificandolo che puoi indirizzare gli esperimenti. 

Se vuoi che l'agente si concentri sui meccanismi di attenzione, dillo in program.md. 

Se vuoi che eviti di toccare l'ottimizzatore, aggiungi quel vincolo. L'agente non devierà da quanto scritto lì.

Per una prima esecuzione notturna, aspettati 80-100 esperimenti con forse 15-20 miglioramenti mantenuti. Alcune cose pratiche da sapere:

• I costi API scalano con il numero di esperimenti. Una singola esecuzione notturna è gestibile per i ricercatori individuali, ma esecuzioni di più giorni richiedono un budget.
• Alcuni esperimenti andranno in crash. Il loop si riprende automaticamente, quindi non interromperanno un'esecuzione notturna.
• Controlla results.tsv al mattino invece di guardare il terminale. Il pattern a gradini dei punteggi val_bpb in miglioramento racconta la storia meglio dei singoli log.

Risultati di AutoResearch e il tetto della creatività

AutoResearch è stato testato in diverse esecuzioni, dagli esperimenti di Karpathy a riproduzioni della community fino all'adozione in produzione.

L'agente ha trovato cose che un umano metodico prima o poi troverebbe. QKnorm mancava di uno scaler multiplier per affinare l'attenzione, le Value Embeddings beneficiano della regolarizzazione, e ci sono stati guadagni nel tuning dell'attenzione a bande, nei parametri beta di AdamW e nella schedulazione del weight decay. 

Si tratta di modifiche strutturali al codice, non di sweep casuali di iperparametri, e testarne ciascuna manualmente avrebbe richiesto giorni.

Il CEO di Shopify Tobi Lutke ha adattato AutoResearch per un modello interno di espansione delle query e ha ottenuto un miglioramento del 19% nel punteggio di validazione da 37 esperimenti su un modello da 0,8B di parametri, riportando i risultati il giorno dopo l'avvio.

Il grafico a scala è reale, ma ogni gradino è piccolo. L'agente trova miglioramenti genuini, ritoccando un parametro beta qui, aggiungendo regolarizzazione lì. Nessuno ha riportato che inventi un nuovo meccanismo di attenzione o proponga un'idea di architettura a cui un ricercatore umano non arriverebbe eventualmente.

Il tetto della creatività

GitHub Issue #22 cattura il problema strutturale. Un utente ha osservato che l'agente cicla tra piccole variazioni di ciò che ha funzionato per ultimo, bloccato in un pattern di ricerca locale. 

Il cricchetto accetta solo modifiche che migliorano immediatamente val_bpb, quindi l'agente non può mai fare un passo indietro per preparare un guadagno più grande. 

I ricercatori umani ragionano di routine, "peggiorerà prima di migliorare". Il cricchetto non ha spazio per questo.

Karpathy ha riconosciuto un problema correlato su Hacker News: l'agente sembra "guardingo e impaurito" su problemi aperti. 

Attribuisce questo all'RLHF (Reinforcement Learning from Human Feedback), che premia output sicuri e conservativi rispetto a sperimentazioni audaci. L'agente è capace di proporre modifiche creative ma è costruito per andare sul sicuro.

La finestra di addestramento fissa di 5 minuti aggiunge un ulteriore vincolo. 

Le modifiche che mostrano il loro valore rapidamente vengono trovate; quelle che si dimostrerebbero valide solo su esecuzioni più lunghe restano invisibili. E l'esecuzione di 100 esperimenti sullo stesso set di validazione comporta un rischio di overfitting: alcuni miglioramenti potrebbero essere specifici di quella valutazione piuttosto che guadagni reali. L'immutabilità di prepare.py, la garanzia di equità del sistema, è anche il suo punto cieco.

La community sta discutendo se il tetto dipenda dal framework o dal modello sottostante. Le proposte includono ottimizzazione del meta-prompt (un secondo agente riscrive program.md in base ai risultati), direttive di diversità che premiano la novità oltre al miglioramento e esperimenti periodici di "reset" partendo da un checkpoint precedente per sfuggire agli ottimi locali.

Al momento, AutoResearch è uno strumento che automatizza la parte metodica della ricerca in ML: eseguire e valutare centinaia di piccoli esperimenti. Non sostituisce la parte creativa, cioè formulare nuove direzioni di ricerca, che resta un lavoro umano. Quella divisione del lavoro è anche il segnale più chiaro per capire se questo strumento ha senso nel tuo workflow.

Quando usare AutoResearch

Il contratto a tre file (valutatore immutabile, implementazione modificabile dall'agente, direzione scritta dall'umano) si trasferisce oltre il training degli LLM a qualsiasi dominio in cui puoi definire una funzione di scoring automatica. 

Ottimizzazione del ranking di ricerca, categorizzazione di prodotto, riconoscimento di entità cliniche nominate, scoring antifrode, classificazione delle intenzioni: questi task hanno i tratti giusti in comune. Modelli piccoli che si addestrano in minuti, funzioni di scoring chiare e miglioramenti che si trasferiscono quando si scala.

Quando gli esperimenti girano 100 volte più velocemente di quanto un umano possa gestire, però, la pipeline di valutazione diventa il vincolo. I benchmark statici si saturano rapidamente. I team che adottano questo pattern hanno bisogno di set di valutazione che evolvano insieme ai dati di produzione e casi limite più difficili.

Karpathy stesso esegue un "cugino più grande" di AutoResearch su 8x H100 GPU con il suo framework di produzione nanochat, il che suggerisce che il pattern scala oltre i semplici esperimenti. La community lo ha già forkato per macOS/Apple Silicon e proposto integrazioni per GPU più vecchie. La guida CPU vs GPU spiega perché l'hardware GPU è imprescindibile per questo tipo di training iterativo.

Se il tuo obiettivo è spremere miglioramenti incrementali da una pipeline di training ben compresa, AutoResearch è un buon fit. Il tetto della creatività significa che avrai comunque bisogno di ricercatori umani per i problemi che richiedono vera novità, e lo strumento rende al meglio sulla maggior parte della ricerca che è iterazione metodica.

Conclusione

Scrivere un buon program.md richiede di aver fatto tu stesso la ricerca. Devi sapere quali direzioni vale la pena provare, cosa significa "meglio" per il tuo problema e quando i guadagni incrementali hanno fatto il loro corso. L'agente gestisce l'esecuzione, ma il giudizio dietro l'agenda di ricerca resta umano. Se la prossima generazione di ingegneri salta quel lavoro formativo perché ora se ne occupano gli agenti, il campo avrà un sacco di compute e nessuno con l'esperienza per indirizzarlo nella direzione giusta.