PRD-gesteuerte Entwicklung: Wie ich über 30 PRDs nutze, um mit KI-Agenten zu liefern

Der RalphBlaster-Workflow von SaasMaker generiert einen vollständigen Pull Request aus einem einzeiligen Ticket in unter 45 Minuten, wobei der Entwickler während der Implementierung keinen einzigen Code anfasst.¹

Ich habe dieses Muster ausprobiert. Es funktioniert. Es scheitert aber auch auf Arten, die die Demovideos nicht zeigen.

TL;DR

Ich habe in den letzten sechs Monaten über 30 PRDs für KI-Agenten-Aufgaben geschrieben. Das Muster funktioniert gut bei klar definierten Aufgaben mit eindeutigen Akzeptanzkriterien: CRUD-Endpunkte, Testergänzungen, UI-Komponenten nach etablierten Mustern. Es scheitert bei mehrdeutigen Anforderungen, neuartigen Architekturentscheidungen und allem, was iteratives menschliches Urteilsvermögen erfordert. Mein PRD-Template hat sich von einem einfachen User-Story-Format zu einem strukturierten Dokument mit Dateipfaden, Testerwartungen, Einschränkungen und expliziten „Nicht-anfassen”-Listen entwickelt. Diese Weiterentwicklung geschah, weil Agenten vage PRDs auf überraschende Weise interpretierten.

Der Workflow, den ich tatsächlich verwende

Schritt 1: Ein Ticket erstellen

Ich definiere in einfacher Sprache, was passieren soll. Genauigkeit ist wichtiger, als ich anfangs dachte:

Vage (erzeugt unvorhersehbare Ergebnisse):

Add user preference saving to the settings page.

Spezifisch (erzeugt vorhersehbare Ergebnisse):

Add dark mode toggle to /settings. Persist to user_preferences
table (column: dark_mode, type: boolean, default: false).
Use existing SettingsForm component. Add toggle below the
notification section. No new dependencies.

Die zweite Version schränkt den Agenten ausreichend ein, sodass das Ergebnis den Erwartungen entspricht. Die erste Version lieferte mir eine Einstellungsseite mit einer neuen React-Komponente, drei neuen npm-Paketen und einer localStorage-Implementierung anstelle der gewünschten Datenbankpersistierung.

Schritt 2: Das PRD generieren oder schreiben

Mein /prd-Skill wandelt ein Ticket in ein strukturiertes PRD mit User Stories, Akzeptanzkriterien, Dateipfaden und Testerwartungen um.² Ein typisches PRD sieht so aus:

## Story: Add dark mode toggle
**As a** user
**I want to** toggle dark mode from settings
**So that** I can read comfortably in low light

### Acceptance Criteria
- [ ] Toggle appears in SettingsForm below notifications
- [ ] Persists to user_preferences.dark_mode (boolean)
- [ ] Default: false (light mode)
- [ ] Toggle state reflects current DB value on page load

### Files to Modify
- app/routes/settings.py (add dark_mode to form handler)
- app/templates/settings.html (add toggle component)
- app/models/user.py (add dark_mode column if missing)

### Files NOT to Modify
- app/static/css/styles.css (dark mode CSS already exists)
- app/templates/base.html (already reads dark_mode class)

### Test Expectations
- Test toggle persists to database
- Test default value on new user
- Test toggle reflects current state on reload

Der Abschnitt „Files NOT to Modify” war die größte Template-Weiterentwicklung. Ohne ihn „verbesserten” Agenten hilfsbereit verwandte Dateien und führten Änderungen ein, die ich weder angefordert hatte noch wollte.

Schritt 3: Implementierung durch den Agenten

Der Agent arbeitet in einem isolierten Git-Worktree, um Konflikte mit meinem aktuellen Branch zu vermeiden:³

# Create isolated worktree for agent task
git worktree add ../worktrees/dark-mode -b feature/dark-mode

# Agent works in ../worktrees/dark-mode/
# I continue working in main workspace

# Review and cleanup after merge
git worktree remove ../worktrees/dark-mode

Mein Rekursionsschutz überwacht das Spawn-Verhalten des Agenten. Mein Git-Sicherheitswächter verhindert, dass der Agent Force-Pushes durchführt oder Anmeldedaten committet. Diese Hooks laufen automatisch. Ich beaufsichtige den Agenten während der Implementierung nicht.

Schritt 4: Review

Eine Benachrichtigung erscheint, wenn der Agent fertig ist. Ich überprüfe den Diff anhand der PRD-Akzeptanzkriterien. Wenn alle Kriterien bestanden sind, merge ich. Wenn nicht, behebe ich die Probleme entweder manuell oder starte den Agenten mit aktualisiertem Kontext neu.⁴

