Prompt-gesteuerte Entwicklung: Der neue Software-Lebenszyklus erklärt

TL;DR: Prompt-gesteuerte Entwicklung (PDD) ist der Software-Lebenszyklus von 2026, der den traditionellen Zyklus 'Anforderungen → Design → Bau → Test → Deployment' für die Standard-80 % der Software ersetzt hat. Statt dieser diskreten Phasen komprimiert PDD alles in eine kontinuierliche Schleife strukturierter Prompts. Die PRD ist der grundlegende Prompt. Features sind geschichtete Prompts. Bugs werden in Prompts beschrieben. Refactors sind Prompts. Dieser Guide erklärt den neuen Lebenszyklus, die fünf Phasen, die das alte Wasserfallmodell ersetzt haben, und die Disziplin, die Teams, die ausliefern, von Teams unterscheidet, die stecken bleiben.

Einleitung

40 Jahre lang folgte die Softwareentwicklung ungefähr demselben Lebenszyklus. Anforderungserhebung → Design → Bau → Test → Deployment → Betrieb. Die Namen änderten sich (Wasserfall, Agile, Scrum), aber die zugrunde liegende Form blieb ähnlich. 2026 hat sich diese Form spürbar verschoben. Für die Standard-80 % der Software, die AI-App-Builder gut abdecken, hat sich der Lebenszyklus zu etwas wirklich Neuem verdichtet: prompt-gesteuerte Entwicklung.

Dieser Guide erklärt den neuen Lebenszyklus. Nicht 'derselbe Lebenszyklus, nur mit etwas AI obendrauf' --- sondern die tatsächlich andere Form, die entsteht, wenn Prompts traditionelle Phasengrenzen ersetzen. Am Ende kennst du die fünf Phasen der prompt-gesteuerten Entwicklung, die Disziplin, die sie funktionieren lässt, und wie du sie auf deine eigenen Projekte anwendest. Die Namen klingen vertraut; die Rhythmen sind anders.

Was sich geändert hat und was nicht

Der traditionelle Lebenszyklus existiert, weil jede Phase ein Artefakt erzeugte, das die nächste Phase konsumierte. Anforderungsdokumente speisten Designer; Designs speisten Engineers; Engineers schrieben Code, den QA testete; Tests gaben das Deployment frei. Phasengrenzen waren natürlich, weil sie Übergabepunkte für Artefakte waren.

Prompt-gesteuerte Entwicklung löst diese Artefaktgrenzen auf. Die PRD ist ein Prompt. Der Prompt erzeugt funktionierenden Code, live deployt. Es gibt keine Design-Phase, die an Engineering übergibt; es gibt einen Prompt, der Design und Code gemeinsam erzeugt. Es gibt keine Test-Phase, die das Deployment freigibt; Verifikation ist in die Prompt-und-Vorschau-Schleife eingebettet.

Was sich nicht geändert hat: Disziplin zählt weiterhin. Dieselben Probleme, die traditionelle Projekte scheitern ließen (schlechte Anforderungen, Scope Creep, fehlendes Security-Review, Nutzer ignorieren), lassen auch PDD-Projekte scheitern. Die Form ist neu; die zugrunde liegenden Prinzipien nicht. PDD macht dich schneller; es macht dich nicht klüger.

Die fünf Phasen der prompt-gesteuerten Entwicklung

Fünf Phasen ersetzen den traditionellen Wasserfall. Sie sind nicht strikt sequenziell --- in der Praxis wechselst du zwischen ihnen --- aber sie sind nützliche Rahmen, um zu verstehen, was in jeder Stufe passiert.

Phase 1: Spec

Spec ist dort, wo früher die Anforderungserhebung stand. Das Artefakt ist eine einseitige PRD, die zum grundlegenden Prompt für alles Folgende wird.

• Zielnutzer mit mehreren konkreten Kriterien, nicht Kategorien
• Problem, quantifiziert mit konkreten Zahlen
• Kernaktion, benannt mit Zeitrahmen
• Datenmodell mit typisierten Feldern
• Design-Vibe mit Referenzmarken und Hex-Farben
• Erfolgskriterien, gebunden an Wert, nicht an Features

