Loop Engineering - Dal Prompting al Looping

Ho deciso di dedicare questo articolo a come creare il tuo agente programmabile che farà il lavoro per te, così non dovrai più accendere il computer ogni mattina e impartirgli comandi in continuazione.

Si sveglierà da solo, troverà compiti da solo, identificherà problemi da solo, e salverà e presenterà i risultati sulla tua scrivania per la tua revisione.

Prefazione

L'idea di Loop non è nata dal nulla - durante una singola settimana di giugno 2026, tre esperti del settore hanno quasi contemporaneamente espresso lo stesso pensiero: era ora di iniziare a sviluppare questo livello.

Una settimana dopo, Andrew Ng ha inserito questa conversazione nel contesto più ampio di "Costruire Prodotti da 0 a 1", fornendo un quadro più completo.

Questo articolo parte da quella storia e poi ti guida nella costruzione di un loop minimo ma completo da zero: 5 mosse, 6 parti, una porta che dice "no", e una porta umana - tutto eseguito sulla tua macchina e riutilizzabile su qualsiasi progetto software.

Fonte: HuaShu Orange Book, Loop Engineering: Smettetela di Chiedermi Cosa È (v260615, giugno 2026)

La settimana in cui 3 persone hanno acceso la miccia

Giugno 2026: tre persone, senza alcun coordinamento, hanno detto quasi la stessa cosa a distanza di giorni l'una dall'altra.

Peter Steinberger, creatore di OpenClaw, ha pubblicato due frasi su X che hanno raggiunto 8,9 milioni di visualizzazioni:

https://x.com/steipete/status/2063697162748260627

Quel post è dove il discorso è effettivamente iniziato. Non era un manifesto o un lungo saggio, solo due righe che hanno dato un nome a qualcosa che le persone stavano già facendo in silenzio.

Boris Cherny: Non scrivo più prompt per Claude, ho dei loop che sono in esecuzione. Sono loro che stanno facendo i prompt a Claude e capendo cosa fare.

Addy Osmani: Loop engineering significa sostituire te stesso come persona che fa i prompt all'agente. Progetti il sistema che lo fa al posto tuo.

La pratica è venuta prima del nome di mesi, tutti stavano già scrivendo loop, nessuno lo aveva ancora chiamato in qualche modo.

Quindi, i loop sono ora una parte fondamentale di come permettiamo agli agenti AI di lavorare in modo iterativo a lungo termine per creare software.

Andrew Ng ha disposto i tre loop dal più interno al più esterno in base alle loro scale temporali: il loop più interno è il più veloce, e il loop più esterno è il più lento. Inoltre, l'input del loop più esterno proviene dall'output del loop più interno:

Loop

Chi lo esegue

Durata del ciclo

Cosa produce per lo strato esterno

Agentic coding loop

l'agente stesso

secondi - minuti

una versione funzionante

Developer feedback loop

umano + agente

decine di minuti - ore

una visione e specifica di prodotto più chiara

External feedback loop

utenti + team

ore - settimane

dati reali che evolvono la visione

Andrew Ng ci ha dato la mappa per tempo: tre loop che girano a velocità diverse. Addy Osmani ha disegnato una seconda mappa per astrazione: prompt -> contesto -> harness -> loop.

Loop engineering si trova al vertice e aggiunge tre verbi che l'harness non ha. Gira su un timer, genera aiutanti, e si auto-alimenta - l'output di oggi diventa l'input di domani. Quest'ultima è la cosa che lo rende un loop, non lo stesso compito eseguito N volte.

L'intuizione più importante: lo stesso bug costa un importo diverso a ogni strato:

Strato

Di cosa si occupa

Domanda fondamentale

Prompt eng.

scrivere un prompt

cosa dire al modello

Context eng.

cosa è caricato nella finestra

cosa estrarre, riassumere, cancellare

Harness eng.

armare una singola esecuzione

quali strumenti, quali azioni, cosa conta come fatto

Loop eng.

pianificazione sopra l'harness

come farlo girare da solo, round dopo round

Un loop è per progettazione una macchina che rende grande il "numero di turni". Ogni decisione da qui in poi - valutatore, gate umano, limite di token, file di stato - esiste per accorciare la distanza tra "accade un errore" e "qualcuno lo vede".

Cosa succede all'interno di un turno:

