Warum sollte ein Coding-Agent nicht direkt mit dem Programmieren anfangen?

Wer den Agenten sofort coden lässt, bekommt laut Claude-Code-Dokumentation leicht Code, der das falsche Problem löst. Der Plan Mode trennt deshalb Erkunden und Umsetzen: Der Agent liest Dateien und schlägt einen Plan vor, ändert aber nichts ohne Zustimmung.

Was zählt als Check, den ein Agent selbst ausführen kann?

Alles, was ein lesbares Signal zurückgibt: eine Testsuite, der Exit-Code eines Builds, ein Linter, ein Skript, das Ausgaben mit einer Fixture vergleicht, oder ein Screenshot im Vergleich zum Design.

Muss jedes Ticket durch die Planungsphase?

Nein. Bei explorativen Aufgaben kann es sinnvoll sein, die Planung zu überspringen und den Agenten erst einmal machen zu lassen. Wichtig ist, dass das Team gemeinsam festlegt, für welche Aufgaben das gilt.

Was tun, wenn der Agent nach mehreren Korrekturen immer noch falsch liegt?

Die Dokumentation empfiehlt, nach zwei erfolglosen Korrekturen den Kontext mit /clear zu leeren und mit einem besseren, präziseren Prompt neu zu starten, der das Gelernte enthält.

Plan, Umsetzung, Test: ein Agenten-Workflow fürs Team

Wenn fünf Entwickler mit demselben Agenten arbeiten, entstehen oft fünf Arbeitsweisen. Die eine lässt Claude Code sofort losschreiben, der andere plant jedes Detail, die dritte prüft erst im Review, ob überhaupt etwas funktioniert. Die Ergebnisse schwanken, und niemand kann sagen, warum. Ein gemeinsamer Ablauf für Agenten-Tickets macht diese Unterschiede sichtbar und verhandelbar.

Die Bausteine dafür liefert die offizielle Claude-Code-Dokumentation. Sie beschreibt Muster, die sich bei Anthropics internen Teams bewährt haben. Die Teamfrage ist, welche davon für alle gelten.

Warum der Ablauf überhaupt eine Teamfrage ist

Fast alle Empfehlungen gehen auf eine Einschränkung zurück: Das Kontextfenster füllt sich schnell, und die Qualität sinkt, je voller es wird. Jede gelesene Datei und jede Befehlsausgabe kostet Platz. Wer erkundet, plant und umsetzt in einer einzigen langen Session, arbeitet am Ende mit einem Agenten, der frühere Anweisungen vergisst.

Gleichzeitig zeigt eine Diskussion auf Reddit, warum Einzelne die Empfehlungen oft nicht umsetzen. Mehrere Entwickler beschreiben, dass sich die Dokumentation laufend ändert und sie mit dem Nachlesen nicht hinterherkommen. Andere klagen, dass die Pflege des eigenen Setups so viel Zeit frisst wie die eigentliche Aufgabe. Einige lassen sich deshalb per Skill zusammenfassen, was sich seit dem letzten Lesen geändert hat. Genau hier liegt der Vorteil eines Teams: Eine Person verfolgt die Änderungen, alle anderen arbeiten mit einem abgestimmten Ablauf.

Phase 1: Erst erkunden und planen

Wer den Agenten direkt coden lässt, bekommt leicht Code, der das falsche Problem löst. Der Plan Mode trennt Erkunden und Umsetzen. Claude liest Dateien und schlägt einen Plan vor, nimmt aber keine Änderungen vor, bis jemand zustimmt. Im Terminal wechseln Sie mit Shift+Tab, bis die Statuszeile ⏸ plan mode on zeigt.

Für größere Features geht die Dokumentation einen Schritt weiter: Claude interviewt Sie zu Implementierung, Randfällen und Abwägungen und schreibt daraus eine Spec. Eine gute Spec steht für sich, nennt die betroffenen Dateien und Schnittstellen, sagt, was ausdrücklich nicht dazugehört, und endet mit einer End-to-End-Prüfung. Danach startet eine frische Session mit sauberem Kontext die Umsetzung.

