Vibe Coding in der Produktion: Der Bruch

In der Demo lief alles. In Produktion bricht es: keine Architektur, keine Sicherheit, keine Tests. Niemand kann es warten. Vibe Coding klickt in Minuten eine App zusammen. Produktionsreif wird sie damit nicht. Das lässt sich beheben.

Vibe Coding bringt Prototypen. Wenn die in Produktion sollen, entstehen Lücken: Skalierung, Sicherheit, Wartung. Wir schließen sie. Wir bauen aus, was funktioniert, und retten, was nicht mehr weiterläuft.

Warum scheitern Vibe-Coding-Projekte am Schritt in Produktion?

Sechs Minuten. So lange dauert es, mit einem KI-Tool wie Lovable, Bolt.new oder Cursor eine glänzende App zusammenzuklicken. Hero-Bereich, ein Button, ein Versprechen. Es sieht aus wie fertige Software.

Fangen wir fair an: Das kann etwas wirklich gut. Für einen Pitch, eine Stakeholder-Demo oder den schnellen Test einer Hypothese ist es Gold wert: in Minuten steht etwas, das man anfassen kann. Das Problem beginnt erst, wenn jemand diese Demo mit Produktionssoftware verwechselt. Und das passiert ständig, meist bei Gründerinnen und Produktverantwortlichen, nicht bei Entwicklern, die genau das gebaut haben, was das Tool versprochen hat, und jetzt vor der Frage stehen, was als Nächstes kommt.

Vibe Coding optimiert auf das, was man sieht. Produktion bestraft das, was man nicht sieht. Vier Stellen brechen zuverlässig unter Last:

• Sicherheit, die nie eingebaut wurde. KI-Tools schreiben den Pfad, der funktioniert, nicht den, der angegriffen wird. Authentifizierung, Berechtigungen, Input-Validierung, Secrets-Management entstehen nicht von allein. Das Tool hat keinen Grund, danach zu fragen, also fragt es niemand.
• Architektur, die nicht skaliert. Ein Prototyp hat keine Architektur, er hat Code, der gerade so zusammenhält. Bei zehn Nutzern fällt das nicht auf. Bei zehntausend schon, dann wird jede neue Funktion zum Risiko, weil niemand mehr genau weiß, was sie sonst noch mitverändert.
• Tests, die es nie gab. Ohne automatisierte Tests ist jede Änderung ein Griff ins Ungewisse: niemand weiß, was sonst noch kaputtgeht, bis es ein Nutzer merkt.
• Wartung, die zur Hypothek wird. Code, den niemand versteht, ist Code, den niemand sicher ändern kann. Jede Änderung wird zum Glücksspiel, jeder neue Entwickler braucht Wochen zur Einarbeitung. Die technischen Schulden wachsen mit Zinseszins, bis ein Neubau billiger wirkt als die nächste Funktion.

Der Grund, warum „später aufräumen" fast nie funktioniert: Sobald die Demo läuft, gibt es keinen Druck mehr, sie zu reparieren, nur Druck, das nächste Feature zu liefern. Die Aufräumarbeit wird verschoben, bis sie kein Aufräumen mehr ist, sondern ein Neubau. Sauberer Code ist die Voraussetzung dafür, schnell zu bleiben, nicht der nachträgliche Schritt nach dem schnellen Bauen.

Aufbauen oder neu bauen? Die Bestandsanalyse

Die naheliegende Angst: dass alles verloren ist und ein Neustart bei null der einzige Weg ist. Meistens stimmt das nicht.

Vieles vom Bestehenden bleibt: die Produktidee, oft die Oberfläche, häufig ein Teil der Geschäftslogik. Was in der Regel neu entstehen muss, ist das, was in der Demo nie geprüft wurde: Architektur, Sicherheit, Tests. Eine Pauschalantwort gibt es dafür nicht, weil jeder Prototyp anders zusammengeklickt wurde.

