Il flusso di lavoro "No-Prompt": la teoria basata sui loop di Boris per la produttività degli sviluppatori

"Non scrivo più prompt in Claude. È il ciclo che sta girando, ed è il ciclo che decide cosa fare dopo, dando indicazioni a Claude. Il mio lavoro è diventato scrivere i cicli."

Queste sono le parole pronunciate pubblicamente da Boris Cherny, che guida Claude Code (citato in The New Stack e negli articoli di Addy Osmani).

Mentre molti di noi stanno ancora affinando i prompt per migliorare la precisione, la persona che costruisce lo strumento si è già allontanata dal ruolo di "prompter".

Se ci pensi, finché è coinvolto il "turno umano" – stare davanti a uno schermo, aspettare la risposta dell'IA, controllarla e dare di nuovo istruzioni – il limite di velocità è determinato dalla velocità delle tue stesse mani.

Loop Engineering è l'idea di rimuovere quel turno umano dalla struttura. Boris ci crede fermamente; dice di aver cancellato il suo IDE a novembre 2024 e di non averlo più riaperto. Afferma che quasi tutti i suoi contributi a Claude Code nell'ultimo mese sono stati scritti da Claude Code stesso (si parla di oltre 200 PR).

Il creatore dello strumento non scrive codice lui stesso, ma è passato dalla parte di "osservare se il ciclo gira correttamente". Oggi analizzerò questo concetto a livello di specifiche tecniche, non solo come suggestione. Anch'io sto spostandomi verso il lato dei cicli, e più mi sposto, più sento le mie mani diventare libere.

Articolo correlato: Introduzione a Vibe Coding: 6 passi per chi non sa programmare per creare app con Claude. È arrivata l'era della produzione interna nei fine settimana

https://note.com/nobel/n/n8192ec07d689

Loop Engineering Significa un Cambiamento di Ruoli

In altre parole, la tua posizione cambia. Prima, gli umani erano al centro di uno scambio in cui l'umano dava istruzioni, l'IA rispondeva e l'umano controllava e correggeva. Nel design dei cicli, gli umani sono responsabili della progettazione del meccanismo di circolazione (il loop), mentre la sperimentazione e la verifica dei risultati vengono spostate sul lato dell'IA. Aspetti semplicemente una notifica quando è finito.

Addy Osmani di Google ha scritto lo stesso in un articolo intitolato Loop Engineering, descrivendolo come "sostituire la persona che scrive prompt con un meccanismo che scrive prompt per suo conto". Il punto di leva si è spostato dalla capacità di scrivere buoni prompt a come progettare un sistema che permetta all'IA di scrivere prompt per te. Questo è il nucleo.

Tuttavia, Addy stesso avverte: "È ancora nelle fasi iniziali, e sono piuttosto scettico. Devi davvero fare attenzione ai costi dei token." Torneremo su questa insidia nella seconda metà.

Le Specifiche Tecniche di /loop

Claude Code ha un'abilità integrata chiamata /loop (dalla v2.1.72 in poi). Questo è il punto di ingresso più semplice per il loop engineering. Poiché le spiegazioni online sono spesso piene di errori, mi concentrerò sui punti chiave basandomi sulla documentazione ufficiale delle attività programmate.

Il comportamento cambia a seconda di cosa gli passi:

• Sia intervallo che prompt: /loop 5m check if the deployment is finished and let me know viene eseguito a intervalli fissi.
• Solo prompt: /loop check if the CI passed and respond to review comments. Claude decide l'intervallo da solo tra 1 minuto e 1 ora (auto-regolato).
• Niente passato: /loop. Viene eseguito il prompt di manutenzione predefinito (continuare lavori incompiuti, occuparsi delle PR, pulizie leggere) o un file loop.md che hai inserito.

L'intervallo può essere posizionato all'inizio come 30m o alla fine come every 2 hours. Le unità sono s / m / h / d. Puoi anche passare altri comandi, ad esempio /loop 20m /review-pr 1234, per eseguire abilità salvate ogni volta. Per fermarlo, premi Esc mentre aspetti (le attività create tramite richieste in linguaggio naturale non si fermano con Esc; devi chiedere di eliminarle). In modalità auto-regolata, se Claude determina che l'attività è davvero conclusa, termina senza programmare la prossima esecuzione.

