Jenseits von Vibe Coding

Warum das beste LLM allein den Durchbruch nicht bringt

Erinnert ihr euch noch an die Goldgräberstimmung vor 18 Monaten? Wir haben uns Nächte um die Ohren geschlagen, um den „perfekten Prompt“ zu finden. Wir haben Prompt Engineering betrieben, als wäre es Alchemie – ein bisschen „Step-by-step“, eine Prise „Du bist ein Senior-Experte“, und hoffen, dass das Gold unten rauskommt.

Dann kam das Vibe Coding: Einfach mal locker in den Editor quatschen, die KI machen lassen und schauen, ob der „Vibe“ stimmt. Andrej Karpathy, Mitbegründer von OpenAI, hatte diesen Begriff im Februar 2025 geprägt und damit eine Entwicklung auf den Punkt gebracht, die längst im Gange war: Der Entwickler gibt die Vision vor, die KI übernimmt die Implementierung. Das war spaßig, es war befreiend, aber seien wir ehrlich: Es war die handwerkliche Phase der KI-Revolution. Es war das digitale Äquivalent zum Malen nach Zahlen.

Die Ära der isolierten Werkzeuge ist vorbei

Wir müssen diese Werkzeuge – vom perfekten Prompt bis zum PDD – als das sehen, was sie waren: Lernphasen. Wir haben gelernt, mit der Maschine zu korrespondieren. Aber wer glaubt, dass die Reise damit endet, dass wir immer schlauere Prompts in immer größere Chatfenster tippen, der hat den Kern der Entwicklung noch nicht erfasst.

Die Zukunft der Softwareentwicklung entscheidet sich nicht an der Frage, ob du GPT-5, Claude 4 oder Llama nutzt. Das LLM ist austauschbar geworden – es ist der Motor, aber nicht das Auto.

Es zählt nicht das LLM allein, sondern das Gesamtsystem

Der entscheidende Punkt ist: Nicht das beste Modell entscheidet über den Erfolg, sondern das beste Gesamtsystem.

Das ist keine bloße Behauptung, sondern eine der am härtesten belegten Erkenntnisse der jüngeren KI-Forschung. Andrew Ng, einer der einflussreichsten Köpfe auf diesem Gebiet, hat in mehreren viel beachteten Vorträgen gezeigt, dass die Einbettung eines Modells in einen agentischen Workflow dessen Leistung weit stärker verbessert als der Wechsel auf ein nominell leistungsfähigeres Modell. In seinem HumanEval-Benchmark erreichte GPT-3.5 ohne agentische Unterstützung eine Korrektheit von 48,1%. GPT-4 kam im Zero-Shot-Verfahren auf 67,0%. Doch GPT-3.5, eingebettet in einen iterativen Agenten-Workflow, erzielte 95,1% – und übertraf damit das wesentlich modernere Modell um Längen. Ng selbst brachte es auf die Formel: Der Sprung von GPT-3.5 zu GPT-4 wird durch die Integration eines iterativen Agenten-Workflows in den Schatten gestellt.

Die Landschaft liefert die Bestätigung im großen Maßstab: Frameworks wie LangGraph, CrewAI und AutoGPT etablieren genau diese Architektur – Systeme, die Aufgaben autonom planen, iterieren, reflektieren und korrigieren. Es ist ein technologischer Shift, der den Fokus endgültig vom Modell auf das System verschiebt.

Wir bewegen uns weg von der isolierten Intelligenz hin zu einer symbiotischen Mensch-Maschine-Vereinigung. Es geht um ein hocheffizientes Trio:

Das Denken (Mensch): Wir liefern die Intention, die Architektur und das ethische sowie wirtschaftliche Framework. Wir sind die Strategen.

Das Ausführen (KI-Agenten): Die Maschine übernimmt die fehleranfällige Kleinarbeit, das Refactoring und die Boilerplate-Schlachten.

Das Toolset (Infrastruktur): Die nahtlose Integration in unsere IDEs, CI/CD-Pipelines und Monitoring-Tools.

Wenn diese drei Rädchen nicht perfekt ineinandergreifen, nützt dir auch das schlauste Modell der Welt nichts. Ein brillanter Motor in einem Auto ohne Räder bringt dich nicht von Bremen nach Hamburg.

Die schleichende Standardisierung der Modelle

Die Austauschbarkeit des Motors ist längst kein theoretisches Szenario mehr. In der LMSYS Chatbot Arena, dem derzeit wohl aussagekräftigsten Benchmark für Sprachmodelle, liegen die führenden Systeme dicht beieinander: Claude 3.5 Sonnet führt mit einem Elo-Wert von 1308, dicht gefolgt von GPT-4o (1302) und Gemini 1.5 Pro (1290). Die Abstände sind so gering, dass sie für die praktische Entwicklungsarbeit kaum noch eine Rolle spielen. Das Modell wird zur austauschbaren Ware – zur „Commodity“. Der Wert entsteht nicht mehr durch die Wahl des richtigen Anbieters, sondern durch die Intelligenz der Integration: durch Retrieval Augmented Generation, durch kontextsensitive Tool-Nutzung, durch durchdachte Systemarchitektur.

Die stille Weichenstellung: Wer baut dein System?

Genau dieses Gesamtsystem wird jetzt gebaut – die Frage ist nur: von wem?

