Acht Schritte statt Prompt: So arbeite ich mit Coding Agents

Wenn ich erzähle, dass ich den Großteil meines Codes mit Coding Agents schreibe, kommt fast immer dieselbe Rückfrage: Welchen Prompt nutzt du?

Die ehrliche Antwort ist unspektakulär. Der Prompt ist das Unwichtigste daran.

Zwischen einer Anforderung und einer Änderung, die in Produktion läuft, liegen bei mir acht Schritte. Der Agent, der den Code schreibt, arbeitet in genau einem davon. Die anderen sieben entscheiden, ob aus dem, was er schreibt, Software wird oder nur mehr Code. Agenten tauchen darin noch einmal auf, im Review, aber mit einem anderen Auftrag: Dort schreiben sie nicht, sie prüfen.

Dieser Artikel beschreibt den Ablauf so, wie ich ihn tatsächlich nutze: was jeder Schritt tut, was ohne ihn passiert und was davon beim Menschen bleibt. Am Ende steht, womit ich in einem Team anfangen würde, das gerade erst mit Agenten beginnt.

Wie die Spezifikationen selbst aufgebaut sind, mit Vorlagen für Feature, Bugfix und Wartung, steht in Agentic Coding mit Spec-Driven Development. Hier geht es um den ganzen Weg, nicht um eine Station.

Acht Schritte, und der Agent arbeitet in einem

1. Anforderung. Was gebaut werden soll, in der Sprache dessen, der es braucht. Ob und wann, entscheidet ein Mensch.
2. Spezifikation. Was fertig bedeutet, bevor eine Zeile Code existiert.
3. Architekturkontext. Dokumentierte Entscheidungen, die der Agent als verbindlich bekommt.
4. Abgegrenzte Aufgabe. Ein klarer Schnitt, eine eigene Arbeitsumgebung, ein eigener Klon des Repositorys.
5. Implementierung. Hier arbeitet der Agent: Analyse, Code, Tests, Refactoring, Dokumentation.
6. Automatische Prüfung. Tests und Linting in der CI. Rot geht zurück an den Agenten.
7. Review. Mehrstufig, gegen die Architekturregeln, ebenfalls durch Agenten, die hier aber nichts schreiben, sondern nur prüfen.
8. Integration. Über einen Pull Request, mit einer Staging-Umgebung vor der Produktion.

Auffällig ist, wie wenig davon neu ist. Spezifikation, Review, CI, Pull Requests: Das ist Software Engineering, wie gute Teams es seit Jahren betreiben. Wer das schon sauber macht, muss für Agenten weniger umbauen, als die Diskussion vermuten lässt.

Was sich verschoben hat

Neu ist das Verhältnis der Schritte zueinander.

Früher war Schritt 5 der teure. Eine Änderung zu schreiben kostete Tage, heute kostet sie einen Bruchteil davon. Alles andere im Ablauf war darauf ausgelegt, diese knappe Zeit gut zu nutzen: Man schrieb Anforderungen ungenau, weil der Entwickler beim Umsetzen nachfragen würde. Man reviewte ausführlich, weil jede Zeile von Hand entstanden war und jemand sie im Kopf hatte.

Heute ist Schritt 5 der billigste. Damit verschiebt sich, wo Fehler entstehen. Nicht mehr beim Schreiben, sondern davor und danach: in einer Anforderung, die zwei Lesarten zulässt, in einer Architekturregel, die nirgends steht, in einem Review, das nur noch prüft, ob etwas läuft.

Ein Agent fragt nicht nach, wenn etwas unklar ist. Er entscheidet. Und er entscheidet so überzeugend, dass es im Ergebnis nicht auffällt.

Wer nur Schritt 5 einführt, bekommt deshalb mehr Code. Nicht mehr Software. Das Tempo kommt vom Agenten. Die Qualität kommt aus den anderen sieben Schritten.

1. Anforderung: Priorisierung bleibt Produktarbeit

Am Anfang steht, was jemand erledigen will, in seinen Worten. Nicht „Endpoint für Filter bauen“, sondern „Ich finde meine offenen Vorgänge nicht“.

Ob das gebaut wird und wann, entscheidet bei mir kein Modell. Das klingt selbstverständlich, ist es aber nicht mehr, seit Agenten Tickets lesen, Vorschläge machen und die Umsetzung gleich mitliefern können. Wer die Reihenfolge der Arbeit an den Agenten abgibt, bekommt die Reihenfolge, die am leichtesten umzusetzen ist. Das ist selten die, die am meisten bringt.

