Ho eseguito 1.000 agenti AI usando 6 passaggi, 5 prompt e 1 file (Guida per sviluppatori)

Prompting è morto nel 2024. La nuova skill è l'Orchestrazione

Ho gestito 1.000 Agenti AI per 30 giorni, ed ecco cosa ho scoperto

La skill che ha sostituito il prompting, e i sistemi che puoi usare già oggi.

Smetti di ottimizzare il tuo prompt. Non è più il collo di bottiglia.

Con un singolo agente in una singola finestra di chat, il prompt è gran parte del gioco.

Con dieci agenti che lavorano per ore, il prompt è un errore di arrotondamento.

Ciò che determina la qualità del lavoro è il sistema attorno agli agenti:

• in quale modalità viene eseguita ogni attività
• quale modello esegue quale passaggio
• come gli agenti si coordinano
• come viene verificato il "fatto" mentre dormi

Un prompt ti dà un singolo output. Un loop ti dà un'operazione che si accumula.

Il cambiamento è semplice. Smettere di essere la persona che legge ogni risultato e scrive l'istruzione successiva. Diventi la persona che progetta il sistema una volta e lo lascia eseguire.

Quel livello di progettazione è il lavoro ora. Ecco come costruirlo.

Costruisci l'orchestratore, non il codice

Non gestisci trenta agenti parlando con trenta agenti. Parli con uno. Quello è l'orchestratore, e gestisce tutti gli altri.

Un buon orchestratore fa esattamente tre cose:

1. Decomporre un obiettivo in sotto-attività delimitate e verificabili indipendentemente.
2. Delegare ogni sotto-attività a un worker, con un brief preciso e una chiara proprietà dei file.
3. Assembla i risultati e decide cosa fare dopo.

Una regola è al di sopra di tutte le altre: l'orchestratore non fa mai il lavoro da solo.

Nel momento in cui il tuo agente principale inizia a scrivere codice di implementazione, il suo contesto si riempie di dettagli e perde il filo dell'intero lavoro.

Mantieni il suo contesto pulito. Pensa, suddivide, assegna e controlla. Nient'altro.

Poi vai in profondità, non in ampiezza:

• Non far generare direttamente otto worker all'orchestratore. Questo frantuma il suo contesto.
• Fallo invece generare due o tre lead.
• Lascia che ogni lead generi i propri due o tre specialisti.

Il risultato è una profondità di scomposizione tripla allo stesso costo di contesto. È così che scala una vera organizzazione, attraverso i livelli, non facendo assegnare ogni compito a una singola persona.

Verificabile o no: la divisione che decide tutto

Prima di costruire qualsiasi cosa, fai una domanda sul compito. Una macchina può verificare se è stato completato?

Questa risposta determina l'intero approccio.

Se il compito è verificabile, puoi metterlo in un loop:

• I test passano o non passano.
• Il type checker è verde o non lo è.
• Il benchmark supera la soglia o non la supera.

Punta un agente su un compito verificabile e lui lo scalerà come una collina durante la notte. Ti svegli con un problema risolto.

Se il compito non è verificabile, un loop da solo non ti salverà. Esempi:

• Progettare una buona eval.
• Decidere se un'API è "giusta".
• Giudicare se una direzione di ricerca vale la pena di essere perseguita.

Per questi, devi iniettare il gusto. Non puoi consegnare l'obiettivo e andartene, perché non c'è un cancello dove fermarsi.

Quindi la mossa è rendere verificabile più lavoro possibile:

• Trasforma "rendilo buono" in "supera questi controlli specifici".
• Sostituisci obiettivi vaghi con obiettivi concreti e misurabili.
• Dove non puoi, tieni un umano nel loop e guida.

Gran parte dell'ingegneria dell'orchestrazione consiste nel convertire obiettivi fuzzy in obiettivi verificabili, così che il loop possa prendere il sopravvento.

Inizia con il sistema reale più piccolo: un goal loop

