L’idea parte da un tweet di Apex (@0xApexAi, 8 ottobre 2026): prima di affidare a un modello come Claude Opus o Grok un task lungo, incolli un “prompt harness” ispirato a Andrej Karpathy che trasforma una semplice sessione LLM in un processo ingegneristico molto più affidabile. La frase chiave del tweet: l’LLM smette di comportarsi come una finestra di chat e inizia a comportarsi come un processo ingegneristico persistente.
Cos’è un “harness”
Un harness è il sistema di esecuzione che sta tra il modello e il task: le regole, il contesto, i tool, i cicli di verifica e la memoria di lavoro. Nel tweet, però, l’harness non è codice: è un prompt, un set di procedure che il modello deve rispettare. I punti elencati da Apex:
- Legge lo stato esistente del progetto prima di toccare qualsiasi cosa
- Mantiene un progresso durabile tra le esecuzioni
- Usa i tool solo quando servono
- Verifica ogni modifica importante
- Retenta i passi falliti invece di continuare alla cieca
- Mantiene una procedura riutilizzabile per il lavoro ricorrente
- Restituisce output esatti, check, blocker e next step
- Protocollo fisso come un laboratorio di ricerca
- Valutazione binaria: la metrica migliora o peggiora, e l’edit viene tenuto o scartato
- Git come memoria degli esperimenti
- Budget di tempo fisso (es. 5 minuti di training per esperimento)
- Scrivi un program.md (o AGENTS.md): protocollo, regole, procedure riutilizzabili
- Definisci una metrica binaria o scalar: migliorata o peggiorata, tenuta o scartata
- Usa git: ogni esperimento committato, revert facile
- Imposta un budget di tempo fisso: task time-boxed
- In coding agent: leggi lo stato esistente prima di toccare, usa i tool solo quando servono, verifica ogni modifica, ritenta i falliti, restituisci output esatti + blocker + next step
- Tweet di Apex (@0xApexAi) — Karpathy-inspired harness prompt
- karpathy/autoresearch su GitHub
- The New Stack — Andrej Karpathy’s 630-line Python script ran 50 experiments overnight
- hwchase17/autoresearch-agents
- OpenAI — Harness engineering: leveraging Codex in an agent-first world
- Martin Fowler — Harness engineering for coding agent users
Apex concluse: “Non vorrei più eseguire un task serio lungo termine senza questa struttura”.
Origine: l’AutoResearch di Karpathy
Il riferimento implicito è il progetto autoresearch di Andrej Karpathy: un agent AI che esegue esperimenti di training LLM autonomamente su una singola GPU. Come documentato da The New Stack, uno script Python di ~630 righe ha fatto girare 50 esperimenti overnight senza alcun input umano: al mattino l’agent aveva eseguito 50 esperimenti, trovato un learning rate migliore e committato la prova su git.
Il file più importante non è train.py ma program.md: un protocollo sperimentale di ~40 righe di Markdown. Il pattern:
Il pattern si applica oltre il ML: query DB ottimizzate overnight, configurazioni di routing ridotte, agent.py (prompts + tool + architettura) ottimizzati con lo stesso loop, come nell’adattamento autoresearch-agents di Harrison Chase.
Il tema più ampio: “Harness Engineering”
La ricerca di Apex arriva in un momento in cui il tema è caldo. OpenAI ha documentato un esperimento interno di 5 mesi in cui un team ha costruito un prodotto beta di ~1 milione di righe di codice con agenti Codex: nel workflow “agent-first” il codice è economico e gli umani guidano, mentre la difficoltà vera è la agent legibility: organizzare l’informazione e i feedback loop in modo che l’agente ragionino in modo corretto. Come riassume Martin Fowler, la conclusione è: “Le sfide più difficili riguardano la progettazione di ambienti, feedback loop e sistemi di controllo”.
Come applicarlo in pratica
Il mio commento
Il tweet di Apex è utilissimo ma un po’ marketing: “incollalo ora, salvalo per dopo”. Il prompt harness è un buon set di procedure, ma un prompt da solo non è un harness. La differenza la fa la struttura dell’ambiente: program.md + metrica + budget di tempo + git. Un prompt che dice al modello di “verificare ogni modifica” non ha la forza di un loop che scarta automaticamente gli edit che peggiorano la metrica. Detto questo, il set di procedure in un coding agent è esattamente quello che serve ogni giorno: leggere lo stato esistente, mantenere un progresso durabile tra le run, verificare le modifiche e ritentare i falliti. In questo senso il tweet è un buon promemoria: la stessa disciplina che Karpathy ha usato overnight su una GPU è quello che un coding agent ben configurato dovrebbe rispettare su ogni task lungo.