"Loop" viene frainteso come "girare su se stessi". Non lo è, ogni turno ha 5 mosse concrete. Tagliane una e il loop o non gira - o gira senza andare da nessuna parte.

1. La verifica è la mossa che dice "no."
2. La pianificazione è la mossa che alimenta questo turno nel successivo.

Questa è esattamente la parte che lo rende un loop.

Mappato al progetto che stiamo per costruire: un loop di triage mattutino per un piccolo team:

Azione

Cosa fa

Nel TRIAGE LOOP

Discovery

capire cosa dovrebbe fare questo turno

una skill legge CI / issue / commit recenti

Handoff

assegnare il compito e isolarlo

ogni risultato ottiene il proprio worktree

Verification

sostituire con un altro agente per dire no

un secondo sotto-agente come revisore, che testa e analizza le skill

Persistence

scrivere lo stato fuori dalla conversazione

PR + ticket Linear + ./state/triage.md

Scheduling

lasciarlo girare turno dopo turno

trigger cron di GitHub Actions alle 06:00

Ognuna delle 5 lezioni seguenti sviluppa esattamente una mossa.

Cinque lezioni = un Loop completo.

E iniziamo con la prima: Discovery, perché se il Loop non può decidere cosa vale la pena fare oggi, niente dopo quello ha importanza.

Lezione 1 Discovery: scrivi una SKILL.md per il triage mattutino

Skill, non un muro di prompt.

Immagina, è lunedì alle 6 del mattino. Il tuo portatile è chiuso e GitHub Action si sveglia e lancia claude --skill morning-triage: cosa legge, cosa giudica come azionabile, dove scrive i risultati - tutto questo vive dentro la SKILL.md che stai per scrivere.

La frase chiave di Osmani: l'automazione dovrebbe attivare una skill - conoscenza del progetto scritta e aggiornabile, non un muro di prompt incollato in un cron job. Il prompt incollato lì marcisce, perché nessuno torna mai ad aggiornare qualcosa sepolto dentro una pianificazione.

Il tuo compito per questa lezione: scrivi una skill in .claude/skills/morning-triage/SKILL.md che legga tre fonti (CI / issue / commit) da sola, decida cosa vale la pena fare da sola, scriva i risultati in ./state/triage.md - e abbia una sezione Stop esplicita che spieghi cosa al loop NON è permesso fare.

Ecco l'inizio - cambia tre cose ed è tua:

1# .claude/skills/morning-triage/SKILL.md
2---
3name: morning-triage
4trigger: invocato dall'automazione giornaliera
5---
6
7## Read   (input di discovery — sostituisci con le fonti che il TUO repo ha effettivamente)
8- esecuzioni CI fallite dall'ultima esecuzione      # gh run list --status failure
9- issue aperte nelle ultime 24h                     # gh issue list --search "created:>=…"
10- commit uniti da ieri                              # git log --since=yesterday
11- il precedente ./state/triage.md                   # il passaggio di consegne "ieri → oggi"
12
13## Judge  (il tetto — lascia che il loop scelga, non dargli una lista)
14Per ogni candidato, decidi:
15- è azionabile ORA, o è rumore?
16- blocca un rilascio? → priorità = P0
17- è già tracciato? → salta
18Tieni solo ciò che vale un worktree OGGI.
19
20## Write  (persistenza — scrivilo in markdown, non in chat)
21Aggiungi a ./state/triage.md:
22| risultato | fonte | priorità | stato |
23Fai il commit del file così domani può leggerlo.
24
25## Handoff  (preparazione per la Lezione 2)
26Per ogni risultato tenuto, emetti una riga di attività:
27  worktree=fix/<slug>
28  goal=<condizione-di-arresto>
29
30## Stop   (l'UNICA sezione non boilerplate — pensaci bene qui)
31Mai unire. Mai cancellare.
32Tutto ciò di cui sei meno che sicuro → ./inbox/ per un umano.
33NON una PR.

Tre sezioni fanno il lavoro vero qui:

Read: questo è l'input di Discovery - elenca fonti concrete, fino al comando effettivo. Ricorda, "leggi il contesto" non è una fonte, ma gh run list --status failure è una fonte.

