Vibecoding Cleanup: So geht dein KI-Prototyp in Production

Der Begriff kommt aus dem Englischen und ist noch neu, im deutschsprachigen Raum schreibt darüber praktisch niemand: Vibecoding Cleanup. Gemeint ist der Prozess, der aus einem schnell mit KI zusammengepromptetem Prototyp ein Stück Software macht, das man auch echten Nutzern und echten Daten anvertrauen kann. Kein Neuschreiben von null, sondern ein gezieltes Aufräumen dessen, was schon da ist.

Wenn du noch nicht sicher bist, ob dein Projekt das überhaupt braucht: dazu gibt’s den Grundlagenartikel mit Checkliste und den Zahlen, die zeigen, wie oft KI-generierter Code tatsächlich Lücken hat. Hier geht’s um den nächsten Schritt, wenn du schon weißt, dass da was fehlt, oder es einfach sauber wissen willst.

Bauen ist nicht Betreiben

Der eigentliche Denkfehler, der Vibecoding Cleanup überhaupt erst nötig macht: Bauen und Betreiben werden wie dasselbe behandelt, sind aber zwei komplett verschiedene Disziplinen. Ein KI-Tool baut in Minuten etwas, das funktioniert, das ist die eigentliche Stärke von Vibe Coding, keine Frage. Aber “gebaut” ist ein einmaliger Zustand, ein Foto vom Moment, in dem es zum ersten Mal lief. “Betrieben” ist ein Dauerzustand: Es muss auch in drei Monaten noch sicher sein, wenn eine neue Schwachstelle bekannt wird. Es muss durchhalten, wenn an einem Tag zehnmal so viele Leute draufklicken wie sonst. Es muss nachweisbar DSGVO-konform bleiben, nicht nur beim ersten Deploy. Kein Prompt der Welt baut das automatisch mit, weil kein Prompt eine dauerhafte Betriebsverantwortung beschreibt. Genau diese Lücke, zwischen “einmal gebaut” und “dauerhaft betrieben”, ist das, was ein Cleanup schließt.

Was ein Cleanup konkret ist, und was nicht

Ein Cleanup ist kein Rewrite. Der Prototyp funktioniert ja, das ist der Punkt, an dem KI-Tools wie Cursor, Lovable, Bolt oder Claude Code richtig gut sind. Was fehlt, ist meistens nicht Funktionalität, sondern das, was beim Prompten selten mitgedacht wird: Absicherung, Struktur, die dauerhaft trägt, und ein Blick, der nicht nur “läuft es” fragt, sondern “hält es”.

Sieben Bereiche, die in der Praxis fast immer betroffen sind:

Sicherheit

Hartkodierte API-Keys, fehlende Row-Level-Security, offene Endpunkte, keine Rate Limits. Nichts davon fällt beim Testen im Browser auf, alles davon fällt auf, sobald jemand gezielt danach sucht. Genau das ist der Kern von CVE-2025-48757: 170 von 1.645 untersuchten Lovable-Apps hatten exponierte Endpunkte, weil Row-Level-Security beim Prompten nie zur Sprache kam.

DSGVO und Datenschutz

Wo läuft die App eigentlich? KI-Tools deployen standardmäßig oft auf US-Infrastruktur, auch wenn europäische Nutzerdaten verarbeitet werden, eine klassische Grauzone, die beim Bauen selten thematisiert wird. Dazu kommt: gibt es Auftragsverarbeitungsverträge mit den eingebundenen Diensten, werden Nutzerdaten länger gespeichert als nötig, gibt es überhaupt ein Löschkonzept, und falls Analytics oder Tracking drin ist, läuft das DSGVO-konform oder braucht es einen Cookie-Banner, den bisher niemand eingebaut hat.

Infrastruktur

Wie und wo die App läuft, entscheidet, was passiert, wenn plötzlich mehr los ist als beim Prompten angenommen. Läuft das Deployment automatisiert über eine CI/CD-Pipeline, oder wird manuell hochgeladen, sobald jemand dran denkt? Ohne CI baut und testet niemand vor dem Live-Schalten, jeder Fehler landet direkt bei den Nutzern statt vorher in einer automatisierten Prüfung abzufangen. Merkt irgendetwas, wenn der Dienst down ist, oder merkt das zuerst ein Nutzer? KI-generierte Datenbankabfragen sind zudem oft ineffizient gebaut, unauffällig bei zehn Testern, aber teuer und langsam, sobald echte Last draufkommt.