Deshalb steht am Anfang eine ehrliche Bestandsaufnahme, keine Verkaufsschätzung: Was funktioniert und bleibt, was wird gehärtet, was muss neu gebaut werden. Das Ergebnis ist eine klare Liste, sortiert nach dem, was am meisten zählt, nicht nach dem, was am einfachsten zu verkaufen ist. Ein ehrliches Warnsignal, unabhängig davon, wer die Prüfung macht: Wenn vor jeder Bestandsaufnahme schon ein kompletter Neubau vorgeschlagen wird, lohnt eine zweite Meinung. Das ist selten die günstigste oder schnellste Antwort.

Als grobe Orientierung, kein Versprechen: Typisch bleibt die Kernidee, das Datenmodell in Grundzügen, oft ein großer Teil der Oberfläche. Typisch kommt neu hinzu, was die Demo nie brauchte: Auth auf API-Ebene, automatisierte Tests, eine geprüfte Fehlerbehandlung. Typisch wird gehärtet, nicht neu geschrieben: die Geschäftslogik, sobald sie gegen echte Eingaben geprüft wurde statt nur gegen die Demo-Daten.

Das gilt vom ersten MVP bis zur gewachsenen App mit echten Nutzern: der Bestand unterscheidet sich, die Vorgehensweise nicht.

Ist KI-generierter Code sicher genug für Produktion?

Ehrlich: meistens nicht, ohne Nacharbeit. Der Grund: Niemand hat die Sicherheitsfragen gestellt, die ein Prototyp nie beantworten musste. KI-Tools schreiben den Pfad, der funktioniert, nicht den, der einem Angriff standhält. Das ist eine Frage, die in einer Demo nie gestellt wird, kein Fehler im Werkzeug. Am häufigsten finden wir:

• SQL-Injection über ungeprüfte Eingaben.
• Fehlende Input-Validierung an Formularen und API-Routen.
• Unsichere oder offene API-Endpunkte, erreichbar, aber nie abgesichert.
• Secrets im Code, API-Schlüssel im Klartext, oft mit einem // FIXME later daneben.
• Fehlende Auth auf API-Ebene, der Login sichert die Oberfläche, nicht die Schnittstelle dahinter.

Das ist kein Weltuntergang, das ist der Normalzustand von Software, die auf Tempo gebaut wurde und auf nichts sonst. Und die Konsequenz ist konkret, nicht abstrakt: Ein einzelner ungeprüfter API-Endpunkt reicht, damit fremde Nutzer fremde Daten sehen. Ein Secret im Klartext reicht, damit jemand mit Repository-Zugriff deine gesamte Infrastruktur übernimmt. Das sind keine Restrisiken, das sind die Standardfunde eines ersten Audits.

Die Reihenfolge, die daraus produktionsreif macht: Security-Audit, dann Auth auf API-Ebene, dann Härtung der gefundenen Lücken, bevor die App echte Nutzer und echte Daten sieht.

Ist eine Vibe-Coding-App automatisch DSGVO-konform?

Nein. Und das überrascht die meisten. Viele KI-Baukästen hosten standardmäßig auf US-Cloud-Infrastruktur oder verarbeiten Daten dort, wo das Tool zufällig läuft. Für einen Klick-Prototyp ist das egal. Für echte Nutzerdaten ist es das nicht.

Produktionsreif heißt deshalb auch: Hosting und Daten in Deutschland, DSGVO-konform von Anfang an: Teil der Architektur, nicht nachträglich draufgesetzt. Dazu gehören ein sauberer Auftragsverarbeitungsvertrag, ein Löschkonzept für Nutzerdaten und die Entscheidung, welche Daten das System überhaupt speichern muss, statt aus Bequemlichkeit alles zu sammeln, was das Tool anbietet.

Konkret prüfen wir jede Stelle, an der Daten das System verlassen: eingebundene Analyse- und KI-API-Aufrufe, Drittanbieter-Widgets, E-Mail- und Zahlungsdienste. Viele davon senden im Standard-Setup still Daten an US-Server. Das klingt nach böser Absicht, ist aber meist nur die Werkseinstellung des jeweiligen Tools. Produktionsreif heißt, das bewusst zu entscheiden statt es zu übersehen.

