Autopilot: Claude als selbstgesteuerter Praktikant
Die meiste Zeit, die du mit einem KI-Coding-Agenten verbringst, bist du der Flaschenhals: Er macht eine Sache und bleibt dann stehen und wartet auf dich. Autopilot ist ein Skill, der dich aus diesem Sitz holt. Der Agent sucht die Arbeit aus, macht sie, verifiziert sie, committet sie und nimmt die nächste Sache, während du den Strom von Commits nach deinem eigenen Zeitplan reviewst. Hier ist, wie es funktioniert, warum man es laufen lassen kann und warum es dich nicht unter Beschäftigungstherapie begräbt.
Autopilot: Claude als selbstgesteuerter Praktikant
Die meiste Zeit, die du mit einem KI-Coding-Agenten verbringst, bist du der Flaschenhals. Du gibst ihm eine Aufgabe, er erledigt sie, dann bleibt er stehen und wartet. Was als Nächstes? Du antwortest. Er macht die nächste Sache und bleibt wieder stehen. Der Agent ist schnell. Die Schleife um ihn herum ist langsam, weil du am Anfang jeder Runde sitzt.
Autopilot ist ein Skill, der dich aus diesem Sitz holt. Du übergibst das Projekt statt der Aufgabe, und der Agent läuft seine eigene Schleife: such die Arbeit aus, mach sie, beweise, dass sie funktioniert, committe sie, nimm die nächste Sache. Du reviewst den Strom von Commits, wann es dir passt, statt jeden Schritt freizugeben.
Dieser Satz aus dem Skill ist das ganze Designproblem in einem Satz. Ein Agent, der nie aufhört, ist einfach. Ein Agent, der nie aufhört und den man trotzdem allein lassen kann, ist der schwere Teil, und alles weiter unten ist, wie er dorthin gelangt.
Die Schleife
Autopilot versetzt den Agenten in einen Modus, in dem er ohne Anweisung arbeitet. Jede Iteration läuft dieselben sieben Schritte:
Sichten. Lies das README, die Projektanweisungen, die jüngsten Commits, die Tests, die offenen TODO- und FIXME-Marker. Lass Build und Tests laufen, um die Baseline zu lernen. Gibt es ein UI, starte es und schau dir die echten Screens an. Man kann nicht verbessern, was man nicht gesehen hat.
Wählen. Eine Verbesserung. Erst Kandidaten generieren, dann ranken. Ein Anliegen pro Iteration.
Zuschneiden, klein genug, um es in einer Sitzung fertigzustellen und zu reviewen. Geht das nicht, nimm die kleinste wertvolle Scheibe und lass den Rest als Notiz zurück.
Tun, im Idiom des umgebenden Codes, angepasst an die Konventionen des Projekts statt an deine eigenen Vorlieben.
Verifizieren. Lass Tests, Build und Linter laufen. Bei allem, was den Nutzer betrifft, starte die App und schau dir das gerenderte Ergebnis an, inklusive Lade-, Leer- und Fehlerzuständen. Ein grüner Build sagt dir nie, dass ein Screen richtig aussieht.
Committen, für sich allein, mit einer Nachricht, die sagt, was sich geändert hat und warum. Eine Iteration, ein reviewbarer Commit.
Schleifen. Nimm die nächste Sache. Frag nicht um Erlaubnis zum Weitermachen.
Der siebte Schritt ist der, auf den es ankommt, und der, gegen den sich ein Modell am stärksten sträubt. Stehenzubleiben und zu fragen fühlt sich sicher und höflich an. Es ist auch genau das Verhalten, das Autonomie wertlos macht. Das meiste, was der Skill tut, ist, den Agenten durch Schritt sieben in Bewegung zu halten, ohne ihn über eine Klippe laufen zu lassen.
Warum man es laufen lassen kann
Zwei Regeln machen unbeaufsichtigtes Schleifen vernünftig:
Jede Iteration hinterlässt das Projekt besser, als sie es vorgefunden hat, und ist eigenständig reviewbar. Klein, fokussiert, für sich allein committet. Du bekommst nie einen einzigen riesigen Diff zum Entwirren.
Der Agent überschreitet nie stillschweigend eine gefährliche Linie. Stößt er auf eine, schreibt er die Entscheidung auf und geht zur nächsten sicheren Sache über. Ein blockierter Weg stoppt nie die Schleife.
Die zweite Regel beruht auf einer harten Grenze zwischen Arbeit, die der Agent frei erledigt, und Arbeit, die er vorher melden muss.
Frei erledigen (additiv, umkehrbar, lokal)
Erst melden, dann weiter (nie stillschweigend tun)
Bugs fixen, mit einem Test, der den Fix beweist
Alles Destruktive: Löschen, Migrationen, History-Rewrites
Tests ergänzen, Fehlerbehandlung und Validierung schärfen
Alles nach außen Gerichtete: Publishen, Deployen, geteilte Branches pushen
Docs, Kommentare, Dev-Tooling verbessern
Public-API- oder Vertragsänderungen, große Dependency-Bumps
Refactoren unter Erhalt des Verhaltens
Nutzergerichtete Redesigns, die auf einer Ermessensfrage beruhen
Alles rund um Secrets, Auth, Zahlungen, Produktivdaten
Stößt der Agent auf eine zu meldende Sache, hält er sie als kurzen Vorschlag fest (was sie ist, warum, und das Risiko) und macht mit sicherer Arbeit weiter. Du kommst zu einer Liste von Entscheidungen zurück, die auf dich warten, nie zu einer Überraschung.
Warum es keine Beschäftigungstherapie ist
Das eigentliche Risiko bei einem eifrigen Agenten ist nicht Gefahr. Es ist Lärm: hundert Commits, die technisch etwas ändern und nichts verbessern. Die meisten Regeln von Autopilot existieren, um das zu bekämpfen.
Erst stabilisieren, dann bauen. Ein kaputter Build, ein fehlschlagender oder flakiger Test oder ein aktiver Bug hat Vorrang vor allem anderen. Der Agent darf keine Features auf ein Fundament stapeln, das brennt. Erst grün, dann ist das Feld offen.
Generieren, dann ranken. Statt einer Checkliste generiert der Agent Kandidaten aus den Blickwinkeln aller, die vom Projekt abhängen, und rankt sie dann auf vier Achsen: Hebel (Wirkung pro Aufwand), Ausrichtung (die erkennbare Richtung des Projekts, nicht der Geschmack des Agenten), Vertrauen (er kennt den Bereich gut genug, um recht zu haben) und Umkehrbarkeit (leicht rückgängig zu machen, falls falsch). Alles, was bei zweien der letzten drei schwach ist, wird verworfen, so verlockend es auch sein mag. Diese Kombination ist genau dort, wo autonome Arbeit Schaden anrichtet.
Selbstprüfung vor dem Commit. Vor jedem Commit prüft sich der Agent gegen den Praktikanten, der er werden könnte. Schreibt er funktionierenden Code aus Geschmacksgründen um? Erfindet er eine Abstraktion für einen einzigen Aufrufer? Polstert er die Coverage mit Tests für triviale Getter auf, während ein echter Pfad nackt bleibt? Generiert er Docs, nach denen niemand gefragt hat, während der tatsächliche Bug daneben liegt? Würde ein Senior-Reviewer seufzen statt nicken, wird die Arbeit verworfen, und er wählt neu.
Die eine Gewohnheit, die es leise tötet
Das Menü. Der Agent bleibt stehen, listet fünf Optionen auf und fragt, welche
er verfolgen soll. In dem Moment, in dem er "sag mir, welche davon ich tun
soll" schreibt, ist die Autonomie vorbei. So eine Liste enthält fast immer
schon eine sichere, wertvolle Option: einen Accessibility-Fix, einen Test, ein
Doc, ein sauberes Refactoring. Die Regel von Autopilot lautet, die beste jetzt
zu nehmen, den Rest zu notieren und weiterzumachen. Es hört erst wirklich auf,
wenn eine frische Sichtung zeigt, dass jede verbleibende Option eine echte
Ermessensfrage ist. Das ist selten.
Was du zurückbekommst
In der Praxis ändert es die Form einer Session. Du übergibst ein Repo vor einem Meeting oder über Nacht, mit etwas so Lockerem wie "arbeite eine Weile auf eigene Faust", oder du rufst /autopilot auf. Du kommst zurück zu einer Reihe kleiner Commits, jeder eine fertige, verifizierte Änderung mit einer Nachricht, die sagt, was und warum. Du liest sie in deinem Tempo. Die guten behältst du. Den seltenen falschen machst du isoliert rückgängig, gerade weil er für sich allein committet wurde. Zeit, die früher totes Warten war, wird zu einer Warteschlange von Arbeit zum Reviewen.
Was es nicht tut, ist deine Architektur entwerfen oder die Produktentscheidungen treffen. Das sind die Ermessensfragen, die es zu melden und dir zu überlassen gebaut ist. Was es entfernt, ist der lange Schwanz an offensichtlicher, risikoarmer, wertvoller Arbeit, die nie erledigt wird, weil sie nie eine eigene Sitzung wert war: der fehlende Test, der kaputte Leerzustand, das veraltete Doc, der nicht behandelte Fehler, die Accessibility-Lücke. Ein Praktikant, der diesen Rückstau von allein abarbeitet und genau weiß, wann er anhalten und fragen muss, ist viel wert.
Probier es aus
Autopilot installiert sich in jeden Agenten, der das skills.sh-Format spricht (Claude Code, Cursor, Codex, Cline, Windsurf, OpenCode):
Übergib dann ein Projekt offen und lass es schleifen.
Dafür gibt es einen Skill
Die vollständige Schleife, die Grenze des Erlaubten und das Rubric zum Ranken
der Kandidaten leben als Agent-Skill. Installiere ihn mit npx skills@latest add saschb2b/skills --skill autopilot oder lies den vollständigen
autopilot-Skill.
Eine Randnotiz, weil es für mich ungewöhnlich ist. Normalerweise schreibe ich zuerst den Post und destilliere danach einen Skill daraus. Autopilot lief andersherum: Ich habe den Skill gebaut, ihn wochenlang laufen lassen und das hier danach geschrieben. Eine Schleife ist etwas, das man laufen lassen muss, bevor man sie beschreiben kann, also kam ausnahmsweise der Skill zuerst und der Post ist der Feldbericht.
