Was die KI in deinem Code wirklich gebaut hat

Du siehst die App. Die KI sieht den Prompt.

Du promptest: “Füge Login hinzu.” Die KI baut ein Login. Es funktioniert. Du siehst einen Anmeldebildschirm, du kannst dich einloggen, die App geht weiter.

Was du nicht siehst: Die KI hat das gelöst, was du in dieser Session gefragt hast. Nicht mehr und nicht weniger. Nicht die sicherste Lösung. Nicht die, die im App Store akzeptiert wird.

Und wenn du in der nächsten Session sagst “das Login funktioniert nicht richtig, fix es”, erinnert sie sich an was du gebaut hast, aber nicht daran warum. Sie baut vielleicht einfach ein zweites.

Das ist kein Bug. Das ist wie KI-Code-Generierung funktioniert.

Die häufigsten Befunde

Aus echten Audits von Vibe-Coding-Projekten, anonymisiert, aber unverändert in der Substanz.

1. API-Keys im Client-Code

Das häufigste Problem. Die KI braucht einen API-Key, um Supabase, Firebase oder einen externen Service anzubinden. Also schreibt sie ihn dahin, wo er am schnellsten funktioniert: in den Code.

Das Problem: Client-Code wird ausgeliefert. Bei einer Web-App liegt er im Browser. Bei einer nativen App lässt er sich aus dem Bundle extrahieren. Jeder kann ihn lesen. Was das im Ernstfall bedeutet, hat t3n dokumentiert: ein Entwickler bekam eine Rechnung über 82.000 Dollar, weil sein API-Key im Code lag.

Wie du es erkennst: Suche in deinem Code nach supabaseKey, apiKey, NEXT_PUBLIC_, EXPO_PUBLIC_. Wenn diese Werte direkt im Code stehen (nicht in .env-Dateien), sind sie öffentlich.

Was du tun kannst: Keys gehören in Umgebungsvariablen. Sensible Operations gehören auf den Server, nicht in den Client. Supabase hat dafür Service Role Keys, die nur serverseitig verwendet werden dürfen.

2. Mehrere Auth-Systeme parallel

Die KI hat kein Gedächtnis für Architekturentscheidungen. Wenn du in Prompt 12 ein Login baust und in Prompt 47 sagst “der User soll sich anmelden können”, baut sie möglicherweise ein zweites System. Oder ein drittes.

Wer mid-project die Auth-Lösung wechselt, von Supabase Auth zu Clerk oder von Firebase zu etwas eigenem, bekommt von der KI das Neue implementiert. Das Alte bleibt. Die KI räumt nicht auf, das macht sie generell ungern. Der alte Code liegt still im Projekt, bis er irgendwann mit dem neuen kollidiert. Das hängt mit dem Sycophancy-Problem bei KI-Modellen zusammen: Die KI bestätigt jede neue Richtung, statt auf Widersprüche hinzuweisen.

Wie du es erkennst: Suche nach signIn, login, authenticate, createSession in deinem Code. Wenn du mehr als eine Implementierung findest, hast du ein Problem.

Was du tun kannst: Entscheide dich für ein Auth-System. Supabase Auth, Firebase Auth, Clerk: eines. Lösche den Rest. Sag der KI explizit: “Verwende ausschließlich Supabase Auth. Baue kein eigenes Login-System.”

3. Keine Row Level Security

Supabase-Projekte ohne RLS-Policies sind offen wie ein Scheunentor. Jeder angemeldete User kann alle Daten aller User lesen, und oft auch schreiben und löschen.

Die KI setzt Row Level Security selten von sich aus auf. Warum? Weil die App auch ohne RLS funktioniert. Der Prototyp läuft. Du merkst es nicht. Erst wenn jemand anderes die API aufruft, wird das Problem sichtbar. Bei einer Analyse von 670 KI-generierten Websites war fast jede zweite Datenbank von außen zugänglich.

Wie du es erkennst: Öffne dein Supabase Dashboard → Table Editor → klicke auf eine Tabelle → prüfe ob “RLS enabled” angezeigt wird. Wenn nicht: offen.

Was du tun kannst: Aktiviere RLS für jede Tabelle. Schreibe Policies, die regeln wer was sehen und ändern darf. Minimum: auth.uid() = user_id auf jeder Tabelle mit Nutzerdaten.

4. Zu viele Datenbank-Tabellen

Jeder Prompt, der ein neues Feature beschreibt, erzeugt oft eine neue Tabelle. Die KI optimiert nicht auf Gesamtstruktur. Sie optimiert darauf, dass dieser Prompt jetzt funktioniert.

Dutzende Tabellen für ein MVP mit wenigen Kernfunktionen. Keine Migrationen, keine Versionierung. Jede Änderung direkt in der Datenbank, ohne Möglichkeit sie rückgängig zu machen.

Wie du es erkennst: Zähle deine Tabellen. Wenn du mehr als 10-12 für ein MVP hast, ist wahrscheinlich etwas schief gelaufen.

Was du tun kannst: Zeichne auf einem Blatt Papier deine drei Kernfunktionen. Welche Daten braucht jede? Welche Tabellen gehören zusammen? Dann bereinige und richte Migrationen ein, damit Änderungen nachvollziehbar sind.

5. DSGVO: Unvollständig oder fehlend

Kein Einwilligungsdialog. Keine Datenschutzerklärung. Kein Löschrecht. Kein Auftragsverarbeitungsvertrag mit dem Hosting-Provider. Manchmal sensible Daten (Gesundheit, Finanzen) unverschlüsselt gespeichert.

Die KI kennt DSGVO als Konzept. Aber sie implementiert sie nicht von sich aus. Und wenn du “mach die App DSGVO-konform” promptest, bekommst du oft einen Cookie-Banner, der für eine native App völlig irrelevant ist.

Wie du es erkennst: Frag dich: Kann ein User seine Daten exportieren? Kann er seinen Account löschen? Gibt es eine Datenschutzerklärung? Weißt du, wo die Daten gespeichert werden und ob der Server in der EU steht?

Was du tun kannst: DSGVO ist kein Feature, das du einmal implementierst. Es ist eine Anforderung, die du von Anfang an mitdenkst. Account-Löschung, Datenexport, Einwilligung, Impressum, Datenschutzerklärung: das sind Pflichtfelder für den Store.

Das Muster

Keines dieser Projekte musste komplett neu geschrieben werden. Das ist die gute Nachricht. Die KI baut funktionierenden Code. Die Grundstruktur stimmt meistens. Die Screens funktionieren. Die Logik ist da.

Aber die Stellen, an denen es scheitert, sind immer dieselben: Sicherheit, Architektur, Recht. Das sind die Dinge, die kein User sieht, die aber darüber entscheiden, ob die App im Store akzeptiert wird, ob sie sicher ist, ob sie skaliert. Warum Vibe Coding inzwischen ein Mainstream-Problem ist, zeigen die Reaktionen von Apple und die aktuelle t3n-Recherche.

Das Gefährliche ist nicht, dass die KI Fehler macht. Das Gefährliche ist, dass du sie nicht siehst. Die App auf deinem Handy funktioniert einwandfrei.

---