La modalità auto-regolata ha un vantaggio sottile: si regola automaticamente, aspettando poco se una build è quasi finita e più a lungo se non succede nulla. A volte viene utilizzato un meccanismo chiamato "Monitor" per trasmettere l'output in background anziché fare polling, che spesso è più economico che lanciare un prompt a intervalli fissi.

Lasciatemi correggere un malinteso comune trovato negli articoli di partenza. A volte si scrive che le attività vengono "automaticamente eliminate 3 giorni dopo la creazione", ma con precisione, le attività ricorrenti scadono 7 giorni dopo la creazione (vengono eseguite un'ultima volta e poi spariscono). Inoltre, /loop è legato alla sessione e scompare quando avvii una nuova conversazione. Se lo chiudi, puoi tornare con --resume se non è scaduto.

Esistono tre metodi di programmazione, scelti in base al caso d'uso:

• Cloud (Routines): Viene eseguito sul lato Anthropic. Funziona anche se la macchina è spenta. Intervallo minimo 1 ora.
• Attività programmate desktop: Viene eseguito sulla tua macchina e può toccare i file locali.
• /loop: Solo finché la sessione è aperta. Minimo 1 minuto, comodo per il polling durante una sessione.

La divisione dei compiti è: usa Routines o GitHub Actions per la residenza permanente senza intervento umano, e /loop per il monitoraggio durante una sessione.

Attività Standard per Cui i Loop Sono Efficaci

Le attività nella tua routine in cui ripeti "controlla e correggi un po'" sono generalmente adatte ai loop. Ci sono tre modelli comuni:

• Bug Patrol: Rileva problemi o fallimenti dei test, legge la causa, li sistema, esegue i test e crea una PR a intervalli regolari.
• Revisione Continua: Monitora le modifiche al codice e continua a segnalare aree di preoccupazione. Gli umani decidono solo se accettare i suggerimenti.
• Sincronizzazione Documenti: Rileva modifiche al codice sorgente e mantiene aggiornati README o specifiche.

Il punto in comune tra questi tre è che l'obiettivo può essere giudicato chiaramente, come "test superati" o "PR creata". Al contrario, le attività con criteri ambigui non sono adatte ai loop. Se il punto di arresto non è chiaro, continuerà semplicemente a girare consumando token. Per la tua prima attività, è più sicuro sceglierne una in cui successo o fallimento siano evidenti a colpo d'occhio.

Prevenire Fughe e Smemoratezze con i "File di Stato"

Ci sono due paure con i loop: ripetere lo stesso fallimento e consumare token all'infinito.

Qui è efficace progettare con un singolo file di stato nel progetto. Che sia STATE.md o todo.md, l'IA legge e scrive l'obiettivo corrente / elementi completati / prossimi passi / punti critici durante ogni ciclo. Anche se la sessione viene interrotta, l'IA non perde traccia di "dove si trova e cosa sta cercando di ottenere".

Non è solo una pratica casuale; la stessa Anthropic è giunta a quasi la stessa conclusione in Effective harnesses for long-running agents (novembre 2024). La loro configurazione utilizza due ruoli: un agente inizializzatore per preparare l'ambiente e un agente di codifica per far progredire una funzionalità per sessione. Il progresso viene passato tra le sessioni tramite commit git e un file claude-progress.txt. Per lavori lunghi, la compressione tramite riepilogo è insufficiente. La politica è scrivere in un file strutturato una volta e ricostruire il contesto.

Nelle mie operazioni, uso tasks/state.md come hub per lo stato condiviso, che sia il lato brainstorming che quello implementazione leggono prima di agire. È come nel documento: "Non fidarti del contesto, fidati del file." È semplice, ma senza questo, il ciclo si perde al secondo giro.

Il Metodo Ralph e la Separazione tra Creatore e Controllore

Esiste una versione estrema del loop chiamata metodo "Ralph". Resa popolare da Geoffrey Huntley, la fonte originale è solo un semplice loop bash:

Fornendo lo stesso prompt all'infinito e usando un file Markdown con il piano come stato condiviso su disco, l'IA lo legge ogni volta e decide "cosa fare dopo" da sola. Sembra avventato, ma poiché esiste un file di stato, avanza a ogni giro. Claude Code ha anche un plugin ufficiale ralph-loop che continua a reinviare lo stesso prompt fino a quando non viene soddisfatta una condizione di completamento (promessa di completamento). C'è un vincolo: la dichiarazione di completamento deve essere emessa solo quando è realmente raggiunta.

Tuttavia, se affidi tutto a una sola IA, dirà "OK" al codice che ha scritto lei stessa. È qui che è efficace separare l'IA che crea (Maker) e l'IA che ispeziona (Checker). Nelle mie operazioni, separo implementazione e verifica in agenti diversi, e non do al lato verifica l'intento di implementazione – mostro solo i requisiti e lascio che valuti in modo indipendente. Ho imparato a mie spese che le auto-revisioni nella stessa sessione sono inevitabilmente indulgenti.

Incorporare un "agente di revisione con una prospettiva diversa" nel loop – progettare questo controllo multilivello è uno dei compiti che gli umani dovrebbero mantenere.

Progettare l'Autonomia in Tre Fasi

Affidare tutto in una volta porterà a incidenti. È più sicuro separare il livello di coinvolgimento in strati:

• L1 (Manuale): Gli umani scrivono prompt e li controllano uno per uno. Il modo tradizionale.
• L2 (Loop Semi-Autonomo): Segue un file di stato e monitora un insieme specifico di attività fino al completamento con /loop.
• L3 (Residente): Viene eseguito continuamente tramite Routines o GitHub Actions senza intervento umano.

È realistico iniziare con L2. Esegui un'attività fino al completamento con /loop e osserva il comportamento. Passa a L3 una volta che vedi il range di affidabilità. Le prime volte, ho guardato i log su uno schermo laterale per vedere "dove faceva un giudizio sbagliato".

Insidie (Conoscerle Prima)

Dato che ho scritto solo degli aspetti positivi, ecco tre punti dove potresti incappare:

1. Costi dei Token: I loop consumano di più più a lungo girano. Questo è ciò che Addy ha sottolineato; se imposti l'intervallo troppo breve, può costare una bella somma durante la notte. La modalità auto-regolata è meglio degli intervalli fissi perché aspetta quando necessario, riducendo gli sprechi.
2. Operazioni Irreversibili: Il prompt di manutenzione predefinito esegue solo azioni irreversibili come push o cancellazioni entro il "range già consentito nella conversazione". Quando scrivi i tuoi prompt, è più sicuro definire tu stesso i confini per le operazioni distruttive.
3. Scompare in 7 Giorni: Le attività /loop ricorrenti scadono 7 giorni dopo la creazione. Se vuoi farle girare più a lungo, passa a Routines o attività desktop.

Note per Utenti Intermedi

• /loop e /goal sono diversi. /loop viene eseguito per intervallo. Se vuoi continuare a ogni turno fino a quando una condizione è soddisfatta, usa /goal. Se vuoi che reagisca nel momento in cui si verifica un evento, usa il push tramite Channels.
• Inserendo un file loop.md (.claude/loop.md o ~/.claude/loop.md) puoi sostituire il prompt predefinito di un /loop nudo con il tuo. È utile per scrivere attività di routine come "sistema se la CI del branch di rilascio è rossa."
• Fino a 50 attività programmate per sessione. Puoi vedere l'elenco con CronList ed eliminarle per ID con CronDelete.

Riepilogo

Prima, il tempo che passavo davanti allo schermo era il limite massimo del progresso. Ora, un ciclo che legge un file di stato mentre dormo fa progredire una funzionalità alla volta, e la mia mattina inizia controllando quel progresso.

Prima di migliorare il contenuto (precisione del prompt), progetta il modo in cui viene eseguito (separazione dei cicli, gestione dello stato e verifica). La leva si è spostata lì – questo è il punto comune nelle storie di Boris, Addy e dell'harness di Anthropic. Credo non sia una teoria difficile, ma un accumulo costante di progetti semplici, come decidere quando fermarsi prima di avviare il loop.

Informazioni utili che non possono essere condivise su X vengono condivise nel LINE OpenChat. Se sei interessato a utilizzare Claude Code/Codex o a usare l'IA per operazioni su X, unisciti a noi.

https://t.co/9LOoUYvCbO