Doom Scrolling PDD

Eigentlich wollte ich gestern die dritte Staffel The Night Agent auf Netflix binge-watchen.

Ein letzter Griff zum Telefon.

Irgendwo zwischen S3 E2 und S3 E3 wurde mir klar:
Ich sehe gar nicht hin.

Ich war in Posts, Threads und Artikeln verschwunden.

Prompt Driven Development.
PDD hier, PDD da.

Weniger Netflix, mehr Meinung.
Mehr Deutung.
Mehr Projektion.

Zwischen zwei Absätzen begriff ich:
Ich setze den Begriff „Prompt“ viel zu sehr ins Zentrum.

Dabei weiß ich es besser:

PDD ist kein Prompt Engineering.
Prompts sind nur das Interface – nicht das System.

Prompt Driven Development ist Architektur-Arbeit mit neuen Mitteln.

Es braucht Kontext.
Es braucht Rollenverteilung.
Es braucht die harte Disziplin von Iteration und Review.

Der „perfekte Prompt“ ist eine gefährliche Illusion.

Sie entsteht oft dort, wo solide Architektur fehlt –
oder wo man hofft, Design-Entscheidungen durch geschickte Formulierungen ersetzen zu können.

Ich werde wohl noch Zeit brauchen, bis das neue Vokabular aus dem flüchtigen Speicher
in mein echtes Gedächtnis wandert.

Bis aus Experiment und Hype-Coding wieder das wird, was es immer war:

Handwerk.
Einfach nur: Coding.

— Eine Randnotiz aus dem Zwischenraum zwischen zwei Tabs.

Ich hab ChatGPT gefragt – und der hat gesagt, ich soll das so machen

Eine kleine Bestandsaufnahme zwischen Vibe-Coding, VIPe, Wipe-Coding und Prompt-Engineering

Es gibt Tage, da fühlt sich die Tech-Szene an wie ein schlecht kuratiertes Buzzword-Bingo.
Kaum scrollt man einmal zu weit, stolpert man über Begriffe wie:

Vibe-Coding
VIPe
Wipe-Coding
Prompt-Engineering
Prompten
„Ich hab ChatGPT gefragt“

Alle meinen irgendwie dasselbe.
Und doch meint jeder etwas anderes.

Zeit, das einmal sauber auseinanderzunehmen – nicht um Begriffe zu verteidigen, sondern um zu verstehen, was wir da eigentlich gerade tun.

Vibe-Coding: Arbeiten nach Gefühl (und Algorithmus)

Fangen wir mit dem aktuell populärsten Begriff an.

Vibe-Coding beschreibt im Kern einen Zustand:

Man beschreibt, was man will
Die KI liefert irgendetwas
Man iteriert, solange es sich richtig anfühlt
Hauptsache, der Flow reißt nicht ab

Das ist kein Vorwurf.
Das ist ein Modus.

Vibe-Coding ist das, was passiert, wenn:

man experimentiert
man lernt
man spielt
man neugierig ist

Problematisch wird es erst, wenn aus diesem Zustand eine Methode gemacht wird.

Denn ein Vibe:

ist nicht dokumentiert
ist nicht reproduzierbar
ist nicht übertragbar
ist nicht überprüfbar

Vibe-Coding funktioniert hervorragend –
solange nur eine Person beteiligt ist und niemand Verantwortung übernehmen muss.

Prompten: Ich tippe, was mir einfällt

„Prompten“ ist die sprachliche Kurzform von:

Ich rede mit einer KI.

Mehr nicht.

Prompten kann alles sein:

ein Satz
ein Roman
eine halbe Idee
eine emotionale Eingebung
ein Copy-Paste aus StackOverflow
ein „mach mal besser“

Prompten ist keine Disziplin, sondern eine Tätigkeit.
So wie „Tippen“.

Niemand würde sagen:

„Ich habe ein neues Software-Paradigma: Tastatur-Coding.“

Aber bei KI sind wir erstaunlich großzügig.

Prompt-Engineering: Ordnung im Gespräch

