Un flusso di lavoro notturno per agenti di coding

Scrivi i task come per un nuovo collaboratore esterno

Un task notturno non ha nessuno a cui chiedere. Deve portarsi dietro il proprio contesto. Ogni task deve stare in un paragrafo e rispondere a tre domande. Cosa non va o cosa manca. Come si presenta il lavoro finito. Come dimostrarlo.

## Task: paginate the /orders endpoint
Problem: GET /orders returns every order. Large accounts time out.
Done: accepts ?cursor and ?limit (max 100), returns next_cursor.
Proof: new tests in tests/orders_pagination.test.ts pass; existing tests pass.
Do not: change the response shape of existing fields.

Tieni i task piccoli. La misura ideale è tra due e quattro ore di lavoro umano. Se è più grande, dividilo. Va bene anche un task che l’agente chiude in venti minuti. Mettili in un file nel repository o in issue che l’agente può leggere. Il file è la soluzione più semplice.

Un task, un branch, un worktree

I task non devono condividere un working tree. Due task che modificano lo stesso checkout producono un diff che nessuno riesce a districare. I git worktree danno a ogni task la sua cartella sullo stesso repository.

git worktree add ../work/orders-pagination -b agent/orders-pagination
git worktree add ../work/retry-webhooks -b agent/retry-webhooks

Ogni branch ha la sua esecuzione dell’agente e la sua pull request. Al mattino le rivedi una alla volta. Se una è sbagliata la chiudi, e le altre restano intatte.

Decidi cosa fa l’agente da solo

Imposta la modalità dei permessi e la lista deny prima della prima esecuzione, non dopo. La guida per far girare Claude Code senza supervisione ha le impostazioni esatte. Per il lavoro notturno la versione breve è questa. Modifica i file liberamente. Esegui la suite di test liberamente. Fai commit e push del branch del task liberamente. Apri una pull request. Nient’altro senza chiedere, e niente che esca dal repository.

Il ciclo di esecuzione

Un piccolo script avvia un’esecuzione headless per ogni task, nel suo worktree, con un tetto di turni e un file di log. È tutto qui.

#!/bin/sh
# run-overnight.sh: one agent run per task file in tasks/
for task in tasks/*.md; do
  name=$(basename "$task" .md)
  dir="../work/$name"
  git worktree add "$dir" -b "agent/$name" 2>/dev/null
  (
    cd "$dir" || exit 1
    claude -p "Complete the task in $task. Commit on this branch, push it, and open a pull request with gh pr create. Stop when the tests pass or when you are blocked, and say which." \
      --permission-mode acceptEdits \
      --max-turns 80 \
      > "../logs/$name.log" 2>&1
  )
done

Eseguilo dentro tmux, così la connessione SSH non conta. I task girano uno dopo l’altro. Le esecuzioni in parallelo sono possibili. Però si contendono la CPU e il tuo rate limit, e rendono i log più difficili da leggere. Inizia in sequenza.

Lascia giudicare i test

Il prompt dice all’agente di fermarsi quando i test passano. Poi la tua CI esegue gli stessi test sulla pull request. Se l’agente dice verde e la CI dice rosso, lo sai prima di leggere una riga del diff. Proteggi main, così niente entra senza quel controllo. È la protezione più preziosa di tutto il flusso, e non costa nulla.

La revisione del mattino, dieci minuti

• Apri la lista delle pull request. Confrontane il numero con la lista dei task. Quelle mancanti sono nei log.
• Leggi il log di ogni task che si è fermato perché bloccato. Di solito manca una credenziale o il task è ambiguo. Correggi il testo del task, non l’agente.
• Rivedi le pull request verdi partendo dalla più piccola. Fai il merge di quelle giuste. Chiudi quelle sbagliate con una riga che spiega perché, e copia quella riga nel file dei task di domani.
• Cancella i worktree e i branch già uniti, così stasera si riparte puliti.

git worktree remove ../work/orders-pagination
git branch -d agent/orders-pagination

Cosa affidare per primo

Alcuni lavori si adattano alla notte meglio di altri. Parti da questi e allarga man mano che cresce la fiducia.

• Test che falliscono o instabili, con un comportamento atteso chiaro.
• Aggiornamenti delle dipendenze in cui giudica la suite di test.
• Refactoring meccanici su molti file.
• Test mancanti per codice che funziona già.
• Errori di tipo, errori di lint e avvisi di deprecazione.

Tieni per il giorno le decisioni di design, tutto ciò che tocca fatturazione o autenticazione e tutto ciò che i test non possono verificare. Di giorno puoi rispondere alle domande.

La macchina sotto

Tutto questo presuppone una macchina che alle 4 di notte sta ancora girando. Un portatile che va in stop è il motivo più comune per cui una notte di lavoro non produce nulla. La guida sullo stop risolve il problema su un Mac tuo. Un Mac per agenti in hosting lo ha già risolto.