Barrierefreiheit

Hier hilft KI allein am wenigsten, und das aus einem Grund, der über die üblichen Symptome hinausgeht: Barrierefreiheit ist keine Code-Eigenschaft, sondern eine Aussage darüber, ob ein echter Mensch die Software tatsächlich bedienen kann, mit Screenreader, nur über Tastatur, mit eingeschränktem Sehvermögen. Das kann eine KI kaum zuverlässig beurteilen, weil sie nie selbst mit einem Screenreader durch die eigene Oberfläche navigiert. Sie erkennt zwar die üblichen technischen Symptome (anklickbare divs statt echter button-Elemente, Bilder ohne Alt-Text, Formulare ohne Labels, Farbkontraste, die nur auf einem guten Monitor lesbar sind), aber ob sich das am Ende auch wirklich bedienen lässt, muss ein Mensch tatsächlich ausprobieren, korrigieren, nochmal ausprobieren. Genau dieser iterative Praxistest ist bei Barrierefreiheit nicht optional, sondern der eigentliche Kern der Prüfung. Beim Prompten kommt das praktisch nie vor, weil “barrierefrei” niemand explizit mitbeschreibt. Seit dem Barrierefreiheitsstärkungsgesetz (BFSG), das seit Juni 2025 gilt, ist das für viele digitale Produkte in Deutschland zudem keine Kür mehr, sondern eine echte rechtliche Pflicht.

Struktur und Code-Qualität

KI-Tools bauen in kurzen Zyklen, ein Feature nach dem anderen, ohne Blick aufs große Ganze. Nach ein paar Wochen Prototyp-Entwicklung ist die Codebasis oft ordentlich verschachtelt, mit Logik, die an drei Stellen gleichzeitig lebt, wenn sie sich mal ändern muss. Das merkt man daran, dass jede neue Änderung länger dauert als die davor.

Testing

Die meisten KI-gebauten Prototypen haben null automatisierte Tests, jede Änderung wird von Hand durchgeklickt, so lange, bis das irgendwann keiner mehr konsequent macht. Ein Cleanup sichert zuerst die Pfade ab, die am meisten kosten würden, wenn sie kaputtgehen: Login, Checkout, alles mit Zahlungen oder echten Nutzerdaten.

Der Prozess selbst, der weiterhin mit KI baut

Der Punkt, den die meisten Cleanup-Anleitungen auslassen: Wenn sich am eigentlichen Bau-Prozess nichts ändert, sind dieselben sechs Lücken beim nächsten per Prompt gebauten Feature wieder da. Ein Cleanup, der nur den aktuellen Stand repariert, aber nicht dafür sorgt, dass künftige KI-Durchläufe anders laufen, ist nur eine Momentaufnahme.

Was das konkret heißt, dieselben Bausteine, die schon bei Claude Skills und dem Agent SDK eine Rolle spielen, jetzt als Absicherung statt als Feature:

• Eine echte AGENTS.md oder CLAUDE.md mit Guardrails, keine Wunschliste. Die brauchbare Faustregel dafür: jede Regel drin sollte sich auf einen tatsächlich passierten Fehler zurückführen lassen, nicht auf eine Befürchtung. Sonst wächst die Datei zu einem Dokument, das keiner mehr liest, geschweige denn befolgt. AGENTS.md ist inzwischen kein Ad-hoc-Standard mehr, sondern liegt seit 2026 zusammen mit MCP unter der Linux-Foundation-Agentic-AI-Initiative, gemeinsam getragen von den großen Anbietern.
• Hooks für deterministische Prüfungen statt Vertrauen aufs Modell. Ein Hook, der nach jeder Datei-Änderung automatisch Linting oder einen Typecheck laufen lässt, fängt Fehler mitten im Lauf ab, nicht erst hinterher, wenn längst weitergebaut wurde. Der Unterschied zu einer Regel in der AGENTS.md: ein Hook läuft garantiert, eine Textregel wird bestenfalls befolgt.
• Skills für die Dinge, die immer gleich richtig gemacht werden müssen. Ein Deployment-Check, ein Security-Review-Ablauf, einmal sauber als Skill definiert, statt bei jedem neuen Prompt wieder zu hoffen, dass die KI zufällig an Row-Level-Security denkt.
• Plugins, um das Ganze bündelbar zu machen, wenn mehrere Projekte oder ein Team dieselben Skills, Hooks und MCP-Anbindungen brauchen, statt es in jedem Repo einzeln neu zusammenzustecken.