Prompt-Engineering ist der Versuch, dem Ganzen Struktur zu geben:

Rollen definieren
Kontexte setzen
Formate vorgeben
Iterationen steuern
Ergebnisse vergleichen

Prompt-Engineering ist keine Magie.
Es ist Gesprächsarchitektur.

Und genau hier fängt die Verwirrung an:
Denn vieles, was heute als Vibe-Coding verkauft wird, ist schlicht unsauber ausgeführtes Prompt-Engineering – ohne es so zu nennen.

VIPe: Vibe-Inspired Prompt Engineering

VIPe taucht in diesem Kontext als Begriff auf, der versucht, zwei Welten zusammenzubringen:

den Vibe (Intuition, Gefühl, Vision)
das Engineering (Struktur, Prozess, Verantwortung)

VIPe sagt nicht:

„Vergiss den Vibe.“

Sondern:

„Nimm ihn ernst genug, um ihn zu formalisieren.“

Das bedeutet:

Der Vibe ist der Startpunkt
Nicht der Endzustand

VIPe ist kein neues Werkzeug.
Es ist ein Ordnungsversuch.

Ob man das braucht?
Kommt darauf an, was man baut – und mit wem.

Wipe-Coding: Wenn der Vibe alles wegwischt

Und dann gibt es noch Wipe-Coding.
Kein offizieller Begriff, aber jeder kennt es.

Wipe-Coding ist der Moment, wenn:

alles irgendwie funktioniert
niemand mehr weiß, warum
Änderungen alles kaputt machen
Entscheidungen nicht mehr erklärbar sind
man sagt: „Lass das lieber so, sonst geht’s wieder nicht“

Wipe-Coding ist das natürliche Endstadium von:

ungefiltertem Vibe-Coding
undokumentiertem Prompten
blindem Vertrauen in KI-Output

Es fühlt sich produktiv an –
bis es das nicht mehr tut.

„Ich hab ChatGPT gefragt und der hat gesagt …“

Dieser Satz ist das eigentliche Kernproblem.

Nicht, weil ChatGPT „falsch“ liegt.
Sondern weil er jede Verantwortung aus dem Satz entfernt.

Nicht ich habe entschieden.
Die KI hat gesagt.

Das ist kein Engineering.
Das ist Delegation ohne Rückversicherung.

KI kann Vorschläge machen.
Aber:

sie trägt keine Verantwortung
sie kennt keinen Kontext jenseits des Prompts
sie haftet nicht für Entscheidungen

Wer baut, bleibt verantwortlich.
Auch wenn der Prompt noch so gut war.

Also: Ist das nicht alles dasselbe in unterschiedlichen Kleidern?

Ja.
Und nein.

Alles bewegt sich im Spektrum von Prompt-Engineering.

Der Unterschied liegt nicht im Begriff, sondern im Reifegrad:

Vibe-Coding → Exploration
Prompten → Interaktion
Prompt-Engineering → Struktur
VIPe → Prozessbewusstsein
Wipe-Coding → Warnsignal

Die Begriffe sind nicht das Problem.
Das Problem ist, wenn man sie verwechselt.

Mein persönliches Zwischenfazit

Ich habe keine Lust auf Buzzword-Religionen.
Aber ich habe Lust auf Begriffe, die mir helfen, klarer zu denken.

Wenn VIPe mir hilft:

Vibes nicht zu verlieren
aber trotzdem Verantwortung zu übernehmen

dann nutze ich es.

Nicht, weil es neu klingt.
Sondern weil es mich zwingt, langsamer und sauberer zu arbeiten.

Und wenn sich am Ende herausstellt,
dass das alles nur Prompt-Engineering mit besserer Dokumentation war?

Dann wäre das kein Scheitern.
Sondern ein ziemlich ehrliches Ergebnis.

Ich habe ChatGPT gefragt.
Aber entscheiden musste ich trotzdem selbst.

Fortsetzung folgt.
Vielleicht.

VIPe – Vibe Inspired Prompt Engineering