Un goal loop è un obiettivo persistente più un controllo deterministico. L'agente lavora passo dopo passo verso un target invece di fermarsi dopo un turno.

L'intero sistema è un loop attorno al tuo agente e a un validatore:

1i=0
2until npm test -s; do
3  agent -p "Goal: far diventare verde la suite di test.
4            LEGGI il codice e costruisci un quadro completo PRIMA di cambiare qualsiasi cosa.
5            'npm test' sta fallendo. Fai la modifica più piccola possibile per far passare i test."
6  (( ++i > 20 )) && { echo "stop: 20 iterazioni"; exit 1; }
7done

Il validatore è qualsiasi comando il cui codice di uscita è il cancello. Test, un typecheck, un lint o uno script personalizzato.

Due cose sono non negoziabili:

1. Un limite. Un loop senza condizione di arresto è il modo per svegliarsi con una bolletta di token a cinque cifre.
2. Un'istruzione "leggi prima". La modalità di fallimento predefinita di ogni agente è sparare a caso sulla prima soluzione plausibile invece di leggere il codice.

Forza la lettura. È più lenta per passaggio, ma molto più veloce nel complesso.

Rendi il "fatto" non negoziabile: il giudice

Gli agenti smettono presto. Sono addestrati a fermarsi nel momento in cui possono giustificarlo.

"Ho fatto del mio meglio, mi fermo qui" non è la stessa cosa di "fatto".

Se un agente valuta i propri compiti, imbroglia. Non in modo malevolo. Si convince semplicemente di aver finito.

La soluzione è un giudice separato:

• Un secondo agente il cui unico compito è valutare il lavoro rispetto a una rubrica concreta.
• Risponde a una domanda: fatto o non fatto, e cosa manca.
• Non ha alcun interesse a fermarsi, quindi non esita.

Esegui il costruttore e il giudice su famiglie di modelli diverse. Famiglie diverse commettono errori non correlati, quindi il giudice vede ciò a cui il costruttore è cieco.