Judge: questo è il tetto dell'intero tuo loop. Il loop decide "azionabile vs rumore" da solo - non riceve una lista da te, perché se gli stai ancora dando una lista ogni mattina, hai automatizzato il fare ma non lo scegliere. E scegliere è solitamente il passo più costoso. Non importa quanto siano buone le tue fonti, se questa sezione raccoglie spazzatura, le altre quattro mosse girano a vuoto su lavoro inutile.

Stop: l'unica parte di questo file che non è boilerplate. Il loop farà tutto ciò che la skill dice, e solo ciò che la skill dice. Se non scrivi "mai unire" - un giorno lo farà per te.

Spiega le linee rosse: mai unire, mai cancellare, mai fare push su main, tutto ciò che è incerto va in ./inbox/ per un umano, non in una PR.

Un'altra cosa che vale la pena sapere: questa stessa struttura di skill funziona oltre il triage mattutino: sostituisci la sezione Read con "log di accesso di ieri + nuove issue + versione di deploy corrente" e diventa un loop serale per la salute del sito. Aggiungi una riga a Judge - "è una regressione da ieri?" - e sviluppa un confronto tra giorni.

La malattia che questa lezione previene - Blind Loop:

Il più comune "sembra un loop ma non lo è.": il loop gira, ma stai ancora assegnando il lavoro ogni mattina ("ehi, guarda questi tre bug"). Questa è automazione dell'esecuzione, non automazione della scoperta.

Sintomo: il loop non ti sorprende mai, perché fa solo ciò che sapevi già andasse fatto.

Rimedio: metti Judge dentro la skill e lascia che scelga il lavoro di oggi da solo.

Prima di andare avanti, rispondi a queste tre:

1/ Quante righe ha la tua sezione Stop?

Se è solo "mai unire" - aggiungine un'altra: cos'altro dovrebbe mai fare questo loop per te? (mai chiudere issue / mai fare push su main / mai prendere più di 3 risultati alla volta..)

2/ Riscrivi la prima riga di Read in un comando che viene effettivamente eseguito nel TUO progetto

**3/ Se questa skill rimane invariata per un anno - cosa succede?

**ora confronta: cosa succede a un muro di prompt incollato in un cron job per un anno?

Lezione 2 Handoff: distribuisci il lavoro e isolalo

La skill della Lezione 1 ha appena finito di girare. ./state/triage.md ora contiene 5 risultati azionabili. Il pensiero successivo più naturale - lancia 5 agenti contemporaneamente, vai veloce. Quel passo esatto è come si sviluppa un Tangled Loop: diversi agenti che modificano gli stessi file nella stessa directory, e il giorno dell'unione si trasforma in archeologia.

L'antidoto è una riga: ogni risultato ottiene il proprio worktree.

git worktree è un meccanismo git integrato: un repo, multiple directory di lavoro indipendenti, ognuna checkout sulla propria branch. git worktree add ../fix-auth fix/auth apre uno spazio di lavoro completamente isolato in ../fix-auth. build, modifiche, test - niente tocca nessun altro. un worktree per risultato = agenti fisicamente separati.

Il tuo compito per questa lezione: scrivi uno script che legga ogni risultato da ./state/triage.md, apra un worktree isolato per risultato (chiamato fix/<slug>), invii un agente a redigere una correzione al suo interno - e imposti un limite di parallelismo in modo che non generi all'infinito.

1# leggi state/triage.md, un worktree per risultato
2# modifica: MAX_PARALLEL a ciò che la tua macchina / fattura può gestire
3MAX_PARALLEL=3
4
5# modifica: parsing per corrispondere alle colonne del tuo triage.md effettivo
6findings=$(awk -F'|' 'NR>2 && $5 ~ /open/ {print $2}' \
7           state/triage.md | head -n $MAX_PARALLEL)
8
9for finding in $findings; do
10  slug=$(echo "$finding" | tr ' ' '-' | tr -cd '[:alnum:]-')
11
12  # la riga chiave: isolamento fisico per agente
13  git worktree add ../wt-$slug -b fix/$slug
14
15  # modifica: goal è la condizione di arresto che il valutatore della Lezione 3 leggerà
16  claude --worktree ../wt-$slug \
17    --goal "i test in tests/$slug passano e lint è pulito" \
18    "redigi una correzione per: $finding" &
19done
20
21wait   # lascia che tutti gli agenti paralleli finiscano
22
23# regola di chiusura: gli agenti non fanno mai auto-merge — i worktree aspettano
24# il gate umano nella Lezione 5
25echo "Tutti i worktree pronti per la revisione:"
26git worktree list