Die großen KI-Anbieter arbeiten mit Hochdruck an einer Zukunft, in der Agenten, Skills und Deep Reasoning nahtlos miteinander verzahnt sind. GitHub Copilot Workspace etwa ist der Prototyp eines geschlossenen Ökosystems, in dem die KI die gesamte Pipeline kontrolliert – von der Idee über den Code bis zum Pull Request, alles in natürlicher Sprache. Code wird automatisch mit Tests versehen, durchläuft Iterationen und Validierungsschleifen, bevor ein Entwickler überhaupt einen Blick darauf wirft. Die IDE denkt mit, die Pipeline korrigiert, der Agent antizipiert. Das sind keine isolierten LLM-Features mehr – das ist ein durchdesigntes Ökosystem, das uns schrittweise an die Hand nimmt. Bequem, effizient, produktiv.

Und genau hier liegt die Gefahr: der schleichende Vendor Lock-in. Wir gewöhnen uns an eine nahtlose Erfahrung und geben dafür Stück für Stück die Kontrolle über unseren Stack ab. Aus der Symbiose wird Abhängigkeit. Die Frage, die sich jede und jeder stellen muss, lautet: Will ich Anwender in einem fremden System sein? Oder schaffe ich mein eigenes?

Die gute Nachricht: Noch sind nicht alle Wege verbaut. Die Entwicklung lokaler Modelle hat in den letzten Monaten eine Dynamik entfaltet, die selbst Optimisten überrascht hat. Modelle wie Llama 3 oder Mistral lassen sich mit Tools wie Ollama oder LM Studio auf handelsüblichen Laptops ausführen – und liefern Ergebnisse, die für viele professionelle Coding-Aufgaben völlig ausreichen. Ja, ein lokaler Tech-Stack verlangt heute noch ein Quäntchen mehr Geduld. Aber wer hätte vor zwei Jahren gedacht, dass leistungsfähige LLMs flüssig auf unseren Notebooks laufen? Ich gebe zu, ich war mir sicher, dass das kommt. Und wer heute beobachtet, wie schnell sich lokale Modelle, offene Orchestrierungs-Frameworks und community-getriebene Toolchains entwickeln, der spürt: Die Möglichkeiten sind nicht nur absehbar – sie sind zum Greifen nah.

Mein Denkanstoß für die kommende Zeit

Hör auf, dem nächsten „Wunder-Prompt“ hinterherzujagen. Fang an zu überlegen: Wie sieht mein persönlicher Tech-Stack der Symbiose aus? Wie integriere ich das Denken und das Ausführen so, dass ein stabiler Workflow entsteht, der auch dann noch steht, wenn das nächste Modell um die Ecke kommt? Und vor allem: Wem vertraue ich die Architektur meines Systems an – einem Anbieter oder mir selbst?

Butter bei die Fische: Die Technik der Vergangenheit war das „Was“. Die Zukunft ist das „Wie“ im großen Systemzusammenhang. Und die entscheidende Weiche für dieses „Wie“ stellen wir jetzt.

Quellen

  • Andrej Karpathy – Prägung und Popularisierung des Begriffs „Vibe Coding“ (2025, u. a. in Vorträgen und Social Media Beiträgen)
  • Andrew Ng – Vorträge und Veröffentlichungen zu „Agentic Workflows“ und der These, dass Systemdesign (Workflows, Iteration, Tooling) wichtiger ist als das einzelne Modell
  • LMSYS – Chatbot Arena Benchmark (Elo-Ranking von LLMs)
  • LangGraph – Framework zur Orchestrierung von zustandsbasierten Agenten-Workflows
  • CrewAI – Framework für kollaborierende KI-Agenten
  • AutoGPT – Frühes Open-Source-Projekt für autonome KI-Agenten
  • GitHub Copilot Workspace – Konzept eines integrierten, KI-gestützten Entwicklungs-Workflows
  • Llama 3 – Open-Source-Sprachmodell von Meta
  • Mistral – Europäische KI-Modelle, optimiert für lokale Ausführung
  • Ollama – Tool zum lokalen Ausführen von Sprachmodellen
  • LM Studio – Desktop-Anwendung für lokale LLMs
  • Eigener Artikel: „Prompt Driven Development (PDD) – Ein Manifest gegen das bequeme Raten“ – Blog von Benjamin Lam

Jenseits der Nostalgie:

Was der „Vibe Coding“-Stresstest über die reale KI-Entwicklung 2026 verrät

Wenn KI-Assistenz kein reines Werkzeug-Upgrade ist, sondern ein Stresstest für unsere Arbeitsweise, dann zeigt sich im „Vibe Coding“ nicht primär eine neue Schwäche – sondern die Skalierung eines altbekannten Problems. Und zum ersten Mal auch Ansätze, damit umzugehen.Wir leben in einer Ära beschleunigter Entwicklung.Auf Entwickler-Events herrscht Aufbruchstimmung: Anwendungen entstehen in Minuten, und „Vibe Coding“ – das iterative Generieren nach Gefühl – wird als Produktivitätssprung gefeiert.Und ja: Die Werkzeuge sind beeindruckend.Ein Formular, das früher einen halben Tag gebraucht hat, steht nach zwei Prompts. Eine API-Anbindung funktioniert plötzlich auf Anhieb.Das ist kein Problem. Das ist messbarer Fortschritt.

Der Stresstest beginnt später.


Die Szene ist bekannt:

Ein Entwickler erhält Code von der KI. Er ist syntaktisch sauber, benannt, strukturiert.

Ein kurzer Blick. Die Unit-Tests – ebenfalls generiert – laufen grün.

Der Entwickler geht zum nächsten Task über.

Nicht aus Faulheit. Sondern weil das Risiko-Ertrags-Verhältnis diesen Schritt rational erscheinen lässt.


