Prompt Driven Development (PDD)

Die Szene

Du sitzt da. Kaffee. Tabs. Eine Timeline voller „AI will replace developers“.
Du gibst einen Prompt ein. Das Modell liefert Code. Der Code sieht gut aus.
Und genau deshalb ist es gefährlich.

Denn LLMs sind höflich. Sie widersprechen selten. Sie liefern. Sie füllen Lücken.
Und Lücken sind im Projektmanagement nicht romantisch. Lücken sind Budget.

 „Du wolltest eine Lösung. Du hast eine Antwort bekommen. Das ist nicht dasselbe.“

Was PDD ist (und was nicht)

Prompt Driven Development (PDD) behandelt Prompts als prüfbare Spezifikationen.
Nicht als Wunschzettel. Nicht als Chat. Sondern als Vertrag, der sich an der Realität messen lassen muss.

PDD ist nicht

• kein „Prompt Engineering“ (mehr Worte, bessere Magie)
• kein „LLM schreibt meinen Code“ (Delegation ohne Haftung)
• kein „Tests generieren lassen und hoffen“
• kein Workflow für Buzzword-Pitches

PDD ist

• Spezifikation zuerst – als Prompt
• Tests als Schiedsrichter (nicht als Deko)
• Iterationen am Prompt, bis er messbar ist
• Code erst dann, wenn „Done“ definierbar ist

Der Loop

Klassisch (und leider verbreitet): Prompt → Code → Fix → Noch mehr Fix → „Warum dauert das so lange?“

PDD dreht die Reihenfolge um:

1. Prompt (als Spezifikation)
2. Test (als Realitätssensor)
3. Prompt (Iteration: Präzision statt Poesie)
4. Code (Implementierung im Testkäfig)

Wenn du das System nicht messen kannst, steuerst du es nicht.
Du erzählst nur eine Geschichte über Kontrolle.

Die fünf Thesen (Manifest)

1) Prompts sind Artefakte

Ein Prompt ist kein Gespräch. Er ist ein Dokument. Versionierbar. Reviewbar. Kritikwürdig.
Wenn dein Prompt im Chat versickert, ist er im Projekt faktisch nicht existent.

2) Unklarheit ist der eigentliche Bug

Wenn etwas schief läuft, ist es selten „einfach ein Bug“. Oft ist es ein Nebelwort.
„Schnell.“ „Intuitiv.“ „Einfach.“ – diese Wörter sind wie Nebelgranaten, nur ohne Explosion, dafür mit Sprint-Meetings.

3) Tests prüfen den Prompt, nicht nur den Code

Scheitert ein Test, ist die erste Frage nicht: „Wer hat das kaputt gemacht?“
Sondern: „Was haben wir eigentlich wirklich verlangt?“

4) LLMs sind Co-Autoren, keine Orakel

Das Modell liefert Möglichkeiten. Du lieferst Verantwortung.
PDD ist die Methode, die diese Rollen trennt, statt sie romantisch zu vermischen.

5) Erst der Vertrag, dann die Implementierung

PDD ist eine Rückkehr zu etwas Altmodischem:
Definition of Done, die man ausführen kann.

 „Wenn mein Prompt nicht testbar ist, ist er keine Spezifikation.“

Die Praxis: Wie ein Prompt testbar wird

Ein testbarer Prompt benennt:

• Ziel (warum existiert das Feature?)
• Input/Output (welche Daten rein, welche raus?)
• Constraints (Performance, Security, Offline, KISS/YAGNI)
• Edge Cases (wie scheitert es korrekt?)
• Nicht-Ziele (was wird bewusst nicht gebaut?)
• Akzeptanzkriterien (messbar: was heißt „fertig“?)

Wenn du nur „mach mal“ schreibst, bekommst du „mach mal“-Qualität zurück.
Und dann diskutierst du drei Tage über Ergebnisse, statt zwei Stunden über Anforderungen.

Anti-Patterns (die du erkennen wirst)

• Der Roman-Prompt: zu lang, zu vage, zu viel Welt – und keine einzige harte Kante.
• Der Good-Vibes-Test: „soll sich gut anfühlen“ – schön, aber nicht ausführbar.
• Der Tool-Fetisch: neue Modelle, neue Plugins – aber keine Definition of Done.
• Der Halluzinations-Deal: „Wird schon stimmen“ – bis Production es anders sieht.

Warum das gerade jetzt zählt

Weil KI nicht nur den Code schneller macht.
Sie macht auch das Scheitern schneller – wenn wir weiterhin im Nebel spezifizieren.

PDD ist keine Religion. Es ist ein Geländer.
Und Geländer sind nicht sexy. Sie sind das, was dich davon abhält, nachts um 23:48 Uhr
eine „kleine Änderung“ in Production zu machen.

„Du willst Geschwindigkeit? Dann hör auf, in Unklarheit zu investieren.“