Wo PRD-gesteuerte Entwicklung funktioniert

CRUD-Endpunkte mit klaren Datenmodellen. Das PRD spezifiziert das Modell, die Routen und das Antwortformat. Der Agent generiert Boilerplate-Code, der bestehenden Mustern entspricht.

Testergänzungen für bestehenden Code. „Schreibe Tests für app/content.py, die load_post_by_slug mit gültigem Slug, ungültigem Slug und fehlender Datei abdecken” erzeugt nützliche Tests, weil die Funktion bereits existiert und die Akzeptanzkriterien objektiv sind.

UI-Komponenten nach etablierten Mustern. „Füge einen Kategoriefilter zur Blog-Übersichtsseite hinzu, der dasselbe Tab-Muster wie die Guide-Seite verwendet” funktioniert, weil der Agent das bestehende Muster referenzieren kann.

Datenbankmigrationen mit definierten Schemata. Das PRD spezifiziert Spalten, Typen, Standardwerte und Einschränkungen. Der Agent generiert die Migration und aktualisiert das Modell.

Wo PRD-gesteuerte Entwicklung scheitert

Mehrdeutige Anforderungen. „Mach den Blog besser” ist kein PRD. Der Agent wird Änderungen vornehmen, aber sie werden nicht Ihrer Absicht entsprechen, weil Ihre Absicht nicht spezifiziert wurde.

Neuartige Architekturentscheidungen. Als ich das Konsensmodell des Deliberation-Systems entwerfen musste, konnte kein PRD diese Entscheidung erfassen. Ich musste Optionen erkunden, Kompromisse bewerten und iterativ am Design arbeiten. Dafür brauchte ich meinen Deliberation-Skill, kein PRD.

Performanceoptimierung. „Mach die Seite schneller” erfordert Profiling, Messung und iterative Untersuchung. Der Agent kann Ihre Produktions-Traffic-Muster nicht anhand eines PRDs profilieren.

Sicherheitskritischer Code. PRDs für Authentifizierungssysteme erzeugen Code, der den Happy Path abdeckt. Randfälle in der Authentifizierung (Timing-Angriffe, Session Fixation, CSRF in nicht standardmäßigen Abläufen) erfordern menschliche Expertise, die PRDs nicht kodieren können.

Wie sich mein PRD-Template weiterentwickelt hat

Version 1 (Monat 1): Einfache User Stories

As a user, I want to save preferences so I can customize my experience.

Problem: Zu vage. Der Agent traf vernünftige, aber falsche Annahmen über Speichermechanismus, UI-Platzierung und Umfang.

Version 2 (Monat 2): Dateipfade hinzugefügt

## Story: Save preferences
### Files to Modify
- app/routes/settings.py
- app/templates/settings.html

Problem: Besser, aber Agenten „verbesserten” weiterhin benachbarte Dateien ohne Erlaubnis.

Version 3 (Monat 4): Einschränkungen hinzugefügt

## Story: Save preferences
### Files to Modify (only these)
- app/routes/settings.py
- app/templates/settings.html
### Constraints
- No new dependencies
- Use existing database models
- Do not modify CSS

Problem: Agenten ignorierten manchmal Einschränkungen, wenn diese mit „Best Practices” aus den Trainingsdaten kollidierten.

Version 4 (Aktuell): Explizite Ausschlüsse + Testerwartungen

Das aktuelle Template fügt „Files NOT to Modify”, explizite Testerwartungen und Akzeptanzkriterien-Checkboxen hinzu. Diese Version erzeugt in etwa 85 % der Fälle vorhersehbare Ergebnisse. Die verbleibenden 15 % erfordern einen zweiten Durchlauf mit präzisierten Anweisungen.⁵

Die 30-PRD-Musterbibliothek

Nach über 30 PRDs kristallisierten sich Muster heraus:

Die Erfolgsrate für neuartige Features (50 %) erklärt, warum PRD-gesteuerte Entwicklung meinen Workflow ergänzt, anstatt ihn zu ersetzen. In der Hälfte der Fälle erfordert neuartige Arbeit Iteration, die PRDs nicht im Voraus erfassen können.

Wichtigste Erkenntnisse

