Lektion 11. Gescheiterten Vibe-Code retten

Praxistipps — Das reicht zum Loslegen

Die App ist abgestürzt. Der Login, der gestern noch funktionierte, funktioniert nicht mehr. Die Zahlung wird doppelt abgebucht. Je mehr man am Code dreht, desto mehr bricht anderswo etwas. Der KI “Reparier das” zu sagen, macht es schlimmer.

Nicht neu bauen. Neu bauen — in 3 Monaten bricht es an derselben Stelle. Den aktuellen Zustand zuerst sperren.

Es gibt drei Strukturwerkzeuge:

• codistill — Diagnose. Extrahiert automatisch API-Endpoints, DB-Schema und Authentifizierungsflüsse aus dem vorhandenen Code.
• huma — Sperrung. Setzt Regressionstests auf alle Endpoints, um das aktuelle Verhalten zu schützen.
• yongol — Übergang. Generiert ein neues Backend aus dem SSOT und beweist mit den bestehenden Tests identisches Verhalten.

Von links nach rechts vorgehen. Mit codistill diagnostizieren, mit huma sperren, mit yongol übergehen wenn man bereit ist.

An den Agenten: “Führe codist scan aus, um die Endpoint-Liste, das DB-Schema und die Authentifizierungsflüsse dieses Projekts zu extrahieren.”

Der aktuelle Stand erscheint. Man sieht, wie viele der 25 Endpoints aktiv und wie viele tot sind.

An den Agenten: “Führe huma verify aus, um den Zustand aller Endpoints zu prüfen, und schreibe für jeden aktiven Endpoint einen Hurl-Test.”

Das ist der Regressionstest. Was jetzt funktioniert, wird gesperrt. Solange diese Tests bestehen, kann der Agent Code ändern, ohne das bestehende Verhalten zu brechen.

An den Agenten: “Korrigiere jetzt den Login-Bug. Aber alle Hurl-Tests müssen bestehen.”

Den Bug beheben, ohne anderes zu zerstören. Reparieren mit eingerastet Klinke.

Schnelltest

Auch ohne kaputte App kann man das erleben. Den Prozess “bauen → kaputt machen → retten” in 3 Minuten durchleben.

Schritt 1 — App bauen

In Claude Code:

“Erstelle eine einfache Aufgabenlisten-API. 5 Endpoints: Aufgaben auflisten, Aufgabe hinzufügen, Aufgabe bearbeiten, Aufgabe löschen, Aufgabe als erledigt markieren. Starte den Server.”

Schritt 2 — Mit codist diagnostizieren

“Führe codist scan aus, um die Endpoint-Liste dieses Projekts zu extrahieren.”

codist extrahiert automatisch Pfad, Methode und Parameter der 5 Endpoints. Das ist die aktuelle Karte.

Schritt 3 — Mit huma sperren

“Führe huma verify aus und schreibe Hurl-Tests für alle Endpoints.”

Für jeden der 5 Endpoints wird eine Hurl-Datei erstellt. Das aktuelle Verhalten ist gesperrt.

Schritt 4 — Absichtlich kaputt machen

“Ändere das Antwortformat des Aufgaben-Bearbeitungs-Endpoints. Benenne das Feld title in name um.”

Nach der Änderung:

“Führe die Hurl-Tests aus.”

Die Tests schlagen fehl. “title erwartet, aber name erhalten.” Die Drift ist erkannt. Die Klinke greift.

Schritt 5 — Mit eingerasteter Klinke reparieren

“Korrigiere so, dass alle Hurl-Tests bestehen. Aber die neue Funktion mit dem name-Feld muss auch beibehalten werden.”

Der Agent behält die Abwärtskompatibilität bei der Korrektur. Wenn Hurl besteht, ist das bestehende Verhalten erhalten.

Das ist die Miniaturversion von codistill → huma → Reparatur. Bei einer echten kaputten App skaliert dieser Prozess auf 25, 50, 200 Endpoints — das Prinzip bleibt dasselbe.

Warum so vorgehen

Einleitung: der wahre Grund, warum Ihre App abgestürzt ist

2025 wurde die Datenbank von 170 mit Lovable erstellten Apps vollständig im Internet exponiert. E-Mails, API-Schlüssel, Zahlungsinformationen. Die Ursache war kein Code-Bug. Die KI hatte Apps ohne Sicherheitsrichtlinien erstellt, und niemand hatte es geprüft.

