Ich habe das Vibe Coding beendet und eine echte App gebaut. Die Methode, die niemand lehrt.

Du hast eine KI gebeten, dir eine App zu bauen. Sie sieht gut aus und funktioniert. Fast. Sobald du ein Feature antippst, geht ein anderes kaputt.

Jedes Mal, wenn ein echter Nutzer sie ausprobiert, gibt es einen Bug. (Nein nein, klick nicht darauf.) Der Login schützt eigentlich nichts. Die Kunden von Nutzer A tauchen im Dashboard von Nutzer B auf. Die Zahlungsseite sammelt die Kreditkartendaten, aber speichert die Transaktion nie.

Dein Prozess ist kaputt. Der Code ist nur das Symptom.

Ich habe fünf Jahre lang ein Strohballenhaus mit meinen eigenen Händen gebaut. Die Parallele zur Softwareentwicklung (ich bin seit 30 Jahren in der IT) ist verblüffend: dieselbe Notwendigkeit für Abfolgen, dieselbe Notwendigkeit, jede Fachrichtung zu verstehen, ohne Spezialist zu werden. Das habe ich in eine Methode verwandelt, damit du deine App wie ein Profi entwickeln kannst.

Die Lücke, über die niemand spricht

Vibe Coding ist kaputt. Nicht die Tools. Nicht die KI. Die Art, wie Leute sie verwenden.

Jedes Tutorial zeigt dasselbe: Prompt eingeben, App bekommen, feiern. Und es funktioniert, für eine Demo. Ein Bildschirm mit Buttons, die richtig aussehen.

Dann brauchst du, dass die App echte Dinge tut. Mehrere Nutzer, die jeweils nur ihre eigenen Daten sehen. Zahlungen, die tatsächlich verarbeitet werden. Ein neues Feature, das nicht stillschweigend drei alte kaputt macht.

Die KI optimiert für "funktioniert gerade jetzt." Eine echte App braucht "funktioniert noch in sechs Monaten." Diese Lücke hat nichts mit Code-Qualität zu tun. Es geht darum zu wissen, was man fragen soll, in welcher Reihenfolge, und wie man überprüft, dass man es bekommen hat.

Die Blueprint-Methode

Acht Schritte. Derselbe Kreislauf für jedes Feature, von einer einfachen Kundenliste bis zur Stripe-Zahlungsintegration.

1. Globale Spezifikation. Was willst du, in einfachen Worten? "Ich will Kunden verwalten." Absichtlich vage. Gerade genug, um anzufangen.

2. Implikationen. Der Schritt, den die meisten überspringen, und der dich rettet. Frag die KI: "Was impliziert das technisch? Welche Tabellen, Seiten, Komponenten brauche ich?" Die KI packt deine Anfrage in eine Liste konkreter Dinge aus, die existieren müssen. Manche hast du erwartet. Andere (eine ID-Spalte, Zeitstempel, Validierungsregeln) hast du nicht bedacht. Jetzt siehst du das vollständige Bild, bevor du etwas baust.

3. Detaillierte Spezifikation. Werde spezifisch. Felder, Typen, Validierung, Fehlerbehandlung, was passiert, wenn etwas schief geht. Hier wird aus "bau mir eine Kundenliste" etwas Brauchbares.

4. Bauen. Gib der KI die detaillierte Spezifikation. Lass sie bauen.

5. Erklären. Frag die KI: "Erkläre, was du gerade gebaut hast und warum." Du liest nicht den Code. Aber du verstehst den Ablauf. Dieses Verständnis akkumuliert. Bei deinem zehnten Feature hast du ein reiches mentales Modell deiner gesamten App.

6. Verifizieren. Überprüf, dass es funktioniert. Nicht durch Code-Lesen. Durch Nutzen der App, Testen von Grenzfällen und Fragen an die KI "was könnte hier schief gehen?"

7. Was kann schief gehen. Jedes Feature hat spezifische Fallen. Auth? Die KI speichert Passwörter im Klartext. Zahlungen? Sie ignoriert Webhook-Fehler. Sicherheit? Zu permissive Richtlinien. Benenne die Fallen, damit du sie abfängst.

8. Nicht-Regression. Überprüf, dass alles von vorherigen Features noch funktioniert. Der häufigste Vibe-Coding-Fehler: etwas Neues hinzufügen, das stillschweigend drei alte Dinge kaputt macht.

Die Tiefe nimmt zu, während du vorangehst. Deine erste Spezifikation sind zwei Sätze. Wenn du bei Zahlungen ankommst, sind es zwei Seiten. Dieselbe Methode. Deine Fähigkeiten wachsen.

