Software mit KI-Agenten bauen: Ein Workflow

„Bau mir eine API für einen Warenkorb.” Ein Satz, und der Agent legt los: Modelle, Controller, Services, Persistenz, vielleicht gleich noch Checkout und Rabattlogik. Nach zehn Minuten steht viel Code da — mit Annahmen, die niemand getroffen hat, in einem Umfang, den niemand reviewen kann.

Coding-Agenten sind schnell. Genau das ist das Problem. Wer sie wie eine Wunschmaschine bedient, bekommt viel Output und wenig Kontrolle. Wer sie wie einen Entwickler im Team führt — mit klarem Briefing, kleinem Auftrag und Abnahme — bekommt Code, den man verantworten kann.

Dieser Artikel beschreibt einen solchen Workflow Schritt für Schritt, mit einem durchgehenden Beispiel: einer API zum Erfassen eines Warenkorbs. Er ist bewusst werkzeugunabhängig — ob Claude Code, Codex, Cursor, Aider oder eine andere Agent-CLI, die Disziplin bleibt dieselbe.

Die Prinzipien dahinter sind nicht neu: Struktur, Validierungs-Gates und klare Rollenteilung waren schon früher das Ziel. Was fehlte, war ein konkreter, wiederholbarer Loop — mit festem Ablauf und einem durchgehenden Beispiel.

Der Loop im Überblick

Der Workflow ist eine Schleife: ein kleiner, in sich abgeschlossener Funktionsausschnitt von der Idee bis zum Commit — danach beginnt der nächste. Kein Schritt wird übersprungen, auch nicht der „langweilige” am Anfang.

Innerhalb dieser vier Phasen verteilen sich zehn Schritte. Die Reihenfolge ist bewusst: Jeder Schritt schafft die Voraussetzung für den nächsten — übersprungene Schritte erzeugen später Mehraufwand, keinen Zeitgewinn.

Phase 1 — Erst verstehen, dann bauen

Die ersten beiden Schritte produzieren keinen Code. Sie verhindern, dass der Agent rät — und das spart später mehr Zeit, als sie kosten.

Brainstorming: was soll entstehen?

Nicht mit „Bau mir eine API” starten, sondern erst grob klären, was sie können soll. Der Agent ist hier Sparringspartner, nicht Umsetzer.

Lass uns eine API zum Erfassen eines Warenkorbs planen.

Ziel: Ein externer Client soll einen Warenkorb mit mehreren
Positionen anlegen können.

Brainstorme mit mir:
- Welche Daten braucht ein Warenkorb?
- Welche Endpunkte sind sinnvoll?
- Welche Sonderfälle müssen wir beachten?
- Was sollten wir bewusst noch nicht bauen?

Das Ergebnis ist eine grobe Landkarte — inklusive einer expliziten Liste dessen, was nicht zum Umfang gehört. Diese Negativliste ist wertvoller als sie aussieht: Sie hält Zahlung, Versandkosten, Rabatte und Benutzerkonten aus dem ersten Schnitt heraus.

Alignment: den Agenten Fragen stellen lassen

Jetzt wird das Verständnis geschärft. Der Agent soll kritische Rückfragen stellen — und noch nicht implementieren.

Stell mir kritische Rückfragen zur Warenkorb-API.
Beginne noch nicht mit der Umsetzung.

Klären wollen wir: Datenmodell, API-Verhalten, Fehlerfälle,
Validierung, technische Grenzen.

Typische Fragen: Funktioniert der Warenkorb anonym oder gehört er einem Nutzer? Darf ein Produkt mehrfach vorkommen? Kommt der Preis aus dem Request oder serverseitig? Aus den Antworten werden Entscheidungen, die du festhältst:

Entscheidungen:
- Warenkorb kann anonym erstellt werden, erhält eine cartId.
- Produkte dürfen nicht doppelt vorkommen — erneutes Hinzufügen
  erhöht die Menge.
- Preise kommen im Request, werden später serverseitig validiert.
- Status: draft, submitted. In diesem Slice nur draft.

Phase 2 — Scope eng halten

Hier entscheidet sich, ob der Workflow funktioniert. Die ganze Warenkorb-Welt auf einmal zu bauen, führt zu genau dem unkontrollierbaren Diff, den man vermeiden will.

Vertical Slice statt Architektur-Schichten

Der falsche Weg ist horizontal: erst alle Modelle, dann alle Controller, dann alle Services. Das ergibt lange nichts Lauffähiges und lässt sich nicht prüfen.

Der richtige Weg ist ein Vertical Slice — ein dünner, vollständiger Schnitt durch alle Schichten, der eine einzige Sache von Anfang bis Ende kann:

Vertical Slice 1: Warenkorb anlegen

Endpoint: POST /api/carts
Input:  currency, items[] (productId, name, quantity, unitPrice)
Output: cartId, status, totalAmount, items, createdAt

Nicht enthalten: PUT, DELETE, Checkout, User-Login, Produktdatenbank