Wenig später taucht ein Bug auf. Eine Inkonsistenz zwischen zwei generierten Komponenten.

Früher war der Weg klar: Stack Trace lesen, Breakpoint setzen, verstehen.

Heute gibt es einen zweiten Weg. Einen schnelleren:

„Behandle diesen Edge Case explizit und robust.“

Die KI liefert eine neue Version, inklusive angepasster Tests. Der Bug ist weg.

Das System läuft.

Der Stresstest ist noch offen.


Ein kurzes, reales Szenario:

Du änderst einen Prompt von „formatiere Datum als DD.MM.YYYY“ zu „als YYYY-MM-DD“. Die KI passt die Funktion an. Ein Test prüft das Format – grün.

Was der Test nicht prüft: Eine Vergleichslogik im Reporting-Modul erwartet das alte Format per Regex.

Alles grün. Drei Tage später ruft der Kunde an.

Das ist kein Einzelfall. Das ist der Stresstest im Kleinen.


Die Nostalgie-Falle: War früher wirklich alles stabiler?

Hier setzt ein vertrautes Gefühl ein:

„Früher musste man es verstehen, um es zum Laufen zu bringen.“

Das ist nachvollziehbar. Aber nur die halbe Wahrheit.

Denn das, was wir heute sehen, ist kein neues Problem.

Unverstandene Drittanbieter-Bibliotheken. Copy-Paste aus Stack Overflow ohne Kontext. Legacy-Systeme, deren ursprüngliche Architekt:innen längst nicht mehr im Team sind.

Das alles gab es vorher.


Die Probleme, die „Vibe Coding“ sichtbar macht, sind keine neuen Probleme.

Sie sind alte Probleme. Nur dass sie jetzt durch die Geschwindigkeit der KI gnadenlos skaliert werden.


Was sich verändert hat, ist nicht die Art der Probleme – sondern ihre Frequenz.

Mehr Code entsteht schneller. Und wird schneller wieder verworfen.

Die Code-Churn-Rate steigt. Duplikation nimmt zu. Refactoring nimmt ab.

Nicht dramatisch im Einzelfall – aber signifikant im System.


Der Unterschied ist damit weniger qualitativ als quantitativ.

KI bringt uns nicht in unbekanntes Terrain. Sie beschleunigt, wie oft wir durch bekanntes Terrain laufen – inklusive aller Schwächen.


AI-Legacy: Ein reales, aber adressierbares Phänomen

Was dabei entsteht, ist keine klassische technische Schuld.

Sondern etwas Diffuseres:

AI-Legacy.

Funktionierender Code, der sich schwer greifen lässt. Und niemandem wirklich „gehört“.


Die typische Situation:

Du änderst etwas Kleines – und etwas Großes bricht.

Nicht, weil der Code schlecht ist. Sondern weil das mentale Modell der Abhängigkeiten nicht mitgewachsen ist.


Das ist der eigentliche Stresstest.

Nicht der Code. Das Verständnis.


Und hier liegt die unangenehme Wahrheit:

Das Problem ist nicht, dass die KI unsicher arbeitet. Das Problem ist, dass sie uns sicher in die Irre führen kann.

Mit grünem Licht. Mit sauberem Code. Und trotzdem falschen Annahmen.


2026 ist nicht das Jahr, in dem die Branche das ignoriert. Es ist das Jahr, in dem sie beginnt, darauf zu reagieren.


Was sich gerade verschiebt

1. Tests entstehen nicht mehr nachgelagert

Moderne Umgebungen generieren Implementierung und Tests parallel.

Das „grüne Licht“ ist nicht mehr nur ein Indikator, sondern Teil des generierten Systems.

Vertrauen verschiebt sich – von der einzelnen Codezeile hin zur Testabdeckung.


2. Verständnis wird rekonstruierbar

Mit RAG über das Repository lässt sich fragen:

„Warum existiert diese Funktion – und wer hängt davon ab?“

Das mentale Modell wird nicht mehr nur aufgebaut. Es kann bei Bedarf wiederhergestellt werden.


3. Abstraktion verschiebt sich weiter nach oben

Die meisten Entwickler verstehen heute keine Speicheradressen mehr. Und das ist kein Problem.

KI-Code ist die nächste Abstraktionsebene.

Der Stresstest liegt nicht mehr im Verstehen jeder Zeile – sondern im Verstehen von Schnittstellen, Verträgen und Tests.


Die eigentliche Verschiebung: Vom Debuggen zum Verifizieren

Die KI erzeugt nicht nur Code. Sie verschiebt Verantwortung.

Weg von: „Habe ich jede Zeile verstanden?“ Hin zu: „Habe ich die richtigen Rahmenbedingungen gesetzt – und die Ergebnisse ausreichend geprüft?“


Der entscheidende Moment ist nicht der Bug. Der entscheidende Moment ist das „funktioniert“.


Ein kurzer Check:

Würde ich den generierten Test verstehen, wenn er fehlschlägt?


Wenn die Antwort „Nein“ lautet, liegt dort der Engpass. Nicht im Code. Sondern im Modell dahinter.


Fazit: Bestanden – oder nur schneller geworden?

Der Stresstest 2026 zeigt kein klares Scheitern. Aber auch keinen vollständigen Erfolg.


Wir sind schneller geworden. Und wir sehen klarer, wo wir vorher schon unsauber gearbeitet haben.


Die Illusion der Kompetenz ist kein KI-Problem. Sie ist ein altes Muster – das durch KI schwerer zu übersehen wird.


Früher konnten wir uns länger darin bewegen. Heute bricht sie schneller auf.


