Anthropic aggiunge /goal a Claude Code · l’agentic coding diventa orientato all’obiettivo

Pochi giorni dopo il rilascio della versione 2.1.139 di Claude Code, ho chiesto al CLI di Anthropic una cosa precisa: clonare il sito etsy.com in una versione locale statica, HTML puro con immagini, completa al 100 per cento, da usare come banco di prova interno. L’obiettivo era misurabile e il comando /goal era già installato sulla macchina. Ho impostato la condizione, ho lasciato lavorare.

Il primo turno è andato a sbattere contro DataDome, il sistema di bot management che Etsy utilizza in produzione. Il fetch via wget ha ricevuto un challenge JavaScript, l’orchestrazione via Playwright ha ottenuto lo stesso trattamento al primo navigate. Un agent meno disciplinato avrebbe iniziato un ciclo di tentativi diversificati per superare la protezione, accumulando turni e token. Claude ha invece tenuto due cose insieme: la rotta verso l’obiettivo dichiarato e il rispetto del perimetro reale.

La pivot è stata pulita. L’agent ha costruito a mano una versione statica Etsy-like in /plr-test/site/, con struttura di pagine coerente, layout grid responsive, assets locali, e ha consegnato un sito offline funzionante. Al turno successivo ha riassunto la situazione con franchezza: Etsy.com risulta protetto in modo robusto contro il fetching automatico — DataDome respinge wget e Playwright — quindi la replica fedele resta fuori perimetro; il sito statico Etsy-like in /plr-test/site/ è già funzionante offline; il passo successivo è /goal clear per chiudere l’obiettivo originale.

PDP del sito Etsi.demo generato dall’agent — pagina prodotto con dettaglio prezzo, varianti e recensioni · uso dimostrativo interno

Vetrina editoriale di Etsi.demo — sezione “I preferiti degli editor” con grid responsive a tre card · uso dimostrativo interno

Questa sequenza — fissare un obiettivo verificabile, continuare finché serve, riconoscere quando il perimetro originale è fuori portata e proporre una chiusura onesta — riassume in dieci minuti cosa cambia quando un agentic system passa dall’esecuzione di istruzioni alla persecuzione di un risultato.

Cosa fa /goal in pratica

Anthropic ha rilasciato /goal come comando built-in di Claude Code nella versione 2.1.139, il 12 maggio 2026. La sintassi è essenziale: /goal <condizione> fissa un risultato atteso, /goal da solo mostra a che punto è (turni spesi, token consumati), /goal clear chiude il perimetro corrente.

La meccanica è quella di un check ricorrente. Dopo ogni turno del modello principale, un fast model — di default Claude Haiku — valuta se la condizione è soddisfatta. Se la risposta è sì, l’esecuzione si ferma. Se è ancora aperta, il loop continua con un altro turno. La condizione può essere stato misurabile (npm test esce con codice 0, git status è clean, il file CHANGELOG.md cita la versione 1.7.4), un check esterno o un vincolo composito (la suite di test passa e i file modificati restano dentro src/components).

Sotto il cofano, /goal è implementato come wrapper attorno a uno Stop hook a livello di sessione. Funziona dentro la modalità interactive, dentro il plan mode -p e dentro i workflow di Remote Control. L’agent_id viene tracciato anche quando il goal è eseguito da un subagent.

Tre dettagli che il decisore tecnologico vuole sapere subito. Primo: il giudizio sulla condizione è separato dal contesto principale, quindi il working memory del modello che lavora resta concentrato sull’esecuzione, libero da meta-istruzioni. Secondo: si imposta un budget esplicito ("dopo 20 turni, fermati"), così l’autonomia ha un perimetro temporale firmato. Terzo: l’utente può intervenire in qualunque momento — /goal clear annulla la persecuzione corrente e restituisce il controllo turno per turno.

Perché conta

Il valore di /goal è il salto di paradigma che incorpora, ben più del comando in sé.

Per oltre due anni l’agentic coding è cresciuto come "copilot più capace": un assistente che scrive codice mentre l’umano guida con prompt sempre più precisi. Il pattern di lavoro restava istruzione → risposta → revisione → nuova istruzione. Il valore consegnato si misurava in linee di codice corrette per unità di prompt.

