vibe coding ist tot — jetzt Spezifikationen schreiben? Der dritte Weg für Product Manager: Sag es, und es entsteht
Im Methoden-Diskurs tobt gerade ein Streit, und die Schlagzeilen klingen alarmierend: „vibe coding ist tot — wechselt jetzt zu spec-driven development.”
Der Wind dreht sich spürbar. GitHubs Spec Kit hat über neunzigtausend Sterne, AWS hat mit Kiro ein Tool rund um „erst Spezifikation, dann Code” auf den Markt gebracht, und Thoughtworks hat spec-driven development in den Technology Radar aufgenommen. Die herrschende Meinung lautet: Die Spezifikation ist die einzige Quelle der Wahrheit, Code ist nur ihr Ergebnis — wenn beide sich widersprechen, ändert man den Code, nicht die Spezifikation.
Das klingt einleuchtend. Aber wenn du Product Manager bist, lass dich nicht vorschnell mitreißen und diesen „Spezifikationen schreiben”-Kurs nachholen.
Das Pendel hat zu weit ausgeschlagen
Die Geschichte läuft so ab:
Erst kam vibe coding und begeisterte alle — einen Satz hinschmeißen, und die KI produziert im Nu einen Haufen Code. Herrlich, aber der Absturz kam schnell: kein Gerüst, nicht wartbar, niemand konnte sagen, was eigentlich gebaut worden war. Also schlug das Pendel in die entgegengesetzte Richtung: Dann schreiben wir alles zuerst als Spezifikation auf, so detailliert wie möglich, und lassen die KI danach arbeiten.
Das Problem für Product Manager: „Einen ausführlichen Vorab-Spec schreiben” — das kennst du in- und auswendig. Das ist ein PRD. Dieses Dokument, das gerne Dutzende Seiten lang wird, das veraltet ist, bevor die Tinte trocken ist, das niemand vollständig liest. Einer der größten Befreiungsschläge der KI-Ära war, dich aus dieser Dokumenten-Fronarbeit herauszuholen — und jetzt lädt spec-driven sie eins zu eins wieder auf deine Schultern, bloß mit einem trendigen neuen Namen.
Von „wild draufloswursteln” zu „alles vorher aufschreiben” zu wechseln heißt, von einem Extrem ins andere zu kippen. Keines der beiden Extreme ist der richtige Ort für einen Product Manager.
Der dritte Weg: Spezifikationen werden nicht geschrieben — sie werden gesagt und herbeigeführt
vibe coding ist zu fragil, Spezifikationen schreiben ist zu schwerfällig. Dazwischen liegt ein dritter Weg — genau der, den doaipm von Anfang an geht: 言出法随.
Der Kern ist: Du brauchst keinen Spec in einem Dokument. Du brauchst die Fähigkeit, klar zu sagen, was du bauen willst. Und „klar reden” ist genau die ureigenste Grundkompetenz von Product Managern — keine neue Fähigkeit.
Konkret zerfällt das in zwei Dinge:
Erstens: Die Spezifikation lebt im Dialog, nicht im Dokument. Du musst nicht erst einen vollständigen Spec fertig haben, bevor du anfängst. Du kommunizierst deine Absicht — wen soll es lösen, welches Problem, welche entscheidenden Randbedingungen, woran erkennt man, dass es stimmt — und lässt die KI das unmittelbar in etwas Lauffähiges verwandeln. Wo etwas unklar ist, fragt die KI nach (ein guter Agent sollte zuerst 3–5 präzise Fragen stellen, bevor er loslegt), und du klärst es im Gespräch. Klärung geschieht im Austausch — nicht in einem Dokument, das niemand lesen möchte.
Zweitens: Der lauffähige High-Fidelity-Prototyp ist die beste Spezifikation. Einen Textspec lesen zehn Personen und verstehen ihn auf zehn verschiedene Weisen; einen Prototypen, den man anklicken und durchlaufen kann — mit echten Zuständen (Laden / Leer / Fehler / Erfolg) — sieht jeder einmal und weiß sofort, ob es stimmt. Ein High-Fidelity-Prototyp ist eine Spezifikation, die für sich selbst spricht — er wird nicht interpretiert, er wird erlebt. Genau deshalb wendet sich doaipm gegen Low-Fidelity-Wireframes: Im KI-Zeitalter ist es schneller und weniger fehleranfällig, direkt das Echte zu bauen als eine Attrappe zu zeichnen.
Woher kommt die „Struktur”? — Kleine Schritte und ein Sicherheitsnetz
Manche werden fragen: Ohne schweren Spec — wie verhindert man dann, dass man in dieselben Fallen tappt wie bei vibe coding und die Kontrolle verliert?
Durch zwei Dinge, nicht durch dicke Dokumentenstapel:
- Kleine Schritte, schnelles Vorankommen. Immer nur eine Sache auf einmal ändern, kurz laufen lassen, kurz schauen, dann weitergehen. Struktur wächst durch eine Reihe verifizierbarer kleiner Schritte — sie wird nicht vor dem Start einmalig festgezurrt.
- Sicherheitsnetz. Keine echten Schlüssel oder echten Daten im Prototyp; unumkehrbare Aktionen (deployen, löschen, bezahlen) liegen immer beim Menschen; keine Produktionsumgebung anfassen; bei Unsicherheit fragen. Das Urteil bleibt stets bei dir — genau das ist der unersetzbare Teil des Product Managers.
Wer sagt, die Spezifikation sei die einzige Quelle der Wahrheit, lässt einen Satz aus: Im KI-Zeitalter ist die hochfidelste „Wahrheitsquelle” kein Dokument — es ist das Produkt, das gerade vor deinen Augen läuft.
Was also gilt heute?
Wähle keine Seite zwischen „vibe coding” und „spec-driven” — das ist eine falsche Dichotomie.
- Nicht wie vibe coding: nichts durchdenken, das Gehirn einfach an die KI delegieren.
- Auch nicht wie schwere Spezifikationen: die Dokumentenlast, die das KI-Zeitalter gerade von dir genommen hat, wieder auf die Schultern nehmen.
- Den mittleren Weg gehen: Klar sagen, was du willst (das kannst du bereits), einen High-Fidelity-Prototypen für dich sprechen lassen (die KI hilft dir dabei), in kleinen Schritten vorankommen, das Sicherheitsnetz halten.
Das ist kein weiteres Framework, das du lernen musst — es gibt schon genug davon. Es ist eine Rückkehr zur einfachsten Bewegung, die ein Product Manager macht: Herausfinden, was gebraucht wird, es klar artikulieren, und es dann zum Laufen bringen.
言出，法随。
Diskussion