Was gehört zu „produktionsreif"?

Eine feste Reihenfolge, keine Wunschliste. So bringen wir eine KI-gestützt gebaute App in Produktion:

1. Architektur. Module, Grenzen, Verantwortlichkeiten, bevor mehr Code entsteht. Wir zerlegen den bestehenden Prototyp in klar abgegrenzte Komponenten, damit eine neue Funktion nicht drei andere unbemerkt mitverändert.
2. Security-Audit. Die Lücken aus dem Abschnitt zur Sicherheit systematisch finden, nicht stichprobenartig. Jeder Endpunkt, jedes Formular, jede Abhängigkeit wird geprüft: Ergebnis ist eine priorisierte Liste, keine vage Einschätzung.
3. Tests (E2E). Die kritischen Nutzerpfade automatisiert abgesichert: Login, Bezahlvorgang, die Kernfunktion, für die deine Nutzer überhaupt da sind. Ein Test ist eine Versicherung: Er schlägt Alarm, bevor ein Fehler live geht.
4. CI/CD. Jede Änderung wird automatisch geprüft und ausgeliefert, nicht von Hand hochgeladen. Das macht „schnell liefern" und „sicher liefern" zum selben Vorgang, nicht zu einem Kompromiss.
5. DB-Migration und Rollback. Datenbankänderungen sicher und rückholbar: wenn eine Änderung schiefgeht, kommst du ohne Datenverlust zurück zum letzten funktionierenden Stand.
6. Monitoring, Observability, Alerting. Du erfährst von einem Problem, bevor deine Nutzer es melden, nicht danach, aus einer verärgerten E-Mail.
7. Last- und Performance-Tests. Belastbar bei echtem Nutzeraufkommen, nicht nur in der Demo mit einem einzelnen Browser-Tab. Was bei zehn Testern flüssig läuft, muss bei zehntausend Nutzern noch stehen.
8. Dokumentation und Übergabe. Übergabesicher: jeder neue Entwickler versteht das System anhand der Doku, nicht nur derjenige, der es gebaut hat. Das ist auch deine Absicherung: Wissen bleibt im System, nicht bei einer einzelnen Person.

Nicht alle acht Punkte wiegen für jede App gleich schwer. Wir priorisieren nach drei Fragen: Folgenschwere (was passiert im Fehlerfall, consequence), Angriffsfläche (wie exponiert ist die Stelle, exposure) und Abdeckung (wie gut ist sie heute schon abgesichert, coverage). Das ist der ehrliche Weg, zuerst das zu härten, was am meisten zählt, statt blind die ganze Liste abzuarbeiten.

Der Test, der Demo von Produktionssoftware trennt: Verstehst du das System auch nach drei Jahren noch? Kannst du es anfassen, erweitern, einem neuen Entwickler erklären? Wenn ja, hast du Software. Wenn nein, hast du eine glänzende Oberfläche ohne Fundament. Eine Vibe-Coding-Demo besteht diesen Test praktisch nie, weil sie nie dafür gebaut wurde, nicht weil sie schlecht gebaut ist.

Wer kontrolliert das Ergebnis?

Die berechtigte Folgefrage: Wenn KI mitschreibt und wir deinen Bestand härten, wem gehört der Code danach, und wer hat die Kontrolle?

Die Antwort ist dieselbe wie bei der Qualität: Transparenz. Offenes Repository, sichtbare Commits, dokumentierte Entscheidungen: du siehst jederzeit, was verändert wurde und warum. Jede Zeile, die eine KI geschrieben hat, durchläuft dieselbe Code-Review wie jede andere: es gibt keine Sonderspur für KI-Output. Code, Dokumentation und geistiges Eigentum gehören vollständig dir, übergabesicher und ohne Lock-in. Dahinter stehen 40+ Jahre Software-Engineering-Expertise: wir professionalisieren, was andere nur zusammengeklickt haben, statt es dir als Black Box zurückzugeben.

