Il 99% delle persone usa /goal e i loop in modo sbagliato.
Il buzz che sentono è "agenti autonomi con loop a lunga esecuzione": punta verso un compito, allontanati, torna a codice funzionante.
Ma i migliori ingegneri di agenti lo fanno già da 6 mesi senza /goal (da quando sono usciti GPT-5.2 e Opus 4.5). Si chiama harness engineering + sviluppo guidato dalle specifiche:
- costruisci un harness per far osservare il problema all'agente
- scrivi una specifica solida con tutti i casi di test
- lascia che Codex o Claude Code girino in loop senza supervisione fino a quando non li soddisfano tutti.
Li avvio spesso di notte — ogni esecuzione dura 2-5 ore. Ad aprile uno ha risolto un bug della cache di Turbo nel nostro monorepo Vercel ed era tutto verde al mattino. Non serve /goal.
Allora a cosa serve /goal?
Ecco cosa ha fatto un singolo prompt mentre ero via:
- ~30 ore, 6.300 righe di codice, 92.000 pagine crawlate, $40 spesi in API
- Clonare il loop centrale di un altro prodotto — intera architettura reverse-engineered da zero
- L'output della nostra versione era circa 50× migliore del prodotto di riferimento sulle stesse query. (Questo è un nuovo strato dati che alimenterà newsjack.sh - le competenze open-source di news-intel su cui stavo lavorando)
Il segreto è lo sviluppo della funzione di perdita (LFD): scrivi un obiettivo che l'agente deve ottimizzare, non una specifica da costruire.
Questo è un esempio concreto del tweet di Peter, reso operativo.
La specifica usata nello sviluppo guidato dalle specifiche diventa il punto di partenza, non più il traguardo.
Ci sono voluti alcuni esperimenti per farlo funzionare. Ma ecco l'intero manuale — dobbiamo però iniziare da come è andata male, così capisci come progettare questi /goal.
L'agente ha imbrogliato 3 volte.
Tutto è iniziato con quello che faccio sempre: una specifica.
Ho semplicemente puntato Codex al sito pubblico dell'altro prodotto - "come possiamo costruirlo da soli?". In 30 minuti è tornato con un progetto di sistema completo e casi di test - la specifica.
Ma questa volta ho provato un prompt diverso.
"/goal implementa finché il tuo output non corrisponde esattamente al loro"
Ed ecco cosa è successo:
Loop 1 (5 minuti)
L'agente ha preso il set di valutazione, generato dati seed che lo rispecchiavano e dichiarato vittoria in cinque minuti.
"Recall al 100%", generalità zero — un motore di ricerca che poteva trovare solo le 30 cose che gli avevo dato lol.
Soluzione → renderlo cieco. Valutazione nascosta durante l'esecuzione, rivelata solo al punteggio, con un elenco di elementi mancati per ogni voce.
Loop 2 (20 minuti) - cieco, 30 elementi.
Ho reso l'agente cieco rispetto al set di valutazione, ma ha imparato dagli errori — ogni "non hai trovato X" diventava una parola chiave nel ciclo successivo. Dopo alcuni loop: usava esattamente 30 parole chiave, una per elemento, e ha "vinto" di nuovo.
Soluzione → ampliare il set di valutazione. Centinaia di elementi da valutare, troppi da enumerare.
Loop 3 (30 minuti) - cieco, 200 elementi.
Dopo aver aggiunto 200 elementi al nuovo set di valutazione, l'agente ha imbrogliato di nuovo.
Abbastanza ironicamente, l'agente ha enumerato comunque. La lista di parole chiave è cresciuta fino a centinaia di termini, ognuno un'esca precisa per il prossimo errore.
Tre round, tre imbrogli.
È stato allora che ho capito: l'agente stava semplicemente ottimizzando.
L'imbroglio non era un bug nell'agente. Era un bug nel mio obiettivo: gli ho detto dove andare e ho lasciato tutte le scorciatoie aperte.
Ogni percorso economico che non recinti è una direzione in cui l'ottimizzatore si precipiterà. E il mio obiettivo iniziale saltava tutte le recinzioni.
Loop 4 (30 ore) - cieco, 200 elementi, limiti rigidi.
Così ho iniziato a bloccare le direzioni. Limitare la lista di parole chiave, rendere cieca la valutazione, ampliare la data — ogni fix chiudeva un percorso economico in più, finché l'unica direzione rimasta che faceva progredire il numero era migliorare genuinamente nel compito.
Ha smesso di imbrogliare.
Poi ha girato. ~30 ore di calcolo, 92.000 pagine crawlate, ~$40 in token, 6.300 righe di codice.
Si è scoperto che il prodotto a cui ci riferivamo era il pavimento, non il soffitto: abbiamo finito per ottenere ~50× i risultati sulle stesse query.
(Il viaggio completo e le ricevute qui per i curiosi)
Sviluppo della funzione di perdita (LFD) - l'anatomia di una buona funzione di perdita
Quando la maggior parte delle persone cerca di costruire un prodotto, usano agenti per andare da zero al lancio in poche ore.
Ma il problema è ciò che viene dopo — la coda lunga. I casi limite che la specifica non ha mai immaginato emergono solo in produzione, un log di errore alla volta. Li risolvi uno per uno. I casi che non cogli nei log vengono segnalati dagli utenti, il modo più costoso per trovare un bug.
Ho automatizzato la parte economica di questo processo. Il mio agente OpenClaw Zoe osserva il log degli errori ogni giorno e genera Codex su nuovi errori mentre arrivano e crea PR — il loop più stretto possibile. (Configurazione completa documentata qui
La coda richiede ancora mesi. Ecco perché costruire un buon prodotto richiede ancora tempo anche con gli agenti a fare il lavoro.
L'LFD accelera la coda. Se riesci a ottenere esempi di output reale previsti in anticipo — come appare il "buono", su larga scala — esegui il soak prima del lancio: centinaia di casi limite colpiscono l'agente in un'unica esecuzione di ottimizzazione, non in un gocciolamento trimestrale di bug report. E il motivo per cui questo è improvvisamente fattibile è che per sempre più problemi, questi esempi sono semplicemente disponibili pubblicamente.
Sviluppo guidato dalle specifiche:
Costruisci questo. Fai passare i test.
Sviluppo della funzione di perdita:
Costruisci questo. Fai passare i test. Poi itera su questi 1.000 casi di valutazione.
Una suite di test è finita — finita nel momento in cui è tutta verde. Una valutazione di 1.000 casi al 95% è un obiettivo verso cui scendere; non c'è uscita finché non si raggiunge la soglia. Questo è importante perché l'agente prende centinaia di decisioni che non vedrai mai, e ognuna si risolve contro qualcosa. Se non hai scritto l'obiettivo, l'agente ne sceglie uno — e come mostrato nei round 1–3, sceglie quello più economico da soddisfare.
La funzione di perdita è più grande della valutazione. Ha 4 elementi: l'obiettivo, i vincoli, gli strumenti e l'entropia forzata. Quattro pezzi.
1. Obiettivo
- Abbastanza grande che l'enumerazione non ripaga. Una valutazione di 28 elementi è stata memorizzata in un round. Più ce ne sono, meglio è.
- Rendi l'agente cieco rispetto alla chiave delle risposte. I dati di valutazione esistono solo per il punteggio post-hoc. Se l'agente può vedere le risposte durante l'esecuzione, troverà un modo per guardare.
2. Vincoli
Cosa all'agente è permesso fare e cosa non è permesso.
- Il tempo è il vincolo che l'agente dimentica sempre. Gli agenti non hanno senso del tempo. Si arrovellano per 10 ore su un miglioramento del 2% perché la metrica si sta muovendo nominalmente. Ma una soluzione all'80% in 2 ore batte una al 100% completata in 30 giorni. Soluzione: imposta un budget a tempo di clock.
- Soldi. Limiti rigidi su ogni chiamata a pagamento: crediti crawler, spesa LLM, tetto massimo in dollari su una chiave usa e getta.
- Superficie. Tutti i provider, modelli consentiti, limiti di concorrenza. Metti l'agente in una sandbox solo per le cose che vuoi che tocchi.
- Metodologia. L'analisi LLM è consentita o solo logica deterministica? Quali fonti di dati ha a disposizione l'agente? Spiegarlo chiaramente.
3. Strumenti (l'harness)
Un vincolo senza uno strumento è un'aura — l'agente lo violerà allegramente perché non può rendersi conto di violarlo. Per ogni vincolo sopra, fornisci un comando CLI per l'agente per ispezionarlo.
- Misurazione dell'obiettivo, alla giusta risoluzione. Scegli lo strumento di misurazione con cura. Esempio reale: un giudice ingenuo "fai valutare a un LLM due screenshot" approva cloni UI con errori di spaziatura di 12px, perché gli LLM non possono effettivamente vedere le immagini, le convertono in embedding poi confrontano gli embedding. Quindi se vuoi cloni UI pixel-perfect, dai al tuo agente uno strumento di pixel-diff. Poi /goal finché pixel diff è 0.
- Contabilità del tempo. Timbra ogni esecuzione e ogni passo. L'agente dovrebbe sapere quanto tempo ha impiegato ogni passo, il tempo di clock totale trascorso. Il tempo è uno strumento di prima classe, non una nota a piè di pagina.
- Budget del provider. "Quanto stiamo bruciando sui crawler in questo momento?" dovrebbe essere un comando, non un'ipotesi. Tieni traccia dei crediti di scraping rimanenti, del consumo in questo loop, del consumo cumulativo e del consumo previsto prima del prossimo batch a pagamento.
- Spesa LLM. Dargli una chiave API LLM da usare nel data-plane può semplificare molta logica. Ma l'agente dovrebbe spenderli in modo responsabile, sapendo prima quanto sta effettivamente spendendo.
- Utilizzo Codex. Questo è un po' meta. Il loop dovrebbe essere auto-consapevole: quanti token sto spendendo su questa ottimizzazione? Utile per conoscere il gradiente del passo di ottimizzazione corrente.
Lo schema è il solito vecchio detto: non puoi ottimizzare ciò che non puoi vedere.
Se sei nuovo nell'eseguire questi loop, non avviarli e andartene. Siediti con il primo ciclo. Osserva cosa tocca. Conferma che l'harness che hai costruito viene effettivamente usato correttamente. Poi vai a letto. (E cerca di addormentarti senza pensare a ciò con cui ti sveglierai)
4. Entropia forzata
Perché l'entropia forzata è importante: ogni loop continua dal contesto intero dell'esecuzione precedente. Il modello non ricomincia da zero — sta leggendo le sue ultime cento decisioni e il gradiente che ha funzionato finora.
In un loop /goal, raggiungere i massimi locali è lo stato predefinito. Senza un calcio esplicito, l'agente continua a salire sulla stessa collina, e "la stessa collina" è ovunque si trovasse quando ha smesso di migliorare.
Ad esempio, se una piccola manopola migliora il risultato dello 0,1%, l'agente continuerà a girare quella manopola anche se ha altre 1000 manopole da provare.
L'entropia deve essere forzata nell'esecuzione esplicitamente, perché il modello non la adotterà da solo:
- Riflessione sull'overfit ogni ciclo. Sto costruendo una soluzione più generale o sto memorizzando la valutazione? Se sta memorizzando, la modifica successiva deve rimuovere un artefatto a forma di valutazione (limitare una lista, rendere cieca una caratteristica, ampliare la valutazione, rifiutare un seed), non aggiungerne uno.
- Forza entropia in caso di stallo. Se l'ultimo ciclo non ha mosso la metrica, il successivo non può essere "stessa idea, più dura". Il modello deve fare un vero salto non ovvio — "pensa fuori dagli schemi" è un buon prompt - impedisce all'agente di girare la stessa manopola più forte.
- Mantieni un log di iterazione. Fai in modo che l'agente registri l'ipotesi, la modalità di fallimento attesa, la diagnostica di ogni passo, in modo che possa guardare indietro e riflettere tra le compattazioni.
Il Meta-Meta-Prompt
All'inizio scrivevo questi obiettivi da solo, poi ho subito imparato che è un lavoro per gli agenti.
Così ho scritto una skill che produce questo tipo di obiettivi per una buona esecuzione di sviluppo della funzione di perdita.
Ora reso open-source qui:
https://github.com/elvisun/loss-function-development
/lfd-design per generare l'harness e l'obiettivo
Discesa del gradiente fino in fondo: i due loop
Fai un passo indietro ed è discesa del gradiente fino in fondo.
Il loop interno è l'agente: scrivere codice, eseguire test, correggere. Orizzonte breve, feedback veloce, un obiettivo — far passare i test. Questo è il loop interno di uno sviluppatore, e lo sviluppo guidato dalle specifiche è il modo in cui lo gestisci. Gli agenti di codifica lo hanno già automatizzato.
Il loop esterno è /goal: guidare l'intero sistema verso una metrica di risultato attraverso molti cicli — lanciare, misurare, cambiare rotta, scendere. Orizzonte lungo, feedback scarso. Questo è tradizionalmente il loop di un team di prodotto, i mesi di soak "lancia-misura-itera" compressi in un'unica esecuzione.
Entrambi i loop sono ora automatizzati. Quello che resta a te è definire la funzione di perdita — cosa esattamente dovrebbe ottimizzare il /goal e in che modo.
Stai distillando un prodotto — o qualsiasi cosa che lasci un artefatto pubblico
Un'altra lente: questo è essenzialmente distillazione, spostata dal tempo di training al tempo di prompt. È così che la linea DeepSeek, Kimi, Minimax ha chiuso la maggior parte del divario con GPT e Claude — addestra il tuo modello sugli output di qualcun altro finché i tuoi non li riproducono.
Ma invece di distillare un modello, puoi ora usare /goal e LFD per eseguire l'adattamento della distillazione a qualsiasi artefatto pubblicamente reperibile — non ispeziona mai gli interni e non ne ha bisogno.
Poggia sulla parola pubblicamente. Distillare l'output di qualcuno protetto da ToS, dietro login o a pagamento non è lecito. Ma ciò che è pubblicato apertamente — gli output che un'azienda pubblica per conquistare clienti — è sempre stato lecito da cui imparare. Questa parte non è nuova - è la mossa più vecchia nel software. La novità è che ora è economica e può essere fatta in ore invece che mesi.
Fai un passo indietro, ed ecco il cambiamento più grande. Il costo dell'esecuzione crolla a ~$0 ovunque ci sia simmetria informativa — quando gli output sono pubblici, tutti possono vedere come appare il "buono", quindi chiunque può distillarlo in un weekend per $40.
Quindi ecco un nuovo fossato che sta diventando sempre più prezioso: l'asimmetria informativa.
La società open-source canonica ha già battuto le palpebre. Nell'aprile 2026, cal.com ($5M ARR) ha reso privato il suo codice di produzione ed è passata a closed-source. La ragione che hanno dato si legge letteralmente come l'abstract di questo saggio: in un'era di minacce alla sicurezza guidate dall'IA, non puoi lasciare il tuo codice sorgente dove un agente può leggerlo.
"/goal leggi il codice sorgente di cal.com ed enumera la sua superficie d'attacco finché qualcosa non funziona"
Questo è un attacco troppo pericoloso e troppo facile da eseguire.
L'azienda la cui intera identità era "open source" ha deciso, nel 2026, che l'apertura era diventata un peso. Questo dovrebbe dirti tutto.
Per l'intera storia del software, "l'abbiamo costruito noi" era il fossato.
Quell'era sta finendo.
La prossima appartiene a chi possiede ciò che l'artefatto non ha mai contenuto: il set di valutazione che nessun altro può valutare. La lista di casi limite su cui i tuoi utenti inciampano effettivamente. La verità di base che misuri privatamente. Chiunque abbia l'obiettivo che l'agente del concorrente non può vedere è l'unico il cui loop continua a scendere.
Il prodotto è un weekend ora.
Vai a costruire la valutazione che un weekend non può toccare.
