Tag eins einer Vibe-Coded-App ist die beste Demo, die Sie je gegeben haben. Der Prompt funktionierte, die Screens sind clean, die Datenbank enthält Daten und Sie haben einen Tweet mit einem Screenrecording abgesetzt. Diesen Tag haben wir oft erlebt. Wir wollen Ihnen diesen Moment nicht nehmen.
Wir sind hier, um über Tag zwei zu sprechen, denn darüber schreibt niemand in seinem Launch-Thread. Tag zwei ist der Moment, in dem ein echter Nutzer sich einloggt, etwas tut, an das Sie beim Testen nicht gedacht haben, und Ihre App die Lücke zwischen “generiert” und “engineered” spürt.
Wie Tag zwei wirklich aussieht
Es beginnt selten mit einem Totalabsturz. Es beginnt mit einer Seltsamkeit: Ein Formular akzeptiert unsinnige Eingaben, eine Seite stürzt für einen ganz bestimmten Nutzer ab, eine Zahl ist auf eine Weise falsch, die niemand reproduzieren kann. Sie kopieren den Fehler in den Chat. Die KI behebt ihn selbstbewusst. Der Fix macht etwas anderes kaputt.
Willkommen beim Prompt-Whack-a-Mole. Da die KI Symptome statt Ursachen bekämpft, wird jeder Patch auf den letzten geschichtet. Die Codebasis wird schleichend zu dem, was Entwickler “Frankenstein-Code” nennen: ein Flickenteppich aus widersprüchlichen Stilen, doppelten Funktionen und verstrickter Logik, bei der Datenbankabfragen mitten im Interface-Code stehen. Sobald das Projekt das Kontextfenster der KI übersteigt, beginnt das Modell, frühere Entscheidungen zu vergessen und schlägt Code vor, der diesen widerspricht. Sie warten keine App mehr. Sie verhandeln mit einer.
Es gibt eine noch grausamere Variante: den stillen Deployment-Fehler. Ihr Hosting-Build schlägt wegen eines kleinen Fehlers fehl, die Live-URL zeigt weiterhin die alte Version, und Sie – da Sie keine Änderung sehen – sagen der KI, ihr Fix habe “nicht funktioniert”. Also generiert sie eine völlig andere, komplexere Lösung für ein Problem, das eigentlich schon gelöst war. Einige Runden später haben Sie eine aufgeblähte Version 5 von einem Code, dessen Version 1 eigentlich völlig in Ordnung war.
Der Teil, den man nicht sieht
Das Debugging-Hamsterrad ist zumindest sichtbar. Die Sicherheitsprobleme sind es nicht – und genau deshalb sind wir bei Business-Builds so streng.
Die Forschungsergebnisse hier sind wirklich beunruhigend. LLM-generierter Code lässt sich in etwa 90 % der Fälle erfolgreich kompilieren, aber rund 45 % enthalten Sicherheitslücken aus den OWASP Top 10 – etwa umgehbare Login-Prüfungen oder Injection-Fehler. KI-Tools optimieren darauf, dass die Demo funktioniert, was zu vorhersehbaren Abkürzungen führt: Zugriffskontrollen werden im Browser implementiert, wo jeder Nutzer sie durch Editieren der Seite umgehen kann; Datenbankberechtigungen werden komplett geöffnet, damit beim Build nichts abstürzt; und API-Keys werden direkt in die Dateien hardcodiert, weil der Builder nicht weiß, was eine Umgebungsvariable ist. Diese Dateien landen dann in öffentlichen GitHub-Repos, wo sie von Credential-Scrapern zuverlässig gefunden werden.
Das ist genau der Grund, warum dies ein typisches „Day Two“-Problem ist: Eine ausnutzbare App läuft perfekt. Es gibt keine Fehlermeldung, die besagt: „Kunde A kann technisch gesehen die Datensätze von Kunde B lesen“. Im besten Fall erfährt man es von einem Nutzer – im schlimmsten Fall erst viel zu spät. Und der Standardrat („Testen Sie es einfach!“) kollidiert mit der Realität: Nicht-technische Builder testen den Idealfall (Happy Path), während die Fehler in den Edge-Cases liegen – der Concurrency-Bug oder der vergessene Passwort-Reset-Flow, den die KI nie generiert hat, weil die Demo ihn nicht benötigte.
Die Wartungsschulden, die niemand auflistet
Wenn sich diese Mechanismen über Monate summieren, entsteht das, was man als den „Kredit mit Wucherzinsen“ der technischen Schulden bezeichnen kann: Sofortige Software heute, Zinseszinsen später. Jede Abkürzung, die die KI genommen hat, ist ein zukünftiger Fix. Jeder Fix kostet weitere Credits und führt zu mehr Code-Bloat. Plattform-Updates werden veröffentlicht und machen Dinge kaputt, die man gar nicht angefasst hat – erfahrene Builder auf Prompt-to-App-Plattformen berichten, dass sie monatliche Wartungsgebühren von Kunden verlangen müssen, nur um Regressionen der Plattform selbst zu beheben.
Das ist die bittere Ironie an der Sache: Vibe Coding versprach, Software zu demokratisieren, aber für Produktions-Apps hat es primär die technischen Schulden demokratisiert. Der nicht-technische Builder steht am Ende genau vor dem, was er mit KI vermeiden wollte – einer Codebasis, die das Urteilsvermögen eines Entwicklers erfordert – nur dass diese nun das Fundament seines Geschäfts bildet und er sie nicht lesen kann.
Die ehrliche Entscheidung
Was also tun? Nach vielen Projekten und einigen schmerzhaften Erfahrungen glauben wir, dass es auf eine Entscheidung zwischen zwei ehrlichen Wegen ankommt. Der unehrliche Mittelweg ist die einzige falsche Antwort.
Weg eins: Lernen, Code zu warten. Wenn Ihnen das Projekt wichtig genug ist, um tiefer einzusteigen, wird Vibe Coding zu einem echten Beschleuniger statt zu einer Falle. Lesen Sie, was der Agent schreibt. Verstehen Sie, was RLS bedeutet, bevor Sie eine App veröffentlichen, die darauf basiert. Steigen Sie von reinen Prompt-Tools auf Cursor oder Replit um, wo der Code die Schnittstelle ist und Sie ein echtes technisches Urteilsvermögen entwickeln können. Dieser Weg ist großartig – aber es ist eben ein Weg, der Monate an Arbeit erfordert. So zu tun, als wäre man auf diesem Weg, während man ungelesenen Code an Kunden ausliefert, ist die Falle.
Weg zwei: Die kritischen Teile auf ein nicht-generiertes Fundament setzen. Seien Sie ehrlich: Ihre App ist ein Business-Tool – ein Kundenportal, ein Tracker, ein internes CRM. Dabei stellen Sie fest, dass 80 % davon genau die „Rohre“ sind, die die KI am schlechtesten generiert: Authentifizierung, Berechtigungen, Passwort-Resets, Datenzugriff. Bauen Sie diese Kategorien auf einer No-Code-Plattform wie Softr auf, wo die Infrastruktur getestet ist und visuell konfiguriert wird, während der AI Co-Builder Ihnen dennoch die Geschwindigkeit vom ersten Tag gibt. Wenn Sie individuelle Besonderheiten wünschen, begrenzt der Vibe-Coding-Block den generierten Code auf eine einzelne Komponente. So kann die KI das Haus dekorieren, ohne das Dach zum Einsturz zu bringen. „Day Two“ ist auf diesem Weg eine einfache Anpassung, keine archäologische Ausgrabung – deshalb führt es unser Ranking für Kundenportale an.
Nutzen Sie Vibe Coding weiterhin bedenkenlos für die spaßigen Dinge – Prototypen, Spielereien oder Wochenend-Experimente sind genau das, worin diese Tools brillant sind. Entscheiden Sie nur, bevor echte Nutzer kommen, auf welcher Seite der Entscheidung Sie stehen. „Day Two“ fragt nicht höflich.