Le regole che contano qui: mai lavorare su main.

Main è la pista di atterraggio per la revisione umana - non la scrivania degli agenti. Tutti gli agenti vivono su worktree fix/*.

Limita il parallelismo: la generazione illimitata è la porta d'ingresso per un'esplosione di token (la Lezione 5 ci tornerà). scegli MAX_PARALLEL basandoti su una domanda onesta: non "quanti ne può eseguire la mia macchina" ma "quante PR posso effettivamente revisionare."

L'unione è una decisione umana: Stripe esegue 1.000+ PR a settimana attraverso loop come questo, e gli umani revisionano ancora ognuna. L'umano non ha lasciato il processo - ha cambiato scrivania: dallo scrivere codice al revisionare codice.

E un dettaglio del caso Stripe che vale la pena rubare: hanno usato controintuitivamente un modello più piccolo con gate deterministici rigorosi invece del modello più grande disponibile.

La lezione: un gate di verifica stretto batte la potenza grezza del modello per il lavoro di loop.

La malattia che questa lezione previene - Tangled Loop:

Un loop a singolo agente sembra perfettamente sano. Il problema si presenta solo il giorno in cui vai in parallelo - cinque agenti girano, cinque diff collidono nello stesso file, l'unione è caos.

Rimedio: ogni compito ottiene il proprio worktree, mai condividere una directory di lavoro tra agenti.

Prima di andare avanti, rispondi a queste tre:

**1/ Che numero hai impostato per MAX_PARALLEL - e perché?

**(soldi? macchina? o "quante PR posso onestamente revisionare"?)

**2/ Se un worktree crasha - l'agente esce senza toccare nulla

**cosa dovrebbe registrare il file di stato di domani a riguardo?

**3/ Stripe ha usato un modello più piccolo + gate deterministici rigorosi

**Invece del modello più grande, cosa significa quella scelta per il TUO loop?

Lezione 3 Verification: installa una porta che dice "no" (la lezione più pesante)

Questa è la mossa più difficile nel loop engineering, e merita più sforzo di qualsiasi altra lezione.

L'ingegnere di Anthropic Prithvi Rajasekaran, lavorando su applicazioni agentiche a lunga esecuzione, ha notato qualcosa: chiedi a un agente di valutare il codice che ha appena scritto, e quasi sempre si loderà da solo - anche quando un umano può vedere a colpo d'occhio che è mediocre.

Questo non significa che il modello sia stupido: valutare il proprio lavoro è strutturalmente rotto. Quando il codice è finito, il contesto dell'agente è pieno della catena di auto-giustificazione del perché ha scritto le cose in quel modo. Guardando il proprio output, non vede il risultato - vede l'argomento per il risultato.

Mettilo dentro un loop e si amplifica in un disastro: la risposta a ogni turno "è abbastanza buono?" viene data dall'agente che lo ha appena scritto. Ogni turno annuisce a se stesso. Più a lungo gira, più si allontana dalla qualità reale. Questo è il Nodding Loop - ed è la malattia più costosa della lista.

La soluzione di Rajasekaran, con le sue parole:

"Mettere a punto un valutatore indipendente per essere scettico è molto più gestibile che rendere un generatore critico del proprio lavoro."

Questo è un problema strutturale, non un problema di formulazione. Non puoi chiedere a un autore di uscire dalla propria testa, ma puoi portare un agente diverso, con istruzioni completamente diverse, che guarda il codice da zero - senza alcuna catena di auto-giustificazione attaccata.

L'analogia viene dalle GAN: una rete costruisce, un'altra attacca: creatore e controllore. La stessa vecchia regola bancaria: la persona che trasferisce il denaro e la persona che lo approva devono essere persone diverse.

Il tuo compito per questa lezione - scrivi due cose:

1) Un prompt di sistema per il valutatore in .claude/agents/reviewer.md con cinque sezioni: RUOLO + PRESUPPONI + CONTROLLA + USA + VERDETTO.

2) Un comando /goal che dichiari la condizione di arresto di questo loop - giudicata da un modello fresco separato, non dal generatore.

1# .claude/agents/reviewer.md  (cambia 3 cose)
2RUOLO: Revisore di codice avversariale.
3PRESUPPONI: questo codice è ROTTO fino a prova contraria.
4NON lodare. Trova cosa fallisce.
5
6# modifica: ordina CONTROLLA in base alle reali modalità di fallimento del tuo progetto,
7# controlli eseguibili prima
8CONTROLLA, in ordine:
9  1. Gira?  (esegui, non leggere)
10  2. Test: eseguili, incolla l'output reale.
11  3. Casi limite che l'autore ha saltato.
12  4. Il comportamento corrisponde al ticket?
13
14# modifica: quale MCP dipende da cosa stai testando —
15# frontend → Playwright, API → curl/httpie
16USA Playwright MCP: apri la pagina, clicca,
17fai screenshot, ispeziona il DOM.
18Giudica il comportamento, non l'intento.
19
20VERDETTO: PASS solo se ogni controllo è valido.
21         Altrimenti RIFIUTA + elenca ogni motivo.

1# condizione di arresto — giudicata da un modello piccolo fresco, NON dal generatore
2# modifica: sostituisci con la condizione verificabile reale del tuo risultato
3/goal tutti i test in test/auth passano e il passaggio lint è pulito
4
5# attenzione: /goal e /loop NON sono la stessa cosa
6#   /loop = riesegui a intervallo (nessun giudizio di arresto — pericoloso)
7#   /goal = esegui finché un modello fresco giudica la condizione vera

Due agenti, idealmente due modelli: "stesso modello, prompt diverso" spesso preserva gli stessi punti ciechi. scambia anche il modello se puoi.

Scetticismo predefinito: la linea di base del valutatore è PRESUPPONI ROTTO - la fiducia deve essere guadagnata superando i controlli, non concessa per impostazione predefinita.

Giudica il comportamento, non l'intento: "questo JSX sembra a posto" e "ho cliccato il pulsante, la pagina ha navigato, ecco lo screenshot" sono due universi diversi. il valutatore deve agire - eseguire i test, cliccare la pagina, non leggere il codice e avere una sensazione.

Rifiuta con motivazioni: un RIFIUTO senza motivi elencati non è un rifiuto - il generatore non ha idea di cosa sistemare.

E il test decisivo: il tuo valutatore ha effettivamente rifiutato qualcosa negli ultimi 5+ turni? Un loop che non ha mai detto "no" in centinaia di turni è statisticamente impossibile su qualsiasi carico di lavoro reale. Quindi dimostra che il valutatore non funziona.

La malattia che questa lezione previene - Nodding Loop:

Il loop gira, l'agente scrive codice, lo stesso agente dice "sembra a posto." Ogni turno si auto-approva, accumulando errori apparentemente plausibili a velocità macchina. rimedio: tutta questa lezione: separazione strutturale + scetticismo predefinito + giudizio tramite azione + una condizione di arresto di terze parti.

Prima di andare avanti, rispondi a queste tre:

1/ Il tuo valutatore è lo stesso modello con un prompt diverso, o un modello diverso? perché?

2/ Traduci "giudica il comportamento, non l'intento" in una

frase concreta del tuo progetto: "il mio valutatore non legge il codice, esegue _____, e PASSA solo quando vede _____"

3/ Quanto è probabile che un modello fresco "abbastanza buono" faccia falsamente PASSARE la tua condizione /goal?

se la tua modalità di fallimento più spaventosa è X - aggiungi un controllo per X alla condizione di arresto adesso

Lezione 4 Persistence: fai sopravvivere il lavoro di oggi a domani

La Lezione 3 è finita. il tuo valutatore ha giudicato tre risultati - due PASS, uno RIFIUTA. domanda: dove vivono in questo momento quei tre verdetti?

se la risposta è "nella finestra di contesto" - allora domani alle 6 del mattino, il loop si sveglia con un contesto svuotato e non ricorda nulla. Rifà il triage da capo, inciampa nel RIFIUTO non risolto di ieri, magari assegna un altro agente per sistemarlo di nuovo, magari lo perde completamente, magari cade nella stessa buca.

Questo è l'Amnesiac Loop - ogni giorno ricomincia dalla stessa casella.

L'antidoto in una riga: la memoria è lo stato scritto su disco, non il contesto. un file markdown, una bacheca Linear, un database - una volta scritto, non importa quanto a fondo l'agente dimentichi.

Questi due vengono confusi costantemente, quindi fissa la differenza:

CONTESTO = la finestra che l'agente vede QUESTO turno -> cancellata a ogni aggiornamento.

MEMORIA = lo stato che vive attraverso turni e giorni -> scritto su disco (markdown / DB / bacheca).

Un loop collega oggi -> domani solo attraverso la MEMORIA.

Il tuo compito per questa lezione:

1. Crea ./state/triage.md con almeno 4 colonne (risultato / fonte / priorità / stato) - la skill della Lezione 1 lo scrive, i worktree della Lezione 2 lo leggono.
2. Collega un connettore (MCP): un verdetto PASS apre automaticamente una PR, un RIFIUTO aggiorna automaticamente il ticket.
3. Verifica che il loop di domani possa effettivamente rileggere lo stato di oggi.

1# ./state/triage.md  (la memoria del loop — modifica come necessario)
2
3| risultato         | fonte       | priorità | stato     |
4|-------------------|-------------|----------|-----------|
5| test auth instabile | CI #4821   | P0       | in correzione |
6| deref nullo       | issue 92   | P1       | PR aperta |
7| dipendenza obsoleta | commit a3f9c | P2    | inbox     |
8
9# estendi le colonne come necessario: ultima_visita, conteggio_ritentativi, assegnato_a
10# questo file DEVE essere committato nel repo —
11# altrimenti il runner cloud di domani non può vederlo

1// .mcp/connectors.json — collega il loop al mondo esterno
2{
3  "github_pr": {
4    "type": "mcp",
5    "on_event": "evaluator.verdict.PASS",
6    "action": "open_pr",
7    "branch": "fix/${slug}",
8    "auto_merge": false        // ← DEVE essere false. gate umano = Lezione 5
9  },
10  "linear": {
11    "type": "mcp",
12    "on_event": "evaluator.verdict.REJECT",
13    "action": "update_ticket",
14    "fields": { "status": "Bloccato", "reason": "${verdict.reasons}" }
15  }
16}

Perché ogni colonna è importante: nessuna fonte -> non puoi verificare da dove proviene un risultato. nessuna priorità -> non puoi ordinare il lavoro. nessuno stato -> domani non può raccogliere il testimone.

E la verifica per questa lezione è l'unica che non puoi falsificare: aspetta fino a domani. Sveglati, controlla - l'inbox è ancora lì? I risultati non finiti mantengono ancora il loro stato? L'esecuzione delle 6 del mattino ha ripreso da dove ieri si era fermato invece di ricominciare da capo? Questo lo scopri eseguendolo, non ragionandoci sopra.

Una disciplina silenziosa che arriva con la persistenza - leggi un campione, sempre.

Una volta che la persistenza funziona, si apre una trappola: il loop spedisce PR a velocità, ti senti produttivo - e la tua mappa mentale del codebase silenziosamente diventa obsoleta. la regola: non leggere tutto (questo sconfigge lo scopo del loop), ma leggi una PR campione al giorno e sforzati di spiegare cosa ha cambiato il loop e perché.

Nel momento in cui non riesci a spiegarlo - la tua mappa è rimasta indietro. Sistemarla in una mattina tranquilla costa dieci minuti. Sistemarla durante un incidente di produzione costa molto di più.

La malattia che questa lezione previene - Amnesiac Loop:

Il loop trova buon lavoro, lo fa, poi dimentica di averlo fatto - perché il risultato viveva solo in un contesto svuotato. Il turno successivo riscopre lo stesso lavoro, o peggio - lo rifà e sovrascrive il primo tentativo.

Sintomo: nessun progresso accumulato, ogni giorno ricomincia dallo stesso posto. Rimedio: file di stato su disco.

Prima di andare avanti, rispondi a queste tre:

1/ Traduci "memoria ≠ contesto" in una frase concreta

del tuo progetto: "il mio _____ è memoria, il mio _____ è contesto"

**2/ Il loop di domani si sveglia - quale COLONNA di state.md

**legge per prima per decidere la sua prima mossa? hai chiamato quella colonna correttamente, o hai appena seppellito una mina per lui?

**3/ Disciplina: a che ora del giorno leggerai la tua

**PR campione? imposta il promemoria del calendario ora - questo è un contratto con te stesso.

Lezione 5 Scheduling: rendilo reale, rendilo sicuro, tieni una porta aperta

Le Lezioni 1-4 sono installate, ma il loop si ferma ancora nel momento in cui smetti di premere il pulsante. La mossa finale è un verbo: appendilo a un trigger.

Ma la parte più pericolosa di questa lezione non è sbagliare cron. È azzeccare cron giusto - perché allora il loop gira veramente da solo, e un bug può farlo girare tutta la notte, aiutanti che generano aiutanti, finché non ti svegli con una fattura che non riconosci.

Quindi questa lezione fa in realtà tre cose: appendi il trigger, imposta i limiti, tieni una porta umana.

Primo - scegli il tuo scheduler:

1Cloud (GH Actions)   Desktop schedulato   /loop (in CC)
2dove gira          cloud                la tua macchina        la tua macchina
3macchina accesa?   non necessaria       necessaria              necessaria
4sessione aperta?   non necessaria       non necessaria          necessaria
5intervallo minimo  1 ora                1 minuto                1 minuto
6vede file locali?  no                   sì                      sì

La domanda decisiva: questo lavoro può lasciare il tuo portatile?

1"controlla il mio server dev locale ogni minuto"
2   → deve essere locale + /loop (l'intervallo di 1 ora del cloud non può raggiungerlo)
3
4"scansiona le issue di GitHub alle 3 del mattino e apri PR"
5   → deve essere cloud (il tuo portatile è chiuso — il loop non può
6     aspettare che sia acceso)

E l'auto-inganno più subdolo in tutta la pratica: trattare un timer locale come "in esecuzione mentre dormi." Non lo è. è "esegue qualche turno extra mentre sono ancora in giro."

Il tuo compito per questa lezione:

1. Scrivi .github/workflows/triage.yml con un trigger cron che attivi la skill morning-triage.
2. Imposta tre limiti: budget per esecuzione, budget giornaliero, numero massimo di tentativi.
3. Concludi il workflow con la regola: nessuna PR viene unita automaticamente, tutto ciò che è incerto finisce in ./inbox/.

1# .github/workflows/triage.yml  (cambia 3 cose)
2name: morning-triage
3
4on:
5  schedule:
6    - cron: '0 6 * * *'        # cambia: le 06:00 del tuo fuso orario in UTC
7
8jobs:
9  triage:
10    runs-on: ubuntu-latest
11    timeout-minutes: 45          # ← limite per esecuzione · cambia
12    permissions:
13      contents: write
14      pull-requests: write
15    steps:
16      - uses: actions/checkout@v4
17
18      - name: morning triage
19        env:
20          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
21          DAILY_BUDGET_USD: '20'   # ← limite giornaliero · cambia
22          MAX_RETRIES: '3'          # ← limite tentativi · cambia
23        run: |
24          claude --skill morning-triage \
25            --max-retries "$MAX_RETRIES" \
26            --daily-budget-usd "$DAILY_BUDGET_USD"
27
28      - name: apri PR (MAI unire automaticamente)
29        run: |
30          # Le PR si aprono automaticamente. L'unione resta umana.
31          gh pr create --draft --base main \
32            --title "[loop] $(date +%F) triage" \
33            --body-file ./state/triage.md
34          # non c'è `gh pr merge` qui — di proposito
35
36      - name: instrada l'incerto verso la inbox
37        run: |
38          ls ./inbox/ && echo "elementi in attesa di revisione umana"

Le tre regole che lo mantengono vivo al sesto mese:

Limita prima di spedire: tre livelli - timeout per esecuzione, budget giornaliero, numero massimo di tentativi - impostati prima della prima esecuzione autonoma, non dopo la prima bolletta spaventosa. Un limite di token non riguarda il risparmio. È un interruttore automatico che trasforma un rischio illimitato in un rischio controllato. Un loop senza limiti ha esternalizzato la sua autorità di spesa ai propri bug.

Per dare un'idea: Uber ha limitato gli ingegneri a $1.500 a persona per strumento al mese dopo aver bruciato il suo budget AI in quattro mesi. Il tuo limite per loop è la versione granulare di quella lezione.

Tieni una porta aperta: le PR non si uniscono automaticamente. Gli elementi incerti finiscono nella inbox. Ne leggi un campione al giorno. La porta non c'è perché un umano la attraverserà sempre, ma perché l'esistenza della porta ti mantiene in una posizione in cui puoi farlo. Salda ogni porta, e il giorno in cui dovrai entrare, avrai perso la chiave.

Verifica che si svegli davvero. Eseguilo per almeno 3 turni (le prove a secco contano). Il fallimento più comune: splendido il giorno della demo, morto entro giovedì. "L'ultima esecuzione è stata il giorno della demo" è la firma diagnostica di un Loop Manuale.

Funziona allo stesso modo al di fuori di Claude Code - le capacità non sono vincolate al fornitore, solo rinominato:

1CAPACITÀ              Claude Code          Codex
2pianificazione        /loop · worker       scheda Automations
3esecuzione condiz.    /goal                riesecuzione automazione + giudice
4isolamento parallelo  --worktree           worktree in background
5sotto-agenti          .claude/agents/      .codex/agents/
6connessione esterna   MCP + plugin         connettore MCP
7skill esplicita       SKILL.md             $nome-skill
8esecuzione offline    Cloud Routines       cloud (in programma)

La domanda non è mai stata "quale fornitore". È "sono installate tutte e sei le capacità."

La malattia che questa lezione previene - Loop Manuale:

Quattro mosse costruite magnificamente, nessun cron. Non è un loop - è uno script che hai eseguito una volta e dimenticato.

Soluzione: aggancia qualsiasi trigger che non dipenda dal tuo ricordarti.

Prima di spedire, rispondi a queste tre domande:

1/ Quali sono i numeri esatti dei tuoi tre limiti?

Se un bug gira tutta la notte - quale limite rompe la caduta per primo? Se nessuno di loro lo facesse... Cosa ti dice questo?

2/ Com'è la tua porta umana?

(Revisione PR / inbox / campione giornaliero / riconciliazione settimanale?) Scrivilo = firma il contratto con te stesso

3/ La domanda conclusiva: tra sei mesi, questo loop ti avrà reso più forte (comprensione, giudizio, sensibilità per il sistema) - o ti avrà trasformato nel custode di una macchina che non sai leggere? Qual è il tuo piano per evitare la seconda opzione?

I 4 debiti e rimanere l'ingegnere

Il tuo loop è costruito: si sveglia, trova lavoro, si critica, ricorda e programma il proprio domani.

Mentre un loop gira, quattro cose si accumulano silenziosamente - e la loro caratteristica comune è che nessuna di loro fa scattare un allarme.

1DEBITO DI VERIFICA         output non rifiutato che si accumula
2DEGRADO DELLA COMPRENSIONE  il codebase cresce, la tua mappa mentale no
3RESA COGNITIVA             "Non ho più voglia di esaminare"
4ESPLOSIONE DI TOKEN        un bug gira tutta la notte → lo vedi come una bolletta

Si alimentano a vicenda: l'output non verificato erode la tua comprensione -> la comprensione erosa invita alla resa -> la resa lascia girare il loop più a lungo e spendere di più -> che produce più output non verificato.

Controlla il tuo nuovo loop contro tutti e quattro prima della sua prima esecuzione in solitaria:

• Il mio valutatore rifiuta davvero - non è un ornamento.
• Leggo una PR campione al giorno e posso spiegare cosa è cambiato.
• Ho mantenuto l'abitudine di dire "questo è sbagliato".
• I miei limiti sono stati impostati PRIMA della prima esecuzione, non dopo la prima bolletta.

Ed ecco la parte che decide tutto:

Lo stesso loop, costruito da due persone, può finire in posti opposti. Uno lo usa per muoversi più velocemente continuando a leggere il codice e mantenendo la direzione - il loop amplifica il giudizio che già possiedono.

L'altro usa l'esatto stesso loop specificamente per non capire mai più niente - sei mesi dopo, il primo è più affilato, e il secondo è un custode per una macchina che non sa leggere.

Addy Osmani: "costruisci il loop, ma costruiscilo come qualcuno che intende rimanere l'ingegnere - non solo la persona che preme 'vai'."

I loop rendono la generazione quasi gratuita, ciò che rimane scarso è il giudizio: quale piano è giusto, su quale riga fermarsi, quale cosa funziona ma è sbagliata alla radice. Il loop non svaluta il giudizio - spoglia via tutto ciò che non è giudizio, e lascia solo quello.

Un loop è un moltiplicatore fedele:

Porta comprensione - amplifica la comprensione.

Porta pigrizia - amplifica la pigrizia.

Decidi cosa vuoi amplificato - prima di costruirlo.

Resta sintonizzato!

Buona fortuna :)