Die PRD-als-Prompt ist das Artefakt mit dem größten Hebel im Lebenszyklus. Eine klare PRD erzeugt sauberen Output durch jede folgende Phase. Eine vage PRD erzeugt chaotische Iterationen. Verbringe 30--45 Minuten damit; spare hier nicht.

Phase 2: Scaffold

Scaffold ersetzt, was früher Design + initiale Implementierung war. Der Output ist eine funktionierende App mit Platzhalterinhalten --- echte Screens, echte Navigation, echte Datenbanktabellen, aber mit Seed-Daten statt echten Daten und ohne das Kernfeature verdrahtet.

• Erster Prompt erzeugt das visuelle Scaffold --- Screens, Navigation, angewendetes Designsystem
• Zweiter Prompt erzeugt das Datenmodell --- typisierte Felder, Beziehungen, Indizes
• Dritter Prompt seedet realistische Beispieldaten, damit sich die App während der Entwicklung echt anfühlt
• Vierter Prompt fügt Authentifizierung und geschützte Routen hinzu

Am Ende des Scaffolds (typischerweise Tag 1--2 eines Builds) hast du etwas, das wie eine App aussieht und sich so anfühlt, auch wenn es noch nichts Nützliches tut. Die visuelle Form stimmt. Das Datenmodell stimmt. Der Auth-Flow funktioniert.

Phase 3: Layer

Layer ist die Phase, in der Features nacheinander hinzugefügt werden, in Abhängigkeitsreihenfolge. Das ist der Löwenanteil der Arbeit jedes Builds --- typischerweise 60--70 % der gesamten Prompt-Zahl.

Die Disziplin, die Layer definiert: ein Feature pro Prompt, in Abhängigkeitsreihenfolge. Auth vor Daten, Daten vor Features, Kernfeatures vor Feinschliff, Feinschliff vor Zahlungen. Das Kombinieren von Belangen in einzelnen Prompts erzeugt kaputten Output. Das ist der häufigste Fehler, den Builder bei PDD machen.

• Kernfeature 1 --- Gebaut in einem fokussierten Prompt mit expliziten Erfolgskriterien
• Kernfeature 2 --- Gleicher Ansatz; aufgebaut auf der bestehenden Grundlage
• Suche, Filterung, Sortierung --- Angrenzende Fähigkeiten für bestehende Daten
• Benachrichtigungen, transaktionale E-Mails --- Hintergrundfeatures, die Nutzer erwarten
• Admin-Kontrollen --- Verwalten, was Nutzer nicht können
• Zahlungen --- Stripe-Abos oder Einmalzahlungen

Jeder Layer-Prompt wird verifiziert, bevor es weitergeht. Den nächsten Prompt nicht ausführen, bevor der aktuelle Output stimmt. Vor Ort verfeinern statt auf kaputten Grundlagen weiterzubauen.

Phase 4: Harden

Harden ersetzt, was früher QA + Security-Review war. Der Output ist eine produktionsreife App. Die Arbeit umfasst Security, Performance, mobile Responsivität, Fehlerbehandlung und operative Instrumentierung.

• Security-Audit-Prompt --- Bestätigen, dass RLS auf jeder Query aktiv ist, keine sensiblen Daten in URLs stehen, Datei-Uploads validiert und teure Operationen rate-limitiert sind
• Prompt für mobile Responsivität --- Jeder Screen funktioniert bei 375px Viewport, Tap-Targets mindestens 44px
• Prompt für Empty States --- Freundliche Illustrationen und CTAs für jede Liste, die leer sein könnte
• Prompt für Fehlerbehandlung --- Freundliche nutzerseitige Meldungen, strukturiertes Logging, Recovery-Pfade
• Prompt für Analytics-Events --- Event-Tracking bei Signup, Kernaktionen, Conversion-Punkten
• Performance-Prompt --- Häufige Queries haben Indizes; teure Operationen sind gecacht

Das Härten wird von enthusiastischen Buildern oft übersprungen. Nicht tun. Die Harden-Phase ist es, die Apps, die echte Nutzer bewältigen, von Apps unterscheidet, die am ersten Tag zusammenbrechen.

Phase 5: Iterate

