L’autoresearch di Andrej Karpathy ha dimostrato che un file Markdown ben scritto può dirigere agenti AI a fare vere scoperte scientifiche durante la notte. Ma non tutti i file program.md sono creati uguali.

La qualità delle tue istruzioni Markdown determina direttamente la qualità dell’output dell’agente AI. Un program.md vago produce esperimenti casuali e non diretti. Uno preciso produce miglioramenti focalizzati che si moltiplicano.

Ecco come scrivere un program.md che funziona davvero.

La Struttura di un Buon program.md

Ogni program.md efficace ha bisogno di cinque sezioni, che tu stia facendo ricerca ML o qualsiasi altro lavoro diretto da agenti.

1. Contesto: Cosa Deve Sapere l’Agente?

L’agente inizia con zero comprensione del tuo progetto. Il tuo primo compito è dargli abbastanza contesto per prendere decisioni intelligenti.

Cosa includere:

Cosa fa il progetto
Come appare il codebase
File chiave e loro scopi
Terminologia specifica del dominio
Stato attuale e problemi noti

Cosa omettere:

Informazioni ovvie che l’LLM già conosce
Dettagli di implementazione che può leggere dal codice
Storia che non influisce sulle decisioni attuali

2. Obiettivi: Cosa Dovrebbe Ottimizzare l’Agente?

Questa è la sezione più critica. L’agente ha bisogno di un obiettivo chiaro e misurabile.

Nell’autoresearch, l’obiettivo è diretto: ridurre val_bpb (validation bits per byte). L’agente può misurarlo dopo ogni corsa di training di 5 minuti.

Per i tuoi progetti, definisci il successo in termini che l’agente possa valutare:

“Ridurre il tempo di caricamento della pagina sotto i 2 secondi”
“Aumentare la copertura dei test sopra l’80%”
“Ridurre la dimensione del bundle di almeno il 15%”

Obiettivi vaghi come “rendere il codice migliore” producono risultati vaghi. Obiettivi misurabili producono miglioramenti focalizzati.

3. Vincoli: Cosa Non Dovrebbe Mai Fare l’Agente?

I vincoli sono importanti quanto gli obiettivi. Senza di essi, l’agente potrebbe trovare soluzioni creative che non vuoi --- come eliminare tutti i test per “migliorare” la velocità di build.

Vincoli comuni:

Non modificare i file di test o il codice di valutazione
Non cambiare l’API pubblica
Non introdurre nuove dipendenze
Non superare un budget di memoria
Mantenere il codice leggibile e manutenibile

Nell’autoresearch, il vincolo chiave è che solo train.py può essere modificato. La pipeline dei dati, il codice di valutazione e il test set sono bloccati. Questo impedisce all’agente di manipolare le metriche.

4. Strategia: Come Dovrebbe Affrontare il Problema l’Agente?

Qui brilla la tua competenza nel dominio. Sai cose che l’agente non sa --- quali direzioni sono promettenti e quali sono vicoli ciechi.

Buone istruzioni strategiche:

“Inizia con il tuning degli iperparametri prima dei cambiamenti architetturali”
“Concentrati sul meccanismo di attenzione --- l’implementazione attuale potrebbe essere sub-ottimale”
“Prova prima le tecniche di regolarizzazione: dropout, weight decay, layer norm”
“Evita cambiamenti che aumentano il tempo di training di più del 10%”

Cattive istruzioni strategiche:

“Prova tutto” (troppo vago)
“Cambia il learning rate a 0,001” (troppo specifico --- stai microgestendo)

Il punto di equilibrio è la guida direzionale che lascia l’agente esplorare entro confini produttivi.

5. Valutazione: Come Dovrebbe Giudicare il Successo l’Agente?

L’agente deve sapere come misurare se i suoi cambiamenti hanno aiutato. Nell’autoresearch, questo è incorporato nel loop: se val_bpb migliora, mantieni il cambiamento. Se no, ripristina.

Per altri contesti, definisci i tuoi criteri di valutazione:

Quali metriche contano?
Quale soglia conta come miglioramento?
Come dovrebbe gestire l’agente i risultati ambigui?
Quando dovrebbe l’agente fermarsi e riferire?

Errori Comuni

Essere Troppo Vaghi

“Migliora il modello” non dà all’agente nessuna direzione. Sii specifico su cosa significa “meglio”, come misurarlo e quali approcci provare prima.

Essere Troppo Specifici

“Cambia la riga 47 per usare un learning rate di 3e-4” vanifica lo scopo dell’ingegneria agentica. Dovresti impostare la direzione, non dettare l’implementazione. Lascia che l’agente esplori.

Dimenticare i Vincoli

Senza vincoli, gli agenti trovano il percorso di minore resistenza --- che spesso non è quello che vuoi. Un agente a cui viene detto di “ridurre il tempo di training” potrebbe saltare metà dei dati di training se non lo specifichi diversamente.

Non Iterare

Il tuo primo program.md non sarà perfetto. Guarda cosa fa l’agente, vedi dove va storto e aggiorna le tue istruzioni. I migliori file program.md si evolvono attraverso dozzine di iterazioni.

Il Loop di Iterazione

Scrivere program.md non è un processo una tantum. È un loop:

Scrivi il tuo program.md iniziale
Esegui l’agente
Rivedi cosa ha fatto l’agente
Aggiorna le tue istruzioni in base a cosa ha funzionato e cosa no
Ripeti

Ogni iterazione rende le tue istruzioni più precise. Dopo qualche round, avrai un program.md che produce risultati buoni in modo consistente.

Questa è la competenza fondamentale dell’ingegneria agentica: non scrivere codice, ma scrivere istruzioni per agenti sempre più efficaci attraverso l’iterazione.

Costruire la Tua Libreria di Riferimento

I migliori file program.md non vengono dal nulla. Sono costruiti su una conoscenza profonda del dominio --- documentazione, paper, best practice ed esempi.

Quando incontri materiale di riferimento utile sul web, salvalo come Markdown. Poi quando scrivi il tuo program.md, puoi integrare il contesto rilevante, citare tecniche specifiche e dare all’agente le conoscenze di base di cui ha bisogno.

I ricercatori che ottengono i migliori risultati dall’autoresearch non sono solo buoni scrittori. Sono esperti di dominio con materiale di riferimento ben organizzato che possono sintetizzare in istruzioni chiare per gli agenti.

Save converte qualsiasi pagina web in Markdown pulito --- perfetto per costruire la libreria di riferimento che alimenta file program.md efficaci. Prova Save gratis.