Diese Verantwortung trägt bei uns immer ein eingespieltes Team, kein Einzelkämpfer und kein internes Team, das du dafür erst aufbauen müsstest. Keine eigenen Entwickler? So begegnet AI-Shoring dem Fachkräftemangel.

Was kostet es, und wie läuft der Produktionsreife-Check ab?

Der Produktionsreife-Check selbst ist kostenlos und unverbindlich. Keine versteckte Verkaufsstunde, keine Stundensätze, die während des Gesprächs eskalieren: eine ehrliche Bestandsaufnahme.

Drei Schritte: Bestand sichten (was ist da, was funktioniert), Lücken benennen (sortiert nach Folgenschwere, nicht nach Bauchgefühl), und eine erste Einschätzung: was es braucht und in welche Richtung Aufwand und Kosten gehen. Beim Lücken-Schritt beantworten wir für jeden Fund dieselben drei Fragen aus dem Checkliste-Abschnitt: Was passiert im Fehlerfall, wie exponiert ist die Stelle, wie gut ist sie heute schon abgesichert. Das ist derselbe Maßstab, den wir beim Bauen selbst anlegen, keine gesonderte Verkaufslogik für den Check.

Der Check gibt dir eine ehrliche Richtung, keinen bindenden Preis: dafür ist eine kostenlose Erstprüfung der falsche Rahmen. Den belastbaren Festpreis liefert der nächste Schritt: eine kurze Architekturphase, die vollständig auf den Bau angerechnet wird, kein zusätzliches Budget obendrauf. Erst die ehrliche Richtung, dann der verbindliche Preis, dann erst wird gebaut.

Nach dem Check entscheidest du, nicht wir. Du bekommst die Liste und die Richtung, ohne Verpflichtung zum nächsten Schritt. Wenn der Bestand tatsächlich einen Neuanfang rechtfertigt, sagen wir das genauso offen wie das Gegenteil.

Häufige Fragen

Kann mein festgefahrenes KI-Projekt gerettet werden, oder muss alles neu?

Meist rettbar. Wir prüfen den Bestand ehrlich (im Produktionsreife-Check) und sagen klar: was bleibt, was neu muss. Ein kompletter Neuanfang ist die Ausnahme, nicht die Regel.

Wie lange dauert es, eine Vibe-Coding-App produktionsreif zu machen?

Typischerweise Wochen, nicht Monate. Der Produktionsreife-Check gibt eine erste Richtung, der belastbare Fahrplan mit Festpreis kommt aus der anschließenden, angerechneten Architekturphase: jedes Projekt bringt einen anderen Bestand mit.

Ist AI-Shoring nur „Vibe Coding" mit KI?

Nein. Wir kombinieren KI-Tempo mit erfahrenen Entwicklern, Tests und Architektur. Produktionsreif statt Wegwerf-Demo. Mehr dazu: Was ist AI-Shoring?

Wird bestehender Code aus Lovable, Cursor, Bolt.new oder Claude Code übernommen?

Ja. Wir übernehmen bestehenden KI-generierten Code, härten ihn und liefern die produktionsreife Version: du fängst nicht bei null an.

Behalte ich Code und IP?

Ja, vollständig: übergabesicher, kein Lock-in.

Muss ich selbst Entwickler sein, um das zu verstehen?

Nein. Der Produktionsreife-Check und die Richtung, die er liefert, sind auf Entscheider geschrieben, nicht auf Entwickler: du bekommst eine klare Liste, keinen Technik-Vortrag. Verstehen müssen es die Menschen, die es bauen.

Unterm Strich

Vibe Coding zerbricht in Produktion nicht aus Zufall. Es zerbricht, weil es auf das Sichtbare optimiert und alles Unsichtbare ignoriert: genau das, was Software tragfähig macht.

Baue die Variante, die du auch nach drei Jahren noch verstehen, anfassen und ausbauen willst. KI darf dabei helfen. Prüfen muss ein Mensch.

Der AI-Shoring Leitfaden geht tiefer: Definition, ein reales Fallbeispiel und die Kostenrechnung dahinter, auf acht Seiten.

Leitfaden herunterladen →