Codifica autonoma si sta spostando da un prompting migliore a sistemi di controllo migliori. Il cambiamento importante è che gli ingegneri stanno imparando a racchiudere gli agenti in obiettivi, valutatori, cicli e artefatti che permettano loro di continuare a lavorare dopo che l'umano smette di digitare.
Questo è importante perché la maggior parte del lavoro ingegneristico serio si estende su orizzonti lunghi: requisiti ambigui, vincoli nascosti, fallimenti parziali, contesto mutevole e verifica ripetuta. La nuova frontiera è progettare il sistema attorno all'agente in modo che possa pianificare, eseguire, verificare il proprio lavoro, riprendersi dagli errori e continuare a progredire senza una guida umana costante.
Questo articolo si basa su una sessione DAIR.AI Academy sugli agenti di codifica autonomi a lunga esecuzione, in cui ho esplorato la modalità /goal di Claude Code, il più recente comando /loop, verificatori, artefatti e pattern di orchestrazione nella pratica. Scritto in collaborazione con Codex e Claude Code.
Dal Prompting alla Progettazione degli Obiettivi
L'idea alla base di funzionalità come /goal di Claude Code è semplice. Un agente di codifica rimane l'esecutore, ma l'umano non interagisce più con esso turno per turno. Invece, l'umano specifica lo stato finale desiderato, l'evidenza necessaria per provare il successo, i vincoli che non devono essere violati e, dove possibile, il numero di turni e il budget.
Quell'obiettivo funziona più come un contratto che come un prompt più lungo. Un obiettivo debole lascia spazio al modello per fermarsi presto, prendere scorciatoie o ridefinire il successo in un modo che sembra plausibile nella trascrizione ma fallisce nel sistema reale. Un obiettivo forte dà all'agente un bersaglio rispetto al quale può misurarsi ripetutamente.
Il giudizio ingegneristico conta ancora qui. I migliori obiettivi codificano conoscenze di dominio che altrimenti il modello indovinerebbe. Per un esperimento di ricerca, ciò potrebbe significare un punteggio benchmark target, una valutazione su dati non visti, una curva di loss richiesta e una regola per cui il risultato deve superare una baseline iniziale. Per un'attività UI, potrebbe significare un riferimento screenshot, vincoli di layout concreti e un passaggio di verifica nel browser. Il modello può eseguire, ma l'umano definisce ancora cosa significa realmente "fatto".
Il Valutatore Diventa un Componente di Prima Classe
Gli agenti a lunga esecuzione necessitano di un secondo ruolo oltre all'obiettivo. Quel valutatore può essere un altro agente di codifica, un LLM-as-judge, uno script, una suite di test, un benchmark harness o un mix di tutti. La scelta progettuale chiave è abbinare il valutatore al compito. Quando il successo è netto, sono migliori i controlli deterministici. Controlli di tipo, test unitari, regole di lint, test di integrazione e script di benchmark dovrebbero essere usati ogni volta che possono esprimere chiaramente la condizione.
Quando il successo è sfumato, un valutatore agente diventa utile. Uno script può dirti se i test passano, ma non può facilmente decidere se un report di ricerca generato sia coerente, se un'implementazione segua fedelmente un articolo scientifico o se una UI corrisponda a un intento di design. È qui che il valutatore beneficia di linguaggio, giudizio e talvolta visione.
Il pattern pratico utilizza i controlli deterministici come base e la valutazione dell'agente come revisione di livello superiore. Questa combinazione riduce il successo allucinato pur consentendo l'autonomia su compiti che non si adattano perfettamente a un'asserzione di test.
I Verificatori Definiscono il Confine della Fiducia
Il punto più profondo è che l'autonomia funziona solo quando il sistema ha un verificatore affidabile. Un agente di codifica può generare un piano, implementare una funzionalità e spiegare perché crede che il lavoro sia completo, ma quella spiegazione non dovrebbe essere trattata come evidenza. L'evidenza proviene da un controllo esterno che l'agente non può facilmente aggirare con le parole.
Per il codice, il verificatore potrebbe essere una suite di test, un type checker, un benchmark, un'esecuzione nel browser, un confronto di screenshot o uno script riproducibile. Per il lavoro di ricerca, potrebbe essere una valutazione su dati non visti, una tabella riprodotta, una curva di loss o un punteggio benchmark che migliora la baseline. Per il lavoro di design, potrebbe essere uno screenshot di riferimento più un passaggio di revisione visiva. Il verificatore è ciò che trasforma un agente a lunga esecuzione da un generatore di testo sicuro di sé in un sistema di cui ci si può fidare per più tempo.
La maggior parte delle scorciatoie appare a questo confine. Se il verificatore è vago, il modello spesso soddisfa l'interpretazione più facile del compito. Se il verificatore è troppo stretto, il modello potrebbe sovra-adattarsi ad esso e perdere di vista l'intento più ampio. Un buon workflow autonomo, quindi, necessita di verifica a livelli, con controlli deterministici economici che intercettano i fallimenti di base e una revisione di livello superiore che intercetta i fallimenti che richiedono giudizio. Alcuni dei modelli più avanzati possono già raggiungere un certo livello di verifica, ma sulla base della mia ricerca, c'è ancora un evidente problema OOD (out-of-distribution), dove se il compito di verifica che assegni all'agente cade al di fuori della distribuzione di addestramento, i modelli faticano significativamente.
I verificatori sono ancora un'area di ricerca aperta, ma prevedo che molte aziende inizieranno a fare grandi investimenti in questo settore. Il concetto di verificatori fine-tuned è anche molto richiesto nelle imprese.
I Cicli Rendono l'Autonomia Durevole
Un obiettivo dà all'agente una direzione, ma un ciclo mantiene vivo il lavoro. Questa distinzione è importante perché i modelli spesso si fermano prima che il vero compito sia finito. Possono raggiungere un limite di turni, perdere fiducia, esaurire il contesto o decidere che una soluzione parziale è sufficiente.
Il ciclo è il sistema di controllo esterno. Si sveglia, ispeziona i progressi, esegue controlli, confronta il risultato con l'obiettivo e rimanda indietro l'agente con l'istruzione successiva quando l'obiettivo non è stato raggiunto. Nella sua forma più semplice, questo è il pattern del ciclo Ralph con un agente di codifica e una condizione deterministica. In una forma più flessibile, il ciclo include un agente valutatore che può ragionare sui progressi e decidere cosa dovrebbe succedere dopo.
L'autonomia a lunga esecuzione funziona come sforzo ripetuto sotto supervisione da un livello di controllo, non come un unico atto continuo di intelligenza. L'agente può ancora fallire, ma il ciclo dà al sistema un modo per notare il fallimento e continuare invece di dichiarare silenziosamente vittoria.
La Pianificazione è Dove Entra la Competenza
Uno dei temi più forti emersi dalla sessione è che la pianificazione rimane fondamentale. Puoi chiedere a un modello avanzato di generare un piano, ma devi comunque ispezionarlo, mettere in discussione le ipotesi e rendere i criteri di successo più precisi prima di affidare il compito a un ciclo autonomo.
Questo porta a una utile divisione del lavoro. Un modello di pianificazione più forte può aiutare a definire l'obiettivo, identificare vincoli mancanti e strutturare la valutazione. Un modello di esecuzione diverso può poi eseguire l'implementazione una volta che il piano è chiaro. In pratica, questo significa che gli ingegneri dovrebbero smettere di pensare a "il modello" come a una scelta singola. La scelta del modello diventa una decisione architetturale.
Alcuni modelli sono migliori pianificatori. Altri sono migliori esecutori. Alcuni sono valutatori più economici. Altri sono migliori nella revisione basata sulla visione. Un buon orchestratore ti permette di scambiare questi ruoli invece di aspettare che un singolo fornitore fornisca l'interfaccia perfetta per l'agente di codifica.
Gli Artefatti Visivi Diventano Superfici di Controllo
Le trascrizioni di terminale non scalano quando molti agenti sono in esecuzione. Una volta che hai diverse sessioni che lavorano in parallelo, il testo grezzo diventa un'interfaccia povera per comprendere i progressi.
Gli artefatti live sono importanti perché una dashboard con curve di loss, punteggi benchmark, stati delle attività, screenshot, stime di costo e decisioni recenti dà all'umano un modo molto migliore per supervisionare l'autonomia. L'artefatto diventa la superficie di controllo per decidere quando intervenire, anziché un report generato dopo i fatti.
Il pattern più utile è separare l'archiviazione dalla presentazione. Markdown o un vault possono archiviare evidenze durevoli, log, note, piani e risultati. Gli artefatti HTML possono rendere quello stato in qualcosa di visivo e interattivo. L'agente può cercare nel Markdown, mentre l'umano può monitorare l'artefatto.
Per il lavoro su UI e prodotto, gli indizi visivi sono particolarmente potenti. Un riferimento screenshot può comunicare l'intento di design più precisamente della prosa, e un valutatore con capacità visive può confrontare l'implementazione con quel riferimento. Questo riduce la modalità di fallimento comune in cui l'agente implementa tecnicamente il componente richiesto ma sbaglia spaziatura, gerarchia, allineamento o sensazione del prodotto.
Il Session Mining Trasforma l'Utilizzo in Memoria
Un'altra intuizione importante è che le sessioni passate degli agenti sono una ricca fonte di dati sul workflow. Se un agente fallisce ripetutamente nello stesso modo, dimentica di eseguire lo stesso controllo, usa il percorso sbagliato o riprova lo stesso comando rotto, quel pattern non dovrebbe rimanere sepolto nei log.
Il session mining trasforma quelle trascrizioni in regole operative. Un agente può scansionare gli ultimi trenta giorni di lavoro, trovare modalità di fallimento ricorrenti e proporre aggiornamenti alle istruzioni di progetto, agli apprendimenti del vault o alle regole dell'agente. Questo è il modo in cui un team può migliorare gradualmente il proprio harness senza ricordare manualmente ogni errore.
L'obiettivo è rendere l'ambiente locale più intelligente senza addestrare un modello da zero. Una piccola regola in un file di istruzioni dell'agente può prevenire fallimenti ripetuti in sessioni future, specialmente quando la regola è specifica per il progetto.
Un Modello Operativo Pratico
Per gli ingegneri AI, il workflow emergente è il seguente.
- Iniziare con un sottoinsieme piccolo ed economico prima di lanciare l'esecuzione autonoma completa.
- Scrivere un obiettivo con criteri di successo misurabili, vincoli espliciti e un budget di turni o tempo (dove possibile).
- Separare l'esecutore dal valutatore in modo che implementazione e giudizio non siano collassati in un unico ruolo.
- Definire verificatori esterni prima che inizi il ciclo a lunga esecuzione.
- Usare controlli deterministici quando possibile, quindi aggiungere la revisione dell'agente per criteri sfumati.
- Richiedere artefatti probatori come log, screenshot, curve di benchmark o file modificati.
- Estrarre dati dalle sessioni passate e promuovere lezioni ripetute in istruzioni di progetto.
Questa è la differenza tra usare un agente di codifica e progettare un sistema di codifica autonomo. Uno ti dà una conversazione. L'altro ti dà un harness.
Cosa Ancora Si Rompe
Niente di tutto questo rimuove i problemi difficili. Gli agenti prendono ancora scorciatoie. Si fermano ancora presto. Sopravvalutano ancora il completamento. Producono ancora piani sicuri di sé ma deboli, specialmente su articoli recenti, benchmark sconosciuti o sistemi al di fuori della loro distribuzione di addestramento.
Fidarsi di loro di più non risolverà questo. Sistemi di controllo migliori lo faranno. Obiettivi, cicli, valutatori, controlli deterministici, artefatti visivi e memoria di sessione sono tutti modi per rendere l'autonomia osservabile e correggibile.
La direzione è chiara. Il futuro degli agenti di codifica dipende da una migliore orchestrazione attorno a modelli più capaci, in cui gli ingegneri progettano le condizioni in cui gli agenti possono funzionare in sicurezza per ore o giorni e produrre comunque lavoro verificabile.
