Vibe Coding

Ich will ein kleines Werkzeug bauen: [IDEE IN EINEM SATZ]. Nutzer sind [NUTZER]. Ich kann [KENNTNISSTAND].

Schreibe noch keinen Code. Arbeite in dieser Reihenfolge und halte nach jedem Schritt an, bis ich bestaetige:

Schritt 1 - Spec: Was das Werkzeug tut und was ausdruecklich nicht. Die drei bis fuenf Bildschirme oder Kommandos. Welche Daten gespeichert werden und wo. Was passiert, wenn es niemand mehr pflegt.
Schritt 2 - Technikwahl: Nenne genau eine Option, die zu meinem Kenntnisstand passt, und begruende sie in drei Saetzen. Keine Auswahl von fuenf Frameworks. Bevorzuge, was ohne Build-Schritt laeuft.
Schritt 3 - Bauplan: Dateiliste mit einem Satz pro Datei.
Schritt 4 - Code: eine Datei pro Nachricht, vollstaendig und lauffaehig, mit einem Satz dazu, wie ich sie starte und woran ich sehe, dass es geklappt hat.

Regeln: keine Abhaengigkeit, die du nicht begruendest. Keine Funktion, die ich nicht verlangt habe. Wenn dir eine Anforderung unklar ist, frag statt zu raten.

Ich will mit einem Wegwerf-Prototyp genau eine Frage klaeren: [FRAGE, z. B. "Verstehen Nutzer den Bestellablauf ohne Erklaerung?" oder "Liefert [SYSTEM] die Daten in unter [SEKUNDEN] Sekunden?"]. Getestet wird mit [TESTPERSONEN ODER TESTAUFBAU]. Ich kann [KENNTNISSTAND]. Nach dem Test wird der Code geloescht, nicht weiterentwickelt.

Schreibe noch keinen Code. Arbeite in dieser Reihenfolge und halte nach jedem Schritt an, bis ich bestaetige:

Schritt 1 - Frage schaerfen: Formuliere die Frage so, dass sie sich mit ja oder nein beantworten laesst. Stecken zwei Fragen darin, nenne beide und lass mich eine streichen.
Schritt 2 - Abbruchkriterium: Lege mit mir fest, welches Ergebnis ja bedeutet, welches nein, und wann ich auch ohne Antwort aufhoere. Zahlen statt Eindruecke, z. B. "4 von 5 Testpersonen schaffen den Ablauf ohne Hilfe" und "spaetestens nach [ZEITRAHMEN]".
Schritt 3 - Faelschliste: Was fuer die Frage egal ist, wird vorgetaeuscht oder weggelassen, etwa feste Beispieldaten statt Datenbank, keine Anmeldung, keine Fehlerbehandlung, keine Randfaelle. Gib mir eine Tabelle: Was / echt oder gefaelscht / warum fuer die Frage egal. Was die Antwort verfaelschen wuerde, bleibt echt, und du sagst mir, welche Punkte das sind.
Schritt 4 - Code: so wenig wie moeglich, am liebsten eine Datei, die ohne Installation laeuft. Oben in die Datei kommt ein Kommentar mit Frage, Abbruchkriterium und Faelschliste.
Schritt 5 - Auswertung: Nach dem Test gebe ich dir meine Beobachtungen. Du beantwortest die Frage mit ja, nein oder offen, gemessen am Kriterium aus Schritt 2, und nennst, welches Ergebnis auf eine gefaelschte Stelle zurueckgehen koennte.

Regeln: Keine Funktion, die nicht zur Frage gehoert. Keine echten Kunden- oder Beschaeftigtendaten, auch nicht zum Testen. Schlage nicht vor, den Prototyp weiterzubauen; ist die Antwort ja, beginnt die naechste Version bei null.

