Un workflow de nuit pour les agents de code

Rédigez les tâches comme pour un nouveau prestataire

Une tâche de nuit n’a personne à qui poser ses questions. Elle doit porter son propre contexte. Chaque tâche doit tenir en un paragraphe et répondre à trois questions. Qu’est-ce qui est cassé ou manquant ? À quoi ressemble le travail fini ? Comment le prouver ?

## 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.

Gardez des tâches petites. Deux à quatre heures de travail humain, c’est l’idéal. Au-delà, découpez. Une tâche que l’agent termine en vingt minutes convient aussi. Mettez-les dans un fichier du dépôt ou dans des issues que l’agent peut lire. Un fichier est le plus simple.

Une tâche, une branche, un worktree

Les tâches ne doivent pas partager un arbre de travail. Deux tâches qui modifient le même checkout produisent un diff que personne ne peut démêler. Les worktrees Git donnent à chaque tâche son propre dossier, sur le même dépôt.

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

Chaque branche a sa propre exécution d’agent et sa propre pull request. Le matin, vous les relisez une par une. Si l’une est mauvaise, vous la fermez, et les autres restent intactes.

Décidez ce que l’agent fait seul

Fixez le mode de permission et la liste deny avant la première exécution, pas après. Le guide pour faire tourner Claude Code sans surveillance donne les réglages exacts. Pour le travail de nuit, la version courte est la suivante. Modifier les fichiers librement. Lancer la suite de tests librement. Commiter et pousser la branche de la tâche librement. Ouvrir une pull request. Rien d’autre sans demander, et rien qui sorte du dépôt.

La boucle d’exécution

Un petit script lance une exécution headless par tâche, dans son worktree, avec un plafond de tours et un fichier de log. Le voici en entier.

#!/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

Lancez-le dans tmux, pour que la connexion SSH n’ait pas d’importance. Les tâches s’exécutent l’une après l’autre. Des exécutions en parallèle sont possibles. Mais elles se disputent le CPU et votre limite de débit, et elles rendent les logs plus difficiles à lire. Commencez en séquentiel.

Laissez les tests trancher

Le prompt dit à l’agent de s’arrêter quand les tests passent. Votre CI relance ensuite les mêmes tests sur la pull request. Si l’agent annonce du vert et que la CI dit rouge, vous le savez avant de lire une ligne du diff. Protégez main pour que rien ne soit mergé sans cette vérification. C’est le garde-fou le plus précieux du workflow, et il ne coûte rien.

La revue du matin, en dix minutes

• Ouvrez la liste des pull requests. Comparez leur nombre à la liste des tâches. Les manquantes sont dans les logs.
• Lisez le log de tout ce qui s’est arrêté comme bloqué. En général, c’est un identifiant manquant ou une tâche ambiguë. Corrigez le texte de la tâche, pas l’agent.
• Relisez les pull requests au vert, les plus petites d’abord. Mergez celles qui sont justes. Fermez celles qui sont fausses avec une ligne qui explique pourquoi. Copiez cette ligne dans le fichier de tâches de demain.
• Supprimez les worktrees et les branches mergés, pour que la nuit suivante reparte de zéro.

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

Quoi confier en premier

Certains travaux se prêtent mieux à la nuit que d’autres. Commencez par ceux-ci, et élargissez à mesure que la confiance s’installe.

• Les tests en échec ou instables, avec un comportement attendu clair.
• Les mises à jour de dépendances, quand la suite de tests fait juge.
• Les refactorings mécaniques sur de nombreux fichiers.
• Les tests manquants pour du code qui fonctionne déjà.
• Les erreurs de typage, les erreurs de lint et les avertissements de dépréciation.

Gardez pour la journée les décisions de conception, tout ce qui touche à la facturation ou à l’authentification, et tout ce que les tests ne peuvent pas vérifier. Vous pourrez alors répondre aux questions.

La machine en dessous

Tout cela suppose une machine qui tourne encore à 4 h du matin. Un portable qui se met en veille est la raison la plus courante d’une nuit sans résultat. Le guide sur la mise en veille règle cela sur un Mac à vous. Sur un Mac pour agents hébergé, c’est déjà réglé.