Die eigentliche Antwort ist kurz – und sie tut weh:

Grüne Tests bedeuten nicht „richtig“.
Sie bedeuten nur, dass sich das System nicht widersprochen hat.

Und das reicht nicht.


Der Stresstest ist damit nicht bestanden. Aber er ist sichtbar geworden.


Wir sind schneller geworden. Und wir lernen gerade, ob wir in dieser Geschwindigkeit stabil sein können.


Die offene Frage ist nicht, ob KI uns besser macht.

Die offene Frage ist, ob wir bereit sind, Verantwortung auf einer neuen Ebene zu übernehmen.


Denn die Alternative ist leise:

Dass wir schneller werden. Komplexere Systeme bauen. Und den Unterschied zwischen „funktioniert“ und „verstanden“ verlieren.


Und genau dort entscheidet sich, ob das Fortschritt ist. Oder nur Beschleunigung.

Der nächste Programmier-Standard entsteht vor dem Code

Der nächste Programmier-Standard der Softwareentwicklung wird nicht mehr im Code definiert.

Er entsteht in der Leere davor.

Wir beobachten gerade eine Verschiebung der Zuständigkeit.

Lange Zeit war ein Repository vor allem ein Archiv für menschliche Logik: ein Ort, an dem Entwickler:innen ihre Gedanken in Syntax übersetzen.

Doch mit dem verstärkten Einsatz von KI beginnt sich diese Rolle zu verändern.

Ein Repository wird zunehmend zu einem Habitat für synthetische Intelligenz.

Die Kontrolle migriert.
Weg von der Syntax – hin zur kuratierten Umgebung, in der Systeme arbeiten.

Die alte Frage

Lange Zeit lautete die zentrale Frage der Softwareentwicklung:

Wer schreibt die effizienteste Schleife?

Oder allgemeiner:

Wer kann eine Idee am präzisesten in Code übersetzen?

Dieses Paradigma hat uns weit gebracht.

Aber mit KI verschiebt sich der Schwerpunkt.

Die neue Frage

Die entscheidende Frage könnte künftig eine andere sein:

Wer konstruiert den präzisesten Rahmen, in dem eine KI nicht halluziniert?

Denn moderne Entwicklungsprozesse bestehen immer häufiger aus einer Zusammenarbeit zwischen Menschen und Modellen.

In dieser Zusammenarbeit wird Code zunehmend zu einem Resultat, nicht mehr zum alleinigen Ursprung der Lösung.

Das bedeutet nicht, dass Programmieren unwichtig wird.

Aber der Engpass verschiebt sich.

Wir brauchen vielleicht nicht unbedingt bessere Coder.

Wir brauchen bessere Architekt:innen für Kontext.

Das Experiment: AARRS

Genau aus diesem Gedanken heraus beobachte ich ein kleines Versuchskonstrukt namens

AARRS – AI-Assistant-Ready Repository Specification

Zum Repository auf GitHub

AARRS ist kein Tool und kein Framework.

Es ist eher eine forensische Untersuchung einer einfachen Frage:

Wie muss ein Projekt strukturiert sein, damit eine KI nicht nur rät, sondern tatsächlich versteht?

Die Hypothese dahinter ist simpel:

KI ist nur so gut wie der Kontext, den sie bekommt.

Viele Repositories liefern diesen Kontext aber nur indirekt – verteilt über Code, Commit-Historie und implizites Wissen im Team.

Für Menschen ist das mühsam.
Für Maschinen ist es nahezu unsichtbar.

Was ein KI-lesbares Repository auszeichnet

Ein Repository, das für KI-Assistenz vorbereitet ist, könnte zum Beispiel:

  • klare Einstiegspunkte für nicht-menschliche Leser enthalten
  • explizite Constraints als Leitplanken gegen Entropie definieren
  • maschinenlesbaren Repo-Kontext bereitstellen
  • eine Art Gebrauchsanweisung für Algorithmen mitliefern

Nicht als Ersatz für Architektur.

Sondern als Erweiterung der Dokumentationsebene.

Der mögliche Wendepunkt

Vielleicht erleben wir gerade eine stille Veränderung der Softwareentwicklung.

Eine Verschiebung von

Code-Produktion
hin zu
Problem-Definition und Kontext-Architektur.

Die eigentliche Ausführung rückt zunehmend in den Hintergrund.

Nicht weil sie unwichtig wird.

Sondern weil Maschinen sie immer häufiger übernehmen können.

Ein Artefakt, kein Standard

AARRS ist aktuell nur ein MVP.

Ein Denkanstoß.

Ein Artefakt, das eine Frage sichtbar machen soll.

Vielleicht entsteht daraus irgendwann ein Muster.

Vielleicht auch nicht.

Aber die zugrunde liegende Frage wird bleiben:

Wie bereiten wir unsere Projekte auf die Zusammenarbeit mit KI-Assistenten vor?

Oder anders gefragt:

Wie muss ein Repository aussehen, damit nicht nur Menschen darin denken können – sondern auch Maschinen?

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.

Von der Intuition zur Methodik: Die Synthese etablierter Prompt-Engineering-Praktiken im PDD-Ansatz nach Benjamin Lam

Zusammenfassung