Ein lauffähiger Schnitt ist mehr wert als drei halbfertige Schichten — er lässt sich testen, reviewen und committen.

Plan: in kleine Tasks zerlegen

Der Agent erstellt einen Umsetzungsplan für genau diesen Slice — und programmiert noch immer nicht.

Erstelle einen Implementierungsplan für Vertical Slice 1.
Wichtig: kleine Schritte, testbare Zwischenergebnisse,
keine Features außerhalb des Scopes. Erst planen, nicht bauen.

Ein brauchbarer Plan trennt Request/Response-Modelle, Validierung (currency erforderlich, items nicht leer, quantity > 0, unitPrice >= 0), Businesslogik (cartId erzeugen, totalAmount berechnen, Status draft setzen), den Endpoint und die Tests in einzelne Schritte. Jeder Schritt ist für sich überprüfbar.

Definition of Done: wann ist Schluss?

Ohne Akzeptanzkriterien weiß der Agent nicht, wann er fertig ist — und neigt dazu, „hilfreich” weiterzubauen. Die Definition of Done setzt die Grenze:

Definition of Done — Slice 1 ist fertig, wenn:
- POST /api/carts funktioniert
- ein gültiger Request eine cartId zurückgibt
- totalAmount korrekt berechnet wird
- ungültige Requests mit HTTP 400 abgelehnt werden
- mindestens vier Tests existieren
- keine Checkout- oder Payment-Logik eingebaut wurde

Die letzte Zeile ist Absicht: Eine Definition of Done definiert nicht nur, was da sein muss, sondern auch, was nicht da sein darf.

Phase 3 — Bauen und prüfen

Erst jetzt — nach Brainstorming, Alignment, Slice, Plan und Definition of Done — wird Code geschrieben.

Nur diesen Slice implementieren

Setze jetzt nur Vertical Slice 1 um.
Halte dich strikt an Implementierungsplan und Definition of Done,
keinen zusätzlichen Scope.

Danach: geänderte Dateien auflisten, Architektur kurz erklären,
nennen wie ich die Tests ausführe.

Testen heißt Verhalten prüfen

„Läuft” ist kein Testergebnis. Geprüft wird konkretes Verhalten — vor allem die Fehlerfälle, die ein Agent gern optimistisch übergeht.

Teste den Warenkorb-Slice. Prüfe insbesondere:
gültiger Warenkorb, leerer Warenkorb, Menge 0, negativer Preis,
fehlende productId.

Fehlt ein Test, ergänze ihn. Schlägt einer fehl, analysiere
zuerst die Ursache — ändere nicht blind den Code.

Ein gültiger Request mit zwei Positionen (Mengen 2 und 1, Preise 10 und 25) muss Status draft, totalAmount 45 und eine cartId liefern. Ein leeres items-Array muss mit HTTP 400 abgewiesen werden. Der Zusatz „ändere nicht blind den Code” ist wichtig: Sonst passt der Agent im Zweifel den Test an die Implementierung an, statt den Fehler zu finden.

Phase 4 — Verstehen, aufräumen, abschließen

Der Code läuft — aber damit ist der Slice nicht fertig. Drei Schritte sichern, dass er auch wartbar bleibt.

Recap: was wurde gebaut?

Du musst verstehen, was der Agent produziert hat — sonst wächst mit jedem Slice eine Codebasis, die dir fremd ist.

Erkläre mir den aktuellen Warenkorb-Slice:
Request-Ablauf, beteiligte Klassen/Funktionen, Validierung,
Berechnung von totalAmount, bekannte Grenzen.

Ein gutes Recap benennt auch klar die Lücken — keine Persistenz, kein Checkout, keine Produktvalidierung, keine Benutzerzuordnung. Diese Grenzen sind der Startpunkt für die Planung des nächsten Slice. Dass ein Prompt so zu einer überprüfbaren Funktion mit Eingaben, Ausgaben und Fehlerfällen wird, ist derselbe Denkschritt wie beim Übergang vom Playground zur API.

Refactoring: weglassen statt erweitern

Agenten bauen tendenziell zu viel — zusätzliche Abstraktionen, vorsorgliche Optionen, Code für Fälle, die es nicht gibt. Vor dem nächsten Slice wird vereinfacht, nicht erweitert.

Prüfe den Code auf unnötige Komplexität:
Was kann entfernt werden? Welche Funktion ist zu groß?
Gibt es doppelte Logik? Versteht ein neuer Entwickler den Ablauf?

Verhalten darf sich nicht ändern. Erst Vorschlag, dann Änderung.

Die Leitfrage ist „Was können wir weglassen?”, nicht „Was können wir noch verbessern?”. Verbessern fügt hinzu; der Engpass beim agentischen Arbeiten ist aber fast immer das Zuviel, nicht das Zuwenig.

Commit / PR

Sauber abschließen heißt: ein atomarer Commit für genau diesen Slice, temporäre Planungsdateien wieder entfernt.