Priorisierung ist Produktarbeit. Sie braucht Wissen über Nutzer, Umsatz und Risiko, das in keinem Repository steht.

2. Spezifikation: Was fehlt, erfindet der Agent

Bevor ein Agent eine Zeile schreibt, steht fest, was gebaut wird und woran man erkennt, dass es fertig ist. Das ist der Schritt, an dem sich bei mir am meisten verändert hat. Ich tippe weniger und lege mehr fest.

Bei einer Oberfläche heißt das: alle Zustände. Liste, leerer Zustand, Detail, Bearbeiten, Erfolg, Fehler. Das wirkt pedantisch, bis man sieht, was ohne passiert. Fehlt der leere Zustand, baut der Agent trotzdem einen. Er sieht plausibel aus und passt zu nichts anderem im System. Im Review fällt das nur auf, wenn jemand genau danach sucht.

Genauso wichtig ist der Abschnitt, den die meisten weglassen: Out of Scope. Ein Agent driftet gern in angrenzende Funktionalität. Aus einem Filter wird schnell noch eine Sortierung, ein Export und ein neues Feld in der Datenbank. Gut gemeint, nichts davon bestellt, alles muss jetzt mitgetestet und mitbetrieben werden.

Bei Fehlern verlange ich vor der Umsetzung eine Hypothese zur Ursache. Ein Agent ohne Hypothese ändert Code, bis das Symptom verschwindet. Das ist kein Debugging. Das ist Raten mit sehr hoher Geschwindigkeit, und es hinterlässt Änderungen, die niemand erklären kann.

Der Agent macht dabei nichts falsch. Er füllt Lücken, weil er Lücken füllen muss. Die einzige Frage ist, wer die Entscheidung trifft: ich in der Spezifikation oder er beim Implementieren. Was nicht spezifiziert ist, entscheidet der Agent. Und er fragt vorher nicht.

3. Architekturkontext: einmal entscheiden

Ein Agent ohne Architekturregeln trifft in jeder Aufgabe eigene Entscheidungen. Jede einzelne ist für sich vernünftig. Nach hundert Aufgaben hat das System hundert Architekturen.

Das ist kein Modellproblem. Ein Agent kennt die Entscheidungen vom letzten Quartal nicht. Er weiß nicht, dass Geldbeträge als ganze Cent gespeichert werden und nie als Gleitkommazahl. Oder dass Wiederholungsversuche gegen einen externen Anbieter in die Schicht gehören, die mit diesem Anbieter spricht, und nicht in die Anwendungslogik. Er optimiert für die Aufgabe vor ihm, nicht für das System in einem Jahr.

Die naheliegende Reaktion ist, solche Regeln in den Prompt zu schreiben. Das hält genau eine Session. In der nächsten fehlt die Hälfte, und welche Hälfte, hängt davon ab, wer den Prompt geschrieben hat.

Ich behandle Architekturentscheidungen deshalb wie Code. Sie sind dokumentiert, liegen im Repository und gehen bei jeder Aufgabe als verbindlicher Kontext an den Agenten. Was eine einzelne Aufgabe zusätzlich betrifft, steht in ihrer Spezifikation: welche Module sie berühren darf, welche Grenzen sie nicht überschreitet. Der Agent verhandelt diese Regeln nicht in jeder Aufgabe neu. Er setzt sie um.

Der Nebeneffekt ist fast wertvoller als der eigentliche Zweck. Um eine Regel für einen Agenten aufzuschreiben, muss man sie erst einmal klar formulieren können. In gewachsenen Systemen ist das oft das erste Mal, dass das überhaupt jemand tut.

Wie ich Wissen und Entscheidungen so ablege, dass Agenten zuverlässig damit arbeiten, steht in Ein Agent ist so gut wie sein Kontext.

4. Abgegrenzte Aufgabe: ein Schnitt, ein Klon

Eine Aufgabe, ein klarer Schnitt. Der Agent verändert den Teil des Systems, um den es geht, nicht das ganze. Je kleiner der Schnitt, desto besser lässt sich prüfen, was er getan hat, und desto billiger ist es, eine Aufgabe zu verwerfen und neu zu beginnen.

Mehrere Aufgaben laufen bei mir parallel, und jede bekommt eine eigene Arbeitsumgebung mit eigenem Klon oder eigenem Worktree des Repositorys. Das habe ich nicht aus Prinzip so eingerichtet, sondern nach einem Tag ohne. In meinem eigenen Wissens-Repository liefen zwei Sessions im selben Verzeichnis. Zweimal hat eine davon die vorbereiteten Änderungen der anderen mitgenommen und unter ihrer eigenen Commit-Nachricht abgelegt. Einmal wäre ein ganzer Abschnitt verloren gegangen, weil eine Session eine Datei zurückschrieb, die Sekunden vorher von der anderen erweitert worden war. Aufgefallen ist es nur, weil der Diff Dutzende Löschungen zeigte, wo nur etwas hinzukommen sollte.