1while :; do
2  agent --model "$BUILD" -p "Task: $TASK. Leggi prima, implementa, esegui i test."
3  verdict=$(agent --model "$JUDGE" -p "Revisore severo. Valuta rispetto a ogni elemento in rubric.md.
4            Rispondi esattamente 'PASS' o 'FAIL: <cosa manca>'.")
5  [[ $verdict == PASS* ]] && break
6done

Rendi la rubrica concreta e binaria:

• Buona rubrica: "tutti i test verdi, migrazione inclusa, nessun debug logging."
• Cattiva rubrica: "rendilo buono."

Un controllore disinteressato con diritto di veto è l'unica cosa che permette a un'esecuzione di continuare per ore invece di crollare nel momento in cui il worker si stanca.

Attivalo al completamento di ogni attività. Poi vedrai solo lavoro approvato con verdetto verde.

Altri loop che userai davvero

Il goal loop è lo schema di base. Alcune varianti coprono la maggior parte di ciò che eseguirai.

1. Il validation loop.

Agisci, esegui il validatore, rimanda il fallimento indietro, ripeti fino a quando il cancello è verde.

Usalo per regression sweep, type check e qualsiasi passaggio o fallimento deterministico.

2. Il queue and reset loop.

Suddividi il lavoro in una lista di piccole attività atomiche. Elaborane una alla volta.

Dopo ogni attività, resetta l'agente a un contesto pulito e passa alla successiva.

Un contesto che funziona per ore si riempie di confusione. Il reset mantiene ogni attività pulita.

La memoria vive al di fuori dell'agente, nel file delle attività e nella cronologia dei commit.

1while read -r task; do
2  agent -p "Task: $task. Leggi prima. Implementa, poi esegui i test."
3  npm test -s && git commit -aqm "auto: $task"   # committa solo a verde
4done < tasks.txt

3. Il monitor loop.

Punta un agente su un flusso di segnali e lascia che emerga ciò che conta. Issue aperte, build fallite, log di errore, nuovi feedback.

Non aspetta che tu glielo chieda. Legge, tria e riporta verso l'alto, oppure apre una bozza di fix.

1while sleep 300; do
2  agent -p "Leggi gli ultimi 5 minuti di log degli errori. Se appare un NUOVO pattern,
3            apri un'issue con una riproduzione minima. Altrimenti di' 'niente di nuovo'."
4done

4. Il plan-then-build loop.

Esegui il loop in due fasi. Prima un passaggio di pianificazione che produce un piano scritto e si ferma.

Tu revisioni il piano. Poi un passaggio di esecuzione segue il piano approvato.

Il piano è economico da correggere. Il codice è costoso da correggere. Cattura la direzione sbagliata nel piano.

I prompt che fanno il lavoro

Un prompt non è un desiderio. Per un agente, è una specifica.

Il divario tra un output mediocre e uno eccellente è quasi interamente la qualità di questi.

Tieni un piccolo set di prompt riutilizzabili. Cinque coprono la maggior parte del lavoro.

1. Il prompt di scomposizione, per l'orchestratore:

1Sei l'orchestratore. NON scrivere codice.
2Suddividi questo obiettivo in 3-6 sotto-attività delimitate.
3Per ognuna: un brief di una riga, i file esatti che possiede e il suo done-check.
4Segnala qualsiasi attività che dipende da un'altra. Restituisci la lista, poi fermati.
5Obiettivo: <obiettivo>

2. Il brief del worker, per uno specialista:

1Possiedi SOLO questi file: <file>.
2Task: <una riga>. Fatto quando: <controllo verificabile>.
3Leggi quei file e i loro chiamanti PRIMA di modificare. Non cambiare nulla al di fuori dei tuoi file.
4Quando hai finito, scrivi un report di 5 righe in <nome>.md, poi esegui i test.

3. Il prompt del giudice, per una famiglia di modelli diversa:

1Sei un revisore severo e senza indulgenza. Non hai scritto questo codice.
2Valuta il repository rispetto a OGNI elemento qui sotto. Una mancanza è un FALLIMENTO.
3<rubrica>
4Rispondi con esattamente una riga: 'PASS' o 'FAIL: <cosa manca>'.

4. Il prompt plan-first, per la modalità piano:

1Producici un piano scritto per <obiettivo>. Copri: approccio, file da toccare,
2casi limite, strategia di test e cosa NON farai.
3Non scrivere ancora codice. Fermati dopo il piano in modo che io possa revisionarlo.

5. Il prompt reflect-or-kill, quando un agente è bloccato:

1Hai fallito lo stesso controllo 3 volte. Smetti di ripetere l'approccio.
2Rispondi in 3 righe: cosa è fallito esattamente, quale presupposto era sbagliato,
3e la più piccola cosa diversa da provare. Poi prova SOLO quella.

Un pattern attraversa tutti e cinque. Indica il ruolo, i confini, il done-check e cosa NON fare.

Il routing dei modelli: la domanda che tutti fanno

La domanda è solitamente inquadrata come una scelta. Metto il modello costoso sulla pianificazione o sull'implementazione?

Questo è il quadro sbagliato. Instrada invece per raggio di danno. Chiediti dove un errore ti costa di più.

La logica è semplice:

• Una decisione sbagliata nella pianificazione si propaga attraverso l'intera flotta.
• Una riga sbagliata in una singola funzione delimitata e testata viene scoperta in pochi minuti.
• Quindi spendi dove gli errori sono costosi e irreversibili, e risparmia dove sono economici e contenuti.

Ecco il routing, livello per livello:

1. Pianificazione, architettura e scomposizione: livello superiore, sempre. La leva più alta, volume di token minimo. Risparmiare qui è l'errore più costoso che tu possa fare.
2. Implementazione con specifica stretta: livello medio, esegui in parallelo. La specifica ha fatto il pensiero. Verifica con i test.
3. Implementazione con specifica lasca: livello superiore. Il riempimento dei vuoti è ragionamento, e un modello economico indovina male in una dozzina di direzioni.
4. Revisione e giudizio: una famiglia diversa, e non economica. È qui che si individuano gli errori costosi.
5. Navigazione, ricerca, riepilogo e classificazione: il modello più economico e veloce. Zero ragionamento, alto volume. Non pagare mai tariffe premium per un grep.

Quindi la vera risposta a "pianificazione economica o implementazione economica" non è nessuna delle due, ciecamente.

Modello top su pianificazione e revisione, sempre. L'implementazione è quella variabile.

Famiglie di modelli diverse hanno anche personalità diverse, e questo conta per il routing:

• Una famiglia riempie i vuoti. Quando la specifica è lasca, fa presupposti ragionevoli e va avanti. Questo aiuta quando i presupposti sono buoni, e danneggia quando non lo sono.
• Un'altra famiglia è letterale. Fa esattamente ciò che hai detto e poco più, come un coltellino multiuso di precisione.

Usa il riempitore di vuoti dove il lavoro è aperto e la specifica è lasca. Usa quello letterale per la revisione e per modifiche esatte e ben specificate.

La leva che controlla l'implementazione è la tua specifica

• Una specifica stretta ti dà il diritto di eseguire worker paralleli ed economici.
• Una specifica lasca ti costringe a tornare su un modello costoso per riempire i vuoti.

Investi nel piano proprio per poter rendere più economica la build.

Una trappola merita di essere menzionata. Il routing economico ottimizza il prezzo di ogni chiamata, ma può distruggere silenziosamente la quota di token che producono output unibile e consegnabile.

Un modello economico che riprova cinque volte e produce codice che non puoi unire è più costoso di un singolo passaggio pulito da un modello premium.

Misura il costo dell'output utile, non il costo per chiamata.

Per la scala, due numeri aiutano:

• Il tuo livello superiore costa circa cinque volte il prezzo per token di output di un livello economico.
• Il routing a livelli in genere riduce la spesa del 40% al 60% rispetto all'esecuzione del tuo miglior modello ovunque.

Skills: impacchetta un workflow una volta, riutilizzalo per sempre

Quando continui a incollare lo stesso prompt o a eseguire lo stesso workflow, trasformalo in una skill.

Una skill è un piccolo file di istruzioni che l'agente carica solo quando è rilevante.

Scrivi il workflow una volta, e ogni agente può attingerci.

Un file skill ha due parti:

• YAML frontmatter con un nome e una descrizione.
• Un corpo in markdown con le istruzioni effettive.

La descrizione è la riga più importante. Dice all'agente cosa fa la skill e esattamente quando usarla, in modo che l'agente la raccolga da solo senza che tu la nomini.

Un file skill minimo:

1---
2name: revisione-termonucleare
3description: Revisione del codice approfondita e antagonistica. Da usare dopo qualsiasi modifica non banale,
4  o quando viene richiesto di revisionare, verificare o irrobustire un diff prima del merge.
5---
6
7# Revisione termonucleare
8
9Leggi l'intero diff e i file che tocca. Non sfogliare superficialmente.
10
11Revisiona in tre passaggi:
121. Correttezza: errori logici, casi limite, race condition, errori off-by-one.
132. Sicurezza: injection, autenticazione, segreti, input non sicuri, operazioni distruttive.
143. Adeguatezza: corrisponde all'architettura esistente o introduce un nuovo pattern?
15
16Per ogni scoperta: file, riga, gravità e la correzione in una riga.
17Concludi con un verdetto: SHIP o BLOCK, più le prime 3 cose da correggere.

Regole per buone skill:

1. Tieni il file breve. Sotto poche centinaia di righe. Sposta il materiale di riferimento lungo in file separati a cui la skill punta.
2. Fai corrispondere il nome alla sua cartella, altrimenti non verrà caricato.
3. Scrivi la descrizione per l'attivazione. Specifica i casi di "usa quando".
4. Non permettere mai a un agente di riscrivere una skill. Un umano cura ogni riga.

Le skill sono il modo in cui un workflow si accumula. La prima volta che risolvi qualcosa bene, lo salvi e lo rendi scopribile. Ogni sessione successiva, è gratis.

Eseguirne molti: la flotta

Una volta che un loop funziona, lo scalì.

Dai a ogni worker due cose:

• Il proprio git worktree, così nessun agente tocca mai gli stessi file.
• La propria finestra di terminale, così puoi guardarlo e mandargli messaggi.

1tmux new-session -d -s fleet
2for name in hilbert gauss poincare; do
3  git worktree add -B "agent/$name" "../wt-$name" main
4  tmux new-window -t fleet -n "$name" -c "../wt-$name" "$AGENT"
5done

• Dai un nome ai tuoi agenti. Eseguirne quindici, chiamarli "agent_7" è inutile.
• I nomi ti permettono di tenere a mente l'intera flotta. Questo possiede il data layer, quello scrive le eval, quell'altro revisiona.
• La leggibilità è il punto. Una flotta che non puoi tracciare è una flotta che non puoi guidare.
• Poi falli cooperare. Di default, gli agenti si ignorano a vicenda e trattano qualsiasi cosa da un pari come rumore di fondo.

Il trucco è consegnare messaggi tra agenti come turni utente. I modelli sono addestrati a rispondere all'utente e a ignorare per lo più i segnali ambientali.

1send() { tmux send-keys -t "fleet:$1" "$2" Enter; }
2send hilbert "GET /search?q= restituisce [{id,title,url}]. Collega l'interfaccia utente a questo."

Quella singola mossa trasforma un mucchio di processi isolati in un team che si passa i compiti e si sblocca a vicenda.

Tu rimani al vertice. Messaggi al lead, e il lead li inoltra ai worker.

Workflow dinamici: compila il coordinamento in codice

Un loop mantiene il coordinamento all'interno del modello. Il modello decide ogni passo, il che consuma token e riempie il suo contesto.

Un workflow dinamico inverte tutto questo. L'orchestratore scrive uno script che coordina i worker, e un runtime separato esegue lo script in background.

L'idea chiave è dove risiede lo stato. Il loop, la ramificazione e i risultati intermedi risiedono nelle variabili dello script, non nella memoria del modello.

Cosa ti compra questo:

• I costi di coordinamento sono zero token del modello, perché lo sta facendo codice semplice.
• Il tuo contesto principale rimane pulito. Solo il risultato finale torna indietro.
• Si espande in larghezza. Decine di worker alla volta, fino a un migliaio in una singola esecuzione.

Quando ricorrervi:

• Il pattern è noto e la verifica è oggettiva.
• Il lavoro è ampio e ripetitivo. Molti file, molti casi, molti endpoint.
• Può essere eseguito senza supervisione.

Quando non ricorrervi:

• Stai ancora cercando di capire cosa fare. Quello è un goal loop, non un workflow.
• Il compito richiede una singola catena di ragionamento coerente. Quello vuole un singolo agente forte, non un migliaio.

Una forma concreta. Supponi di dover migrare 200 file a una nuova API:

1// l'orchestratore scrive questo una volta; un runtime lo esegue, non il modello
2const files = await glob("src/**/*.ts");
3
4const results = await mapLimit(files, 16, async (file) => {
5  const r = await subagent(`Migra ${file} alla nuova API. Esegui i suoi test.`);
6  return { file, ok: r.testsPassed };
7});
8
9const failed = results.filter(r => !r.ok);
10return `migrati ${results.length - failed.length} di ${results.length}. ` +
11       `riprova: ${failed.map(f => f.file).join(", ")}`;

Leggi cosa fa:

1. Elenca i 200 file nel codice, non nella testa del modello.
2. Esegue 16 subagenti alla volta, ognuno migra un file ed esegue i suoi test.
3. Registra pass o fail per file in un semplice array.
4. Restituisce un breve riepilogo. Le 200 trascrizioni intermedie non toccano mai il tuo contesto.

Questo è l'intero punto. Il modello ha fatto il pensiero una volta, per scrivere lo script. Lo script ha fatto il coordinamento, gratuitamente.

Guardrail: cosa impedisce a una flotta di auto-distruggersi

Il collo di bottiglia umano un tempo faceva il lavoro vero. Alla velocità umana, gli errori fanno male subito e li correggi man mano.

Se ti rimuovi completamente, i piccoli errori si accumulano più velocemente di quanto tu possa sentirli. Una duplicazione qui, un'astrazione inutile là.

Un giorno l'architettura non si piegherà più, e i tuoi test non saranno affidabili perché anche quelli li hanno scritti gli agenti.

Ogni guardrail qui sotto sostituisce la correzione che il collo di bottiglia forniva un tempo:

1. Leggi prima di indovinare. Rendilo una regola fissa in ogni prompt di build, non una supplica per ogni attività.
2. Limita e uccidi. Ogni loop ha un limite di iterazioni. Ogni agente ha un budget di token che si mette in pausa automaticamente vicino all'85%. Dopo tre iterazioni bloccate sullo stesso errore, uccidi l'agente e passa il compito a uno nuovo.
3. Un file, un proprietario. Isola con i worktree. Non permettere mai a due agenti di modificare lo stesso file.
4. Re-inietta la missione. Nelle esecuzioni lunghe, pubblica la checklist come messaggio utente ogni pochi minuti in modo che l'agente non derivi mentre il suo contesto si riempie.

1while sleep 900; do
2  send gauss "PROMEMORIA: ancora sul compito? Leggi prima. Esegui i test dopo ogni modifica. Rimani nei tuoi file."
3done &

Il punto più profondo sta sotto tutto questo:

• La verifica è ora il collo di bottiglia, non la generazione.
• Gli agenti producono output plausibile più velocemente di quanto tu possa verificarlo.
• Plausibile non è corretto.

Fino a quando la tua verifica non sarà veloce quanto la tua generazione, la revisione umana non è un sovraccarico. È il sistema di sicurezza.

Memoria: tu sei l'archivio a lungo termine

Un modello ha la memoria a breve termine, la finestra di contesto, e nient'altro. Tutto ciò che è oltre quella finestra è sparito a meno che tu non lo porti con te.

Quindi tratta te stesso e i file che conservi come la memoria a lungo termine per agenti che hanno solo memoria a breve termine.

Due abitudini contano.

Primo, passa lo stato per riferimento, non per riepilogo:

• Quando un contesto si riempie, la soluzione pigra è riassumerlo. I riassunti sono con perdita e lasciano cadere i dettagli di cui avrai bisogno in seguito.
• Invece, punta gli agenti a file, registri di attività e output precedenti che possono rileggere. Niente di importante viene buttato via silenziosamente.

Secondo, mantieni la memoria durevole al di fuori dell'agente:

• Un file di attività con stati.
• Un registro di avanzamento continuo.
• La cronologia dei commit.
• Un file di appunti a lungo termine che raccoglie pattern e insidie.

Progetta come se i tuoi agenti dovranno funzionare per giorni, perché con una buona compattazione lo faranno.

I modelli non lo sanno ancora di sé stessi. Portano un pregiudizio verso la risoluzione di tutto all'interno di un unico budget breve, come se spendere token fosse fatale. La tua impalcatura è ciò che permette loro di funzionare a lungo senza perdere il filo.

Topologia: quanti agenti, e in quale forma

Più agenti non significa più output. Oltre un certo punto è meno, perché il coordinamento non è gratuito e si accumula con ogni agente che aggiungi.

La regola che conta è abbinare la forma al lavoro:

• Il ragionamento sequenziale e dipendente vuole meno agenti, a volte uno solo. Suddividere una singola catena di pensiero frammenta il ragionamento e degrada il risultato.
• Il lavoro indipendente e parallelo vuole che ti espandi. Topologia piatta, proprietà pulita dei file. È lì che il parallelismo paga.
• Un team coordinato vuole da tre a cinque worker. Il costo dei token scala approssimativamente in modo lineare con la dimensione. Il costo del coordinamento scala peggio. Tre worker concentrati battono cinque worker sparpagliati.

Quindi come fa qualcuno a eseguirne centinaia? Non come un'unica conversazione gigante che litiga con sé stessa.

Li eseguono come profondità e indipendenza:

• Alcuni agenti con cui parli davvero, ognuno che delega verso il basso a sotto-attività delimitate che non hanno bisogno di coordinarsi.
• Sciami di loop indipendenti che fanno le loro cose e riportano verso l'alto.

La scala arriva dalla profondità di delega e dall'indipendenza. Mai dall'allargare un singolo thread.

Il file di controllo: orchestration.md

Probabilmente tieni un file che dice agli agenti come scrivere codice nel tuo repository. Stile, insidie, architettura. Tienilo.

Tuttavia, risponde alla domanda sbagliata per l'orchestrazione.

Il file orchestration.md risponde a una domanda diversa. Come dovrebbe essere eseguito il lavoro qui?

È un contratto scritto da umani che copre:

• quale modalità usare per quale attività
• quale livello di modello va dove
• quali sono i guardrail
• quando escalation a un umano

Ogni agente lo legge all'inizio di ogni sessione e lo usa per autoselezionare il proprio approccio.

Questo è il file con la leva più alta nel repository. Sposta la decisione di selezione della modalità fuori dalla tua testa, dove la riprendi in modo incoerente ogni sessione, e dentro una specifica che la flotta segue.

Una versione breve assomiglia a questa:

1# orchestration.md. Come il lavoro viene ESEGUITO qui. Curato da umani. Gli agenti non devono modificare.
2
3Scegli la modalità:
4- Goal loop (supervisionato): lavoro fuzzy o di progettazione. Definisci il controllo di completamento.
5- Validation loop: cancello deterministico. Limita sempre iterazioni e costo.
6- Build più giudice: worker costruisce, un giudice di famiglia diversa approva.
7- Fleet (da tre a cinque): sotto-attività interdipendenti, worktree isolati, messaggistica tra pari.
8- Queue and reset: molte piccole attività atomiche, contesto fresco ogni volta.
9- Workflow dinamico: pattern noto, cancello oggettivo, ampio e ripetitivo. Coordinamento nel codice, senza supervisione.
10
11Instrada i modelli per raggio di danno:
12- Pianificazione e architettura: livello superiore, sempre.
13- Build, specifica stretta: livello medio, parallelo, verifica con i test.
14- Build, specifica lasca: livello superiore, perché il riempimento dei vuoti è ragionamento.
15- Revisione e giudizio: una famiglia diversa. Mai il modello dell'implementatore.
16- Navigazione, ricerca, riepilogo: il più economico. Ottimizza l'output unibile, non il prezzo per chiamata.
17
18Guardrail:
19- Budget di token per agente. Pausa automatica vicino all'85%. Uccidi e riassegna dopo 3 tentativi bloccati.
20- Qualsiasi esecuzione oltre un'ora necessita di un giudice separato. I worker non si auto-dichiarano mai completi.
21- Leggi il codice prima di formulare ipotesi. Pianifica per iscritto prima della prima modifica.

Due regole governano il file:

1. Tienilo breve.
2. Non permettere mai a un agente di riscriverlo.

Il valore è che un umano ha curato ogni riga.

Cosa rimane tuo

L'orchestrazione rende gli agenti affidabili nell'esecuzione. Non sceglie il problema e non sa cosa sia "buono".

Tre cose rimangono dalla tua parte della linea, permanentemente.

Primo, delega i compiti, non il giudizio:

• Affida agli agenti lavoro con ambito definito e criteri chiari di passaggio o fallimento. Boilerplate, migrazioni, scaffolding di test e approcci che non avresti mai tempo di provare manualmente.
• Tieni per te l'architettura, la decisione su cosa non costruire e la revisione a contesto completo.
• Gli agenti hanno assorbito un oceano di architettura mediocre, e replicheranno felicemente pattern pesanti e superflui in un progetto che non dovrebbe averli. Dire di no è una caratteristica che non hanno.

**Secondo, la tua specifica è la leva:</think>Il testo da tradurre non è stato fornito. Per favore, fornisci il testo in inglese che desideri tradurre in italiano.

• Quando ti espandi su una flotta, il pensiero vago non ti rallenta e basta: si moltiplica.
• Un requisito ambiguo si propaga attraverso dozzine di esecuzioni parallele, ognuna deviando nella propria direzione.
• Una specifica precisa si moltiplica in implementazioni precise ovunque.

Ecco perché un ingegnere bravo ottiene di più da questi strumenti, non meno. La digitazione è stata automatizzata. La comprensione è stata amplificata.

Passa la maggior parte del tempo in modalità pianificazione, su un piano scritto su cui tutti sono allineati, prima della prima modifica.

Terzo, sottofinanzia di proposito:

• Assegna due agenti a un lavoro che ne richiederebbe quattro. Il vincolo forza il comportamento che desideri.
• Costruisci cicli invece di fare le cose a mano, e la prossima volta quel lavoro sarà già automatizzato.
• Sposta il budget dallo sforzo manuale ai token. Investimento iniziale alto, costo marginale quasi zero per sempre.

I team che fanno così crescono in modo esponenziale. Quelli che non lo fanno pagano il prezzo pieno ogni volta.

Non stai più scrivendo il software. Stai costruendo la fabbrica che lo scrive.

Una fabbrica ha bisogno di input precisi, controllo qualità in ogni postazione e un proprietario che sa cosa dovrebbe essere il prodotto.

Inizia da qui

Non provare a far girare cento agenti lunedì. Sali la scala:

1. Esegui un singolo goal loop su un'attività con un traguardo verificabile. Impara cosa significa sentir dire che un completamento è valido.
2. Aggiungi un giudice di una famiglia di modelli diversa per qualsiasi cosa superi un'ora. Vieta la valutazione auto-riferita.
3. Scrivi il tuo orchestration.md. Dì ai tuoi agenti di leggerlo prima. Guardali iniziare a scegliere le modalità per te.
4. Espandi con cautela. Un'attività parallelizzabile, da tre a cinque lavoratori, worktree isolati, budget di token.
5. Instrada i tuoi modelli. Livello massimo per pianificazione e revisione, più economico per build vincolata e lavoro ripetitivo. Misura l'output unibile.
6. Lascialo andare in modo autonomo una volta che il pattern è validato e oggettivamente verificabile. Svuota il backlog durante la notte.

Il sistema deve solo essere direzionalmente corretto, non perfetto:

• Il file di controllo dà alla flotta abbastanza struttura per auto-dirigersi.
• Il giudice intercetta i casi limite.
• Il reminder loop gestisce la memoria.
• Il tuo gusto gestisce le decisioni che non deleghi.

Il prompting era l'abilità dell'anno scorso. Questa è l'abilità ora.

Le versioni eseguibili di ogni sistema qui descritto — il goal loop, il judge loop, il fleet launcher, il message bus, il reminder watchdog e il model router — sono contenute nel kit companion. Imposta una variabile sul tuo CLI per agenti e parti.

Disclaimer

Questo articolo è stato scritto utilizzando sessioni di Claude Code e sessioni di codex dell'autore.

Modificato dall'autore e dal modello Kimi K2.6 per questioni grammaticali e di formattazione.