Ein Workflow für Coding-Agents über Nacht

Schreiben Sie Aufgaben wie für einen neuen Freelancer

Eine Aufgabe über Nacht hat niemanden, den sie fragen kann. Sie muss ihren Kontext selbst mitbringen. Jede Aufgabe sollte in einen Absatz passen und drei Fragen beantworten. Was ist falsch oder fehlt? Wie sieht fertig aus? Wie lässt es sich beweisen?

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

Halten Sie Aufgaben klein. Zwei bis vier Stunden menschlicher Arbeit sind ideal. Ist eine größer, teilen Sie sie. Eine Aufgabe, die der Agent in zwanzig Minuten erledigt, ist auch in Ordnung. Legen Sie die Aufgaben in eine Datei im Repository oder in Issues, die der Agent lesen kann. Eine Datei ist am einfachsten.

Eine Aufgabe, ein Branch, ein Worktree

Aufgaben dürfen sich kein Arbeitsverzeichnis teilen. Zwei Aufgaben im selben Checkout erzeugen einen Diff, den niemand mehr entwirrt. Git-Worktrees geben jeder Aufgabe einen eigenen Ordner im selben Repository.

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

Jeder Branch bekommt einen eigenen Agent-Lauf und einen eigenen Pull Request. Am Morgen prüfen Sie sie einzeln. Ist einer schlecht, schließen Sie ihn. Die anderen bleiben unberührt.

Legen Sie fest, was der Agent allein tut

Setzen Sie den Berechtigungsmodus und die Deny-Liste vor dem ersten Lauf, nicht danach. Die Anleitung für unbeaufsichtigte Läufe mit Claude Code enthält die genauen Einstellungen. Die Kurzfassung für die Nacht lautet so. Dateien frei bearbeiten. Die Testsuite frei ausführen. Den Aufgaben-Branch frei committen und pushen. Einen Pull Request öffnen. Sonst nichts ohne Nachfrage, und nichts, was über das Repository hinausgeht.

Die Schleife

Ein kleines Skript startet pro Aufgabe einen Headless-Lauf in deren Worktree, mit Obergrenze für die Züge und einer Logdatei. Mehr ist es nicht.

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

Lassen Sie es in tmux laufen, dann spielt die SSH-Verbindung keine Rolle. Die Aufgaben laufen nacheinander. Parallele Läufe sind möglich. Aber sie konkurrieren um die CPU und um Ihr Rate-Limit, und die Logs werden schwerer lesbar. Fangen Sie sequenziell an.

Lassen Sie die Tests entscheiden

Der Prompt sagt dem Agent, er soll aufhören, wenn die Tests bestehen. Ihre CI führt dann dieselben Tests auf dem Pull Request aus. Meldet der Agent grün und die CI rot, wissen Sie es, bevor Sie eine Zeile des Diffs lesen. Schützen Sie main, damit nichts ohne diese Prüfung gemergt wird. Das ist die wertvollste Leitplanke in diesem Workflow, und sie kostet nichts.

Die Prüfung am Morgen, zehn Minuten

• Öffnen Sie die Liste der Pull Requests. Gleichen Sie die Anzahl mit der Aufgabenliste ab. Was fehlt, steht in den Logs.
• Lesen Sie das Log von allem, was als blockiert gestoppt hat. Meist fehlen Zugangsdaten oder die Aufgabe ist mehrdeutig. Korrigieren Sie den Aufgabentext, nicht den Agent.
• Prüfen Sie grüne Pull Requests, die kleinsten zuerst. Mergen Sie die richtigen. Schließen Sie die falschen mit einer Zeile Begründung. Kopieren Sie diese Zeile in die Aufgabendatei für morgen.
• Löschen Sie gemergte Worktrees und Branches, damit die nächste Nacht sauber beginnt.

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

Was Sie zuerst abgeben

Manche Arbeit passt besser in die Nacht als andere. Fangen Sie mit dieser an und erweitern Sie, wenn das Vertrauen wächst.

• Fehlschlagende oder wackelige Tests mit klar erwartetem Verhalten.
• Upgrades von Abhängigkeiten, bei denen die Testsuite entscheidet.
• Mechanische Refactorings über viele Dateien.
• Fehlende Tests für Code, der schon funktioniert.
• Typfehler, Lint-Fehler und Deprecation-Warnungen.

Designentscheidungen, alles rund um Abrechnung oder Authentifizierung und alles, was die Tests nicht prüfen können, heben Sie für den Tag auf. Dann können Sie Fragen beantworten.

Die Maschine darunter

All das setzt eine Maschine voraus, die um 4 Uhr morgens noch läuft. Ein Laptop, der einschläft, ist der häufigste Grund, warum ein Lauf über Nacht nichts liefert. Die Anleitung zum Ruhezustand behebt das auf einem eigenen Mac. Bei einem gehosteten Agent-Mac ist es schon erledigt.