Bereite einen atomaren Git-Commit für diesen Slice vor.
Fasse nur Änderungen für POST /api/carts zusammen,
entferne temporäre Planungsdateien, schlage eine Commit-Message vor.

feat(cart): add create cart endpoint

Und dann: der nächste Slice

Nach dem ersten Schnitt beginnt die Schleife von vorn — bei der Planung des nächsten kleinsten nutzbaren Ausschnitts. Für die Warenkorb-API etwa: GET /api/carts/{cartId} (Warenkorb abrufen), dann PATCH /api/carts/{cartId}/items/{productId} (Position ändern), DELETE /api/carts/{cartId}/items/{productId} (Position entfernen) und schließlich POST /api/carts/{cartId}/submit (Status auf submitted).

Jeder Slice ist klein genug, um in einem Durchlauf verstanden, getestet und committet zu werden. Genau das hält das Projekt über viele Iterationen hinweg kontrollierbar.

Was den Unterschied macht

Quer durch alle Schritte ziehen sich ein paar Prinzipien, die wichtiger sind als jeder einzelne Prompt:

Nicht mit der Implementierung starten. Der teuerste Fehler ist, den Agenten raten zu lassen. Erst verstehen, dann bauen.

Den Agenten erst Fragen stellen lassen. Ein Modell, das nachfragt, trifft weniger falsche Annahmen als eines, das sofort liefert.

In Vertical Slices denken. Große Aufgaben sind nicht zu komplex für Agenten — sie sind zu komplex zum Reviewen. Der Schnitt löst beides.

Pro Slice klare Akzeptanzkriterien. Eine Definition of Done sagt dem Agenten, wann er aufhören soll. Ohne sie hört er nicht auf.

Den Agenten zur Selbstprüfung bringen. „Analysiere zuerst die Ursache” und „erst Vorschlag, dann Änderung” verhindern blinden Aktionismus.

Ergebnisse zwischen den Phasen sichern und Kontext zurücksetzen. Lange Sessions verwässern den Fokus. Festgehaltene Zwischenergebnisse erlauben einen sauberen Neustart, ohne Wissen zu verlieren.

Refactoring nicht aufschieben. Komplexität, die einen Slice übersteht, wächst im nächsten weiter. Aufräumen gehört in jeden Durchlauf.

Exkurs: Der Agent am Commit

Commit, Push und Pull Request werden gern als Verwaltungsakt behandelt — die eigentliche Arbeit ist ja getan. Aktuelle Coding-Agenten sind dabei allerdings erstaunlich nützlich, wenn man sie bewusst einsetzt.

Commit-Message. Der Agent hat gerade den gesamten Slice gebaut und kennt jeden geänderten Teil. Eine aussagekräftige Message ist für ihn kein Rätsel: Schlage eine Commit-Message für den aktuellen Diff vor reicht. Das Ergebnis ist fast immer besser als das, was man selbst schreibt, wenn man nach 90 Minuten Implementierung noch schnell abschließen will.

Pull-Request-Beschreibung. Wer den PR öffnet, kann den Agenten auch die Beschreibung schreiben lassen — was geändert wurde, warum, wie man es testet. Agenten kennen keine Bescheidenheit und führen jeden für einen Reviewer relevanten Aspekt auf. Das macht PRs lesbarer, ohne dass jemand extra Zeit investiert.

Self-Review vor dem Push. Bevor ein Commit abgeschickt wird, lohnt sich ein letztes Prompt: Reviewe den Diff kritisch. Was würde ein erfahrener Reviewer beanstanden? Agenten finden zuverlässig das, was man selbst übersieht — fehlende Fehlerbehandlung, hartcodierte Werte, inkonsistente Benennung.

Werkzeuge wie Claude Code, GitHub Copilot im Terminal oder Cursor können diesen Teil vollständig übernehmen — von der Commit-Message bis zum PR-Entwurf. Der Vertical-Slice-Workflow macht das besonders wirksam: Ein sauber begrenzter Slice ergibt einen sauberen Diff, und ein sauberer Diff ergibt eine gute Commit-Message. Wer in großen, unstrukturierten Batches committet, gibt diesen Vorteil auf.

Einordnung

Der Workflow ändert nicht, was gebaut wird — sondern wer welche Rolle übernimmt. Der Agent schreibt den Code; die Verantwortung für Anforderungen, Zuschnitt, Abnahme und Architektur bleibt beim Menschen. Das ist weniger Pair Programming und mehr die Rolle eines Tech Leads, der briefen, begrenzen und abnehmen kann.

Der Unterschied zwischen einem beeindruckenden Demo-Lauf und einer Codebasis, die man Monate später noch verantworten kann, liegt selten am Modell. Er liegt darin, ob jemand den Agenten geführt hat — in kleinen Slices, mit klaren Kriterien, und mit der Bereitschaft, vor jeder Zeile Code erst zu verstehen, was eigentlich gebaut werden soll.