Git warnt in so einem Fall nicht. Für menschliche Entwickler ist die Trennung seit Jahren selbstverständlich. Parallele Agenten sind parallele Entwickler und brauchen dieselbe Isolation.

5. Implementierung: der schnelle Teil

Hier arbeitet der Agent: Er liest den bestehenden Code, implementiert, schreibt Tests, refaktoriert und dokumentiert. Ich setze dafür mehr als einen Agenten ein, je nach Aufgabe, und wechsle das Werkzeug, wenn ein anderes für eine Art von Arbeit besser ist. Die Wahl ist austauschbar. Der Ablauf drumherum nicht.

Wichtig ist, was in diesem Schritt nicht passiert. Der Agent entscheidet nichts, was nicht in Schritt 2 und 3 schon entschieden wurde. Stößt er auf eine offene Frage, ist das ein Befund für die Spezifikation, keine Gelegenheit zur Kreativität.

Der Schritt ist schnell. Genau deshalb gehört er nicht in den Mittelpunkt. Wer ein Team mit Agenten ausstattet und hier aufhört, hat die Geschwindigkeit des Schreibens erhöht, ohne die Fähigkeit, das Geschriebene zu prüfen, mitzunehmen.

Was ein Agent in gewachsenem Code leisten kann und wo er scheitert, steht in Coding-Agenten im Altsystem.

6. Automatische Prüfung: Bedingung, keine Empfehlung

Tests und Linting laufen in der CI, bei mir auf eigenen Runnern. Das Ergebnis ist eine Bedingung für die Übernahme, keine Empfehlung. Scheitert eine Prüfung, geht die Aufgabe zurück an den Agenten. Ins Review kommt sie gar nicht erst.

Abgenommen wird über Exit-Codes, nicht darüber, ob ein Agent sich selbst für fertig hält. Ein Agent meldet zuverlässig Erfolg. Ob die Meldung stimmt, sagt ein Befehl, der mit einem Wert ungleich null endet, wenn etwas nicht stimmt.

Diese Prüfungen wachsen aus Vorfällen. In meinem Wissens-Repository stand eine Formatregel an vier Stellen, in allen Anweisungsdateien, die jeder Agent zu Beginn liest. Zwei Tage später enthielt eine einzige Aufräumrunde zwanzig Zeilen, die genau dagegen verstießen. Die Regel schärfer zu formulieren hätte nichts gebracht: Ein Agent, der eine Regel überliest, überliest auch die schärfere Fassung. Seitdem prüft ein Hook vor jedem Commit und sperrt ihn mit Begründung.

Daraus ist meine wichtigste Regel für diesen Schritt geworden: Was sich als Prüfung formulieren lässt, schreibe ich nicht als Anweisung auf. Ich baue die Prüfung.

Welche Prüfungen ein bestehendes System braucht, bevor Agenten darin sicher arbeiten, und warum alter Code dabei oft im Vorteil ist, steht in Ist Ihr Code zu alt für Coding-Agenten?.

7. Review: eine andere Frage als die CI

Nach den automatischen Prüfungen kommt das Review, mehrstufig und ebenfalls durch Agenten. Findet es etwas, geht die Aufgabe zurück an den Agenten, der sie umgesetzt hat, mit dem Befund als neuer Eingabe.

Die Trennung zwischen Schritt 6 und 7 ist der eigentliche Punkt. Früher war ein Review oft beides gleichzeitig: Fehlersuche und Architekturgespräch in einem Kommentarstrang. Meistens hat die Fehlersuche gewonnen, weil sie konkreter ist und schneller zu einem Ergebnis führt.

Mit Agenten wird das gefährlich. Es kommen deutlich mehr Änderungen an als früher, und jede einzelne sieht ordentlich aus. Wer im Review nur prüft, ob etwas funktioniert, winkt Architektur im Akkord durch.

Ob der Code läuft, haben die Prüfungen beantwortet. Das Review muss diese Frage nicht noch einmal stellen. Es stellt eine andere: Passt diese Änderung in das System, das es in einem Jahr noch geben soll? Geprüft wird gegen die Regeln aus Schritt 3, nicht gegen den Geschmack des Reviewers.

Kurz: Tests prüfen, ob es läuft. Reviews prüfen, ob es bleiben darf.