Im Januar 2026 sind 1,5 Millionen API-Token aus Moltbook, dem KI-sozialen Netzwerk, geleakt. Gleiche Ursache. Die KI hat gebaut, Menschen haben nicht geprüft.

Das ist keine Geschichte von jemand anderem. Wer eine App mit Vibe Coding gebaut hat, sitzt auf derselben Struktur.

“Erstelle den Login” — 30 Sekunden. “Füge Zahlung hinzu” — 2 Minuten. “Füge Admin-Dashboard hinzu” — 5 Minuten. Drei Monate später “bereinigt” die KI die Zahlungslogik und ändert die Rabattberechnung, eine neue Funktion bricht die Authentifizierung, und eine Seite die gestern noch funktionierte gibt heute 500-Fehler zurück.

Man steht vor zwei Optionen:

1. Neu bauen
2. Retten

Neu bauen hätte man vor 3 Monaten können. Das Problem: Neu bauen wiederholt dieselben Muster. Drift ist kein Code-Problem — es ist ein Strukturproblem.

Man muss lernen zu retten.

Selbstrettung des Gestrandeten — 5 Schritte

Eine kaputte App zu retten ist wie das Bewältigen eines Bergnotfalls. Nicht rennen. Die aktuelle Position bestimmen, Sicherheit herstellen, Schritt für Schritt vorgehen.

Schritt 1. Diagnose — was lebt noch?

Das erste, was zu tun ist, ist nicht den Code zu korrigieren. Es ist den aktuellen Zustand zu erfassen.

An den Agenten: "Scanne alle API-Endpoints dieses Projekts.
Sende echte Anfragen an jeden Endpoint
und protokolliere die Antwort-Statuscodes.
Präsentiere die Ergebnisse in einer Tabelle: Pfad, Methode, Statuscode, Antwortzeit."

Wenn 18 von 25 Endpoints 200 zurückgeben, 4 geben 401 und 3 geben 500 — das ist die aktuelle Karte. Reparaturen ohne Karte zu starten bedeutet, beim Korrigieren anderes zu zerstören.

codist scan von codistill automatisiert diese Arbeit. Es extrahiert Endpoints, Datenmodelle und Authentifizierungsflüsse aus dem vorhandenen Code.

Schritt 2. Sperrung — erst schützen was lebt

Nach der Diagnose die aktiven Endpoints sperren.

An den Agenten: "Schreibe Hurl-Tests für jeden
der 18 Endpoints, die 200 zurückgeben.
Nimm die aktuelle Antwort als erwarteten Wert.
Für die, die Authentifizierung benötigen, führe zuerst
die Login-Sequenz aus um den Token zu erhalten."

Diese 18 Hurl-Dateien sind das Sicherheitsnetz. Was auch immer danach geändert wird — wenn diese Tests bestehen, ist das bestehende Verhalten erhalten.

huma verify von huma strukturiert diesen Prozess. Es verfolgt den Zustand pro Endpoint und bestimmt PASS/IMPROVE/FAIL.

Wichtig: Teilsperrung reicht nicht. Sperrt man nur 10 der 18 Endpoints, können die anderen 8 während der Reparatur brechen ohne dass man es bemerkt. Vollsperrung ist das Prinzip.

Schritt 3. Reparatur — mit eingerasteter Klinke korrigieren

Mit dem Sicherheitsnetz kann man jetzt Bugs beheben.

An den Agenten: "Finde und behebe die Ursache des Login-Fehlers.
Aber alle Hurl-Tests müssen bestehen.
Wenn auch nur einer scheitert, mache die Änderung rückgängig."

Das ist die praktische Anwendung des in Lektion 6 gelernten Ratchet Pattern. Korrigieren ohne zu zerstören. Nach jeder Reparatur Hurl ausführen. Wenn bestanden, zum nächsten Bug. Wenn gescheitert, zurücksetzen.

Die 3 Endpoints mit 500-Fehlern werden auf dieselbe Weise repariert. Nach der Reparatur neue Hurl-Tests hinzufügen. Die Klinke rastet einen Zahn tiefer ein.

Schritt 4. Extraktion — Logik aus der Black Box holen

Hier liegt der Kern. Die eigentliche Ursache für den App-Absturz liegt meistens hier.

Wenn man Supabase verwendet:

• RLS-Richtlinien sind nur im Dashboard, nicht im Code
• Geschäftslogik ist in Edge Functions versteckt
• Authentifizierungslogik ist an Supabase Auth gebunden

Wenn man Firebase verwendet:

• Security Rules sind nur in der Console
• Logik ist in Cloud Functions verteilt

Welchen BaaS man auch immer nutzt, die Struktur ist dieselbe. Die Geschäftslogik befindet sich außerhalb der Code-Basis.

An den Agenten: "Extrahiere alle RLS-Richtlinien aus dem Supabase-Dashboard.
Speichere die SELECT-, INSERT-, UPDATE-, DELETE-Richtlinien
jeder Tabelle in SQL-Dateien. In git committen."

An den Agenten: "Analysiere die Geschäftslogik der Edge Functions.
Dokumentiere, welche Funktion welche Geschäftsregel implementiert."

Es geht darum, die Logik aus der Black Box in die Code-Basis zu holen. Erst wenn sie draußen ist, kann der Agent sie lesen, testen und mit der Klinke sperren.

codist ddl von codistill extrahiert das DDL aus der bestehenden DB. codist scan extrahiert das SSOT aus dem Code. Das ist das Werkzeug um von der Black Box zur deklarativen Schicht zu wechseln.

Schritt 5. Übergang — nur wenn man bereit ist

Nach den Schritten 1 bis 4 ist die App in folgendem Zustand:

• Alle Endpoints haben Hurl-Regressionstests
• Bugs sind behoben
• Die Logik der Black Box ist in der Code-Basis dokumentiert
• Die Klinke ist eingerastet: neue Änderungen zerstören nicht das bestehende Verhalten

In diesem Zustand wird der Übergang entschieden. Von Supabase zu einem eigenen Backend, von Deno zu Go, was auch immer.

Das Sicherheitsnetz des Übergangs sind die in Schritt 2 geschriebenen Hurl-Tests. Dieselben Hurl-Tests auf dem neuen Server ausführen — wenn alle bestehen, ist bewiesen, dass das Verhalten identisch zum Legacy ist.

An den Agenten: "Generiere ein Go+Gin-Backend mit yongol generate.
Alle bestehenden Hurl-Tests müssen bestehen."

Der Übergang ist Schritt 5, nicht Schritt 1. Den Übergang in Schritt 1 zu versuchen führt zum Scheitern. Lektion bestätigt bei Post-Incident-Onboardings.

So kommt man aus Supabase heraus

Der häufigste Fall in Lektion 11 ist Supabase. Man beginnt mit Vibe Coding, setzt alles auf Supabase, und in 3 Monaten bricht es.

Reihenfolge zum Herausfinden:

1. DB behalten und nur die Klinke einrasten

Das PostgreSQL von Supabase bleibt wie es ist. Die DB zu wechseln ist das Letzte.

codist ddl → DDL aus bestehenden Tabellen extrahieren
huma verify → Endpoint-Zustand ermitteln
hurl → alle aktiven APIs vollständig sperren

2. Logik in Code migrieren

RLS-Richtlinien → Rego-Dateien. Edge Functions → SSaC-Annotationen. Vom Dashboard in die Code-Basis.

3. Authentifizierung trennen

Supabase Auth ist das Letzte was abgetrennt wird. Da Passwort-Hashes aus auth.users nicht extrahierbar sind, sofort wechseln wenn man in der Anfangsphase ist (ohne Kunden); wenn Kunden vorhanden sind, eine Doppel-Authentifizierungsperiode betreiben.

4. Neuen Server aufsetzen und mit Hurl validieren

yongol generate → Go+Gin-Backend generieren
alle Hurl ausführen → identisches Verhalten zum Legacy beweisen

Wenn alle Hurl bestehen, den Datenverkehr umschalten.

Warum nicht neu bauen

“Kann man nicht einfach neu bauen?”

Nein. Drei Gründe:

1. Dasselbe Muster wiederholt sich

Drift ist ein Strukturproblem, kein Code-Problem. Ohne Klinke neu bauen — in 3 Monaten bricht es an derselben Stelle.

2. Im Legacy steckt Wissen

Die über 3 Monate Vibe Coding angesammelten Geschäftsregeln sind im Code. Neu bauen bedeutet, diese Regeln aus dem Gedächtnis zu rekonstruieren. Das Gedächtnis irrt sich.

3. Es könnte bereits Kunden geben

Es gibt einen Moment, wo der Prototyp zur Produktion wird. Wenn auch nur 1 Benutzer vorhanden ist, bringt “neu bauen” Datenmigration, Authentifizierungswechsel und Ausfallzeiten mit sich.