Iterate ersetzt, was früher 'Wartung' + neue Feature-Releases war. Nach dem Launch ist die Arbeit kontinuierlich: Kundengespräche erzeugen Erkenntnisse; Erkenntnisse erzeugen Prompts; Prompts erzeugen Updates; Updates erzeugen mehr Gespräche.

• Kundengespräche wöchentlich --- Mindestens 5 pro Woche, idealerweise live
• Eine konkrete Änderung pro Woche --- testen; messen; lernen
• Bugfixes über Prompts --- das falsche Verhalten beschreiben; die AI behebt es
• Feature-Wünsche über Prompts --- die meisten nutzergewünschten Features landen in <1 Tag fokussierter Arbeit
• Distributionsarbeit kontinuierlich --- Iterate bedeutet nicht nur, das Produkt zu ändern

Iterate ist die Phase, in der die meisten Projekte scheitern. Der Bau war der leichte Teil; Product-Market-Fit und Distribution zu finden sind die schwierigen Teile.

Wie PDD den traditionellen Lebenszyklus komprimiert

Die Gesamtkompression für Standard-SaaS-Apps liegt bei etwa dem 6--10-Fachen. Nicht jedes Projekt komprimiert gleichmäßig --- komplexe verteilte Systeme, regulierte Branchen und performancekritische Arbeit profitieren weiterhin von traditionellen Zyklen. Für die meisten SaaS-Produkte ist die Kompression real und von Dauer.

Was wirklich neu ist und was traditionelle Konzepte nur umbenennt

Umbenannte traditionelle Konzepte

• PRD-als-Prompt --- Dasselbe Artefakt wie eine traditionelle PRD, aber jetzt der tatsächliche Prompt statt der Input für einen separaten Prozess
• Schema-Design --- Dieselbe Datenbankschema-Arbeit; jetzt in Prompts statt SQL-Migrationen ausgedrückt
• Feature-Toggles --- Dasselbe Konzept, ausgedrückt in Prompts statt Konfigurationsdateien
• Code-Review --- Jetzt Review von AI-generiertem statt menschgeneriertem Code; dieselben Prinzipien gelten

Wirklich Neues

• Prompt als primäres Artefakt --- Der Prompt ist die Quelle der Wahrheit, nicht der Code. Das ist eine bedeutende Verschiebung.
• Ein-Feature-pro-Prompt-Disziplin --- Die Disziplin, sich zu weigern, Belange zu kombinieren, ist neu und hochwirksam.
• Prompt-Bibliotheken --- Gespeicherte Prompts kumulieren über Projekte hinweg auf eine Weise, wie es Code-Snippets nicht taten.
• MCP-native Integration --- Die Verbindung zu externen Tools über das Model Context Protocol unterscheidet sich strukturell von individueller API-Integration.
• AI-native Verifikation --- Das Verifizieren von AI-Output ist eine neue Fähigkeit, verschieden von traditioneller QA.

Die Disziplin, die Shipper von Stallern unterscheidet

Die Geschwindigkeit von PDD ist real. Aber Geschwindigkeit ohne Disziplin erzeugt schnell kaputte Software.

Disziplin 1: Knappe grundlegende PRDs

Vage PRDs erzeugen chaotischen Output über jede folgende Phase. Konkrete PRDs --- enger Zielnutzer, quantifiziertes Problem, typisierte Datenfelder, Referenzdesign --- erzeugen sauberen Output für den gesamten Build.

Disziplin 2: Ein Feature pro Prompt

Mega-Prompts fühlen sich produktiv an, erzeugen aber kaputten Output. Geschichtete Prompts in Abhängigkeitsreihenfolge sind pro Prompt langsamer und pro Gesamtprojekt deutlich schneller. Das ist der häufigste Unterschied zwischen schnellen und langsamen Vibe Codern.

Disziplin 3: Vor dem Weitermachen verifizieren

Den nächsten Prompt nicht ausführen, bevor der aktuelle Output stimmt. Vor Ort verfeinern. Auf kaputten Grundlagen weiterzubauen ist der Grund, warum PDD-Projekte Apps produzieren, die fertig aussehen, aber nicht funktionieren.

Disziplin 4: Speichern, was funktioniert