8. Integration: nachvollziehbar statt lokal grün

Übernommen wird über Pull Requests. Damit ist jede Änderung nachvollziehbar: Anlass, Spezifikation, Prüfungen, Review. Wenn in drei Monaten jemand fragt, warum eine Stelle so aussieht, steht die Antwort an einem Ort und nicht in einer Chat-Session, die niemand mehr findet.

Ausgeliefert wird über eine Pipeline, mit einer eigenen Staging-Umgebung vor der Produktion. Dass etwas auf einem Rechner funktioniert, ist kein Kriterium. Das gilt für Menschen schon immer. Für Agenten gilt es doppelt, weil ein Agent seine lokale Umgebung so lange anpasst, bis sie grün ist.

Was beim Menschen bleibt

Die Aufteilung ist bei mir eindeutig.

Beim Menschen bleiben: was gebaut wird, in welcher Reihenfolge, welche Architektur gilt und gegen welche Regeln geprüft wird. Also die Produktentscheidungen, die Architektur, die Priorisierung und die Maßstäbe.

Die Agenten beschleunigen Analyse, Implementierung, Tests, Refactoring und Dokumentation. Sie prüfen sich gegenseitig. Aber sie setzen sich die Maßstäbe nicht selbst.

Das ist auch der Unterschied zu dem, was gerade als Vibe Coding verkauft wird. Dort bekommt der Agent einen Wunsch in einem Satz und entscheidet den Rest. Bei mir bekommt er eine Spezifikation und einen Architekturkontext, und was er liefert, wird übernommen, wenn es Prüfung und Review besteht, nicht weil es lokal läuft. Das Tempo kommt vom Agenten. Die Disziplin kommt vom Prozess, und sie wird nicht verhandelt, wenn es eilt.

Womit ich in einem Team anfangen würde

Nicht mit dem Agenten. Die Reihenfolge, die ich empfehlen würde:

1. Schritt 6 zuerst. Ein Befehl, der Tests, statische Analyse und Linter ausführt und in der CI rot wird. Ohne ihn ist jeder weitere Schritt Vertrauenssache.
2. Dann Schritt 3. Die fünf Architekturentscheidungen aufschreiben, die am häufigsten verletzt werden. Nicht alle, nur die, die wehtun.
3. Dann Schritt 2. Eine Vorlage für Spezifikationen mit einem Pflichtfeld „Out of Scope“ und, bei Fehlern, einem Pflichtfeld für die vermutete Ursache.
4. Dann Schritt 7. Ein Review, das ausdrücklich gegen die Regeln aus Schritt 3 prüft, nicht gegen Geschmack.
5. Erst dann mehr Agenten. Parallelität lohnt sich, sobald jede Aufgabe ihre eigene Umgebung hat.

Das klingt nach viel Vorarbeit. In der Praxis sind es wenige Tage, und sie zahlen sich bei der ersten Woche mit Agenten aus, in der man nicht jeden Pull Request selbst lesen muss, um ihm zu trauen.

Häufige Fragen

Ist der Ablauf für kleine Änderungen nicht zu schwer? Die Schritte bleiben, ihr Umfang schrumpft. Eine Spezifikation für einen Tippfehler ist ein Satz. Wegfallen dürfen Schritt 6 und 7 trotzdem nie, denn gerade kleine Änderungen werden am seltensten angesehen.

Lohnt sich ein Agenten-Review, wenn ohnehin ein Mensch draufschaut? Ja, weil es eine andere Arbeit macht. Das Agenten-Review prüft jede Änderung gegen jede Regel, auch die fünfzigste am Tag. Der Mensch prüft, ob die Regeln noch die richtigen sind.

Welches Modell ist das beste für die Implementierung? Das ändert sich alle paar Monate, und genau deshalb ist es die unwichtigste Entscheidung im Ablauf. Wer seine Qualität an ein bestimmtes Modell bindet, baut sie bei jedem Wechsel neu.

Funktioniert das auch in einem gewachsenen System? Ja, oft sogar besser als in einem neuen, weil die Grenzfälle dort schon bekannt sind. Der Aufwand liegt in Schritt 3 und 6: Regeln aufschreiben, die bisher nur in Köpfen standen, und Prüfungen wieder zum Laufen bringen, die irgendwann stillgelegt wurden.

Der Agent ist einer von acht Schritten. Wer die anderen sieben weglässt, bekommt mehr Code. Wer sie ernst nimmt, bekommt Software, und zwar schneller als je zuvor.

Wie so ein Ablauf in einem bestehenden Team eingeführt wird, steht unter Claude Code einführen.