Wenn du fragst, ob Specs besser sind als PRDs, stellst du die falsche Frage.
In der KI-gestützten Entwicklung erledigen die beiden unterschiedliche Jobs. Ein PRD beantwortet für Menschen, was wir bauen sollten und warum. Eine Spec beantwortet, was der AI Agent ausführen wird. Reife Teams nutzen beides. Solo Builder brauchen meist weniger PRD und mehr Spec.
Das erklärt auch den Gegenwind. Spec-driven Development wird als „Wasserfall mit Markdown“, als „Spec Drift“ oder als Token verbrennende Zeremonie abgetan, weil viele ein einziges aufgeblähtes Dokument für jeden Job verwenden. Das scheitert. In einem echten Build-Loop sollten das Dokument für die Abstimmung zwischen Menschen und das Dokument für die Ausführung durch die Maschine nicht dasselbe sein. Selbst die Diskussion auf r/ChatGPTCoding darüber, dass „Specification“ ein überladener Begriff ist, zeigt auf dasselbe Durcheinander. Gestritten wird über ein Wort, das inzwischen mehrere sehr verschiedene Artefakte abdeckt.
Die nützliche Frage ist einfacher: Mit welchem Dokument lieferst du korrekten Code mit den wenigsten Fehlern aus?
Inhalt
- PRDs und Specs sind keine Feinde – sie erledigen unterschiedliche Jobs
- Wann du ein Product Requirements Document schreiben solltest
- Wann du eine technische Spec schreiben solltest
- PRD vs. Spec: der direkte Vergleich für KI-Teams
- So umgehst du die Fallen von Spec-driven Development
- Deinen Workflow mit AI Agents wählen
PRDs und Specs sind keine Feinde – sie erledigen unterschiedliche Jobs
Am klarsten denkst du darüber nach, wenn du fragst, welchen Job ein Dokument erledigen soll.
Ein PRD ist ein Abstimmungsdokument. Eine Spec ist ein Ausführungsdokument. Wenn du beides vermischst, bekommst du ein Dokument, das für Cursor oder Claude Code zu vage und für Leute aus Gründungsteam oder Marketing zu technisch ist.
Die eigentliche Trennung
Softwareteams haben PRDs historisch nicht aufgegeben. Als die Systeme komplexer wurden, haben sie das Was und Warum vom Wie getrennt. Martin Fowlers Texte über funktionale Specs und später die Empfehlungen von Productboard ziehen diese Linie klar. Productboard empfiehlt ausdrücklich beide Dokumente, sobald die Umsetzung echte Komplexität hat: das PRD für die Abstimmung, die Spec für technische Tiefe und Umsetzungsdetails – zusammengefasst in dieser Aufschlüsselung funktionaler Specs und der Trennung zwischen PRD und Spec.
Faustregel: Wenn sich Menschen über das Problem einig werden müssen, schreib ein PRD. Wenn ein Agent Dateien korrekt ändern muss, schreib eine Spec.
Warum Founder durcheinanderkommen
Die meisten Ratschläge stammen aus Produktteams großer Unternehmen. So ein Setup hast du nicht. Bei dir sitzen wahrscheinlich nicht Design, Produkt und Engineering in einem Meeting und streiten. Du hast ein Repo, einen AI Agent und ein Feature, das funktionieren muss.
Das ändert die Antwort. Für Solo Builder wird ein PRD oft optional. Eine Spec meist nicht.
Wann du ein Product Requirements Document schreiben solltest
Schreib ein PRD, wenn du Menschen auf ein gemeinsames Verständnis des Problems bringen musst – nicht, wenn ein Agent Code schreiben soll.
Wenn du bei einer unübersichtlichen Produktwette mit Leuten aus Gründungsteam, Design oder externer Unterstützung zusammenarbeitest – oder auch nur mit deinem künftigen Ich –, hilft ein PRD. Es hält das Problem aus Nutzersicht fest, die Rahmenbedingungen, das erwartete Ergebnis und die Abwägungen. Es sollte auf hoher Flughöhe bleiben. Sobald du Endpoint-Details, Datenmodelle und UI-Zustände für Edge Cases hineinstopfst, ist es kein PRD mehr, sondern eine schlechte Spec.
Gute Anwendungsfälle für ein PRD
- Neue Produktwetten: Du entscheidest noch, worauf es ankommt.
- Bereichsübergreifende Arbeit: Andere Menschen brauchen Kontext, keine Umsetzungsdetails.
- Entscheidungsprotokolle: Du willst später noch wissen, warum du diesen Weg gewählt hast.
Für die meisten Founder reicht ein schlankes Dokument in Notion. Wenn du überlegst, wo du diese Art von Planung ablegst, hilft dieser Vergleich der Features von Notion und Confluence, weil er die Abwägung zwischen leichtgewichtiger Zusammenarbeit und schwereren Dokumentationssystemen zeigt.
Ein PRD soll dir beim Entscheiden helfen. Es soll nicht so tun, als wäre es Code.
Wenn du einen Ausgangspunkt brauchst, nimm ein schlankes Format wie diesen PRD-Leitfaden für Founder. Halte es kurz. Wenn du allein baust und das Problem schon kennst, schreib nicht aus Gewohnheit ein sechsseitiges PRD.
Wann du eine technische Spec schreiben solltest
Schreib eine Spec, wenn der nächste Schritt die Umsetzung ist.
Eine nützliche Spec ist in der Codebase verankert. Sie nennt Dateien, Schnittstellen, Scope-Grenzen, Fehlerfälle und Akzeptanzkriterien. Sie sagt dem Agent, was er anfassen soll, was nicht, und woran du erkennst, dass die Arbeit fertig ist.
Bei KI-Arbeit zählt das noch mehr, weil die stärkste Verschiebung in Richtung ausführbarer Akzeptanzkriterien geht. Braintrust bringt das in seinem Plädoyer, dass Evals zur Spec werden, direkt auf den Punkt. Eine Eval-Suite kann bei jedem Commit laufen und zeigen, ob das Produkt besser wird. Ein PRD kann das nicht.
Was in die Spec gehört
- Kontext: Welches Feature sich ändert und warum es existiert
- Scope-Grenzen: Vor allem, was du nicht baust
- Umsetzungsdetails: Pfade, Komponenten, APIs, Schemaänderungen, State-Flow
- Akzeptanzkriterien: Konkrete Prüfungen, aus denen Tests werden können
Addy Osmanis Format mit sechs Abschnitten ist ein guter Standard. Es ist strukturiert, kurz und für Agents gebaut statt für Texte, die ein Gremium abstimmt. Wenn du ein praktisches Template willst, nimm diesen Leitfaden dazu, wie du technische Specs schreibst.
PRD vs. Spec: der direkte Vergleich für KI-Teams
Spätestens hier wird der Unterschied offensichtlich.
| Achse | PRD (Product Requirements Doc) | Spec (technische Spec) |
|---|---|---|
| Hauptjob | Menschen auf Problem und Ergebnis einschwören | Die Umsetzung anleiten |
| Hauptpublikum | Gründungsteam, Design, Marketing, künftiges Team | KI-Coding-Agent, Engineering, Review |
| Detailgrad | Produktabsicht auf hoher Flughöhe | Bauplan, der die Codebase kennt |
| Bester Zeitpunkt | Bevor Details der Lösung feststehen | Direkt vor und während der Umsetzung |
| Erfolgstest | Gemeinsames Verständnis | Akzeptanzkriterien und funktionierender Code |
Gib einem AI Agent ein PRD, und du bekommst meist Rätselraten. Gib einem Stakeholder ohne technischen Hintergrund eine Spec, und du bekommst Verwirrung. Diese Fehlpassung verursacht den Großteil der Reibung, die man KI-Tools anlastet.
Hier ein hilfreiches Gespräch über den Workflow aus PM-Sicht:
Der sinnvolle Stack für kleine KI-Teams ist einfach: ein einseitiges PRD, wenn sich Menschen abstimmen müssen. Eine echte Spec, wenn Code ausgeliefert werden soll.
So umgehst du die Fallen von Spec-driven Development
Die Kritik trifft zu, wenn die Spec riesig, veraltet und vom Code losgelöst ist.
„Eingefrorene Specs“ entstehen, wenn jemand vorab ein großes Dokument schreibt und es nie aktualisiert. „Spec Drift“ entsteht, wenn sich der Code ändert und das Dokument nicht. Die „Produktivitätsfalle“ schnappt zu, wenn das Schreiben der Spec selbst zur Arbeit wird.
Die Lösung ist ein kleinerer Scope
Bind jede Spec an eine Arbeitseinheit. Ein Feature. Ein Refactoring. Eine klar abgegrenzte Änderung. Kein Masterdokument für die gesamte Vision des Unternehmens.
Der Thread auf r/ProductManagement über die Zusammenarbeit mit dem Engineering bei Spec-driven Development hilft hier, weil er die menschliche Seite dieses Fehlerbilds zeigt. Teams tun sich schwer, wenn Specs zum Übergabetheater werden statt zu einem lebendigen Werkzeug der Abstimmung.
Eine bessere Arbeitsregel
- Halte sie eng: Eine Aufgabe oder ein Feature pro Spec
- Halte sie lebendig: Aktualisiere das Dokument, wenn sich der Plan ändert
- Halte sie testbar: Jede wichtige Aussage sollte sich einer Prüfung zuordnen lassen
- Halte sie wegwerfbar: Ist die Arbeit erledigt, archivier sie und mach weiter
Kleine Specs altern gut. Riesige Specs verrotten schnell.
Wenn du das ausführlichere Argument dazu willst, wo es schiefgeht, lies, wann Spec-driven Development zur Produktivitätsfalle wird.
Deinen Workflow mit AI Agents wählen
Arbeitest du allein, ist die Entscheidung schnell getroffen.
Nimm ein PRD, wenn du Klarheit über das Problem brauchst. Nimm eine Spec, wenn du eine korrekte Umsetzung brauchst. Wer mit AI Agents ausliefert, braucht meistens das Zweite mehr als das Erste.
Deshalb zählt die Lücke, vor der Solo Founder stehen. Laut Daten brechen 78 % der Indie-Devs Projekte wegen unklarer Anforderungen ab, und dieselbe Quelle sagt, dass eine McKinsey-Studie von 2025 für Solo Builder modulare, KI-lesbare Specs statt monolithischer PRDs nahelegt – zusammengefasst in dem Beitrag von Signal Thinking darüber, warum PRDs in KI-Workflows versagen. Das deckt sich mit dem, was in der Praxis passiert. Du brauchst nicht mehr Planungstheater. Du brauchst einen Plan, der deine Codebase kennt und den du an Cursor, Claude Code, Codex oder Gemini übergeben kannst.
Tekk.coach ist um genau diese Einheit herum gebaut. Seine Loops lesen, was sich in deinem Code geändert hat, und schreiben die Spec als Proposal für dich; gibst du es mit Greenlight frei, landet die Spec mit Akzeptanzkriterien und Checkliste auf deinem Board. Du kannst auch selbst eine schreiben. Dein Coding-Agent baut sie über MCP, und der gemergte PR schließt die Spec. Tekk schreibt den Code nie selbst.
Wenn du kein Team hast, das sich abstimmen muss, kopier keinen Team-Workflow.
Die kurze Antwort auf „Sind Specs besser als PRDs?“ lautet: Nein. Sie sind enger gefasst. Sie sind besser ausführbar. Und in der KI-gestützten Entwicklung sind sie meist das Dokument, mit dem die Arbeit tatsächlich ausgeliefert wird.
Specs von Hand zu schreiben ist der manuelle Weg. Die Loops von Tekk.coach schreiben sie für dich aus dem, was sich in deinem Code geändert hat: dasselbe Board, dieselben Akzeptanzkriterien, geschlossen, sobald der PR gemergt ist.
Teil des Leitfadens zu Spec-driven Development – ein ehrliches Playbook dafür, mit KI-Coding-Agents auszuliefern. Die andere Hälfte ist Loop Engineering: An der Spec erkennt ein Loop, dass er fertig ist.