Jeder Prompt, der sauberen Output erzeugt, wird zu einer wiederverwendbaren Vorlage. Die meisten erfahrenen PDD-Praktiker sammeln über Projekte hinweg 50--100 wiederverwendbare Prompts. Die Bibliothek kumuliert deutlich, weil die Struktur erhalten bleibt, auch wenn sich die Details ändern.

Disziplin 5: Die Harden-Phase immer einschließen

Security-Audits, mobile Responsivität und Fehlerbehandlung zu überspringen ist die häufigste Ursache für Ausfälle nach dem Launch. Harden-Prompts als nicht verhandelbar in den Workflow einbauen.

Wie Rollen in PDD aussehen

Solo-Gründer

Die meiste PDD-Arbeit wird von Solo-Gründern oder 1-Personen-Teams geleistet. Die Kompression des Lebenszyklus ist es, die Solo-Ausführung überhaupt tragfähig macht. Eine Person übernimmt Spec, Scaffold, Layer, Harden und Iterate --- dieselbe Person, die im traditionellen Engineering ein 5-köpfiges Team geführt hätte.

Produktmanager

PMs bei Unternehmen, die PDD nutzen, liefern zunehmend selbst Validierungsprototypen, statt auf Engineering zu warten. Die PRD-Schreibfähigkeit von PMs überträgt sich direkt auf gutes Prompting.

Designer

Designer bringen Live-Produkte direkt aus Figma ohne Engineering-Übergabe für v1 an den Start. Die Übergabe kommt später zurück (Engineering für Härtung, Skalierung, komplexe Integrationen), aber der initiale Build gehört Designern mehr denn je.

Engineers

Engineering bei stark PDD-orientierten Unternehmen verschiebt sich hin zu Urteilsarbeit --- Systemdesign, Security, Performance, Skalierung, komplexe Integrationen. Boilerplate-lastige Engineering-Arbeit komprimiert dramatisch.

Wo PDD (noch) nicht passt

Eine ehrliche Betrachtung muss auch benennen, wo PDD traditionelle Lebenszyklen noch nicht ersetzt.

• Komplexe verteilte Systeme --- Mehrere Services mit Konsistenzanforderungen brauchen Engineering-Design
• Regulierte Branchen --- Compliance-Arbeit hat Audit-Trail-Anforderungen, die PDD noch nicht nativ abdeckt
• Performance-kritische Systeme --- Feintuning am Rand erfordert menschliches Urteilsvermögen, das AI nicht gut nachbildet
• Neuartige Algorithmus-Arbeit --- PDD ist Musteranwendung; neuartige Algorithmen brauchen Menschen
• Massive Skalierung --- Systeme, die Millionen gleichzeitiger Nutzer bedienen, brauchen maßgeschneiderte Architektur
• Ausgereifte Codebasen mit komplexer Historie --- Features zu einer 10 Jahre alten Codebasis per PDD hinzuzufügen ist schwerer als frisch zu bauen

Für diese Fälle ergänzt PDD traditionelles Engineering, statt es zu ersetzen. Das Hybridmuster --- PDD für die Standard-80 %, traditionelles Engineering für die schwierigeren 20 % --- ist bei ernsthaften Produkten zunehmend verbreitet.

Häufige Fehler, die PDD-Projekte scheitern lassen

• Die Spec-Phase überspringen --- Anfänger, die ohne knappe PRD direkt zum Scaffold springen, brauchen regelmäßig 2--3× länger für die Iteration
• Mega-Prompts --- Der Versuch, alles in einem Prompt zu bauen, erzeugt kaputten Output. Ein Feature pro Prompt, in Abhängigkeitsreihenfolge.
• Die Harden-Phase überspringen --- Ohne Security-Audit, mobiles Testen oder ordentliche Fehlerbehandlung zu launchen ist der häufigste Grund für Ausfälle nach dem Launch
• PDD als Magie behandeln --- PDD macht dich schneller; es ersetzt keine Kundengespräche, Distributionsarbeit oder Produkturteil
• Geschwindigkeit mit Fortschritt verwechseln --- Neue Features auszuliefern fühlt sich produktiv an. Die Aufgabe ist zu lernen, was ausgeliefert werden soll; PDD macht nur das Ausliefern selbst schneller.
• Prompts nicht speichern --- Jeder Prompt, der funktioniert, ist eine Vorlage für das nächste Projekt. Die Bibliothek bewusst aufbauen.
• PDD in nicht passende Projekte zwingen --- Komplexe verteilte Systeme, regulierte Arbeit und neuartige Algorithmen brauchen weiterhin traditionelles Engineering.

