Vibe Coding
Software bauen, indem man ein KI-Tool promptet (Lovable, Cursor, Claude Code, Replit, Bolt, v0) und akzeptiert, was es generiert, ohne es zu lesen. Schnell zum Demo, gefährlich in Produktion, weil das Modell auf Code optimiert, der läuft, nicht auf Code, der einen echten User überlebt.
Vibe Coding heißt: einem KI-Coding-Tool beschreiben, was man will, und ausliefern, was es zurückgibt, ohne den Code Zeile für Zeile zu lesen. Der Begriff wurde Anfang 2025 populär, der Workflow ist älter als der Name: prompten, laufen lassen, sehen dass es funktioniert, wieder prompten. Tools wie Lovable, Cursor, Claude Code, Replit, Bolt und v0 machen es möglich, dass ein Nicht-Engineer an einem Nachmittag von der Idee zur klickbaren App kommt. Das ist echt und für Prototypen, interne Tools und das Validieren einer Idee genuin nützlich.
Der Ärger beginnt in dem Moment, in dem eine vibe-coded App auf einen echten User, echtes Geld oder echte Daten trifft. Ein LLM optimiert auf Code, der den Prompt erfüllt und im Demo läuft. Es optimiert nicht auf die Dinge, nach denen im Prompt niemand gefragt hat: Autorisierungsprüfungen, Input-Validierung, Secrets-Management, Rate Limiting, Error Handling, die Regressions-Suite. Genau das trennt ein Demo von produktionsreifer Software, und genau das lässt das Modell weg, sofern man nicht weiß, danach zu fragen, was ein Nicht-Engineer per Definition nicht tut.
Beispiel. Ein Founder vibe-coded an einem Wochenende ein SaaS-Dashboard. Es hat einen Login, eine Datenbank, ein sauberes UI und demot wunderbar. Was es nicht hat, ist eine serverseitige Prüfung, dass User A nicht die Datensätze von User B lesen kann. Der Login funktioniert, also fühlt es sich sicher an. Aber jeder eingeloggte User kann eine ID in der URL ändern und die Daten jedes anderen Kunden lesen. Das Modell wurde nie gebeten, mandantenweise Autorisierung zu erzwingen, also tat es das nicht, und nichts im Demo machte die Lücke sichtbar. Das ist der mit Abstand häufigste schwere Defekt in vibe-coded Software, und er bleibt unsichtbar, bis jemand, oder eine Behörde, ihn findet.
Der ehrliche Trade-off: Vibe Coding ist tatsächlich schneller zum lauffähigen Demo, und etwas anderes zu behaupten wäre unehrlich. Der Preis ist, dass diese Geschwindigkeit aus dem Auslassen genau der Engineering-Teile kommt, die keinen sichtbaren Payoff haben, bis sie failen. Für einen Wegwerf-Prototyp ist das ein guter Deal, für alles mit Kundendaten ein schlechter. Der Fehler ist nicht, die Tools zu benutzen. Der Fehler ist, das Demo für das Produkt zu halten und es auszuliefern. KI-generierter Code ist nicht per se schlechter als handgeschriebener, aber er sammelt Technical Debt lautlos an und überspringt jedes Mal dieselbe Sicherheitsarbeit.
Wavects Position ist simpel: Prototyp vibe-coden, dann einen strukturierten Production-Readiness-Durchlauf machen, bevor echte User kommen. Dieser Durchlauf ist kein Vibe. Es ist dieselbe Disziplin, die wir auf jeden Code anwenden: TDD auf der Logik, die zählt, Autorisierung auf jedem Endpoint, Secrets raus aus dem Client und eine CI/CD-Pipeline, die die Checks bei jeder Änderung laufen lässt. Wir machen das unter Software Quality Assurance. Die Tools sind gut. Sie wissen nur nicht, was sie weggelassen haben, und du auch nicht, bis es jemand liest.