Come eseguire Claude Code in autonomia per ore senza doverlo supervisionare

Ho lasciato Claude Code in esecuzione durante la notte per un compito reale. Stavo testando AIdaemon, il mio agente AI personale, tramite l'interfaccia web di Telegram. L'ho controllato durante il giorno, l'ho lasciato andare avanti tutta la notte, e la mattina dopo era in esecuzione da oltre 27 ore. 84 compiti completati. Ha trovato bug, ha corretto il codice, ha ritestato e poi è passato a test più difficili. Tutto senza che io toccassi nulla. Sono sull'abbonamento Claude Code 20x, che ti dà capacità sufficiente per eseguire effettivamente sessioni come questa.

La configurazione che ha reso possibile tutto ciò è costituita da tre flag e un buon file di prompt.

Saltare le richieste di autorizzazione

Claude Code normalmente chiede conferma prima di eseguire comandi o modificare file. Va bene quando sei lì seduto. Ma per le esecuzioni notturne, ogni richiesta di autorizzazione è un blocco totale. La sessione rimane lì in attesa che tu faccia clic su "consenti".

claude --dangerously-skip-permissions

Il nome del flag è spaventoso di proposito. Significa che Claude Code esegue ogni chiamata di strumento senza chiedere. Non lo userei su una macchina con segreti di produzione. Su una macchina di sviluppo con un compito circoscritto, tuttavia, è ciò che rende possibili le esecuzioni non presidiate.

Dagli un browser

Avevo bisogno che Claude Code interagisse con un'applicazione web. Stavo testando il bot Telegram di AIdaemon tramite Telegram Web, e Claude Code da solo non può farlo poiché risiede nel terminale.

Il flag --chrome lo collega a Chrome tramite l'estensione Claude in Chrome MCP. Può navigare nelle pagine, fare clic sui pulsanti, compilare moduli, leggere contenuti, acquisire screenshot. Combina entrambi i flag e ottieni qualcosa che può scrivere codice nel terminale e testarlo nel browser.

claude --chrome --dangerously-skip-permissions

Nel mio caso, Claude Code inviava un messaggio ad AIdaemon tramite Telegram Web, leggeva la risposta, decideva se l'agente aveva fatto la cosa giusta e andava a correggere il codice in caso contrario. Quindi provava la stessa cosa di nuovo per confermare.

Mantienilo in esecuzione con Ralph Loop

Se avvii semplicemente Claude Code con un prompt grande, finisce ed esce. O pensa di aver finito ed esce. Va bene per un compito veloce ma inutile per qualcosa che dovrebbe richiedere ore.

Ralph Loop è un plugin di Claude Code che risolve questo problema. Installa un hook di arresto. Quando Claude tenta di uscire, l'hook lo intercetta e reinserisce lo stesso prompt. Ogni iterazione avvia una conversazione fresca con lo stesso prompt, ma Claude può vedere lo stato attuale dei file e la cronologia git. Capisce cosa è stato fatto e decide cosa fare dopo. Il nome deriva dalla tecnica Ralph Wiggum di Geoffrey Huntley. L'idea originale era semplicissima, un ciclo bash while true che continua a inserire un file di prompt in un agente AI finché non lo ottiene correttamente. Forza bruta incontra persistenza, come il personaggio dei Simpsons che continua ad andare avanti a prescindere da tutto. Anthropic l'ha apprezzato abbastanza da rilasciare un plugin Ralph Wiggum come parte di Claude Code.

/ralph-loop "il tuo prompt del compito qui" --completion-promise "DONE"

Il --completion-promise è l'unica via d'uscita. Claude può interrompere il ciclo solo emettendo quella stringa esatta. Puoi anche impostare --max-iterations, come rete di sicurezza.

Scrivi un prompt reale

Gli strumenti sopra menzionati sono i meccanismi. Ma il prompt determina se ottieni un'ora di lavoro utile o ventisette. "Testa la mia app e correggi i bug" ti darà forse un'ora prima che Claude dichiari vittoria dopo una correzione.

Per qualsiasi cosa seria, scrivo un file markdown. Architettura, obiettivi, vincoli, cosa significa realmente "fatto". Poi lo passo a ralph-loop.

