12 esperimenti all’ora. Zero intervento umano. Andrej Karpathy - ex direttore AI di Tesla, cofondatore di OpenAI - ha rilasciato un repository open source che trasforma qualsiasi agente AI in un ricercatore autonomo. Il progetto si chiama Auto Research, e l’idea è disarmante nella sua semplicità: dai all’AI un obiettivo, una metrica e un ciclo. Poi vai a dormire.
Il mattino dopo trovi un log di esperimenti e - se tutto ha funzionato - risultati migliori di quelli che avevi lasciato.
Karpathy lo ha costruito per il machine learning: addestrare modelli più efficienti senza supervisione. Ma il principio sottostante non ha niente di specifico per il ML. È il metodo scientifico, automatizzato. E quando lo applichi al business - cold email, landing page, campagne ads - le cose si fanno interessanti.
Come funziona Auto Research (in 60 secondi)
Il ciclo è quello di qualsiasi esperimento scientifico, compresso in un loop che gira ogni pochi minuti:
- Ipotesi - l’agente formula una modifica da testare (es. “un’email più corta con CTA specifica avrà un reply rate più alto”)
- Esperimento - crea una variante challenger e la mette in competizione con la baseline
- Misurazione - raccoglie la metrica oggettiva tramite API (reply rate, conversion rate, CTR)
- Selezione - il vincitore diventa la nuova baseline, il perdente viene scartato
- Accumulo - le osservazioni vengono loggate in un file di risorse che informa gli esperimenti futuri
La parte cruciale è l’ultima. L’agente non riparte da zero a ogni ciclo: accumula conoscenza. Dopo 50 iterazioni sa cosa funziona e cosa no. Dopo 500, ha un dataset di insight che nessun team umano avrebbe il tempo di compilare manualmente.
Il ciclo Auto Research
Ogni iterazione alimenta la successiva: l’agente impara dai risultati e formula ipotesi sempre più informate.
Dal machine learning al fatturato: dove applicarlo
Karpathy ottimizzava la validation loss di un modello linguistico. Ma il pattern funziona ovunque esista una metrica oggettiva e un modo per modificare l’input via API.
Qualche esempio concreto:
- Cold email - metrica: reply rate. L’agente riscrive il copy, testa baseline vs challenger, raccoglie i risultati dall’API del provider (es. Instantly) e seleziona il vincitore ogni 4 ore
- Landing page - metrica: conversion rate. Modifica titoli, CTA, struttura della pagina tramite CMS API e misura l’impatto
- Ad creative - metrica: CTR o costo per conversione. Genera varianti e lascia che i dati decidano
- Chatbot e assistenti AI - metrica: customer satisfaction score. Ottimizza il template delle risposte basandosi sul feedback reale
- Newsletter - metrica: open rate. Testa subject line diverse su segmenti paralleli
Il principio è sempre lo stesso: separa l’ipotesi dalla misurazione, automatizza entrambe, e lascia che il volume faccia il lavoro.
L’esempio pratico: cold email che si riscrivono da sole
Un caso d’uso concreto rende l’idea meglio di qualsiasi spiegazione astratta. Prendiamo le cold email - un ambito dove il 90% del lavoro è iterazione su copy e timing.
La pipeline funziona così:
Un orchestratore (un agente Claude Code con accesso alle API di Instantly) gestisce l’intero ciclo. Parte da un’email baseline scritta da un umano. Genera un challenger - una variante con un’ipotesi specifica: “l’email è troppo lunga, proviamo sotto le 75 parole con una CTA temporale precisa”.
Entrambe le versioni girano in parallelo sugli stessi segmenti. Dopo qualche ora, l’orchestratore raccoglie i reply rate, dichiara un vincitore, e genera un nuovo challenger basandosi su tutto ciò che ha imparato fino a quel momento.
Il dettaglio che fa la differenza: ogni osservazione viene salvata in un file resource.md che cresce a ogni ciclo. Dopo una settimana, quell’agente sa cose sul tuo pubblico che tu stesso non avresti mai scoperto - perché nessun umano avrebbe il tempo di testare 168 varianti in 7 giorni.
Cosa serve per costruire la pipeline
Metrica oggettiva
Reply rate, CTR, conversion rate. Qualcosa di misurabile, non soggettivo.
API per gli input
Un modo per modificare le variabili dell’esperimento via codice, senza intervento manuale.
Feedback loop veloce
Più il ciclo è rapido (minuti, non settimane), più esperimenti accumuli e più impari.
I tre requisiti fondamentali per implementare Auto Research in qualsiasi contesto business.
L’umano fa meglio. Ma non basta
Ecco il punto che molti articoli sull’automazione AI evitano accuratamente: su ogni singola decisione, un esperto umano farebbe meglio. Un copywriter senior scriverebbe un’email migliore di qualsiasi challenger generato da Claude. Un CRO specialist ottimizzerebbe una landing page con più intuizione di un agente autonomo.
Ma l’esperto umano dorme. Mangia. Ha riunioni. Lavora su 3-4 varianti al mese, se va bene.
L’agente ne testa 12 all’ora. Il vantaggio non è nella qualità della singola decisione - è nel volume. Centinaia di micro-esperimenti accumulati producono miglioramenti che nessun team umano potrebbe replicare, non per mancanza di competenza, ma per mancanza di tempo.
È la stessa logica con cui gli agenti AI di Prisma gestiscono processi aziendali: non sostituiscono il giudizio umano, lo moltiplicano. L’umano definisce la strategia e i vincoli. L’agente esegue, misura e itera.
Dove Auto Research non funziona (e perché è importante saperlo)
Il pattern ha limiti chiari che vale la pena conoscere prima di investire tempo nell’implementazione.
Feedback loop lenti - se il tuo ciclo richiede settimane per produrre dati significativi (es. SEO, brand awareness), il vantaggio del volume scompare. Servono metriche che maturano in ore, non in mesi.
Metriche soggettive - “quanto è caldo il tono di questa email” non è una metrica. Puoi creare proxy (scale da 1 a 10, sentiment analysis), ma stai aggiungendo un livello di approssimazione che riduce l’affidabilità di ogni esperimento.
Nessun accesso API - se non puoi modificare gli input in modo programmatico, l’agente non può sperimentare. Puoi aggirare il problema con Chrome DevTools o CLI, ma la frizione aumenta e il ciclo rallenta.
C’è anche una questione meno ovvia: la degenerazione della conoscenza accumulata. Dopo 500-1000 cicli, il file di risorse diventa così lungo che l’agente perde contesto. Serve una strategia di consolidamento - riassumere periodicamente le osservazioni chiave e scartare il rumore. È un problema di gestione del contesto che chiunque lavori con LLM conosce bene.
Come implementarlo: i passi concreti
Per chi vuole provare, il setup tecnico non è complesso. Serve familiarità con Claude Code e un minimo di dimestichezza con le API.
- Clona il repository Auto Research di Karpathy da GitHub - contiene la struttura base, il
program.mde gli script di esempio - Definisci il tuo esperimento in un file
test.md: obiettivo, metrica, metodo di test - Adatta l’orchestratore al tuo caso d’uso - sostituisci le chiamate API di training ML con quelle del tuo servizio (Instantly, Google Ads, il tuo CMS)
- Configura lo scheduling con GitHub Actions, un cron job o qualsiasi servizio cloud. Ogni ora è un buon punto di partenza
- Aggiungi notifiche - un webhook Slack o email per monitorare i risultati senza dover controllare manualmente
Il punto chiave è che Claude Code non è solo l’agente che esegue gli esperimenti - è anche lo strumento con cui costruisci l’intera pipeline. Gli dici cosa vuoi ottimizzare, gli dai il contesto del repository, e lui genera orchestratore, client API, script di utilità e workflow di scheduling. Il codice che scrive è il codice che poi eseguirà in autonomia.
Per le aziende che vogliono esplorare questo approccio senza partire da zero, la formazione aziendale sull’AI copre esattamente questi pattern: come passare dall’uso manuale dell’AI all’automazione strutturata.
La democratizzazione della sperimentazione
Quello che Karpathy ha fatto con Auto Research è rendere accessibile ciò che i grandi laboratori AI fanno da anni: sperimentazione continua, autonoma, su scala. OpenAI, Google DeepMind, Anthropic - tutti eseguono migliaia di esperimenti in parallelo ogni notte per migliorare i propri modelli.
Ora lo stesso principio è disponibile per chiunque abbia un’API e una metrica.
La domanda vera non è se il pattern funziona - funziona, i numeri lo dimostrano. La domanda è un’altra: quando l’ottimizzazione è completamente autonoma, chi decide i vincoli etici di ciò che l’agente può testare? Un’email ottimizzata per il reply rate massimo potrebbe essere manipolativa. Una landing page ottimizzata per la conversione potrebbe usare dark pattern.
Il metodo scientifico automatizzato è uno strumento potente. Ma come tutti gli strumenti potenti, la responsabilità di definire i confini resta umana.