Nella maggior parte delle conversazioni sull'ingegneria agentiva, l'azione è passata dal prompting all'operatività. Ecco una frontiera che scruta nella nebbia: fabbriche software, obiettivi, cicli, sessioni in background, subagenti, hook, sandbox, agenti che approvano agenti. Per molti creatori del futuro, questo comportamento sarà integrato nei prodotti fin dal primo giorno: Claude Code e Codex espongono direttamente questo cambiamento.
Dal punto di vista dell'ingegnere, utilizzerai una bassa autonomia per limitare i rischi e aumentare la reversibilità, ma userai una maggiore autonomia per attività esplicite e flotte di agenti paralleli che rifattorizzano in sicurezza enormi codebase. La domanda centrale su un'azione è sempre: quale livello merita questo compito e quale verifica rende quel livello difendibile?
Il confine della frontiera è l'agente manager che si attiva al suo trigger, delegando ai suoi aiutanti mentre verifica continuamente il loro output, e ritorna solo con le decisioni che devono essere prese da un umano. Le persone che utilizzano questo tipo di configurazione potrebbero già gestire centinaia o migliaia di agenti, in gran parte su codebase sempreverdi. Come gran parte del pensiero sull'autonomia, il modo in cui percepisci la scala è ancora diverso per ognuno.
La scala più spesso menzionata è quella di Steve Yegge a singolo asse, citata in "Welcome to Gas Town" e su The Pragmatic Engineer. È un buon riferimento se vuoi un numero che ti dica quanto sei AI-native: la scala ti fornisce un singolo numero per misurare se conosci la tua fiducia in un singolo agente. Ecco una versione:
All'inizio del 2026, anche mentre il lavoro cominciava a spostarsi dalla delega all'orchestrazione, questa era una discreta approssimazione per misurare il rischio. Oggi, tuttavia, molte competenze potrebbero aver aumentato significato e leva quando puoi eseguire molti agenti contemporaneamente. Un singolo gradino non può aiutarti a posizionare un'abilità multi-agente.
Invece, quasi ogni dibattito sull'autonomia che ho visto confonde due domande che dovrebbero essere separate: quanto lontano da noi stessi stiamo lasciando andare questo singolo agente, e qual è la nostra abilità nel coordinare molti agenti?
Per catturare queste due dimensioni separatamente, useremo due assi: agenzia e orchestrazione.
Sull'asse dell'agenzia, il livello basso include suggerire azioni candidate e aspettare una decisione.
Il livello medio significa che l'agente sta lavorando su un compito particolare, ma ne delimita l'ambito, e riferisce costantemente cosa fa insieme alle prove, così puoi continuare a guidarlo.
All'estremità dell'agenzia alta, l'agente lavora verso un obiettivo, sperimentando, imparando, testando, trovando modi per risolvere un problema, bloccandosi, facendo domande, provando approcci diversi, e restituisce tutto questo lavoro sotto forma di prove.
Sull'asse dell'orchestrazione, il livello basso significa un agente, un thread. A livello medio, hai diversi agenti, ognuno che lavora nel proprio worktree, possibilmente verso obiettivi diversi, ma isolati. All'estremità alta, hai un orchestratore che può prendere un backlog, un issue tracker, un programma o un'altra coda, e trasformarlo in lavoro continuo, e devi intervenire solo quando le cose falliscono: "gestione per eccezione". Prodotti e funzionalità che incorporano queste idee includono:
- Le modalità /plan, /goal, /loop, /background, /batch, /code-review, /security-review di Claude Code, subagenti, hook, checkpointing, pratiche di delega e gestione degli agenti, sessioni in background, pattern di team di agenti, argomenti /schedule
- I thread locali/cloud di Codex, la modalità Goal, i worktree, le Automations, i subagenti, i pannelli di revisione, la code review su GitHub, gli hook, il sandboxing, l'Auto-review e il rerun
Queste capacità non si adattano a un'unica scala.
La scalata: tre ere e un'unica pila
Se leggi la scala dal basso verso l'alto, stai immaginando di scalare contemporaneamente sia l'agenzia che l'orchestrazione. In effetti, i sei livelli rappresentano tre ere separate che tutti attraversiamo:
Prima, sei al posto di guida, e un agente per lo più aiuta, aspettando che tu lo guidi.
Secondo, l'agente prende il controllo di un compito o obiettivo delimitato, ma tu sei ancora lì per guidarlo e verificare cosa fa.
E terzo, nell'era dell'orchestrazione, il sistema è in grado di gestire lo spettacolo, smistando il lavoro tra molti agenti, e tu devi intervenire principalmente quando le cose vanno male: "gestione per eccezione".
Questo semplifica le cose, perché la posizione verticale sulla scala cattura perfettamente i due assi (l'orchestrazione entra in gioco solo vicino alla cima), lasciandola come una singola scalata costante attraverso i gradini. Eppure, la scalata fa ancora parte di un cambiamento che tutti stiamo attraversando.
Una buona giornata di ingegneria include toccare diversi gradini, a volte di più: è normale passare da un'era all'altra alcune volte nel corso di un compito.
I sei livelli in dettaglio
Livello 0: Assistenza
L'agente fa suggerimenti che sono per lo più buoni e spesso perfetti, ma deciderai sempre tu se sono abbastanza buoni per agire. Pensa all'autocompletamento, ai suggerimenti di modifica inline, o a rimanere in una sessione di chat a discutere un cambiamento di cui nessuno ha ancora preso possesso. Usalo per errori costosi, piccole modifiche, o quando stai formando il tuo giudizio. La verifica avviene principalmente localmente.
Livello 1: Azione supervisionata
L'agente modifica o esegue comandi per tuo conto, chiedendoti prima di eseguire qualsiasi cosa di conseguenza. Questa è la postura predefinita per la maggior parte delle persone. Può essere fatto in una sandbox locale con approvazioni prima di applicare le modifiche - dove ogni approvazione è una verifica indipendente che la modifica sia ok da applicare - o in una sessione interattiva. La modalità di fallimento è l'affaticamento da approvazione; tutte le approvazioni sembrano uguali indipendentemente da ciò che stanno approvando. Potresti risolvere questo problema dando un'occhiata al diff, seguendo alcune euristiche, verificando con un'altra persona prima di approvare, o semplicemente accettando di lasciare che l'agente sia responsabile. Codex Auto-review risolve questo problema delegando l'approvazione finale delle condizioni al contorno a un agente revisore separato.
Livello 2: Delega di compiti con ambito definito
Affida un compito delimitato all'agente. Quel compito avrà un obiettivo chiaro, vincoli e una definizione operativa di cosa significhi "fatto". Rimarrai nelle vicinanze, in grado di interrompere, ma per lo più non coinvolto. Questo è il centro di gravità nel mondo dell'ingegneria del software. La verifica si sta spostando da te (potresti aver bisogno di riposare e dormire) verso le prove che l'agente può produrre: test automatizzati superati, tipi corretti, suggerimenti di lint, screenshot, passaggi di riproduzione, provenienza tramite esempio, ecc.
Livello 3: Autonomia guidata dagli obiettivi
L'agente fa tutto il necessario per raggiungere un obiettivo, fermandosi solo quando una certa condizione è soddisfatta. In modalità prompt, questo significa che il prompt stesso diventa l'obiettivo (ad esempio, "Puoi ridurre il time-to-interactive di questa pagina sotto 1 secondo?"). In Codex, questa è la modalità Goal: l'agente cicla attraverso i passaggi plan->act->test->review finché non smette di soddisfare i criteri di successo. In Claude Code, sono i comandi /goal, /loop e /schedule. Perché questo livello sia utile, la condizione di arresto deve essere misurabile in modo da poter essere automatizzata.
Non chiedere al tuo agente di aiutarti con obiettivi vaghi e nebulosi come "migliorare l'esperienza utente in generale" o "rendere il codebase più testabile". Scegli qualcosa di specifico, misurabile e automatizzato: trovare bug in produzione che sfuggono all'analisi statica, ridurre il tempo di caricamento, assicurarsi di avere una build TypeScript rigorosa senza "any" espliciti, triare tutte le dipendenze per mantenere solo quelle che comprendiamo e che superano i nostri test, ecc. E, infine, per trovare bug in produzione, l'agente dovrà trovarsi in un ambiente simile a quello di produzione.
Livello 4: Delega parallela
Lavora su molti agenti in parallelo. Ogni agente lavora su una fetta isolata del compito. Il collo di bottiglia più grande a questo livello è la scomposizione: definire le fette giuste da delegare. I supporti includono: subagenti, sessioni in background, /batch, worktree, team di agenti, ecc. La modalità di fallimento è il falso parallelismo: eseguire molti agenti su fette sovrapposte contemporaneamente, così invece di più lavoro ottieni conflitti di merge e decisioni duplicate. Per farlo bene, gli agenti devono essere isolati l'uno dall'altro, ognuno con i propri file e stato. Ognuno deve anche avere la propria coda di revisione. E infine, ogni agente comporta un costo - in termini di token consumati - proporzionale al numero di agenti in esecuzione contemporaneamente. Dal lato umano, la tassa di orchestrazione fa sì che il costo marginale dell'aggiunta di un agente aumenti dopo pochi.
Livello 5: Orchestrazione gestita per eccezione
Definisci come si presenta il successo e quali politiche applicare. Un agente manager si attiverà in base a trigger (ad esempio, nuovo issue, nuovo compito, orario), invierà agenti worker, monitorerà i loro progressi, verificherà l'output, riproverà in caso di fallimento, escalerà ad agenti più competenti o umani quando le condizioni sono soddisfatte, aggregherà i risultati e, infine, restituirà prodotti di lavoro (ad esempio PR) e prove ai sistemi esterni. Pensa a una fabbrica: il tracker degli issue o il backlog è l'input, e il prodotto della fabbrica è l'output (cioè molti issue risolti, bug). Gli agenti lavorano in un ambiente opportunamente isolato con molti muri (e, se necessario, botole di fuga), e solo un sistema operativo - definito dall'agente manager - definisce cosa ci si aspetta che la fabbrica faccia.
La progettazione di questo sistema operativo è lasciata all'umano; OpenAI ha proposto una specifica per Symphony che ha una bacheca Linear al centro: ogni issue ottiene il proprio spazio di lavoro agente, e l'agente si assicura continuamente di progredire verso il suo obiettivo come definito in un file di specifica nel proprio spazio di lavoro. La revisione umana può essere fatta all'altitudine in cui vengono generate le prove, ma la frontiera (cioè ciò che è più potente nel mondo dell'orchestrazione) è costruire fabbriche di agenti continui con centinaia o addirittura migliaia di agenti. A questo punto della scalata, diventa sempre più importante avere una verifica indipendente: implementatori e revisori separati, esecutori di test e QA separati, controlli di sicurezza separati, gate di processo separati per l'accettazione.
Il rischio e la reversibilità fissano il soffitto.
Ricordo di aver letto un precedente studio di Anthropic su alcuni dei compiti più difficili con Claude Code in cui chiedeva chiarimenti più del doppio delle volte rispetto a quante gli utenti lo interrompevano. Gli utenti esperti (~750 sessioni contro meno di 50) erano più propensi ad auto-approvare e interrompere tenendo d'occhio i progressi.
Hanno anche fatto un'analisi più ampia di come le persone usano Claude Code. Hanno esaminato circa 400.000 sessioni di circa 235.000 persone tra ottobre 2025 e aprile 2026. Da ogni sessione potevano capire le decisioni che qualcuno prende, come quante azioni richiede in ogni prompt, quali di queste sceglie di auto-approvare, quanto spesso interrompe, ecc. Le persone prendono circa il 70% delle decisioni di pianificazione, ma Claude esegue circa l'80% dell'esecuzione. L'alta autonomia non significa escludere le persone dal ciclo, ma passare dal far fare loro ogni passo al far decidere loro in quale direzione andare dopo.
Se vogliamo determinare se un grande sistema AI sta operando con alta autonomia, le tre domande che dovremmo porci sono:
- Quanto velocemente sapremo di aver torto su ciò che sta facendo?
- Quanto pulitamente possiamo annullare ciò che sta facendo?
- Cosa proverebbe che abbiamo ragione su ciò che sta facendo?
Se la risposta a tutte e tre è: non rapidamente, con grande difficoltà, e fidandosi del riepilogo, non è alta autonomia.
Ogni esecuzione di un agente dovrebbe essere preceduta da un contratto che definisce cosa sta cercando di fare.
L'obiettivo: cosa stiamo cercando di raggiungere (non un'attività, non la tecnica, ma un risultato).
L'ambito: in quale dominio stiamo operando e quali tecniche sono consentite.
Non-obiettivi: cosa non fa parte dell'obiettivo.
Strumenti e permessi: come l'agente può interagire con il mondo. Condizione di arresto: quando fermarsi; idealmente, una variabile misurabile.
Prove: test specifici, screenshot, log, record di database o altri indicatori che possono essere utilizzati per confermare che qualcosa è stato fatto (indipendentemente dall'agente).
Escalation: chi viene coinvolto in quali circostanze (incluso chi esegue l'agente).
E budget: un limite su quanto tempo, impegno e token dedicare al compito (i token sono il budget dei grandi modelli AI - puoi anche includere un limite al numero di volte che può tentare il compito e un limite al grado di parallelismo).
Le metriche rendono l'autonomia solo un po' più affidabile
Decidere una metrica a posteriori probabilmente non è sufficiente. Le metriche possono essere messe in atto in anticipo, in un documento conciso. E questo rende l'autonomia più affidabile e rende il salto di fede un po' più facile da fare.
Sebbene ci siano molti modi per misurare il successo, considera di monitorare una versione di queste metriche per ogni livello di autonomia:
- Tempo medio tra gli interventi
- Esecuzione autonoma riuscita più lunga con lavoro accettato
- Quota di azioni eseguite in sandbox rispetto a quelle escalate
- Percentuale di azioni auto-approvate rispetto a quelle rifiutate
- Numero medio di azioni dell'agente per istruzione umana
- Tasso di richieste di chiarimento / Tasso di richieste di interruzione
- Tempo di revisione per modifica accettata
- Tasso di rilavorazione per ogni livello di confidenza
- Tasso di difetti sfuggiti per ogni livello di confidenza
- Costo in token per modifica accettata
Tali metriche possono raccontare una storia: un singolo agente tenuto occupato da passaggi di consegne umani è il Livello 4 con una dashboard. Un agente conservatore, riluttante a procedere senza intake automatizzato, tentativi e prove decenti, è il Livello 5 con un vero gate.
Pensa alla preparazione
Classifica il lavoro in base al rischio e a quanto facilmente può essere annullato. Applica l'autonomia in modo conservativo, aumentando solo man mano che le prove a sostegno del livello superiore si accumulano. Un refactoring del motore di pagamento protetto da test solidi e agenti revisori con un percorso di rollback pulito può supportare un'autonomia molto più elevata rispetto a un'attività di automazione della documentazione priva di qualsiasi verità canonica. Il livello di autonomia dovrebbe seguire il processo di verifica, non il nome del compito.
Quattro anti-pattern
Ogni sistema può facilmente cadere preda di questi quattro anti-pattern dell'autonomia se non vengono evitati con vigilanza.
Autonomia come status - il livello di autonomia di un agente diventa un distintivo di status privo di significato. Un'autonomia più elevata viene trattata come prova di capacità, non di sicurezza, e gli agenti vengono eseguiti a temperature più alte di quanto la verifica supporti. Soluzione: Loda e premia coloro che si stabiliscono sul livello corretto di autonomia ed evitano implacabilmente di oltrepassare i limiti.
Riciclaggio di permessi - la tirannia dell'affaticamento da approvazione ci porta a concedere agli agenti e agli strumenti AI un accesso enormemente più ampio del necessario. Soluzione: Confini migliori sono sempre una soluzione, come profili sandbox, radici scrivibili con ambito definito, comandi consentiti, hook e Auto-review.
Sostituzione del riepilogo - il riepilogo del lavoro dell'agente sostituisce la revisione, presumendo che il riepilogo sia sufficiente. Soluzione: Allega lo stesso pacchetto di prove delle revisioni completamente manuali (un diff, test, log, screenshot, risultati del revisore, rischi, lacune, ecc.) evitando al contempo la resa cognitiva.
Cospirazione di flotta - dozzine di agenti vengono eseguiti in parallelo, ma un umano persiste nell'orchestrare manualmente ogni dipendenza. Soluzione: Stato condiviso, regole di proprietà e un migliore tracciamento delle dipendenze riducono gradualmente la necessità di coordinarsi manualmente. Limiti WIP più piccoli costringono a concentrarsi sulla codifica e documentazione dei passaggi coordinati fino a quando l'orchestrazione non diventa automatizzata.
Un esercizio di calibrazione
Rivedi gli ultimi dieci compiti che hai intrapreso con l'assistenza di un agente. Per ogni compito, registra il livello di autonomia esercitato, il rischio coinvolto, quanto facilmente il lavoro poteva essere annullato, le prove prodotte per soddisfare i requisiti di verifica, il tempo di revisione, se è stata necessaria una rilavorazione e se il livello di autonomia scelto sarebbe ancora adatto la prossima volta.
Come scalare in sicurezza
Muoviti su un asse alla volta. Inizia con un singolo agente supervisionato per eseguire un singolo compito con ambito definito che produca prove difendibili del successo (un livello di autonomia 1, se abbastanza ordinato). Quindi espandi gradualmente nelle tre direzioni ortogonali. Parallelizza i compiti di esplorazione ad alta intensità di lettura (livello di autonomia 4). Aggiungi agenti di scrittura che agiscono su worktree separati con regole di proprietà dei file vincolate (livello di autonomia 4). Aggiungi automazioni ricorrenti, poi orchestrazione guidata dall'agente basata su issue, voce, ecc. Ogni passo verso l'alto richiede un nuovo insieme di meccanismi di sicurezza (come nuove modalità di fallimento).
Dai loro un nome: Esecuzioni di agenti singoli più lunghe possono portare a deriva, marciume del contesto, comunicazione persa o obiettivi deviati. Il lavoro in background può portare a presupposti obsoleti e passaggi di consegne deboli. Troppo lavoro parallelo può portare a conflitti di merge o decisioni duplicate. Troppo lavoro ricorrente può portare a spesa silenziosa di token o prompt obsoleti. La gestione per eccezione può portare a lunghe code di revisione e affaticamento da avvisi. Non risolvere fidandoti di più; invece, restringi l'ambito, assicura prove migliori, abilita percorsi di rollback più economici, indurisci i gate e definisci regole di proprietà più chiare.
Usa il livello di autonomia:
- Il Livello 0 è il migliore per lavori delicati e quando il giudizio si sta ancora formando.
- Il Livello 1 è il migliore per la maggior parte dell'esplorazione, se il lavoro viene svolto vicino ai confini di ciò che è ben compreso.
- Il Livello 2 è il migliore per la maggior parte dei compiti con ambito definito, sapendo che potrebbero esserci dipendenze sconosciute e imprevisti.
- Il Livello 3 è il migliore dove le condizioni di successo possono essere enunciate con sufficiente chiarezza.
- Il Livello 4 è il migliore quando il lavoro può essere suddiviso in modo pulito tra queste condizioni di successo.
- Il Livello 5 è il migliore una volta che il coordinamento e la comunicazione necessari tra le varie condizioni di successo sono completamente codificati.
La verifica sarà sempre il collo di bottiglia.
Nonostante l'attuale spavalderia e gli attuali strumenti, la postura matura di un team di ingegneria che lavora con agenti AI è l'autonomia calibrata.
I colli di bottiglia sono il coordinamento, la verifica, la manutenzione, il giudizio sul prodotto e l'apprendimento dagli incidenti
Nel prossimo futuro, vorremo progettare cicli che sappiano quando lavorare, quando verificare e quando chiedere - ma l'abilità dell'ingegnere risiederà ancora nello scegliere il giusto livello di autonomia e nel costruire pattern e prove difendibili che proteggano dai suoi lati più oscuri.
Nota: Pangram etichetta questo articolo come scritto al 100% da umani: https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26