Ich will die kleinste Version von [PRODUKT IN EINEM SATZ] bauen, die echte Nutzer mit echten Daten benutzen. Die ersten Nutzer sind [WER, WIE VIELE]. Sie loesen damit [PROBLEM] und geben dafuer [GEGENLEISTUNG, z. B. "29 EUR im Monat" oder "ihre Rechnungen jede Woche"]. Ich kann [KENNTNISSTAND]. Meine Funktionsliste: [ALLE FUNKTIONEN, DIE MIR EINFALLEN].

Schreibe noch keinen Code. Arbeite in dieser Reihenfolge und halte nach jedem Schritt an, bis ich bestaetige:

Schritt 1 - Streichen: Sortiere jede Funktion aus meiner Liste in Muss oder Spaeter. Muss ist nur, ohne das der erste Nutzer sein Problem nicht loesen kann. Begruende jedes Muss in einem Satz. Mehr als [ANZAHL, z. B. 3] Muss-Funktionen sind zu viele: streiche weiter und sag mir, welche Streichung am meisten kostet.
Schritt 2 - Erfolgsmessung: eine Kennzahl, ein Zielwert, ein Stichtag, z. B. "8 von 20 Nutzern arbeiten in Woche 4 noch damit" oder "3 zahlende Kunden bis [DATUM]". Dazu der Wert, bei dem ich aufhoere oder umbaue, und wie ich die Zahl erhebe, ohne ein Analysewerkzeug einzubauen.
Schritt 3 - Mindestanforderungen, die ab dem ersten echten Nutzer gelten, auch wenn alles andere fehlt:
- Daten: Wo liegen sie, in welchem Land, und kann ich sie vollstaendig als Datei exportieren?
- Zugriff: Anmeldung je Person, niemand sieht fremde Daten, Passwoerter und Schluessel stehen nicht im Code.
- Backup: automatisch, mindestens taeglich, an einem zweiten Ort, und einmal zurueckgespielt, bevor der erste Nutzer kommt.
- Personenbezug: Welche personenbezogenen Daten fallen an, und wie loesche ich sie, wenn jemand das verlangt?
Nenne je Punkt die einfachste Umsetzung, die zu meinem Kenntnisstand passt.
Schritt 4 - Bauplan und Code: Dateiliste mit einem Satz pro Datei, dann eine Datei pro Nachricht, vollstaendig und lauffaehig, mit einem Satz dazu, wie ich sie starte und woran ich sehe, dass es geklappt hat.

Regeln: Keine Spaeter-Funktion im Code, auch nicht vorbereitet. Keine Abhaengigkeit, die du nicht begruendest. Fehlt eine Mindestanforderung aus Schritt 3, sagst du das, bevor du weiterbaust. Bevor mehr Nutzer dazukommen, pruefe ich das Ergebnis mit dem Prompt "Vibe Coding: vom Prototyp in Betrieb".

Ich habe die anhaengende Anwendung groesstenteils mit einem Sprachmodell gebaut und ueberlege, sie mit echten Daten von [NUTZERZAHL] Nutzern zu betreiben. Sei streng, nicht hoeflich.

Pruefe in dieser Reihenfolge und gib je Punkt: Fundstelle, was im schlechtesten Fall passiert, kleinster Fix.
1. Datenverlust: Was passiert bei Absturz, Doppelklick, parallelem Zugriff? Gibt es ein Backup, das jemand je getestet hat?
2. Zugriff: Kann jemand ohne Anmeldung an fremde Daten? Zeig mir die konkrete URL oder den Aufruf.
3. Eingaben von aussen: Wo landen ungepruefte Nutzereingaben in Datenbank, Dateisystem, Shell oder HTML?
4. Geheimnisse: Liegen Schluessel oder Passwoerter im Code, im Repository oder im Browser?
5. Personenbezug: Welche personenbezogenen Daten werden verarbeitet, wo liegen sie, wer koennte ihre Loeschung verlangen?
6. Betrieb: Woran merke ich, dass es kaputt ist, bevor ein Kunde anruft?

Zum Schluss ein Urteil in einem Satz: produktivtauglich, produktivtauglich nach Fix der Punkte X und Y, oder neu bauen. Keine Diplomatie.