/ralph-loop "$(cat task-prompt.md)" --completion-promise "DONE"

Il mio prompt per la sessione di 27 ore era simile a questo.

# Compito. Testa e rafforza l'agente Telegram di AIdaemon

## Contesto
AIdaemon è un agente AI multiuso accessibile tramite Telegram.
L'interfaccia web è su https://web.telegram.org/k/#@aidaemon_coding_bot

## Obiettivi
- Sfida l'agente con compiti progressivamente più difficili
- Non limitarti a testare i percorsi felici. Prova casi limite, input malformati,
  operazioni complesse in più passaggi
- Quando qualcosa si rompe, correggi il codice sottostante
  (non un cerotto per quel caso specifico)
- Ritesta dopo ogni correzione per confermare che funzioni E che nient'altro si sia rotto

## Note sull'architettura
(percorsi di file pertinenti, come l'agente elabora i messaggi,
moduli chiave, schema del database, tutto ciò di cui Claude ha bisogno)

## Criteri di successo
- Tutte le operazioni di base funzionano in modo affidabile
- Casi limite gestiti con grazia
- I messaggi di errore sono utili, non criptici
- Nessuna regressione dalle correzioni precedenti
- Emetti DONE quando tutto quanto sopra è vero

Senza note sull'architettura, Claude spreca iterazioni per capire la codebase. Senza criteri di successo chiari, non sa quando fermarsi. Senza l'istruzione di apportare correzioni generiche, scrive un'istruzione if per un input specifico e va avanti.

Cosa è successo nelle 27 ore

Ho eseguito il comando e sono andato a letto.

La prima ora è stata dedicata alle basi. Messaggi semplici al bot, controllo delle risposte. Poi ha iniziato a intensificarsi da solo. Compiti di refactoring su più file. Recupero degli errori con input non validi. Ha trovato una vulnerabilità di prompt injection, ha scritto una difesa, quindi ha testato una variante di injection più difficile per verificare se la difesa reggeva.

Al test 88, l'agente stava costruendo un parser JSON da zero con 79 casi di test. In precedenza aveva corretto i limiti di ping delle notifiche in background, risolto bug nella risoluzione dei nomi degli strumenti e rilevato un problema di UX in cui le meccaniche interne venivano visualizzate nei messaggi rivolti all'utente.

Le correzioni erano reali, non superficiali. Il "profilo economico" utilizzava first_fallback invece del modello predefinito, quindi ha corretto la logica di configurazione. La risoluzione del nome dello strumento di saturazione della lettura non funzionava, quindi ha aggiunto un fallback a cascata per tutte le profondità, non solo per quella che si era rotta.

84 compiti in totale. Test, correzioni, ritest. Tutto autonomo.

Cosa condividerei con chi prova questo

Ho eseguito alcune sessioni con prompt a riga singola prima di questa. Hanno perso slancio dopo un'ora o due. La sessione di 27 ore è continuata perché il file di prompt aveva abbastanza contesto affinché Claude rimanesse concentrato attraverso decine di iterazioni.

Dire a Claude di apportare correzioni generiche invece di patch specifiche ha fatto una differenza reale. Senza questo, scrive il codice minimo per superare il test corrente. Con questo, le correzioni hanno effettivamente prevenuto anche bug correlati.

L'accesso al browser ha catturato cose che i test unitari non avrebbero rilevato. Stranezze dell'interfaccia utente, problemi di temporizzazione, problemi di formattazione. --chrome ha permesso a Claude di eseguire test end-to-end reali invece di eseguire semplicemente codice in isolamento.

Ho esaminato tutte le modifiche in seguito. La maggior parte erano buone. Un paio erano eccessivamente complesse e un refactoring ha toccato più file del necessario. Ma nel complesso, decine di bug reali trovati e corretti, ognuno confermato con un ritest.

Se vuoi provarlo, installa il plugin Ralph Loop, scrivi un file di prompt appropriato e inizia in piccolo. --max-iterations 10 su un compito circoscritto. Vedi come va prima di aumentare la scala.