Ein konkretes Beispiel: Authentifizierung

Hier versagt Vibe Coding am spektakulärsten.

Vorher.

"Füg einen Login zu meiner App hinzu."

Die KI baut eine Seite mit E-Mail- und Passwort-Feldern, einem Button, einer Weiterleitung. Es sieht wie ein Login aus. Die UI ist in Ordnung. Aber Auth ist kein UI-Feature. Auth ist Infrastruktur. Die Login-Seite sind die sichtbaren 10%. Die anderen 90% sind Session-Management, Token-Validierung, Route-Schutz, Datenisolation. Die KI überspringt das alles, weil du nicht danach gefragt hast.

Du veröffentlichst es. Nutzer A loggt sich ein. Nutzer B loggt sich ein. Nutzer B sieht die Daten von Nutzer A.

Nachher.

Dasselbe Feature, mit der Methode.

Schritt 1 (globale Spezifikation): "Jeder Nutzer hat sein eigenes Konto. Sie loggen sich mit E-Mail und Passwort ein. Einmal eingeloggt, sehen sie nur ihre Daten."

Schritt 2 (Implikationen): du bittest die KI zu erklären, was das technisch bedeutet. Sie kommt zurück mit: Authentifizierung vs. Autorisierung (zwei verschiedene Dinge), Sessions, Token, Route-Schutz und Verknüpfung von Daten mit Nutzern (jede Tabelle braucht eine user_id-Spalte). Du wusstest nicht, dass du die Hälfte davon brauchst. Jetzt schon. Bevor du einen einzigen Prompt zum Bauen schreibst.

Schritt 3 (detaillierte Spezifikation): Anmeldung mit E-Mail-Bestätigung. Login mit E-Mail und Passwort. Logout-Button. Session, die nach Inaktivität automatisch abläuft. Route-Schutz für ALLE Seiten außer Login und Anmeldung. Eine user_id-Spalte in jeder Datentabelle. Automatische Filterung nach Nutzer bei jeder Abfrage.

Das ist ein Vertrag. Jede Erwartung formuliert, jedes Verhalten definiert.

Dann baust du, verifizierst, benennst die Fallen (Sessions, die nie ablaufen, user_id wird bei INSERT überprüft, aber nicht bei UPDATE oder DELETE), und überprüfst Regression gegen jedes vorherige Feature. Du kennst den Kreislauf. Dieselben acht Schritte.

Der Unterschied zwischen "füg einen Login hinzu" und diesem ist der Unterschied zwischen einer Tür, die verschlossen aussieht, und einer Tür, die es tatsächlich ist.

Die Bauabfolge

Baue in dieser Reihenfolge:

• Setup und Deploy (bring sofort etwas online, auch wenn es nur eine leere Seite ist)
• Verstehe die Bausteine (Frontend, Backend, Datenbank, wie sie kommunizieren)
• Entwirf die Schnittstelle, bevor du sie baust (Vokabular + Konsistenzregeln)
• Dein erstes Feature (einfaches CRUD, lerne den Kreislauf)
• Datenbeziehungen (Dinge, die sich mit anderen Dingen verbinden)
• Authentifizierung (wer bist du)
• Datenisolation (jeder Nutzer sieht nur seine eigenen Daten)
• Testing (automatisiere die Verifikation, die du bisher von Hand gemacht hast)
• Dashboard und Politur (lass es sich wie ein Produkt anfühlen)
• Zahlungen (das Feature mit den teuersten Bugs)
• Echtes Live-Gehen (Produktions-Deploy, Domain, Monitoring)

Jeder Schritt baut auf dem vorherigen auf. Du kannst keine Authentifizierung hinzufügen, bevor du Seiten hast, die du schützen kannst. Du kannst keine Zahlungen hinzufügen, bevor du Nutzer hast, die du belasten kannst. Du kannst nicht effektiv testen, bevor du Features hast, die du testen kannst.

Jede Vibe-Coding-Katastrophe, die ich gesehen habe, folgt demselben Muster: jemand hat das coole Feature zuerst gebaut (Zahlungen, Dashboards, schicke UI) und das langweilige Zeug später drangebastelt (Auth, Sicherheit, Fehlerbehandlung). Das langweilige Zeug passt nie richtig, weil es nie Teil der Architektur war.

Überspring Schritte, und du verlegst Elektrizität in einem Haus ohne Wände.

Die Todesschleife (und wie man ihr entkommt)

