Sieben Agentenläufe für ein einziges Feature. So sah die erste Version meines Harness aus: spezialisierte Subagenten für Product Owner, Architect, UX Designer und Software Engineer, später auch für QA, saubere Übergaben, klare Zuständigkeiten. Auf dem Papier klang das nach guter Architektur. In der Praxis war es langsam und kompliziert.
Also habe ich die Subagenten wieder abgeschafft.
Warum die vermeintlich bessere Architektur gescheitert ist und wie aus einer Idee heute eine getestete, dokumentierte Änderung entsteht, zeige ich in diesem letzten Teil der Serie über meinen Harness sparc.
Was an den Subagenten schiefging
Die Idee war naheliegend. Jede Rolle bekommt einen eigenen Agenten mit eigenem Kontext. Der Product Owner schreibt die Anforderungen, der Architect das Design, die Engineers setzen um, QA prüft. Die Arbeit wandert von Agent zu Agent.
Bei der Änderung, die den QA-Agenten einführte, habe ich dann genauer hingeschaut. Für ein Feature waren sieben Agentenläufe nötig, und jeder einzelne hatte Kosten:
- Jeder Agent las dieselben Dateien erneut, weil er seinen eigenen, leeren Kontext hatte.
- Rückfragen liefen über Umwege. Hatte ein Agent eine Frage an mich, musste die Hauptsession sie weiterreichen und die Antwort zurückgeben.
- Agenten blieben einfach stehen, sobald ein Werkzeug fehlschlug.
- Änderungen an einem Agenten waren nicht sofort nutzbar, weil Claude Code Agententypen nur beim Start einer Session lädt.
- Parallele Engineers in eigenen Git-Worktrees erzeugten falsche Warnungen, die Doku passe nicht zum Code, und sparten kaum Zeit.
Die Lösung war fast enttäuschend einfach: Aus jedem Agenten wurde eine Regeldatei. Ein Skill sagt jetzt nur noch „Folge der Rolle Software Engineer“, und die laufende Session arbeitet die Rollen nacheinander ab. Keine Übergaben, keine weitergereichten Fragen, keine Worktrees. Eine geänderte Rolle wirkt sofort.
Ganz umsonst ist das nicht, und das steht auch so im ADR: Es gibt standardmäßig keine unabhängige Prüfung mehr durch einen frischen Kontext, und der Kontext der Hauptsession wächst. Dagegen helfen ein Code-Review und automatisierte Tests als Evidenz. Wer trotzdem eine unabhängige Sicht will, kann QA und Abnahme gezielt an einen einzelnen, frischen Subagenten geben. Warum ein frischer Kontext manchmal genau richtig ist, erklärt Sascha in Context Management.
Mehr Agenten sind nicht automatisch mehr Struktur. Oft sind sie nur mehr Koordination.
Der Workflow heute: propose, apply, archive
sparc baut auf OpenSpec auf. Jede Änderung ist ein eigener Ordner mit Proposal, Spec-Deltas, Design und Tasks und läuft durch drei Schritte. Ich erzähle sparc ein Projekt genau einmal, beim Einrichten. Danach beschreibe ich nur noch einzelne Features oder Fixes.
propose erzeugt nur Planungsdokumente, keinen Code. Der Product Owner schreibt die Anforderungen als testbare Szenarien im Format WHEN/THEN und hält fest, was ausdrücklich nicht dazugehört. Hat die Änderung eine Oberfläche, baut der UX Designer statische HTML-Mockups. Der Architect schreibt das Design, legt relevante Entscheidungen als ADR an und zerlegt die Arbeit in kleine Tasks, von denen jeder seine Verifikation nennt. Am Ende lese ich eine kurze Zusammenfassung. Dass Anforderungen in Zyklen reifen statt in einem Wurf, habe ich in Der Requirements-Zyklus beschrieben. propose ist genau so ein Zyklus im Kleinen.
Die Freigabe war die zweite Vereinfachung. Anfangs wartete sparc nach jedem Proposal auf ein „Ja“ im Chat. Dabei habe ich die Entscheidung längst getroffen, wenn ich die Umsetzung starte. Heute ist der Aufruf von apply die Freigabe. Arbeitet ein Projekt mit Pull Requests, zählt das Approval oder der Merge.
apply setzt die Änderung um. Der Software Engineer arbeitet die Tasks testgetrieben ab, ein Commit pro Task. Danach prüft er den gesamten Diff in einem Code-Review. Dann beweist der QA Engineer jedes Spec-Szenario mit Integrations- oder End-to-End-Tests: Die Szenarien sind der Testplan. Der Product Owner nimmt auf Basis dieses Berichts ab und prüft nur noch, was sich nicht automatisieren ließ.
archive schließt ab: Specs aktualisieren, Backlog abhaken, Changelog schreiben, ADRs annehmen, Dokumentation synchronisieren, Check laufen lassen.
Ein echter Fund aus dem Code-Review
Wie das in der Praxis aussieht, zeigt der Bericht der Änderung, mit der sparc trunk-basiertes Arbeiten gelernt hat. Jede Änderung hat eine Datei qa.md, und deren Code-Review-Abschnitt sah so aus:
## Code review
Reviewed: `d5eb542..64bf322` (software engineer role, `git diff main...HEAD`)
| Finding | Fix |
|---|---|
| A typo in `sparc.workflow` (for example `trunkk`) fell back to
`pull-request` without a message. | 64bf322 |
Ein Tippfehler in der Konfiguration hätte ein Projekt still in den falschen Workflow geschickt. Gefunden hat ihn das Review, behoben wurde er mit einem eigenen Commit, und im Bericht ist beides nachvollziehbar. Darunter folgt im selben Bericht jedes Spec-Szenario mit Ergebnis und Evidenz, also dem Test und dem Befehl, mit dem es geprüft wurde. Ohne Code-Review und mit einem fehlgeschlagenen Szenario gibt es keine Abnahme.
Das Review ersetzt kein menschliches Review. Warum Code-Reviews mit Coding Agents eher mehr Aufmerksamkeit brauchen, habe ich in Code-Reviews im Zeitalter von Coding Agents beschrieben. Es sorgt aber dafür, dass ich einen Diff bekomme, der die offensichtlichen Probleme schon hinter sich hat.
Trunk oder Pull Request
Auch hier gab es eine Kurskorrektur. Zuerst verlangte sparc für jede Änderung einen Branch und einen Pull Request. Im Team ist das richtig, denn der Pull Request ist das Review. In einem Projekt, an dem ich allein arbeite, ist es Aufwand ohne Reviewer: Branch anlegen, PR öffnen, selbst mergen. Heute fragt sparc beim Einrichten: „Arbeitest du allein oder im Team?“ Allein bedeutet Commits direkt auf dem Hauptbranch, im Team Pull Requests.
In beiden Fällen gelten Keep a Changelog, Semantic Versioning und Conventional Commits. Agenten erzeugen viele Änderungen in kurzer Zeit, und ohne feste Konventionen erzählt die Historie niemandem mehr etwas. Aus den Commit-Typen berechnet sparc die nächste Version. Und weil Projekte mit der Zeit veralten, speichert jedes Projekt seine sparc-Version. Die Migrationsschritte stehen in den Breaking-Einträgen des Changelogs, sodass ein Update nur den sparc-Teil ersetzt und Projektregeln unberührt lässt.
Zum Mitnehmen: drei Fragen vor dem nächsten Subagenten
Subagenten sind nicht grundsätzlich schlecht. Bevor du einen einführst, lohnen sich aber drei Fragen, die ich aus dieser Erfahrung mitgenommen habe:
- Braucht die Aufgabe wirklich einen leeren Kontext? Wenn der Agent als Erstes dieselben Dateien liest wie die Hauptsession, zahlst du doppelt.
- Muss der Agent mit dir sprechen? Jede Rückfrage, die über die Hauptsession läuft, kostet Zeit und verliert Kontext.
- Würde eine Regeldatei reichen? Eine Rolle ist oft nur eine Anleitung. Die kann auch die laufende Session befolgen.
Wenn alle drei Antworten für den Subagenten sprechen, etwa für eine unabhängige Prüfung am Ende, ist er richtig. Sonst ist er Koordination ohne Gegenwert.
Fazit
Der Workflow von sparc ist kein neues Vorgehensmodell. Er ist das, was ein gutes Team ohnehin tut: Anforderungen klären, Entscheidungen festhalten, testgetrieben bauen, reviewen, gegen die Anforderungen testen, abnehmen, dokumentieren, versionieren. Der Unterschied ist, dass ich es keinem Agenten mehr erklären muss.
Die wichtigste Erkenntnis der ganzen Serie: Ein Harness wird nicht durch mehr Bausteine besser, sondern durch weniger. Zwei der wichtigsten Entscheidungen in sparc haben etwas entfernt, die Subagenten und den Pull-Request-Zwang. Beide Male wurde der Harness schneller, einfacher und verlässlicher.