Für Einzelentwickler: - Beginnen Sie mit einem gut definierten PRD-Typ (CRUD, Tests) und validieren Sie den Workflow, bevor Sie zu komplexen Aufgaben übergehen - Fügen Sie „Files NOT to Modify” zu jedem PRD hinzu; Agenten werden hilfsbereit Code „verbessern”, den Sie nicht angefasst haben wollten - Nutzen Sie Git-Worktrees, um Agentenarbeit zu isolieren; die Aufräumkosten eines fehlgeschlagenen Agentenlaufs sollten ein einzelner Befehl sein, nicht eine Git-Archäologiesitzung

Für Engineering Manager: - Die PRD-Qualität bestimmt die Qualität des Agenten-Outputs; investieren Sie in PRD-Templates und Review-Prozesse, bevor Sie den Einsatz autonomer Agenten skalieren - Verfolgen Sie die Merge-ohne-Änderungen-Quote, um die Workflow-Reife zu messen; die Quote sollte sich verbessern, wenn sich die PRD-Templates weiterentwickeln - Neuartige Architekturarbeit und sicherheitskritischer Code sollten nicht per PRD delegiert werden; reservieren Sie die Agenten-Delegation für klar definierte, wiederholbare Aufgaben

Häufige Fragen

Was ist PRD-gesteuerte Entwicklung?

PRD-gesteuerte Entwicklung ist ein Workflow, bei dem ein Product Requirements Document eine Aufgabe so präzise beschreibt, dass ein KI-Agent sie autonom umsetzen kann. Das PRD enthält User Stories, Akzeptanzkriterien, Dateipfade, Einschränkungen und Testerwartungen. Der Agent arbeitet in einem isolierten Git-Worktree, während Sie an anderen Dingen weiterarbeiten. Am besten funktioniert das Muster bei klar definierten, wiederholbaren Aufgaben wie CRUD-Endpunkten, Testergänzungen und UI-Komponenten nach etablierten Mustern.

Wie viele PRDs sollte ich schreiben, bevor ich dem Workflow vertraue?

Beginnen Sie mit drei bis fünf PRDs in einer einzigen Kategorie, in der Sie das erwartete Ergebnis sicher einschätzen können, etwa Testergänzungen oder Datenbankmigrationen. Diese Kategorien erreichen nach meiner Erfahrung Erfolgsquoten von rund 90 %. Sobald bestätigt ist, dass Ihr Template vorhersehbare Ergebnisse liefert, erweitern Sie auf UI-Komponenten (Erfolgsquote etwa 85 %) und Bugfixes (etwa 80 %). Neuartige Features haben eine Erfolgsquote von etwa 50 % und sollten nicht Ihr Einstieg in die PRD-gesteuerte Entwicklung sein.

Welches Format eignet sich am besten für PRDs, die mit Claude Code verwendet werden?

Das wirksamste PRD-Format umfasst fünf Abschnitte: eine User Story mit Akzeptanzkriterien-Checkboxen, eine „Files to Modify”-Liste mit konkreten Pfaden, eine „Files NOT to Modify”-Ausschlussliste, Testerwartungen mit konkreten Szenarien sowie Einschränkungen (keine neuen Abhängigkeiten, bestehende Muster nutzen). Die Ausschlussliste war die mit Abstand größte Verbesserung an meinem Template, denn sie hindert Agenten daran, Code außerhalb des Aufgabenbereichs „hilfsbereit” zu verändern.

Kann PRD-gesteuerte Entwicklung das menschliche Code-Review ersetzen?

Nein. PRD-gesteuerte Entwicklung ersetzt den Implementierungsschritt, nicht den Review-Schritt. Jedes abgeschlossene PRD muss vor dem Merge weiterhin von einem Menschen anhand der Akzeptanzkriterien geprüft werden. In meinem Workflow erscheint eine Benachrichtigung, sobald der Agent fertig ist, und ich überprüfe den Diff Kriterium für Kriterium. Die Qualitätsschleife und die unabhängige Testverifikation ergänzen das menschliche Urteil über architektonische Passung und Korrektheit, ersetzen es aber nicht.

Warum ignorieren KI-Agenten manchmal die Einschränkungen eines PRDs?

Agenten ignorieren Einschränkungen dann, wenn diese mit Mustern aus den Trainingsdaten kollidieren. Steht in Ihrem PRD „keine neuen Abhängigkeiten”, verbinden die Trainingsdaten des Modells die Aufgabe aber mit einer bestimmten Bibliothek, installiert das Modell diese Bibliothek womöglich trotzdem. Abhilfe schaffen explizite Ausschlüsse: Listen wie „Files NOT to Modify” und „Nicht installieren” wirken besser als positiv formulierte Vorgaben, weil sie dem Agenten eine konkrete Grenze statt einer allgemeinen Richtlinie geben.

Quellenangaben