Der Ansatz der Prompt-Driven Development (PDD) nach Benjamin Lam stellt keinen Bruch mit bestehendem Wissen dar, sondern vielmehr eine systematische Formalisierung und Synthese etablierter Best Practices des Prompt Engineerings. Dieser Fachartikel analysiert die konzeptionellen Grundlagen von Lams PDD und ordnet sie in den breiteren Kontext des Feldes ein. Es wird argumentiert, dass der wesentliche Innovationsbeitrag nicht in der Erfindung atomarer Techniken, sondern in ihrer rigorosen Neukombination innerhalb eines testgetriebenen Softwareentwicklungs-Paradigmas liegt. Die Analyse zeigt, wie Prinzipien des iterativen Promptings, der evidenzbasierten Validierung und der Aufgabenzerlegung mit der disziplinierten Denkweise des Test-Driven Development (TDD) verschmolzen werden, um Prompt-Engineering von einer heuristischen Kunst zu einer ingenieurwissenschaftlichen Methodik zu erheben.

1. Einleitung: Die Suche nach Systematik im Prompt Engineering

Das Feld des Prompt Engineerings entwickelte sich zunächst als eine praktische, oft intuitive Antwort auf die Interaktion mit Large Language Models (LLMs). Während Techniken wie „Few-Shot Learning“ oder „Chain-of-Thought“ schnell an Popularität gewannen, blieb der Prozess ihrer Optimierung häufig unsystematisch und von Trial-and-Error geprägt. Vor diesem Hintergrund positioniert sich der PDD-Ansatz nach Benjamin Lam als Versuch, dieser Praxis eine methodische, wiederholbare und validierbare Struktur zu verleihen. Dieser Artikel dekonstruiert Lams Rahmenwerk und identifiziert seine Wurzeln in allgemein anerkannten Prinzipien des fortgeschrittenen Prompt Engineerings.

2. Konzeptuelle Dekonstruktion: Die Säulen von Lams PDD und ihre Vorläufer

Lams Ansatz lässt sich in mehrere Kernprinzipien zerlegen, die jeweils eine Entsprechung in der etablierten Theorie und Praxis des Feldes finden.

2.1 Iterative Prompt-Optimierung als strukturierter Zyklus
Lam betont einen dynamischen, feedbackbasierten Optimierungsprozess. Dies entspricht exakt dem etablierten Konzept des strukturierten iterativen Promptings, einem zyklischen Workflow aus Formulierung, Ausführung, Evaluation und gezielter Verfeinerung von Prompts. Diese Praxis ist grundlegend für die Bearbeitung komplexer oder mehrdeutiger Aufgaben, bei denen eine einzelne Prompt-Formulierung selten ausreicht.

2.2 Evidenzbasierte Validierung durch quantitative Metriken
Die Forderung nach systematischer Messung mittels Testdatensätzen und Metriken wie Genauigkeit oder Relevanz ist ein zentraler Grundsatz des professionellen Prompt Engineerings. Sie markiert den Übergang von subjektiver Einschätzung zu objektivierbarer, datengestützter Entscheidungsfindung. Frameworks zur automatisierten Prompt-Optimierung setzen diese Prämisse bereits operativ um.

2.3 Trennung von Aufgabenlogik und sprachlicher Formulierung
Die propagierte klare Trennung zwischen „Task“ und „Prompt“ reflektiert fortgeschrittene Prompting-Strategien. Die Chain-of-Thought (CoT)-Methode operationalisiert diese Trennung, indem sie den LLM explizit anweist, den Lösungsweg (die Logik) vor der finalen Antwort auszugeben. Ähnlich zielt Aufgabenzerlegung (Task Decomposition) darauf ab, eine komplexe Intention in eine Sequenz logisch verknüpfter, simplerer Sub-Prompts zu überführen, wodurch Logik und Implementierung entkoppelt werden.

2.4 Prompts als spezifizierende Artefakte
Die Behandlung von Prompts als präzise, versionierbare und testbare Spezifikationen gewinnt zunehmend an Bedeutung. Die Idee, Prompts als „First-Class Citizens“ innerhalb des Entwicklungslebenszyklus zu behandeln, wird in der Community diskutiert, um Wartbarkeit und Nachvollziehbarkeit zu erhöhen.

3. Die synthetische Innovation: Integration in das Test-Driven Development (TDD)-Paradigma

Hier liegt der eigentliche und originäre Beitrag von Lams PDD-Ansatz. Während die oben genannten Prinzipien einzeln bekannt sind, besteht seine Innovation in ihrer konsequenten Integration in den etablierten und disziplinierten Rahmen von Test-Driven Development.

· TDD-Zyklus für Prompts: Lam überträgt den klassischen Red-Green-Refactor-Zyklus des TDD. Ein „Test“ definiert hier das erwartete Ergebnis einer Aufgabenlogik. Der initiale „Prompt“ (entsprechend dem Code) wird so lange iterativ verfeinert („refactored“), bis er die Tests („grün“) erfüllt.
· Empirische Denkweise: Diese Integration erzwingt eine Präzision und empirische Strenge, die im ad-hoc Prompting oft fehlt. Die Prompt-Entwicklung wird dadurch zu einem gezielten, ergebnisorientierten Engineering-Prozess.
· Methodische Erhebung: Der Ansatz erhebt das Prompt-Engineering damit vom Status einer vorbereitenden oder begleitenden Tätigkeit zu einer kernmethodischen Aktivität innerhalb der Softwareentwicklung selbst.

4. Diskussion und Implikationen

Lams PDD-Ansatz ist ein Beleg für die fortschreitende Professionalisierung und Akademisierung des Prompt Engineerings. Er adressiert eine kritische Lücke, indem er eine Brücke zwischen der schnelllebigen, praxisorientierten Welt der KI-Interaktion und den methodisch fundierten, bewährten Prinzipien der Softwaretechnik schlägt.
Die Stärke des Ansatzes liegt in seiner Systematik und Übertragbarkeit, die es ermöglicht, Wissen über effektive Prompts zu kumulieren und in Teams weiterzugeben. Eine mögliche Limitation könnte der initial höhere methodische Overhead für einfache Aufgaben sein, der den pragmatischen Einsatz in allen Szenarien hinterfragt.