Häufig gestellte Fragen

Q1: Ist PDD nur ein Buzzword oder eine echte Methodik? Echte Methodik, in dem Sinne, dass die Kompression des Lebenszyklus real und von Dauer ist. Der Name ist neu und wird sich wahrscheinlich weiterentwickeln; die zugrunde liegende Verschiebung ist strukturell.

Q2: Können Teams wirklich in 7--14 Tagen mit PDD ausliefern? Für Standard-SaaS-MVPs, ja. Mehrere Solo-Gründer und kleine Teams haben in diesem Zeitrahmen echte Unternehmen ausgeliefert. Der Bau komprimiert dramatisch; der Rest (Distribution, Kundengespräche) bleibt ungefähr gleich.

Q3: Wie geht PDD mit Code-Review um? Genauso wie traditionelles Engineering, nur dass das reviewte Artefakt AI-generierter statt menschgenerierter Code ist. Dieselben Prinzipien gelten --- funktioniert es, ist es sicher, liegt die Abstraktion auf der richtigen Ebene.

Q4: Was, wenn mein Team überwiegend aus Engineers besteht? PDD gilt trotzdem, aber die Rollenverteilung verschiebt sich. Engineers, die PDD nutzen, liefern mehr Features pro Woche als Engineers, die traditionell Code schreiben. Die Lebenszyklusphasen sind dieselben; wer welche übernimmt, unterscheidet sich.

Q5: Funktioniert PDD für Enterprise-Software? Für die Standard-80 % von Enterprise-SaaS (CRMs, Dashboards, vertikale Tools), ja. Für wirklich enterprise-taugliche Systeme (komplexe Integrationen, regulierte Branchen, massive Skalierung) funktioniert das Hybridmuster besser als reines PDD.

Q6: Ist PDD sicher? Das kann es sein, mit Disziplin. Die Harden-Phase zu überspringen erzeugt unsichere Apps. Sie einzuschließen erzeugt Apps, die das Security-Review bestehen. Die Methodik erzwingt Security nicht; die Disziplin innerhalb der Methodik tut das.

Q7: Wird PDD traditionelles Engineering vollständig ersetzen? Nicht kurzfristig. Die Standard-80 % der Software bewegen sich zu PDD; die schwierigeren 20 % bleiben traditionelles Engineering. Beide sind real; beide werden 2030 noch existieren. Die Grenze zwischen ihnen verschiebt sich weiter, während sich AI-Fähigkeiten verbessern.

Fazit

• Prompt-gesteuerte Entwicklung ist der Software-Lebenszyklus von 2026, der den traditionellen Zyklus 'Anforderungen → Design → Bau → Test → Deployment' für die Standard-80 % der Software ersetzt hat.
• Fünf Phasen --- Spec, Scaffold, Layer, Harden, Iterate --- ersetzen den traditionellen Wasserfall. Die Kompression von 8--20 Wochen auf 7--14 Tage ist real und von Dauer.
• Die Disziplin, die ausliefert: knappe grundlegende PRDs, ein Feature pro Prompt, vor dem Weitermachen verifizieren, speichern, was funktioniert, immer die Harden-Phase einschließen.
• PDD ersetzt keine Kundengespräche, Distribution oder Produkturteil. Es macht dich schneller im Ausliefern; es macht dich nicht klüger darin, was du ausliefern solltest.

Wähle das Projekt, das du aufgeschoben hast. Schreibe dieses Wochenende die einseitige PRD. Durchlaufe die fünf PDD-Phasen. Bis nächste Woche hast du eine funktionierende App live und den Anfang einer persönlichen Prompt-Bibliothek, die sich über jedes zukünftige Projekt kumuliert. Die Messlatte fürs Ausliefern hat sich verschoben. Die Disziplin, sie gut zu nutzen, ist, was übrig bleibt.