Drei Wege, einen Coding-Agenten zu briefen: Spezifikation, Produktmodell oder Review mit frischem Blick

Ein Coding-Agent, der das Falsche ausliefert, hat meist die Anfrage verstanden und das Produkt missverstanden. Die spannende Frage Ende 2026 ist nicht mehr, welchen Agenten man nutzt, sondern wie man ihn brieft, und es haben sich drei verschiedene Antworten herausgebildet. Sie unterscheiden sich in einem Punkt: was du aufschreibst und wie lange es Bestand hat.

Spezifikationsgetrieben: ein Dokument pro Änderung

Der am weitesten verbreitete Ansatz schreibt für jedes Feature eine Spezifikation, dann einen Plan und eine Aufgabenliste, und lässt den Agenten danach bauen. Spec Kit (4,3) ist die Version von GitHub, mit etwa 143.000 Sternen und einem Converge-Schritt, der die Umsetzung gegen die Dokumente prüft; es unterstützt mehr als 40 namentlich genannte Agenten. BMAD-METHOD (3,8) deckt ähnliches Terrain mit einer Besetzung aus Personas ab. Die Stärke: Der Vertrag liegt in Git und durchläuft Pull Requests wie Code. Der Preis ist Lesezeit: Der veröffentlichte Versuch von Scott Logic bezifferte die menschliche Prüfung auf etwa zwei bis dreieinhalb Stunden pro Feature, weshalb beide Tools leichtere Wege für kleine Korrekturen mitliefern.

Produktgetrieben: ein dauerhaftes Modell

Eine neuere Schule argumentiert, dass eine Spezifikation die Änderung beschreibt, nicht das Produkt, und das Produkt daher immer wieder von Grund auf rekonstruiert wird. pdd-kit (3,7) führt ein einziges, in Git versioniertes Produktmodell, mit Entitäten, Journeys, Geschäftsregeln und Varianten, das jeder Agent liest, statt zu raten, mit einem Verify-Schritt, der Code dagegen prüft. Die Idee ist schärfer als ein Ordner voller Spezifikationen, aber noch früh: etwa 97 Sterne und ein einziger Maintainer, und ein Modell, das hinter dem Code zurückbleibt, führt Agenten stärker in die Irre als gar kein Modell. Es lohnt sich bei Produkten mit echter fachlicher Komplexität, nicht bei einer CRUD-App.

Review zuerst: frische Augen die Lücken finden lassen

Der dritte Ansatz akzeptiert, dass der entwerfende Agent seine eigenen blinden Flecken übersieht, und holt einen Reviewer dazu, der das Gespräch nie gesehen hat. Elephant-Goldfish Model (4,2), ein Open-Source-Plugin von Google, entwirft ein Design mit einem Agenten mit tiefem Kontext (dem Elephant) und übergibt es dann an Subagenten ohne Kontext (die Goldfish), die nur das Dokument und seine zitierten Quellen lesen. Weil sie sich nicht auf den Chat stützen können, aus dem das Design entstand, bringen sie die unausgesprochenen Annahmen ans Licht. Die Methode ist gut begründet und hat bereits etwa 6.500 Sterne; der Haken ist, dass sie ein Harness braucht, das frische Subagenten starten kann, und dass sie abbricht, statt ein Review vorzutäuschen, wo sie das nicht kann.

Wo Workflow-Pakete hineinpassen

Daneben stehen allgemeine Workflow-Installer wie Superpowers (4,7), die einem Agenten Gewohnheiten zum Planen und zur Selbstprüfung geben, ohne ein Spezifikationsformat vorzuschreiben. Sie lassen sich mit jedem der drei Briefing-Stile kombinieren, statt mit ihnen zu konkurrieren, und sind der Einstieg mit dem geringsten Aufwand.

Was du nutzen solltest

Für eine einzeilige Korrektur nichts davon: Git, die Tests und ein kurzer Prompt, der die Dateien nennt, gewinnen. Für ein Feature, das vor dem Code Designentscheidungen braucht, fängt Review zuerst mit dem wenigsten Schreibaufwand die meisten echten Bugs, sofern dein Agent Subagenten unterstützt. Für eine regulierte Änderung, die später ein Prüfer liest, ist die Papierspur des spezifikationsgetriebenen Ansatzes genau der Sinn. Und für ein komplexes Produkt, bei dem Agenten immer wieder dieselben Regeln neu erfinden, rechtfertigt ein Produktmodell seinen Pflegeaufwand, wenn, und nur wenn, jemand es aktuell hält.