5. Fazit

Benjamin Lams Konzept von Prompt-Driven Development stellt keine Revolution, sondern eine evolutive Synthese dar. Sein Beitrag ist weniger die Erfindung neuer Techniken, sondern die konzeptionelle Rahmung und methodische Einbettung bestehender Best Practices des Prompt Engineerings in das disziplinierte Ökosystem des Test-Driven Development. Dadurch gelingt es ihm, einen wichtigen Schritt zu gehen: die Transformation des Prompt-Engineerings von einer heuristischen Kunst („Craft“) hin zu einer ingenieurwissenschaftlichen, lehr- und lernbaren Methodik. Dieser Ansatz bietet ein vielversprechendes Framework für den zuverlässigen und skalierbaren Einsatz von LLMs in kritischen Softwareentwicklungsprozessen.

Copilot hat mein Projekt gerettet, eine kurze Gutenachtgeschichte.

Ich bin froh, dass die Projekte, an denen ich aktuell arbeite, stabil laufen. Aber Erfahrung entsteht nicht nur aus funktionierenden Systemen, sondern vor allem aus denen, die nicht funktionieren.Als Gedankenexperiment habe ich mir deshalb ein bewusst chaotisches Projekt vorgestellt – eines, das viele Entwickler:innen, Projektmanager:innen und Teams in ähnlicher Form schon erlebt haben dürften.Ein Projekt mit:

  • vielen Tickets, aber wenig Orientierung
  • vielen Beteiligten, aber unklarer Verantwortung
  • vielen Meetings, aber kaum Entscheidungen

Ein Projekt, das niemand bewusst so gebaut hat – das aber genau so gewachsen ist.

Ich habe Copilot gefragt, wie er mit einem solchen Anti-Pattern-Projekt umgehen würde. Die folgende Antwort habe ich nicht als technische Anleitung gelesen, sondern als strukturierte Verdichtung von Erfahrung.


Wie man ein chaotisches Projekt rettet – ohne sich selbst zu verlieren

<Copilot-Anfang>

Ein Feldbericht aus der Realität, in der Best Practices nur auf Folien existieren

Es gibt Projekte, die riechen schon beim Betreten nach verbranntem Gummi.
Zu viele Tickets, zu wenig Klarheit.
Zu viele Meinungen, zu wenig Entscheidungen.
Zu viele Meetings, zu wenig Verantwortung.

Und dann wirst du hineingeschoben.
Mit dem freundlichen Satz:
„Kannst du das bitte retten?“

Willkommen im echten Leben.


1. Erst überleben, dann verbessern

Die wichtigste Erkenntnis:
Du rettest ein Projekt nicht, indem du sofort alles richtig machst.

Du rettest es, indem du Schaden begrenzt.

In chaotischen Projekten ist der erste Schritt immer derselbe:

Stabilisieren, nicht optimieren.

Das bedeutet:

  • keine neuen Features
  • keine neuen Tools
  • keine neuen Prozesse

Sondern eine einzige Frage:

Was brennt gerade wirklich?

Chaos ist laut.
Wahrheit ist leise.


2. Erwartungen sichtbar machen – brutal, ehrlich, sofort

In Projekten voller Anti-Pattern fehlt fast immer dasselbe:
eine gemeinsame Realität.

Alle glauben, sie reden über dasselbe.
Tun sie aber nicht.

Deshalb stelle ich eine Frage, die alles verändert:

„Woran würden wir erkennen, dass wir erfolgreich waren?“

Nicht: Was steht im Ticket.
Nicht: Was jemand „immer so macht“.
Nicht: Was „doch klar ist“.

Sondern: Was ist das erwartete Ergebnis?

Wenn niemand es sagen kann, ist das Problem nicht der Code.
Es ist die Führung.


3. Die kleinste funktionierende Wahrheit bauen

In chaotischen Projekten ist Komplexität der Feind.
Deshalb suche ich nach der kleinsten überprüfbaren Wahrheit.

Das ist kein MVP.
Das ist kein Prototyp.
Das ist ein Realitätsanker.

Ein Beispiel:

  • Nicht: „Checkout optimieren“
  • Sondern: „Unter Bedingung X soll Y passieren – und wir messen Z.“

Diese Mini-Wahrheit ist der erste Stein, auf dem man wieder stehen kann.


4. Tests als Diagnosewerkzeug, nicht als Ritual

In einem Anti-Pattern-Projekt kannst du nicht mit TDD anfangen.
Das wäre wie Yoga in einem brennenden Haus.

Aber du kannst Tests nutzen, um die Wahrheit sichtbar zu machen.

Ein Test ist eine Frage:
„Was genau soll passieren?“

Wenn niemand die Frage beantworten kann, ist das der eigentliche Bug.

Ich schreibe in solchen Projekten zuerst Charakterisierungstests:

  • Was tut das System jetzt?
  • Was sollte es tun?
  • Wo klaffen die Lücken?

Tests werden hier nicht zur Qualitätssicherung genutzt.
Sondern zur Realitätssicherung.


5. Verantwortung neu verteilen – aber richtig

In chaotischen Projekten ist Verantwortung oft ein Wanderpokal.
Jeder hält ihn kurz, bis er heiß wird, und wirft ihn weiter.

Ich drehe das um:

„Wer entscheidet das?“
„Wer trägt die Konsequenz?“
„Wer definiert ‚fertig‘?“

Nicht als Angriff.
Sondern als Struktur.

Verantwortung ist kein Schuldspiel.
Verantwortung ist ein Klärungswerkzeug.


6. Kommunikation entgiften

Chaotische Projekte haben toxische Kommunikationsmuster:

  • „Das war doch klar.“
  • „Das stand im Ticket.“
  • „Das haben wir immer so gemacht.“
  • „Das muss jetzt einfach schnell gehen.“

Ich ersetze das durch:

  • Explizite Erwartungen
  • Explizite Entscheidungen
  • Explizite Risiken

Nicht laut.
Nicht belehrend.
Sondern ruhig, präzise, unmissverständlich.

Chaos verliert gegen Klarheit.
Immer.


7. Kleine Siege sichtbar machen

Ein chaotisches Projekt wird nicht durch einen großen Wurf gerettet.
Sondern durch eine Serie kleiner, konsequenter Verbesserungen.

Ich mache diese sichtbar:

  • Was war vorher unklar?
  • Was ist jetzt klar?
  • Was wurde entschieden?
  • Was wurde verhindert?
  • Was wurde stabilisiert?

Das Team merkt plötzlich:
„Wir bewegen uns wieder.“

Und Bewegung ist der Anfang von Vertrauen.


8. Der stille Trick: Du rettest nicht das Projekt – du rettest die Entscheidungsfähigkeit

Am Ende ist die Wahrheit brutal einfach:

Projekte scheitern nicht an Code.
Sie scheitern an fehlenden Entscheidungen.

Wenn du es schaffst, dass Erwartungen klar werden,
Entscheidungen früher fallen,
und Realität wieder sichtbar wird,

dann rettest du nicht nur das Projekt.

Du rettest die Menschen darin.


Schlussgedanke

Wer in ein chaotisches Projekt geworfen wird,
braucht keine Heldentaten.

Er braucht Klarheit.
Mut zur Wahrheit.
Und die Fähigkeit, Erwartungen in überprüfbare Realität zu übersetzen.

Das ist keine Best Practice.
Das ist Überleben.

Und manchmal ist Überleben der erste Schritt zu Qualität.

</Copilot-Ende>


Fazit: Warum das alles richtig klingt – und in der Realität oft anders ist

Das alles klingt schlüssig.
Fast beruhigend.

Klarheit.
Entscheidungen.
Realitätsanker.
Verantwortung.

Als würde Chaos nur darauf warten, endlich richtig angesprochen zu werden.

Und ja – in der Theorie funktioniert das.
In vielen Situationen sogar erstaunlich gut.

Aber die Realität chaotischer Projekte ist komplizierter.

Nicht, weil die beschriebenen Ansätze falsch wären.
Sondern weil Projekte selten nur technische oder organisatorische Probleme sind.

Sie sind soziale Systeme.

Und soziale Systeme reagieren nicht linear auf Klarheit.

Chaos ist oft kein Zustand, sondern ein Schutzmechanismus

Viele chaotische Projekte sind nicht zufällig chaotisch.
Sie sind es geworden, weil Chaos lange Zeit funktioniert hat.

  • Unklare Tickets vermeiden Entscheidungen.
  • Viele Meetings verteilen Verantwortung.
  • Vage Ziele schützen vor Messbarkeit.

Chaos hält Dinge offen.
Und Offenheit fühlt sich sicher an, wenn niemand verlieren will.

Wer Klarheit schafft, greift in diese Schutzmechanismen ein.
Und das erzeugt Widerstand – nicht aus Bosheit, sondern aus Selbstschutz.

Entscheidungen sind selten technisch – sondern politisch

Die Idee, Entscheidungen „einfach sichtbar zu machen“, unterschätzt einen zentralen Punkt:

Entscheidungen haben Konsequenzen.
Und Konsequenzen haben immer eine Adresse.

In der Realität bedeutet Klarheit oft:

  • jemand liegt falsch
  • jemand verliert Einfluss
  • jemand wird sichtbar verantwortlich

Nicht jedes Projekt scheitert an fehlender Kompetenz.
Viele scheitern daran, dass niemand die Kosten einer Entscheidung tragen will.

Methoden können das nicht auflösen.
Nur Machtverhältnisse können das.

Nicht jedes Projekt will gerettet werden

Das ist unbequem, aber realistisch:

Nicht jedes Projekt will gerettet werden.

Manche Projekte existieren, weil:

  • Budgets gebunden werden müssen
  • Organisationen beschäftigt bleiben sollen
  • politische oder strategische Versprechen erfüllt werden müssen

In solchen Kontexten ist „Projekt retten“ nicht das Ziel.
Stabilität des Systems ist es.

Wer hier echte Klarheit schafft, wird schnell als Störfaktor wahrgenommen –
nicht als Retter.

Klarheit hat einen emotionalen Preis

Was in vielen Leitfäden fehlt, ist der Preis:

  • Klarheit kostet Energie.
  • Wahrheit kostet Beziehungskapital.
  • Entscheidungen kosten Schlaf.

Nicht jede Person kann oder will diesen Preis zahlen –
vor allem nicht dauerhaft.

Viele Anti-Pattern sind deshalb keine Dummheit.
Sondern Erschöpfung, die sich in Struktur verwandelt hat.

Schlussgedanke 2

Der Text beschreibt einen idealen Umgang mit Chaos.
Einen reifen, reflektierten, verantwortungsvollen.

