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

Quellenangaben