Jede Vibe-Coding-Demo ist eine „Tag Eins“-Geschichte. Ein Prompt, eine funktionierende App, ein Screen, der bereit für den Release aussieht. Das Problem ist, dass Software nicht an Tag eins lebt. Sie lebt an Tag zwei, wenn echte Nutzer sich einloggen, die Daten keine Beispieldaten mehr sind und jemand etwas ändern muss, ohne alles andere zu zerstören. Das ist der Tag, an dem sich die Demo und das eigentliche Produkt als zwei völlig verschiedene Dinge entpuppen.
Warum Tag zwei eine andere Maschine ist
An Tag eins wird das Modell gebeten, auf einer leeren Leinwand zu schreiben – darin ist es gut. An Tag zwei soll es ein System modifizieren, an das es sich nur teilweise erinnert – darin ist es schlecht. Vibe Coding ist immer noch eine Abstraktionsschicht, keine Flucht vor der Softwareentwicklung: Man tippt zwar keine Syntax, verwaltet aber immer noch Zustände, entwirft relationale Schemata und bearbeitet Edge-Cases, weil die KI diese Komplexität nicht entfernt, sondern nur an den Nutzer delegiert hat.
Das Artefakt verschlechtert sich, während es wächst. Sobald eine Codebasis das Kontextfenster des Modells übersteigt, beginnt es, seine eigenen strukturellen Entscheidungen zu vergessen und Code vorzuschlagen, der früheren Mustern widerspricht. Der begrenzte Kontext führt auch dazu, dass Utility-Funktionen, die gerade nicht sichtbar sind, neu geschrieben werden, wodurch doppelte Logik im gesamten Projekt verteilt wird. Modelle, die auf unterschiedlichen Datenschnitten trainiert wurden, schreiben für kollidierende Versionen derselben Libraries, sodass Version-Drift entsteht. Übrig bleibt ein Frankenstein-Code: ein Flickenteppich aus Stilen, in dem Interface-Logik, Datenbankabfragen und Business-Regeln in Dateien verschmelzen, die niemand so geplant hat – und jede spätere Änderung muss sich durch dieses Chaos kämpfen.
Fehler kündigen sich nicht an
Ein Absturz ist ehrlich; er sagt Ihnen, dass etwas nicht stimmt. Die Day-Two-Ausfälle, die wirklich wehtun, sind die leisen. Die KI baut den spezifischen Erfolgspfad, den der Prompt beschrieben hat, und ignoriert die Fälle, die niemand in einer Demo zeigt: gleichzeitige Bearbeitungen durch zwei Nutzer, ein Formular, das während des Absendens die Verbindung verliert, ein doppelt geklickter Button oder eine falsch formatierte Eingabe. Ein kleiner Rundungs- oder Rechenfehler läuft bei jeder Transaktion sauber durch und taucht erst Monate später in einem Abrechnungsbericht oder einer Buchungsstatistik auf, die nicht mehr aufgeht.
Die Vertrauenslücke ist das, was dies gefährlich statt nur nervig macht. Ein nicht-technischer Betreiber kann den generierten Code nicht lesen, um zu bestätigen, was er tut, und manuelle Tests prüfen den Idealfall („Happy Path“), nicht die Umgehung. So kann die App, die in der Vorschau „perfekt funktioniert“, und die App, die stillschweigend ein Viertel ihrer Datensätze korrumpiert, dieselbe App sein. Man erfährt es von einem Kunden, nicht durch einen Test.
Die Wartungsklausel
Hier potenziert sich Tag zwei mit den restlichen Kosten. Jede Änderung ist eine neue Generierung, und in der Generierung liegen sowohl die Kosten als auch die Risiken. Das erneute Prompten eines Auth-nahen Features bedeutet, dass die Sicherheitswürfel neu geworfen werden – wie in what ‘45% of AI code is vulnerable’ actually means beschrieben. Eine Ebene, die Sie bereits verifiziert haben, muss also erneut geprüft werden. Und jede Runde, in der Symptome statt Ursachen behoben werden, füttert the fix loop tax: den kostenpflichtigen Debugging-Zyklus, der ein günstiges Abonnement in eine Open-End-Rechnung verwandelt – dieselbe Dynamik, die den Unterschied zwischen den Contendern in Lovable vs Bolt ausmacht.
Die Infrastruktur bringt eigene Day-Two-Überraschungen mit. Builder, die Self-Hosting nutzen, um Platform-Lock-in zu vermeiden, enden damit, eine Supabase-Datenbank, ein Cloudflare-Worker-Frontend und eine Cron-Plattform manuell zu synchronisieren – ein Desync in einem einzigen Teil reißt das gesamte System mit. Builder, die beim Hosting einer einzelnen Plattform bleiben, erben stattdessen deren Uptime, Preisgestaltung und Roadmap. Beides ist nicht die kostenlose Option, die die Demo suggeriert hat.
Was man generieren sollte und was nicht
Die ehrliche Analyse ist nicht, dass Vibe Coding nutzlos ist; es ist exzellent für persönliche Tools, Prototypen und abgegrenzte Custom-Komponenten mit geringem Umfang. Der Fehler liegt darin, es auf die Teile einer App anzusetzen, die wartungsfest sein müssen. Wenn Sie innerhalb einer echten Codebasis bauen und das Review selbst übernehmen, behalten Sie mit Code-First-Tools wie Cursor oder Cloud-Plattformen wie Replit die Kontrolle darüber, was wann geändert wird.
Für Business-Apps – Portale, interne Tools, CRMs, alles mit Logins, Rollen und echten Daten – sind die Ebenen, die an Tag zwei brechen, meist Auth, Berechtigungen und das CRUD-Grundgerüst. Auf einer Plattform wie Softr werden diese nicht pro Projekt generiert; sie sind konfigurierte Plattform-Infrastruktur. Die Änderung einer Berechtigung ist also eine Einstellung, keine neue Generierungsrunde, und es gibt keinen Fix-Loop, in den man zurückfallen kann. Softr bietet KI-Credits für seinen Co-Builder, aber da alles, was die KI tut, auch manuell erledigt werden kann, blockiert ein leeres Guthaben niemals einen Fix. Der günstigste Tag zwei ist der, an dem der wichtigste Teil von vornherein nie generiert wurde.