Aber in der Realität braucht es dafür mehr als gute Methoden:

  • Rückendeckung
  • ein klares Mandat
  • psychologische Sicherheit
  • und manchmal schlicht Glück

Ohne das bleibt Klarheit ein Risiko.

Die eigentliche Frage ist deshalb nicht:
„Wie rette ich ein chaotisches Projekt?“

Sondern:

„In welchem System ist Rettung überhaupt erwünscht –
und was kostet sie mich persönlich?“

Manchmal ist der klügste Schritt nicht, Ordnung zu schaffen.
Sondern zu erkennen, wo Ordnung strukturell nicht vorgesehen ist.

Und auch das ist Erfahrung.

Lost in Translation?

Wie testgetriebene Entwicklung die Qualität wirklich verbessert

Über Erwartungen, Übersetzungsfehler und warum Code selten das eigentliche Problem ist

Es gibt viele Gründe, warum Software scheitert.
Zu wenig Zeit.
Zu wenig Budget.
Zu viele Anforderungen.

Aber erstaunlich selten scheitert sie am Code.


1. Das eigentliche Problem liegt davor

In den meisten Projekten, die ich gesehen habe, beginnt der Qualitätsverlust lange vor der ersten Codezeile.

Er beginnt im Anforderungsmanagement.

Nicht, weil Anforderungen falsch wären.
Sondern weil sie übersetzt werden müssen.

Von:

  • vagen Erwartungen
  • zu Tickets
  • zu Aufgaben
  • zu Code

Jede dieser Übersetzungen ist eine potenzielle Fehlerquelle.

Und je später ein Fehler auffällt,
desto teurer wird er.


2. Tickets sind keine Anforderungen

Ein Ticket ist kein Ziel.
Ein Ticket ist ein Behälter.

Darin liegen:

  • Annahmen
  • Hoffnungen
  • Halbsätze
  • implizites Wissen

„Button einbauen“
„Checkout optimieren“
„Performance verbessern“

Das klingt konkret.
Ist es aber nicht.

Was fehlt, ist fast immer die Antwort auf eine einfache Frage:

Woran erkennen wir, dass es richtig ist?


3. Erwartetes Ergebnis ist keine Selbstverständlichkeit

Viele Teams glauben, sie wüssten,
was ein „erwartetes Ergebnis“ ist.

Bis jemand fragt.

Dann kommen Sätze wie:

  • „Na, das sieht man doch.“
  • „So wie immer.“
  • „Das ist Standard.“

Tests beginnen genau hier.

Nicht beim Tool.
Nicht beim Framework.
Sondern beim Explizitmachen von Erwartungen.

Ein guter Test ist nichts anderes als eine präzise formulierte Erwartung:

Unter diesen Bedingungen soll genau das passieren – und nichts anderes.


4. Testgetriebene Entwicklung ist Übersetzungsarbeit

Testgetriebene Entwicklung wird oft missverstanden als:

  • Technikspielerei
  • Zusatzaufwand
  • Entwicklersache

In Wahrheit ist sie eine Übersetzungsschicht.

Sie übersetzt:

  • fachliche Erwartungen
  • in überprüfbare Aussagen

Bevor Code entsteht.

Der Code ist dann nur noch die Antwort auf eine bereits gestellte Frage.


5. Warum das die Qualität verbessert

Nicht, weil Tests Fehler finden.
Sondern weil sie Denkfehler sichtbar machen.

Wenn ein Test schwer zu formulieren ist,
ist meist nicht der Code kompliziert.

Sondern die Erwartung unklar.

Testgetriebene Entwicklung zwingt dazu,

  • Annahmen offenzulegen
  • Randfälle zu benennen
  • Verantwortung zu übernehmen

Nicht nur technisch, sondern fachlich.


6. Automatisierte Tests sind nur der letzte Schritt

Ob man am Ende mit Playwright, Cypress oder etwas anderem testet,
ist fast nebensächlich.

Wichtiger ist:

  • Was getestet wird
  • Warum es getestet wird
  • Wann entschieden wurde, dass etwas „fertig“ ist

Automatisierte Tests sind kein Ersatz für Denken.
Sie sind dessen Konservierung.


7. Gute Tests wollen getestet werden

Code, der getestet werden soll,
muss testbar sein.

Das führt fast automatisch zu:

  • klareren Schnittstellen
  • weniger Seiteneffekten
  • besserer Struktur

Nicht, weil es „Best Practice“ ist.
Sondern weil untestbarer Code oft auch unverständlicher Code ist.


8. Qualität ist kein Feature

Qualität entsteht nicht am Ende.
Nicht in der Abnahme.
Nicht im Bugfixing.

Sie entsteht dort,
wo Erwartungen präzise genug sind,
um geprüft zu werden.

Testgetriebene Entwicklung ist deshalb weniger eine Methode
als eine Haltung:

Wir versuchen, uns selbst nicht zu täuschen.


Schlussgedanke

Wer testgetrieben arbeitet,
schreibt nicht mehr Tests.

Er trifft früher Entscheidungen.

Und das ist meistens genau das,
was einem Projekt gefehlt hat.

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:

  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.“

Schlusssatz

Wenn dein Prompt nicht testbar ist, ist er keine Spezifikation.
Und wenn du keine Spezifikation hast, baust du nicht schneller – du baust nur früher ins Leere.

Wenn du das ausprobieren willst: Nimm ein Mini-Feature, schreib den Prompt wie einen Vertrag,
lass Tests entstehen, iteriere am Prompt, erst dann Code. Eine Runde. Dann nochmal. Und plötzlich fühlt sich
„KI-Entwicklung“ weniger wie Glückspiel an.