Freitagnachmittag. Du willst nur noch einen Fix vor dem Wochenende ausliefern. Der Bug ist klein. Du promptest die KI. Der Fix funktioniert. Außer dass jetzt die Sidebar kaputt ist. Du promptest wieder. Sidebar gefixt, aber der Speichern-Button sendet nicht mehr ab. Noch ein Prompt. Speichern funktioniert, Sidebar ist wieder kaputt, und die Login-Seite ist ein weißer Bildschirm.

Dein Pool wartet. Deine Kinder fragen, wann du fertig bist. Du promptest weiter. Vor drei Runden hattest du einen Bug. Jetzt hast du vier. 🫠

Das ist die Todesschleife.

Jeder Patch fixt eine Sache und macht eine andere kaputt, weil die KI immer Symptome behandelt. Die Grundursache ist noch da, begraben unter Schichten von Schnellfixes. Du debuggst nicht mehr. Du machst es mit jedem Prompt schlimmer.

Der Ausgang ist immer derselbe. Du hörst auf zu prompten. Du kehrst zur letzten Version zurück, die funktioniert hat (dafür gibt es Git). Und du kommst mit einem anderen Prompt zurück: "Fix nicht das Symptom. Erkläre, was dieser Fehler grundsätzlich bedeutet. Ich habe zweimal versucht, ihn zu fixen, und jeder Fix hat neue Bugs erzeugt."

Manchmal ist das Feature zu verworren, um es zu retten. Du kehrst zurück und baust es von Grund auf mit einer besseren Spezifikation neu. Klingt schmerzhaft. Ist tatsächlich schneller als eine sechste Runde Whack-a-Mole.

Teams stecken wochenlang in Todesschleifen fest. Deshalb war die Diagnose in Bloombergs AI-Coding-Produktivitätskrise falsch: sie haben Output-Geschwindigkeit gemessen, nicht Schleifenhäufigkeit.

Spezifikationsqualität ist alles

Dasselbe Feature. Zwei Spezifikationen. Zwei Ergebnisse.

Schlechte Spezifikation: "Bau mir eine Kundenseite."

Die KI rät alles. Layout, Spalten, Buttons, was passiert, wenn es keine Daten gibt. Das Ergebnis ist zufällig. Du hast nichts spezifiziert, also hat die KI jede Lücke mit ihrem eigenen Urteil gefüllt. Das ist oft falsch.

Gute Spezifikation: "Bau eine Kundenlisten-Seite mit einer Sidebar-Navigation. Im Hauptbereich eine Tabelle mit Spalten: Name, Telefon, E-Mail, Stadt. Eine Suchleiste über der Tabelle. Ein 'Kunde hinzufügen'-Button, der ein Modal-Formular öffnet. Wenn es keine Kunden gibt, zeige 'Noch keine Kunden, füge deinen ersten hinzu' mit einem Button. Ladezustand mit einem Skeleton. Fehlerzustand mit einer nutzerfreundlichen Nachricht."

Jedes Element ist spezifiziert. Das Ergebnis ist vorhersagbar. Und (das ist der Schlüssel) du kannst es verifizieren, weil du genau weißt, was du verlangt hast.

Schlechte Spezifikation = schlechter Vertrag. Die KI füllt die Lücken mit Vermutungen. Gute Spezifikation = guter Vertrag. Jede Erwartung formuliert, jedes Verhalten definiert. Ich habe das vollständige Prompt-Contracts-Framework entwickelt, nachdem genug Features schief gelaufen sind. Dasselbe Prinzip: die Spezifikation ist das Produkt.

Das ist erlernbar. Deine erste Spezifikation werden zwei Sätze sein. Bei deiner zehnten schreibst du zwei Seiten, ohne darüber nachzudenken. Die Methode trainiert dich, ein Feature nach dem anderen.

Spezifizieren. Bauen. Verifizieren. Wiederholen.

Die KI schreibt den ganzen Code. Ich schreibe null. Aber ich spezifiziere genau, was ich will, ich verstehe, was gebaut wurde (ohne Code zu lesen), und ich verifiziere alles systematisch. So liefere ich Produktions-Apps mit echten Nutzern, echten Zahlungen und Datenisolation aus, die tatsächlich hält.

"Bauen" und "Ausliefern" sind nicht dasselbe Verb.

Du hast eine KI gebeten, dir eine App zu bauen. Jetzt weißt du, wie du sie tatsächlich auslieferst. Acht Schritte, derselbe Kreislauf. Mühsam. Nicht sexy.

Das Durchziehen liegt bei dir.

(*) Das Cover ist KI-generiert. Das Strohballenhaus ist aber echt.