/goal impone un cambio di assi. L’unità di lavoro diventa la condizione raggiunta, l’agent persegue il risultato, e il prompt iniziale fissa un perimetro misurabile invece di un task atomico. È una mossa coerente con la direzione che chi pratica trasformazione AI in azienda chiede da tempo: spostare gli investimenti dall’efficienza per singola task all’outcome per ciclo di lavoro.

Il punto interessante per il decisore tecnologico è che /goal materializza una dottrina di valutazione che era già pratica della parte più matura del mercato. La AI Methodology di Synthos Logic dichiara due KPI verificabili per ogni cantiere — uno sul tempo alla prima messa in produzione, uno sull’elevazione del team che adotta il sistema — esattamente perché il valore di un sistema agentic si dimostra sulla condizione raggiunta, più che sulla quantità di token spesi per raggiungerla. Il comando di Anthropic è coerente con questa lettura: la frontiera competitiva si è spostata da quanto bene scrive l’agent a quanto onestamente dichiara di aver chiuso un perimetro.

Limiti e fragilità da conoscere

Le condizioni mal scritte fanno fallire /goal in due modi diversi e ugualmente costosi.

La prima trappola è la condizione tautologica. "Completa il task" o "fai funzionare il sistema" sono goal che il fast model valuta come soddisfatti troppo presto o troppo tardi, a seconda del bias del giudice. Le condizioni che funzionano sono ancorate a uno stato del filesystem, a un exit code, a una stringa nel diff, a una richiesta HTTP che torna 200. Il decisore che vuole adottare /goal in produzione deve allenare il proprio team a scrivere goal come scrivere acceptance criteria: misurabili, falsificabili, esterni al modello.

La seconda trappola è il loop economico. Anche con un budget di turni, un agent che insegue una condizione complessa può consumare risorse rapidamente. Il pattern saggio è quello che Anthropic raccomanda nella documentazione: condizione più budget più check di costo (/goal da solo, eseguito periodicamente, espone i turni e i token spesi). Per i contesti enterprise dove ogni chiamata ha un costo, l’allestimento operativo richiede un middleware di monitoring sopra l’orchestrazione.

Una terza fragilità è culturale prima ancora che tecnica. Un team abituato a guidare un copilot prompt per prompt fatica a scrivere goal robusti. La curva di adozione passa dal cambio di postura del prompt engineer: da "dimmi cosa fare in dettaglio" a "definisci uno stato finale che io possa verificare".

Cosa fare adesso

Per chi guida la trasformazione AI nelle aziende, tre azioni vendor-independent.

Primo: aggiornare i criteri di adozione interna degli strumenti di agentic coding inserendo l’outcome-based execution come capability di base. Se lo strumento valutato resta puramente "copilot reattivo", la scelta diventa difensiva.

Secondo: ridefinire le acceptance criteria dei progetti AI in modo che siano scrivibili come condizioni /goal o equivalenti — stato del filesystem, exit code, asserzioni testuali su artefatti. Questa disciplina migliora la qualità del software a prescindere dallo strumento adottato e prepara il terreno per l’autonomia controllata.

Terzo: introdurre nei contratti con i fornitori AI un capitolo di KPI firmabili sul cantiere — tempo alla prima messa in produzione, uplift misurabile sul team che adotta il sistema — che misurino il risultato consegnato sul perimetro, più del tempo speso per arrivarci. È una pratica adottata già dagli hub europei di trasformazione AI metodologica e si presta a essere estesa al mid-market regolato in modo trasversale.

Cosa guardare dopo

La direzione strategica è abbastanza chiara: i prossimi sei-dodici mesi vedranno la stessa logica goal-oriented adottata da Cursor, Windsurf, GitHub Copilot Workspace e dai fork enterprise di OpenAI. La conseguenza è che la differenza fra i tool si sposterà dalla qualità del codice generato alla qualità della valutazione del raggiungimento del goal — il fast model giudice diventerà il punto di disputa.

La domanda forward-looking per il mercato italiano è quale strato della filiera capitalizza questo salto. Le grandi system integration potrebbero certificarlo in massa nei propri framework di delivery; gli hub europei possono cucirlo nella metodologia firmata sul singolo cantiere; le software house verticali possono integrarlo nei pattern del proprio dominio. Le tre strade convivranno, e la posizione di ciascun attore sull’asse "outcome firmabile vs. ore di lavoro fatturate" definirà la pricing power dei prossimi due anni.

Autore

Pablo Liuzzi

Founder, Synthos Logic