Attenzione: Il testo fornito è in inglese. La traduzione in italiano è la seguente.
Lo scorso dicembre, Boris Cherny ha spedito 259 pull request in un solo mese. Ognuna scritta da Claude. Ha dichiarato di non aver mai aperto un editor per tutto il tempo.
Il suo lavoro non era scrivere codice. Era scrivere la cosa che scrive il codice. Peter Steinberger l'ha riassunto in due righe che sono state viste oltre 8 milioni di volte: "Non dovresti più fare prompt per agenti di codifica. Dovresti progettare cicli che fanno prompt ai tuoi agenti."
Questa è l'ingegneria dei cicli. Costruisci un piccolo sistema che trova il lavoro, lo passa a un agente, controlla il risultato, decide la mossa successiva, poi lo lasci eseguire mentre dormi.
Il problema è arrivato lo stesso mese. Il ciclo di qualcun altro è rimasto in esecuzione per undici giorni senza controllo e ha bruciato 47.000 dollari prima che qualcuno se ne accorgesse. Quindi queste sono in realtà due competenze, e quasi tutti insegnano solo la prima: costruire un ciclo che spedisce lavoro, e costruire i freni che gli impediscono di farti precipitare da un dirupo.
Una singola domanda decide quale ciclo hai costruito: converge verso qualcosa di vero, o è solo una costosa camminata casuale?
1. Un ciclo è sei pezzi e una domanda
Sotto il rumore di fondo, un ciclo funzionante è composto da sei parti. La lista sembra troppo semplice la prima volta che la vedi. Il dettaglio all'interno di ogni parte è dove un ciclo o tiene botta o perde soldi durante la notte.
Non costruisci più nulla di tutto questo a mano. Un anno fa un ciclo significava un mucchio di script shell di tua proprietà che dovevi tenere d'occhio per sempre. Ora i pezzi sono integrati nei prodotti, e le stesse sei parti si applicano sia all'app OpenAI Codex che a Claude Code. Una volta che lo capisci, lo strumento smette di essere il punto centrale e il ciclo diventa il progetto.
1PEZZO RUOLO NEL CICLO CODEX CLAUDE CODE2------------- ------------------------ ------------------------- --------------------------3Stato (State) Ricordare tra le esec. markdown / Linear (MCP) markdown / Routine + MCP4Automazioni Eseguire su pianificazione Tab Automations + Triage /loop (skill), Routine, /goal5Worktree Isolare agenti paralleli Worktree per thread --worktree, isolation: worktree6Skill Codificare la tua intenzione ~/.agents/skills/SKILL.md ~/.claude/skills/SKILL.md7Connettori Toccar i tuoi strumenti re. MCP server (config.toml) MCP server (.mcp.json)8Sub-agenti Separare chi fa da chi contr. TOML in .codex/agents/ .claude/agents/ + team di agenti
2. Lo stato è l'unica cosa che la prossima esecuzione eredita
Inizia dal basso, perché tutto il resto si basa su di esso.
Un modello dimentica quando un'esecuzione termina. La conversazione muore, il contesto viene cancellato, la prossima esecuzione si risveglia senza sapere nulla. La memoria nella chat muore con l'esecuzione. Deve vivere su disco.
In pratica si tratta di un singolo file. Un file STATUS.md nel repository, o una bacheca Linear raggiunta tramite un connettore, che contiene cosa è stato fatto, cosa è in corso, cosa viene dopo, e le poche cose che il ciclo non deve mai toccare.
1# STATUS.md (il ciclo legge questo per primo, lo scrive per ultimo)2## Fatto3- [x] auth: migrato a token v2, test verdi4## In corso5- [ ] fatturazione: refactoring webhook (PR #214, CI rossa)6## Prossimi7- [ ] dashboard: test instabile in test/charts8## Mai9- non modificare infra/ senza un umano
Tratta il ciclo come un turno di notte che non controlli mai. Non vieni giudicato da cosa ha fatto alle 3 del mattino. Vieni giudicato dalla nota che ti aspetta sulla scrivania alle nove. Progetta prima quella nota e la maggior parte del ciclo si progetta da sola.
3. Le automazioni sono la differenza tra un ciclo e una cosa che hai eseguito una volta
Un ciclo si guadagna il nome solo quando si attiva da solo.
Nell'app Codex ne costruisci uno nella scheda Automations: il repository, il prompt, la cadenza. Le esecuzioni che trovano qualcosa finiscono in una casella di posta Triage; le esecuzioni che non trovano nulla si archivia da sole. OpenAI lo usa per la spina dorsale poco appariscente di un codebase: triage quotidiano delle issue, riepiloghi degli errori CI, catturare il bug che qualcuno ha introdotto la settimana scorsa.
Claude Code ci arriva attraverso alcuni elementi primitivi, e gli articoli popolari sbagliano i dettagli, quindi vale la pena essere precisi. /loop è una skill, non un comando integrato, e riesegue un prompt a una certa cadenza mentre la tua sessione è aperta. I lavori cloud ricorrenti sono Routine, impostati con /schedule, con un minimo di un'ora, e continuano a funzionare anche con il tuo laptop chiuso. Non esiste un crontab locale.
Quello che vale la pena imparare è /goal. Viene eseguito finché una condizione che hai scritto non è vera, e dopo ogni turno un modello separato e più piccolo controlla se hai effettivamente finito. L'agente che ha scritto il codice non può valutare se stesso.
1# Claude Code: esegui finché non è veramente finito, non finché sembra finito2/goal tutti i test in test/auth passano e il passaggio lint è pulito34# Claude Code: un lavoro cloud ricorrente (minimo 1 ora)5/schedule triage PR giornaliero alle 9:0067# Codex: un prompt di automazione (imposta la cadenza nel modulo)8"Nei giorni feriali alle 9:00: scansiona le PR aperte, segnala CI fallita o nessun revisore, pubblica in Triage."
Scrivi la condizione di arresto come un contratto. "Tutti i test in test/auth passano" è un contratto. "Miglioralo" è il modo in cui un ciclo funziona fino al giorno di paga.
4. I worktree tengono gli agenti paralleli fuori dai piedi l'uno dell'altro
Nel momento in cui esegui più di un agente, la modalità di guasto cambia. Non è più il modello. Sono due agenti che scrivono lo stesso file, lo stesso pasticcio di due ingegneri che committano sulle stesse righe senza parlarsi.
Un git worktree è il muro tra di loro: una directory di lavoro separata sul proprio ramo, che condivide la cronologia del repository, in modo che le modifiche di un agente non possano raggiungere il checkout di un altro.
1# Claude Code: un checkout isolato per agente2claude --worktree feature-auth34# o su un sub-agente, nel frontmatter di .claude/agents/<nome>.md:5# isolation: worktree67# Codex: scegli "Worktree" quando apri un thread (una HEAD distaccata ciascuno)
Un avvertimento che lo strumento non menzionerà. I worktree rimuovono la collisione, non il collo di bottiglia. Tu sei ancora il limite. Non importa quanti agenti avvii, la tua larghezza di banda di revisione decide quanti puoi fidarti.
5. Le skill sono la tua intenzione, scritta una volta, all'esterno
Un agente inizia ogni esecuzione a freddo e riempie ogni lacuna nella tua intenzione con un'ipotesi sicura di sé. Una skill è quell'intenzione scritta dove il modello la legge ogni volta, così smette di indovinare.
Il formato è lo stesso su entrambi gli strumenti: una cartella con un file SKILL.md che contiene le istruzioni e una descrizione, più eventuali script necessari. Si attiva quando la chiami per nome o quando la tua attività corrisponde alla sua descrizione, che è esattamente il motivo per cui una descrizione piatta e letterale è meglio di una intelligente.
1# .claude/skills/triage/SKILL.md (Codex: ~/.agents/skills/triage/SKILL.md)2---3name: triage4description: Leggi gli errori CI di ieri, le issue aperte e i commit5 recenti; scrivi ogni risultato in STATUS.md come attività.6---71. Recupera gli errori CI e raggruppali per causa principale.82. Associa ciascuno alla issue aperta o al commit che lo ha causato.93. Scrivi un'attività in STATUS.md per ogni risultato reale. Salta il rumore.
Senza skill, ogni ciclo reimpara il tuo progetto da zero. Con esse, il ciclo diventa un po' più affilato ogni mattina.
6. I connettori permettono al ciclo di agire, non solo di parlare
Un ciclo che può vedere solo il filesystem è un giocattolo. I connettori, basati sullo standard MCP condiviso, permettono all'agente di leggere il tuo issue tracker, colpire un'API di staging, interrogare un database, pubblicare in un canale.
1# Claude Code2claude mcp add --transport http linear https://mcp.linear.app/mcp34# Codex5codex mcp add linear --url https://mcp.linear.app/mcp
Questo è il confine tra un agente che dice "ecco la correzione" e un ciclo che apre la pull request, collega il ticket e riporta il via libera da solo. Poiché entrambi gli strumenti parlano MCP, un connettore che colleghi per uno di solito funziona anche per l'altro.
7. I sub-agenti tengono il creatore lontano dal controllore
La mossa di maggior valore in qualsiasi ciclo è separare l'agente che scrive dall'agente che controlla.
Un modello che rivede il proprio lavoro si approva sempre. Un secondo agente, con istruzioni diverse e idealmente un modello diverso, cattura ciò che il primo si è auto-convinto a fare.
1# Codex: .codex/agents/reviewer.toml2nome = "reviewer"3descrizione = "Revisore PR avversariale: correttezza, sicurezza, test mancanti."4istruzioni_sviluppatore = "Rivedi come se fossi il proprietario. Presumi che l'autore abbia5 torto finché il diff non dimostra il contrario."6sforzo_ragionamento_modello = "alto"78# Claude Code: frontmatter di .claude/agents/reviewer.md9# name: reviewer10# description: Revisore avversariale. Usa dopo qualsiasi modifica al codice.11# model: opus
Uno esplora, uno implementa, uno verifica rispetto alle specifiche. Questo è ciò che /goal fa già internamente: un modello nuovo di zecca decide se il lavoro è finito. Le seconde opinioni costano token, perché ogni agente esegue il proprio modello e i propri strumenti, quindi spendili dove essere in errore è costoso.
8. Che aspetto ha un ciclo
Metti insieme i sei pezzi e un singolo thread diventa una piccola macchina.
Un'automazione pianificata viene eseguita ogni mattina sul repository. Chiama la tua skill di triage, che legge gli errori CI notturni, le issue aperte e i commit recenti, e scrive ogni risultato reale in STATUS.md. Per ogni risultato che vale la pena fare, il ciclo apre un worktree isolato, invia un sub-agente a redigere la correzione e un secondo a revisionarla rispetto alle tue skill e ai tuoi test. I connettori aprono la PR e aggiornano il ticket. Qualunque cosa non possa gestire rimane nella tua casella di posta di triage. STATUS.md ricorda cosa è passato e cosa è ancora aperto, così domani inizia da dove oggi si è fermato.
Ciò a cui ti svegli veramente è un breve passaggio di consegne, non un muro di log:
1# 9:00 — il passaggio di consegne notturno del ciclo (la tua casella di posta Triage)2PRONTI PER IL MERGE3 PR #218 correggi test instabile in test/charts CI verde4 PR #219 riprova webhook su 429, aggiungi test backoff CI verde5HAI BISOGNO DI TE6 auth/session.ts due modi sicuri per risolvere; non ho scelto nessuno, decidi tu7SILENZIOSO8 7 esecuzioni pianificate non hanno trovato nulla e si sono archiviate
L'hai progettato una volta. Non hai fatto alcun prompt per nessuna di queste cose.
9. Costruisci i freni prima di allontanarti
Questa è la metà che nessuno insegna, e decide se il tuo ciclo è un'attività o una passività.
Quel conto da 47.000 dollari non era un modello intelligente impazzito. Erano due agenti, un analizzatore e un verificatore, che chiedevano educatamente più lavoro l'uno all'altro, senza limite di passaggi, senza tetto di budget e senza condizione di arresto. Ha funzionato per undici giorni. Un singolo limite lo avrebbe fermato al primo.
Installa i freni prima della potenza. Non spedire il motore finché non hai spedito il pedale del freno.
1# Fissa QUESTI PRIMA di allontanarti:2- limite passaggi: --max-turns 50 (arresto forzato, senza eccezioni)3- tetto budget: claude -p --max-budget-usd 10 (modalità stampa; per fase)4- raggio di danno: un worktree, un ramo, sola lettura fuori da src/5- interruttore automatico: stesso strumento + stessi argomenti 3x di fila = fermati6- controllo uomo morto: scrivi un heartbeat in STATUS.md ad ogni esecuzione; il silenzio ti mette in pagina
Delimita un ciclo in base a cosa può distruggere, non in base a cosa vuoi che faccia: quali repository, quali rami, quanti dollari, quanti passaggi prima che si chiuda forzatamente. Scegli prima il raggio di danno, poi l'attività.
E stabilisci il prezzo onestamente. La flotta di cento agenti di Steinberger è reale e costa circa 1,3 milioni di dollari al mese. Funziona perché OpenAI ora lo impiega e paga il conto. Il caso all'avanguardia è sponsorizzato. Il tuo no. Con un piano da 20 a 200 dollari, il ciclo che ripaga è piccolo, limitato e puntato su un lavoro noioso, non su uno sciame.
1IL VENTAGLIO DI COSTI (tutti reali, tutti degli ultimi sei mesi)2-----------------------------------------------------------------3259 PR in 30 giorni un ingegnere, scritto al 100% da Claude447.000 $ in 11 giorni un ciclo fuori controllo senza limiti, nessuno che guardava5~1,3 milioni $ al mese una flotta di 100 agenti (il conto è sponsorizzato)6-----------------------------------------------------------------7Stessa tecnologia. La differenza sono i freni.
10. Come muoiono i cicli
Ogni ciclo che fallisce muore di una delle quattro morti. Impara i nomi ora in modo da riconoscerli alle 3 del mattino.
Ricorsione incontrollata. Due agenti si alimentano a vicenda per sempre. La cura è il limite di passaggi e il tetto di budget di cui sopra, niente di più intelligente.
Morte silenziosa. L'esecuzione notturna di uno sviluppatore ha raggiunto una finestra di contesto piena, si è fermata, poi ha continuato a tentare di riprendere nello stesso muro mentre sembrava ancora attiva. Il tuo ciclo può essere morto per ore e continuare a riportare progressi. La cura è un heartbeat e un contesto nuovo per ogni fase, non un'esecuzione infinita.
La camminata casuale. Senza una condizione di arresto verificabile, il ciclo si allontana dall'obiettivo invece di avvicinarsi ad esso. Una test suite superata è un punto fisso che può raggiungere. "Sembra finito" non lo è.
Debito di comprensione. Più velocemente un ciclo spedisce codice che non hai scritto, più ampio diventa il divario tra ciò che il tuo repository fa e ciò che tu capisci. Lascialo funzionare abbastanza a lungo senza leggerlo e smetti di essere l'ingegnere e diventi un timbro di gomma. La cura è un gate di revisione umana che al ciclo non è mai permesso saltare.
11. Costruisci il ciclo. Rimani l'ingegnere.
Due persone possono costruire il ciclo identico e ottenere risultati opposti. Uno lo usa per muoversi più velocemente su un lavoro che capisce a fondo. L'altro lo usa per smettere di capire il lavoro del tutto. Il ciclo non può distinguerli. Tu puoi.
Il punto di Cherny non era mai che il lavoro fosse diventato più facile. È che la leva si è spostata: dal prompt al ciclo, e dalla digitazione al giudizio. Questo è un lavoro più difficile che fare prompt, non più facile.
Quindi ecco la mossa, ed è volutamente piccola, perché siamo agli inizi e i costi oscillano selvaggiamente. Domani mattina, prendi il lavoro più noioso che ancora fai a mano, fare triage della CI, chiudere issue vecchie, inseguire un test instabile, e avvolgici un singolo ciclo con dei freni. Prima i freni. Abbastanza piccolo da leggere ancora ogni diff che spedisce.
Nessuno che spedisce 200 pull request al mese ha iniziato con cento agenti. Hanno iniziato con un singolo ciclo di cui si fidavano, e sono rimasti ingegneri per tutto il tempo. Costruisci quello.