Für das Team heißt das: Die Spec ist ein Artefakt, das im Ticket oder im Pull Request landet. Reviewer sehen, was geplant war, nicht nur, was am Ende herauskam.

Phase 2: Umsetzen mit präzisem Kontext

In der Umsetzung entscheidet der Prompt. Statt „fix the login bug“ empfiehlt die Dokumentation, das Symptom, den wahrscheinlichen Ort und das gewünschte Ergebnis zu nennen, etwa mit dem Auftrag, zuerst einen fehlschlagenden Test zu schreiben, der das Problem reproduziert, und es dann zu beheben. Hilfreich ist auch der Verweis auf bestehende Muster im Code, an denen sich der Agent orientieren soll.

Testbefehle und bevorzugte Test-Runner gehören in die eingecheckte CLAUDE.md, damit nicht jede Person sie neu eintippt. Wie Sie diese Datei im Team pflegen, beschreibt unser Beitrag Claude Code im Team.

Eine Regel lohnt sich als Teamstandard: Wenn der Agent nach zwei Korrekturen immer noch falsch liegt, ist der Kontext mit gescheiterten Ansätzen verstopft. Dann /clear und ein neuer, präziserer Prompt, der das Gelernte aufnimmt.

Phase 3: Testen, bis der Check grün ist

Ohne Prüfung hört der Agent auf, wenn die Arbeit fertig aussieht. Dann sind Sie selbst die Verifikationsschleife, und jeder Fehler wartet darauf, dass ihn jemand bemerkt. Geben Sie dem Agenten deshalb etwas, das Bestanden oder Nicht bestanden meldet: eine Testsuite, den Exit-Code des Builds, einen Linter, ein Skript, das Ausgaben mit einer Fixture vergleicht.

Ebenso wichtig: Der Agent soll Belege zeigen statt Erfolg zu behaupten, also Testausgabe, ausgeführten Befehl und Ergebnis. Belege zu prüfen geht schneller, als die Prüfung selbst zu wiederholen, und funktioniert auch für Sessions, die niemand beobachtet hat.

Als letzter Schritt hilft ein zweiter Blick mit frischem Kontext. Ein Reviewer in einer neuen Session ist nicht auf den Code voreingenommen, den er gerade selbst geschrieben hat. Claude Code bringt dafür den Skill /code-review mit, der den aktuellen Diff in einem eigenen Subagenten auf Bugs prüft. Das ersetzt kein menschliches Review, wie es unsere Review-Checkliste für KI-Pull-Requests beschreibt, filtert aber vor.

Was das für Ihr Entwicklerteam bedeutet

Der Ablauf ist kein Dogma. Die Dokumentation sagt selbst, dass Planung bei explorativen Aufgaben übersprungen werden kann, und in der Reddit-Diskussion halten einige das Einfügen von Fehlermeldungen für überflüssig, weil der Agent den Check ohnehin selbst ausführt. Entscheidend ist, dass Ihr Team solche Ausnahmen bewusst festlegt:

Ab welcher Größe braucht ein Ticket eine Spec?
Welche Checks muss jede Agenten-Änderung bestehen, bevor ein Pull Request entsteht?
Welche Belege gehören in die PR-Beschreibung?
Wer verfolgt Änderungen an der Dokumentation und schlägt Anpassungen am Ablauf vor?

Diese Antworten gehören schriftlich ins Repository, damit neue Kollegen denselben Ablauf vorfinden. Welche Themen wir dafür im Training durchgehen, sehen Sie unter Module.

Den gemeinsamen Ablauf üben Teams am besten an einem eigenen Ticket statt an einem Demo-Projekt. Wenn Sie Plan, Umsetzung und Test für Ihren Stack verbindlich machen wollen, fragen Sie ein Inhouse-Training an.