Retten lernen ist wertvoller als neu bauen lernen. Denn Legacy existiert immer, und neuer Code wird in 6 Monaten zum Legacy.

Die Beziehung zwischen den Lektionen 1 bis 10 und Lektion 11

Gleiche Werkzeuge, entgegengesetzte Richtung. Wenn die Lektionen 1 bis 10 “von oben nach unten” waren (Deklaration → Generierung), geht Lektion 11 “von unten nach oben” (vorhandener Code → Extraktion → Deklaration).

codistill ist das Werkzeug, das dieses “von unten nach oben” automatisiert. Es extrahiert das SSOT aus dem vorhandenen Code.

Vom Gestrandeten zum Retter

Nach diesem Prozess verfügt man über zwei Fähigkeiten:

1. Von Anfang an bauen (Lektionen 1 bis 10) — deklarieren, validieren, sperren, verstetigen
2. Gescheitertes retten (Lektion 11) — diagnostizieren, sperren, reparieren, extrahieren, übergehen

Der Großteil des Codes in der Welt ist Legacy. Projekte, die von Grund auf neu gebaut werden, sind selten. Die Fähigkeit zu retten wird häufiger gebraucht.

Vibe Coding ist nicht vorbei. Man hat gelernt, die Zügel zu halten.

Verwandte Artikel

• Supabase ist eine Falle des Vibe Codings — Theoretischer Hintergrund von Lektion 11. Warum BaaS abstürzt.
• Hurl verhindert die Drift beim Vibe Coding — Details zu Schritt 2: Sperrung.
• codistill — SSOT aus bestehendem Code extrahieren — Das Werkzeug für Schritte 1 und 4.
• huma — die Klinke die keinen Endpoint übersieht — Das Werkzeug für Schritt 2: Sperrung.
• yongol — der Kiel des KI-Coding-SaaS — Das Werkzeug für Schritt 5: Übergang. Fullstack-Generierung aus SSOT.
• Eine für Agenten bedienbare Code-Basis — Das Prinzip, eine Black Box in eine Fabrik zu verwandeln.
• tsma — die Regressions-Verteidigungslinie für Legacy-Code — Reparieren mit eingerasteter Klinke.
• Für Agenten bedienbare Systeme bauen — Legacy für Agenten zugänglich machen.

Reins Engineering Gesamtkurs

Quellenangaben

• Feathers, M. (2004). Working Effectively with Legacy Code. Prentice Hall. — Characterization testing의 원전. 레거시 코드에 테스트를 감싸서 현재 동작을 잠그는 기법. 11강 2단계의 이론적 기초.
• CVE-2025-48757 (2025). Lovable 생성 앱 170+ RLS 누락으로 Supabase DB 노출. ameeba.com
• OG William (2026). “Moltbook Hack: Supabase Vibe Coding.” 1.5M API 토큰 노출. blog.ogwilliam.com
• Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427 — Cursor 도입 후 코드 복잡도 41.6% 영구 증가. 바이브 코딩이 터지는 정량적 근거.
• Liu, Z. et al. (2026). “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild.” arxiv.org/abs/2603.28592 — 6,299개 리포지토리, 302,600건 AI 커밋 분석. 미해결 기술 부채가 2025년 초 수백 건에서 2026년 2월 110,000건 이상으로 급증.
• Storey, M.-A. (2026). “From Technical Debt to Cognitive and Intent Debt.” arxiv.org/abs/2603.22106 — 드리프트의 근본 원인을 “인지 부채”(공유 이해 침식)와 “의도 부채”(근거의 미외부화)로 이론화.
• Nguyen, H. et al. (2025). “Vibe Coding in Practice: Flow, Technical Debt, and Guidelines for Sustainable Use.” arxiv.org/abs/2512.11922 — 바이브 코딩의 flow-debt 트레이드오프를 문서화한 최초의 학술 논문.
• Cloud Security Alliance (2026). “Vibe Coding Security Crisis: Credential Sprawl and SDLC Debt.” labs.cloudsecurityalliance.org — AI 생성 코드의 45%가 OWASP Top 10 취약점 포함. AI 커밋의 시크릿 노출률 2배.
• GitClear (2025). “AI Copilot Code Quality 2025.” gitclear.com — 2.11억 라인 분석. 코드 중복 4배 증가, 리팩토링 비율 25% → 10% 감소.
• Encore (2026). “Backend as a Service (BaaS) in 2026: Providers, Tradeoffs, and Migration Paths.” encore.dev — BaaS 이탈은 포팅이 아니라 백엔드 재작성.