Come porto avanti il lavoro mentre dormo: il mio workflow a loop

Pensavo che i loop fossero solo un modo elegante per dire “continua a chiedere cose all’AI”.

Poi ne ho provato uno seriamente e ha cambiato il modo in cui mantengo Synara. Non perché Codex sia diventato magico all’improvviso. Non perché possa fidarmi ciecamente di un agente. Ma per un piccolo cambiamento che fa tutta la differenza:

il prompt non è più soltanto la richiesta. Il prompt è il flusso di lavoro.

Da dove è iniziato tutto

L’idea è arrivata da un post di @theo. Aveva lasciato Codex al lavoro durante la notte su una pila di vecchie PR: chiudere quelle inutili, recuperare quelle non aggiornate, assegnare a ciascuna una chat per svilupparla e una seconda per revisionarla. Diceva che gli aveva cambiato il modo di vedere i loop, e che prima non era nemmeno un loro appassionato.

L’idea originale risale a un post di @steipete, quindi il merito va a entrambi. Theo l’aveva messa in modo semplicissimo:

Chiedi a Codex di mantenere i tuoi repository. Fallo riattivare ogni cinque minuti per assegnare il lavoro alle chat.

Mi ha convinto, così l’ho provato sulle issue e sulle PR di Synara. Ne è valsa la pena.

Un po’ di contesto: cos’è Synara

Synara è un’app desktop open source che mantengo. È un’interfaccia grafica per gli strumenti di coding con agenti: un unico posto in cui usare tutti i tuoi provider e abbonamenti, tra cui Codex, Gemini, OpenCode, Cursor, Grok, Kilo Code e altri. Siamo arrivati a quasi 5.700 download e ci stiamo avvicinando alle 1.000 stelle.

Questo significa anche che c’è sempre qualcosa da fare. Issue, PR, piccoli bug, vecchi branch, funzionalità che vorrei provare ma non ho mai tempo di iniziare.

Se mantieni un progetto open source, conosci la sensazione. La parte difficile non è solo scrivere codice. È far avanzare tutto senza impazzire. Apri GitHub e trovi cinque cose tutte “piccole”, ma ognuna richiede contesto, test, revisione, pulizia e una decisione.

È proprio su questo accumulo di attività che i loop funzionano bene.

Il mio primo vero tentativo durante la notte

Il primo test serio è successo di notte, intorno all’1:40.

Avevo alcune PR e issue di Synara da gestire, ma non volevo stare lì ad affrontarle una per volta. Così, prima di dormire, ho scritto un lungo prompt. L’idea era semplice: affidare quattro PR a Codex e lasciargli eseguire l’intero ciclo di lavoro su ciascuna mentre dormivo. Senza modalità veloce, perché l’obiettivo era lasciarlo lavorare per ore.

Il prompt diceva più o meno questo:

• crea una chat con worktree separato per ogni PR
• mantieni ogni branch isolato, senza mai mescolare le modifiche
• correggi il problema soltanto in quel worktree, poi esegui i test
• avvia una seconda chat nello stesso worktree con /review, cerca problemi e correggili
• elimina la logica duplicata usando le skill appropriate, così il codice resta pulito
• fai push del branch e apri o aggiorna la PR
• tagga il bot Codex e controlla ogni cinque minuti se ha segnalazioni
• correggi le segnalazioni e ripeti finché l’ultimo commit non ha più problemi
• alla fine scrivi un rapporto conclusivo

La riga più importante in assoluto era questa:

NON MESCOLARE BRANCH O MODIFICHE.

Ho ripetuto spesso questo concetto. Quando esegui più agenti contemporaneamente, l’isolamento è tutto. Una PR, un worktree, una chat. Sembra noioso, ma sono proprio le regole noiose a rendere possibile l’automazione notturna. Se salti questo passaggio, le modifiche non preparate su main finiscono nei nuovi worktree e al risveglio trovi un disastro.

Cosa ho trovato al risveglio

La mattina avevo quattro PR completate. Quattro problemi risolti. Branch separati, worktree separati, passaggi di revisione e PR pronte da controllare.

E, soprattutto, un rapporto che spiegava cosa fosse successo.

Quel rapporto finale è sottovalutato. Quando un agente lavora per ore, la domanda del mattino non è soltanto “ha funzionato?”. La vera domanda è: “posso capire cosa è successo senza leggere tutta la chat?”.

Il rapporto rispondeva alle domande che mi interessavano:

