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.

Autopilot versetzt den Agenten in einen Modus, in dem er ohne Anweisung arbeitet. Jede Iteration läuft dieselben sieben Schritte:

1. 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.
2. Wählen. Eine Verbesserung. Erst Kandidaten generieren, dann ranken. Ein Anliegen pro Iteration.
3. 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.
4. Tun, im Idiom des umgebenden Codes, angepasst an die Konventionen des Projekts statt an deine eigenen Vorlieben.
5. 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.
6. Committen, für sich allein, mit einer Nachricht, die sagt, was sich geändert hat und warum. Eine Iteration, ein reviewbarer Commit.
7. 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.

Zwei Regeln machen unbeaufsichtigtes Schleifen vernünftig:

1. 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.
2. 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.

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.

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.

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.

Autopilot installiert sich in jeden Agenten, der das skills.sh-Format spricht (Claude Code, Cursor, Codex, Cline, Windsurf, OpenCode):

bash
npx skills@latest add saschb2b/skills --skill autopilot

Übergib dann ein Projekt offen und lass es schleifen.

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.

• saschb2b/skills

  Das offene Skills-Repo. Autopilot liegt unter productivity, einzeln oder mit dem ganzen Set installierbar.

• skills.sh

  Der Installer und das Registry, das einen Skill-Ordner über Claude Code, Cursor, Codex, Cline, Windsurf und OpenCode hinweg funktionieren lässt.