So sieht das in der Praxis aus, keine abstrakte Wunschliste, sondern zwei konkrete Bausteine. Eine Guardrail-Regel in der AGENTS.md, die genau auf einen der Punkte oben zurückgeht:

## Niemals ohne Row-Level-Security deployen

Jede neue Tabelle mit Nutzerdaten braucht RLS-Policies, bevor sie live geht.
Grund: CVE-2025-48757, 170 von 1.645 untersuchten Apps waren betroffen,
weil das beim Prompten schlicht nie zur Sprache kam.

Und der dazugehörige Hook, der genau diese Regel technisch erzwingt, statt sich darauf zu verlassen, dass sie gelesen wird:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [{ "type": "command", "command": "npm run lint:rls-check" }]
      }
    ]
  }
}

Genau dieses Paar, Regel in der AGENTS.md plus Hook, der sie durchsetzt, ist der Unterschied zwischen “steht dokumentiert” und “kann gar nicht erst passieren”.

Zusammengenommen nennt sich das in der aktuellen Diskussion Harness Engineering, sinngemäß die Trainingsräder für einen KI-Coding-Agenten, die dafür sorgen, dass er auch autonom stabil bleibt, statt bei jedem Lauf neu zu würfeln. Das ist der Unterschied zwischen einem Prototyp, der einmal repariert wurde, und einem Projekt, das ab jetzt sicher mit KI weitergebaut werden kann.

Die vier Phasen, wenn ich das mache

So läuft ein Cleanup bei mir konkret ab, unabhängig davon, mit welchem KI-Tool der Prototyp ursprünglich gebaut wurde:

1. Audit. Vollständiger Codebase-Durchlauf, Security, Datenflüsse, Architektur, DSGVO, Barrierefreiheit. Ergebnis ist ein schriftlicher, priorisierter Befund, keine Vermutung.

2. Priorisieren. Nicht alles, was gefunden wird, ist gleich dringend. Ein exponierter Endpunkt mit echten Nutzerdaten ist etwas anderes als ein bisschen doppelter Code in einer selten genutzten Ecke. Zuerst wird behoben, was wehtut, wenn es schiefgeht.

3. Beheben. Sicherheitslücken schließen, Datenflüsse absichern, Architektur dort entwirren, wo sie tatsächlich im Weg steht. Was funktioniert, bleibt stehen, umgeschrieben wird nur, was muss.

4. Absichern. Tests für die Pfade, die am meisten kosten würden, wenn sie kaputtgehen. Ein Backup-Konzept, das im Ernstfall tatsächlich greift. Monitoring, das merkt, wenn etwas nicht mehr stimmt, bevor ein Nutzer es merkt. Und, wenn danach weiter mit KI gebaut werden soll: eine AGENTS.md mit echten Guardrails plus Hooks, die die wichtigsten davon auch technisch erzwingen, damit die nächste KI-Runde nicht wieder bei null anfängt.

Das ist bewusst kein Alles-oder-nichts-Paket. Nach dem Audit entscheidest du, was davon tatsächlich umgesetzt wird, manches lässt sich mit dem Befund in der Hand auch selbst erledigen.

Woran du merkst, dass es Zeit dafür ist

Ein paar Signale aus der Praxis, keine davon allein ist ein Beweis, aber wenn mehrere zutreffen, lohnt sich ein genauer Blick:

• Das Projekt bekommt jetzt echte Nutzer oder echte Zahlungsdaten, wurde aber nie mit dem Gedanken gebaut.
• Neue Features fühlen sich zunehmend zäher an, jede Änderung bricht etwas anderes.
• Niemand im Team kann mit Sicherheit sagen, wo die API-Keys liegen oder wer worauf Zugriff hat.
• Es gibt keinen Weg zurück zu gestern, falls heute etwas kaputtgeht.
• Die Frage “ist das eigentlich sicher?” wurde bisher nie ernsthaft gestellt, nur “funktioniert es?”.
• Barrierefreiheit oder DSGVO kamen beim Prompten mit keinem Wort vor.

Selbst aufräumen oder aufräumen lassen

Manches davon lässt sich mit Zeit und Recherche selbst angehen. Der Rest, vor allem Auth-Flows und tatsächliche Exploit-Pfade, braucht jemanden, der das schon oft genug gesehen hat, um zu wissen, wonach er sucht. Genau dafür gibt es den Vibecoding Cleanup als Festpreis-Service: Audit zuerst, Umsetzung nur für das, was wirklich gebraucht wird.