• cosa era stato corretto
• quale PR corrispondeva a quale issue
• quali file erano cambiati e quali test erano stati eseguiti
• quali problemi della revisione erano stati risolti
• cosa aveva detto il bot
• cosa restava rischioso o bloccato

Si concludeva persino con una tabella essenziale: per ogni PR, era tutto a posto? Si poteva fare il merge? Cosa mancava? Senza quel rapporto ti svegli nel caos. Con il rapporto ti svegli davanti a un riepilogo ordinato. Una differenza enorme.

Il vero flusso di lavoro

Questa è la parte che conta.

Il valore non sta nello scrivere un prompt gigantesco. Sta nel descrivere il processo di sviluppo reale. Quando dico a Codex “sistema questa PR”, ottengo una patch. A volte buona, a volte disordinata. Ma quando descrivo il ciclo, ottengo qualcosa di molto più vicino a come lavorerei io:

1. Controllare il branch corrente, lo stato della PR e l’ultimo commit.
2. Capire il problema.
3. Implementare la correzione.
4. Eseguire i controlli pertinenti.
5. Revisionare le modifiche.
6. Correggere i problemi emersi.
7. Riorganizzare la logica duplicata o disordinata.
8. Revisionare di nuovo.
9. Fare push.
10. Chiedere una revisione al bot GitHub.
11. Aspettare il feedback.
12. Correggere le segnalazioni.
13. Fermarsi solo quando l’ultimo commit non ha problemi da risolvere.

L’ultima riga è fondamentale. Fermarsi solo quando l’ultimo commit non ha problemi da risolvere. Non quando un vecchio commento diceva che andava tutto bene tre commit fa. Non quando l’agente “si sente arrivato”. La revisione deve riguardare l’ultimo commit pubblicato.

Perché conta l’ultimo commit

I bot di revisione possono trarti in inganno se non controlli quale commit hanno effettivamente esaminato.

Immagina: il bot revisiona il commit A e dice che va tutto bene. Poi Codex pubblica il commit B. Se guardi solo il vecchio commento, pensi che la PR sia a posto. Ma quella revisione positiva riguarda A, non B. È una falsa sicurezza.

Per questo ora dico esplicitamente a Codex: non fidarti delle revisioni non aggiornate. Considera valida una revisione positiva solo se riguarda l’ultimo commit pubblicato. Sono questi piccoli dettagli a rendere i loop affidabili anziché casuali.

Il modello di prompt

Questo è il prompt originale, in inglese, che eseguo prima di andare a dormire:

I want you to create a separate worktree thread for every PR shown in the image.
 
Use GPT-5.5 with extra-high reasoning for every thread.
 
Important:
DO NOT MIX BRANCHES OR CHANGES.
Each PR must have its own isolated worktree, branch, and thread.
Do not touch main unless the workflow explicitly requires it.
Do not edit sibling worktrees.
Keep everything separated.
 
For every PR, start a dedicated worktree thread and run this as the /goal:
 
/goal Try to fix the issue described in this PR. First inspect the current
branch, PR state, latest head, and relevant files. Then implement the fix in
this worktree only.
 
After the fix:
1. Run the relevant tests/checks.
2. Create a new same-worktree thread and run a /review pass on the changes.
3. If the review finds issues, fix them in the same worktree.
4. After that, look for ways to clean up, optimize, or refactor the code you
   created, especially if there is duplicated logic, messy abstractions, or
   avoidable complexity. Use the appropriate skills for this.
5. Run another same-worktree /review pass after the refactor.
6. Fix any remaining review findings.
 
Once the PR is clean:
1. Push the branch.
2. Create or update the PR for that fixed work.
3. Ask codex-bot to review it.
4. Keep checking every 5 minutes for codex-bot feedback.
5. If codex-bot responds with findings, fix them, push again, and ask for
   another review.
6. Only consider the PR done when the latest pushed head has no actionable
   findings.
 
Do not trust stale review results.
Always verify that the clean review applies to the latest pushed head.
 
When a PR is fully handled, close that thread with a concise final status:
PR link
branch/worktree
what was fixed
what was changed
tests/checks run
review status
anything still risky or blocked
 
After every PR is done, create one new final report thread.
That report should explain, in a comprehensive way:
every PR handled
what changed in each one
why the changes were needed
what tests/checks/reviews were run
which branches/PRs were created
what is fully done
what, if anything, is still pending or blocked

