Kostenloser Leitfaden

Agenten arbeiten lassen, während Sie schlafen: Goals, Loops und Routines

Wie ich Teams vom Prompt-Ping-Pong zu Agenten bringe, die selbstständig laufen, mit klarer Ziellinie, Zeitplan und menschlichem Review. Funktioniert mit Claude Code und Codex.

Was drin steht

1. 1. Vorher definieren, was fertig heisst

   • Die Ziellinie so formulieren, dass der Agent sie belegen kann: „npm test endet mit 0“, nicht „mach es besser“.
   • Den Rahmen nennen: welche Ordner, welche Tickets, was tabu ist.
   • Eine Grenze ins Ziel schreiben, etwa „oder nach 20 Runden stoppen und berichten, was offen ist“.

2. 2. Leitplanken setzen

   • Eine Anweisungsdatei pro Repository mit den Regeln, die der Agent einhalten muss.
   • Nur Branches: Der Agent öffnet Pull Requests, er merged nie und deployt nie in die Produktion.
   • Keine Produktions-Zugangsdaten, nur Testkonten, und ein Token-Budget pro Lauf.

3. 3. Den passenden Modus wählen

   • Klare Ziellinie: ein Goal (/goal in Claude Code, Goal Mode in Codex).
   • Wiederkehrende Prüfung, während Sie arbeiten: ein Loop im Intervall, etwa /loop 15m.
   • Muss bei zugeklapptem Laptop laufen: eine Routine in der Cloud, gestartet per Zeitplan, API-Aufruf oder GitHub-Ereignis.

4. 4. Probelauf unter Aufsicht

   • Einmal interaktiv laufen lassen und jeden Schritt lesen.
   • Die Anweisungen korrigieren, wo der Agent danebenlag, nicht nur das Ergebnis.
   • Unbeaufsichtigt läuft es erst, wenn ein Probelauf sauber durchgeht.

5. 5. Unbeaufsichtigt laufen lassen

   • Klein anfangen: ein Repository, eine Aufgabenart, etwa Dependency-Updates, fehlschlagende Tests oder ein nächtlicher Bericht.
   • Jeder Lauf schreibt eine kurze Zusammenfassung: was er getan, was er ausgelassen hat, was einen Menschen braucht.
   • Ein Alert geht in den Team-Chat, wenn ein Lauf fehlschlägt oder deutlich länger dauert als sonst.

6. 6. Review, bevor etwas live geht

   • Ein Mensch prüft und merged, genau wie bei Pull Requests von Menschen.
   • Feste Regeln: Login, Zahlungen, Datenlöschung und Berechtigungen brauchen immer einen Menschen.
   • Erst Staging, dann Produktion, mit Smoke-Tests nach jedem Deployment.

7. 7. Lernen und ausweiten

   • Jeder Fehler wird zur Regel in der Anweisungsdatei, damit der nächste Lauf ihn vermeidet.
   • Gesparte Stunden, Kosten pro Lauf und den Anteil der Läufe messen, die Hilfe brauchten.
   • Die nächste Aufgabenart erst dazunehmen, wenn die aktuelle zwei Wochen ruhig gelaufen ist.

8. Einführung nach Unternehmensgrösse

   • Startup: eine Routine für die lästige Arbeit, etwa Dependency-Updates, fehlschlagende Tests und den Wochenbericht. Meist innerhalb einer Woche live.
   • Mittelstand: ein Pilotteam mit gemeinsamen Anweisungsdateien und Token-Budget, danach die anderen Teams.
   • Konzern: Managed Settings, die Nutzer nicht überschreiben können, eine freigegebene Liste von Modellen und Tools, Audit-Logs und lokale Modelle für sensiblen Code.