VIPE‑Coding vs. VIPe – Warum Vibe‑Inspired Prompt Engineering mehr ist als nur ein Stil

Es gibt Momente in der Tech‑Welt, in denen zwei Begriffe fast gleich aussehen – aber völlig unterschiedliche Welten beschreiben. VIPE‑Coding und VIPe – Vibe‑Inspired Prompt Engineering gehören genau in diese Kategorie.

Beide klingen ähnlich. Beide wirken modern. Beide versprechen Effizienz. Doch nur einer davon ist ein Framework, das Webentwicklung, Kreativität und KI‑Architektur miteinander verschränkt: VIPe.

VIPE‑Coding: Der generische Begriff

VIPE‑Coding ist ein typischer Tech‑Begriff, wie er in vielen Projekten auftaucht: ein Akronym, das für Geschwindigkeit, Pragmatismus oder interne Prozesse stehen kann. Es ist nicht geschützt, nicht formalisiert und nicht an eine Methodik gebunden.

VIPE‑Coding ist damit ein Coding‑Stil, aber kein Engineering‑Framework.

Es beschreibt, wie man schreibt – nicht, wie man denkt.

VIPe – Vibe‑Inspired Prompt Engineering

Der Claim, der den Unterschied macht

VIPe ist kein Zufallswort. Es ist ein bewusst gesetzter Claim: Vibe‑Inspired Prompt Engineering – mit kleinem e, weil es nicht um Ego geht, sondern um Engineering.

VIPe ist ein formaler, dokumentierter Prozess, der kreative Visionen in reproduzierbare Prompt‑Architekturen übersetzt. Es ist die Brücke zwischen:

subjektiver Stimmung
objektiver Struktur
und technisch verwertbarem Output

Während VIPE‑Coding ein Stil ist, ist VIPe ein Framework.

Der VIPe‑Framework: Die vier Phasen

1. Vision – Der Vibe wird dekonstruiert

Der Prozess beginnt nicht mit Code, sondern mit Atmosphäre. Ein Vibe ist schwer greifbar – und genau deshalb wird er in VIPe systematisch zerlegt:

Referenzen
Farbpaletten
Typografie
Tonalität
Interaktionsmuster

Das Ergebnis: ein Vibe‑Sheet, das die kreative Intuition in technische Attribute übersetzt.

2. Interpretation – Die Prompt‑Strategie entsteht

Jetzt wird aus Gefühl Struktur.

Persona‑Definition
Prompt‑Techniken (Few‑Shot, CoT, Constraints)
Rollenverteilung (System/User)
Formatierung (JSON, Markdown, Hybrid)

Das Ergebnis: ein Prompt‑Design‑Dokument, das wie ein Architektengrundriss funktioniert.

3. Prompt – Die technische Generierung

Hier wird der Plan ausgeführt:

finaler Prompt
technische Vorgaben
Code‑Snippets
Ausführung im Zielsystem

Das Ergebnis: Output + Prompt‑Log – versioniert, nachvollziehbar, reproduzierbar.

4. Evaluation – Das Quality Gate

VIPe endet nicht beim Output. Es endet bei der Messbarkeit.

technische Korrektheit
Responsivität
Vibe‑Fidelity (Skala 1–10)
Abweichungen
Empfehlungen

Das Ergebnis: ein Evaluation‑Report, der die nächste Iteration vorbereitet.

VIPe ist damit nicht nur ein Begriff – es ist ein Standard, der Webentwicklung und KI‑Arbeit auf ein neues Level hebt.

Prompt Driven Development (PDD)

Ein Manifest gegen das bequeme Raten

Wir haben TDD gelernt, weil Code lügt. Oder genauer: Code erzählt alles, was du ihm erlaubst.
Jetzt haben wir LLMs – und die erzählen dir sogar dann noch eine runde Geschichte, wenn die Prämisse schon schief hängt.
Zeit für einen kleinen Prozess-Hack, der sich nicht wie ein Hack anfühlt.

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:

Prompt (als Spezifikation)
Test (als Realitätssensor)
Prompt (Iteration: Präzision statt Poesie)
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.“