Non è perfetto, e puoi adattarlo al tuo repository. Ma funziona perché dice all’agente esattamente cosa significhi “finito”. Il vero trucco è questo.

Un buon prompt definisce quando hai finito

Un prompt vago chiede un risultato. Un buon loop chiede uno stato.

Per esempio:

• i test passano
• git diff --check non segnala problemi
• la PR esiste
• l’ultimo commit è stato revisionato
• il bot non ha segnalazioni su cui intervenire
• il rapporto finale esiste

Questi sono stati. Sono verificabili. Rendono molto meno probabile che l’agente si fermi a un generico “mi sembra tutto a posto”.

Probabilmente è il cambiamento più importante per me. Non voglio che Codex si fermi perché è stanco, confuso o soddisfatto. Voglio che si fermi perché il processo ha raggiunto una condizione chiara.

Cosa può ancora andare storto

Non è magia. Serve ancora giudizio, bisogna leggere la PR e bisogna capire quando l’architettura è semplicemente sbagliata.

L’ho imparato in fretta. Per una funzionalità di Synara, la prima direzione era troppo limitata. Il modello ragionava su più account Codex, ma serviva un’astrazione basata su più istanze di provider: una struttura adatta a Codex, Claude, Gemini e a ciò che verrà dopo. Non “account A contro account B”.

In quel caso la mossa giusta non era “continua a programmare”. Era fermarsi, analizzare l’architettura e ripartire con un obiettivo migliore. Anche questo è progresso. A volte il loop migliore è quello che capisce di stare risolvendo il problema sbagliato.

Perché funziona così bene per l’open source

Mantenere un progetto open source significa eseguire tanti piccoli cicli. Revisiona questo. Correggi quello. Controlla se questa PR è ancora valida. Aggiorna il branch. Esegui il test. Correggi la segnalazione. Scrivi il riepilogo.

Niente di impossibile. Ma costa attenzione, e l’attenzione è il vero collo di bottiglia. Questo flusso mi permette di spendere meno energie a sorvegliare la manutenzione e più energie sulle decisioni che contano: cosa integrare, cosa rifiutare e dove portare Synara.

È lì che voglio usare la testa. Non ad aggiornare la stessa PR ogni cinque minuti aspettando un commento del bot.

Come vedo Codex adesso

Non penso più a Codex come a una casella di chat. Lo vedo come un collaboratore che ha bisogno di un sistema di lavoro intorno.

Se gli dai un compito vago, ottieni lavoro vago. Se invece gli dai contesto, confini, regole di isolamento, cicli di revisione, controlli, condizioni di arresto e requisiti per i rapporti, ottieni qualcosa di molto più vicino a un risultato di sviluppo concreto. Non significa fidarsi ciecamente. Significa dargli un processo migliore in cui operare.

Se vuoi provarci

Parti da una issue. Non dieci. Una.

Crea un worktree isolato. Chiedi a Codex di risolvere il problema. Poi chiedi a una seconda chat nello stesso worktree di revisionare le modifiche. Correggi le segnalazioni. Chiedi al bot di revisionare la PR. Fai controllare il feedback a Codex. Solo quando funziona passa a più PR.

Il numero di agenti non è la parte interessante. Lo è il ciclo.

Un consiglio pratico: se lo lasci lavorare di notte su un Mac, il computer deve rimanere sveglio, altrimenti gli agenti si fermano. Tieni aperto qualcosa come Amphetamine oppure lascia il coperchio aperto, in modo che non vada in stop.

Un ultimo pensiero

La cosa incredibile non è che Codex possa lavorare mentre dormo.

È poter definire un processo prima di andare a letto e svegliarmi con un lavoro che ha già attraversato implementazione, revisione, pulizia, feedback del bot e rendicontazione. Somiglia meno a scrivere prompt e più a progettare un piccolo sistema operativo per il mio lavoro.

Per mantenere Synara, cambia davvero le cose. Non voglio spendere le mie energie a spostare attività di manutenzione da una scheda all’altra. Voglio costruire, decidere e far avanzare il progetto. I loop me lo permettono.

Onestamente, credo che ogni manutentore di un progetto open source dovrebbe provarci almeno una volta.

Fonti

• Il video di Theo: I guess we’re writing loops now?
• Il post di Theo: x.com/theo
• Il post di Peter: x.com/steipete

Racconto tutto il mio percorso di sviluppo in pubblico su X/Twitter: cosa pubblico, cosa si rompe e cosa imparo.