Halluzinierte Funktionen aus KI-generierten Repositories sicher entfernen

Was halluzinierte Funktionen sind (und warum sie schaden)

Halluzinierte Funktionen sind Teile des Codes, die wie echte Produktarbeit aussehen, aber nie echte Anforderungen waren. In KI-generierten Repositories tauchen sie oft als zusätzliche Bildschirme, Routen, API-Endpunkte oder Datenbanktabellen auf, weil das Tool geraten hat, was eine „fertige App" enthalten sollte.

In der Praxis kann das eine aufbereitete Einstellungsseite sein, die niemand erreicht, eine „admin"-API, die nie aufgerufen wird, oder eine „subscriptions"-Tabelle, in die nichts geschrieben wird. Alles kompiliert, aber die Funktion ist nicht in echte Nutzerbedürfnisse oder funktionierende Abläufe eingebunden.

Die Kosten sind nicht nur Unordnung. Jede zusätzliche Seite, jeder Endpunkt und jede Tabelle vergrößert die Angriffsfläche der App. Das bedeutet mehr Orte für Bugs, mehr Wege, wie Geheimnisse geleakt werden können, und mehr verwirrende Pfade für spätere Wartende.

Ghost-Funktionen erhöhen Risiko und Kosten, weil sie:

• Beim Debugging Lärm erzeugen und das eigentliche Problem verbergen.
• Die Sicherheitsfläche durch zusätzliche Endpunkte, halb fertig implementierte Auth-Prüfungen und unsichere Defaults erweitern.
• Änderungen verlangsamen, weil man Angst hat, unbekannte Abhängigkeiten zu brechen.
• Produktentscheidungen in die Irre führen, weil das Repo Fähigkeiten suggeriert, die nicht existieren.
• Wartungsaufwand erhöhen (Tests, Migrationen, Refactors) für Dinge, die niemand nutzt.

Solche Funktionen entstehen meist durch KI-Scaffolds, die „standard"-Module generieren, kopierte Templates oder Prompt-Threads, in denen eine Funktion begonnen und nie fertiggestellt wurde. Manchmal war die Idee sinnvoll, sie wurde aber nie in eine echte Nutzerreise eingebunden.

Das Ziel ist einfach: Behalte, was echte Nutzer unterstützt, und lösche, was das nicht tut — ohne kritische Abläufe zu zerstören. Ein typisches Szenario ist ein KI-erstelltes MVP mit drei verschiedenen Login-Bildschirmen, zwei Admin-Dashboards und einem Abrechnungs-Schema, das nichts tut. Das Aufräumen macht die App sicherer und billiger in der Weiterentwicklung.

Die drei Haupttypen: tote Seiten, unbenutzte APIs, Platzhaltertabellen

Beim Entfernen halluzinierter Funktionen konzentriert sich das Risiko meist auf drei Bereiche. Sie liegen ruhig im Repo, erhöhen aber die Angriffsfläche, Verwirrung und zukünftige Wartungsarbeit.

1) Tote Seiten (unerreichbare Routen)

Tote Seiten sind Bildschirme, die im Router existieren, die echte Nutzer aber nie erreichen. Sie treten oft als verwaiste Flows wie "Team Settings", "Billing" oder "Admin" auf, die früh generiert und dann vergessen wurden.

Sie sind trotzdem relevant, weil neugierige Nutzer sie entdecken, teilen, indexieren oder direkt öffnen können. Selbst eine halb fertige Seite kann interne Daten leaken, laute Fehler werfen oder Feature-Flags und Umgebungsinformationen offenbaren.

2) Unbenutzte APIs (Endpunkte ohne echte Aufrufer)

Unbenutzte APIs sind Serverrouten, die keine echten Frontend-Aufrufer haben oder nur von einer übrig gebliebenen Testseite oder einem Beispielskript genutzt werden. Diese Endpunkte werden leicht unabsichtlich deployed, besonders wenn alles in einem generischen API-Ordner liegt.

Die Gefahr ist nicht nur zusätzlicher Code. Unbenutzte Endpunkte umgehen oft Auth-Prüfungen, akzeptieren zu breite Eingaben oder geben mehr Daten zurück, als sie sollten. Das macht sie zu weichen Zielen.

3) Platzhaltertabellen (fingierte Strukturen in der Datenbank)

Platzhaltertabellen sehen nach Fortschritt aus, sind aber oft leere Hüllen: generische Spalten, keine Constraints, keine Indizes und keine echten Lese- oder Schreibzugriffe in der App.

Sie führen auch zu falschen Annahmen in zukünftiger Arbeit. Jemand sieht die Tabelle und geht davon aus, dass das Feature existiert, und baut darauf weiter. So werden „temporäre" Schemata zur langfristigen Schuld.

Weitere Signale für halluzinierte Funktionen sind Module voller TODOs, Demo-Admin-Bildschirme, die Berechtigungen umgehen, Mock-Authentifizierung, die jede E-Mail akzeptiert, und Konfigdateien für Dienste, die ihr nicht verwendet.

Bevor du löschst: definiere, was „sicher" für deine App bedeutet

Code zu entfernen ist nur sicher, wenn ihr euch einig seid, was sich nicht ändern darf.

Beginnt mit den Schlüsselabläufen, nicht mit Dateien. Für die meisten Apps sind das Signup, Login, Passwort-Reset, Logout und alle Geld- oder Datenaktionen wie Checkout, Datensatz erstellen, Export oder Einladen eines Teammitglieds. Wenn euer Team täglich einen internen Admin-Bildschirm nutzt, muss der dazugezählt werden.

Seid ehrlich darüber, wer die App heute nutzt. Zahlende Nutzer erfordern die meiste Vorsicht. Eine interne Demo, die von zwei Personen verwendet wird, kann mehr Änderungen vertragen. Wenn sie noch niemand nutzt, kann „sicher" einfach bedeuten: die Demo funktionsfähig lassen und alles entfernen, das Risiko erhöht.

Eine einfache Entscheidungsregel verhindert lange Debatten:

• Jetzt entfernen: keine Nutzer, keine Referenzen, klarer Platzhalter oder Risiko.
• Archivieren: könnte später zurückkehren, darf aber nicht in Produktion laufen.
• Behalten, aber markieren: wird heute genutzt, braucht einen Owner oder eine Überarbeitung.

Eure Akzeptanzregel kann schlicht sein: „Keine Verhaltensänderung in den Schlüsselabläufen." Dieselben Buttons tun dasselbe, dieselben Seiten laden, und dieselben Daten landen am selben Ort. Wenn sich Verhalten ändern muss, ist das kein Löschen, sondern ein Redesign.

Bevor ihr etwas anfasst, richtet ein Rollback ein. Haltet einen bekannten guten Commit bereit, bestätigt, wie er redeployt wird, und entscheidet, wer einen Rollback genehmigen darf, falls etwas kaputtgeht.

Wie man tote Seiten und verwaiste Routen findet

Tote Seiten sind Bildschirme im Repo, die nicht im Produkt existieren. Verwaiste Routen sind URLs, die technisch funktionieren, aber von nichts in der App referenziert werden.

Fangt bei dem an, worauf ein Nutzer tatsächlich klicken kann. Öffnet jedes Navigationsmenü, Header, Footer, Sidebar und Profil-Dropdown und listet die Ziel-URLs auf. Vergleicht das mit eurer Routen-Konfiguration (Router-Dateien, pages-Ordner, Routen-Arrays). Alles, was in den Routen steht, aber nicht über Navigation erreichbar ist, ist ein Kandidat.

Schnelle Orte zum Nachschauen:

• Routen, die nie von einer Menükomponente referenziert werden.
• Seiten/Komponenten, die nur in Kommentaren, Mock-JSON oder Seed-Daten auftauchen.
• "Temporäre" Pfade wie /admin, /debug, /test, /demo, /old, /v2, /settings-2.
• Routen, die durch Bedingungen geschützt sind, die niemals eintreten (ein Flag, das immer false ist, oder eine Rolle, die nie zugewiesen wird).

Wenn ihr Analytics oder Server-Logs habt, nutzt sie als Realitätsscheck. Eine Route mit null Hits über Wochen ist ein starkes Signal, besonders wenn sie nicht Teil eines Admin-Workflows ist. Ohne Logs macht eine manuelle Crawl: klickt die Hauptflows durch und versucht einige wahrscheinliche URLs direkt.

Beispiel: Ein KI-erstelltes MVP könnte /team/invite und /billing/upgrade enthalten, weil das Prompt „SaaS" erwähnte. Wenn diese Seiten keine Links, keine Tests und keine Backend-Verknüpfung haben, sind sie meist sicher zu entfernen oder zu isolieren.

Wie man unbenutzte oder riskante API-Endpunkte findet

KI-generierte Repos liefern oft Endpunkte, die beim Prototyping nützlich klangen, aber nie Teil des Produkts wurden. Beginnt mit einem Inventar und belegt dann, wer jeden Endpunkt aufruft.

Zuerst listet jede Route aus dem Backend auf (Router-Dateien, Controller, Serverless-Funktionen und api-Ordner). Scannt außerdem die Konfiguration auf Rewrites, die Handler exponieren könnten.

Verfolgt dann Aufrufer. Sucht im Frontend nach fetch oder axios, prüft Hintergrund-Jobs und Queues und sucht nach Webhook-Handlern, die von Dritten getroffen werden. Wenn ihr Logs habt, durchsucht die letzten 7 bis 30 Tage nach Pfaden. Kein Traffic ist kein perfekter Beweis, aber ein starkes Indiz.

Markiert riskante Endpunkte, bevor ihr löscht. Häufige Warnsignale sind Debug-Routen, die in Produktion erreichbar sind, Auth-Bypass (hartkodierte Admin-Tokens, userId in Query-Params), weit aufgemachte CORS für sensible Routen, fehlende Validierung und Endpunkte, die Secrets oder detaillierte interne Fehler zurückgeben.

Für jeden Endpunkt wählt ein Resultat: löschen, absichern (öffentliche Routing entfernen, Zugriff einschränken) oder behalten und ordentlich mit Auth, Validierung und Rate-Limits versehen.

Wie man Platzhaltertabellen und fingierte Datenstrukturen erkennt

KI-generierte Repos enthalten manchmal eine Datenbank, die vollständig aussieht, aber teilweise imaginär ist. Platzhaltertabellen verwirren Entwickler, verbergen echte Fehler und erhöhen das Risiko, wenn „temporäre" Tabellen stillschweigend echte Nutzerdaten aufnehmen.

Beginnt damit, jede Tabelle und Spalte aufzulisten und nachzuverfolgen, was sie tatsächlich berührt. Eine Tabelle ist in der Regel real, wenn die App sie liest, beschreibt und sie klare Beziehungen zu Kern-Tabellen (users, orders, projects) hat. Wenn sie nur in einer Migration auftaucht und sonst nirgends, ist sie verdächtig.

Anzeichen für Platzhaltertabellen

Ein paar verlässliche Signale:

• Namen wie sample_*, demo_*, temp_*, test_*, mock_*, staging_*, placeholder_*.
• Keine Foreign Keys und keine Indizes, obwohl Beziehungen zu anderen Tabellen zu erwarten sind.
• Generische Spalten wie data JSON, value TEXT, meta TEXT, notes TEXT ohne klare Bedeutung.
• Fake-ähnliche Daten (lorem ipsum, gefälschte E-Mails, feste IDs wie user_id = 1).
• Duplikate (zwei Versionen von "subscriptions", "payments" oder "profiles").

Prüft auch Migrationen auf verwaiste Experimente: Eine Migration erstellt eine Tabelle, eine andere eine andere Version, und nichts räumt die alte auf. Wenn mehrere Tabellen dasselbe Konzept abbilden, verlangsamt euch und verifiziert, welches Schema die laufende App erwartet.

Wenn ihr entscheidet, was zu tun ist, wählt einen Weg: droppen, mergen oder richtig neu aufbauen. Droppen ist nur sicher, wenn ihr bestätigt habt, dass es keine Lese- oder Schreibzugriffe und keine Reporting-Jobs gibt, die sie nutzen.

Schritt für Schritt: halluzinierte Funktionen löschen, ohne die App zu brechen

Das Löschen des falschen Teils kann Login, Berechtigungen oder Billing kaputtmachen. Behandelt jede verdächtige Funktion wie eine kleine Change-Request, auch wenn ihr sicher seid, dass sie fake ist.

Für jede tote Seite, jeden unbenutzten Endpunkt oder jede Platzhaltertabelle notiert drei Dinge: was nach dem Entfernen passieren soll, wie ihr verifiziert, dass nichts Wichtiges davon abhängig war, und wer die Entscheidung genehmigen kann.

Eine risikominimierende Reihenfolge:

• Zuerst versteckte Seiten und unbenutzte UI entfernen.
• Dann unbenutzte API-Handler (plus Hilfsfunktionen, die nur für dieses Feature existieren).
• Datenbank zuletzt aufräumen (Migrationen, ORM-Modelle, Cron-Jobs).

Nach jedem Entfernen baut die App, führt Tests aus (falls vorhanden) und klickt die Schlüsselabläufe durch. Überprüft auch Auth-Grenzen erneut. Es ist möglich, Code so zu entfernen, dass Middleware umgangen oder eine Berechtigungsprüfung verändert wird.

Häufige Fehler, die zu Ausfällen oder Sicherheitsproblemen führen

Breakage passiert oft, wenn das Repo im Browser sauber wirkt, aber versteckte Teile in Produktion noch laufen. Denkt an alles, was ohne Klick aufgerufen werden kann: Jobs, Webhooks, Cron-Tasks und direkte HTTP-Requests.

Eine Falle ist, die Seite oder den Button zu löschen, aber die API dahinter stehen zu lassen. Der Admin-Screen ist weg, doch der Endpunkt akzeptiert weiterhin Anfragen. Bei schwacher Auth wird dieser Endpunkt zum leichten Ziel.

Ein weiterer Fehler ist anzunehmen, ein Endpunkt sei ungenutzt, weil er nicht in der UI verlinkt ist. Hintergrundarbeiter, geplante Tasks und Drittanbieter-Integrationen können ihn trotzdem aufrufen. Beispiel: Ihr löscht /api/email/weekly-summary, weil sie nicht auf einer Seite verwendet wird, aber ein nächtlicher Job ruft sie auf, schlägt fehl und erzeugt erneute Versuche und laute Logs.

Beim Datenbank-Cleanup verliert man leicht Daten. Das Droppen von „Platzhalter"-Tabellen ohne Prüfung von Backups, Migrationsreihenfolge und tatsächlicher Produktionseutzung kann Deploys kaputtmachen oder Datensätze löschen, die später wiederverwendet wurden.

Bevor ihr etwas löscht, überprüft:

• Ihr habt Zugriff entfernt, nicht nur die UI (Routen/Controller sind nicht öffentlich erreichbar).
• Ihr habt nach Job-/Worker-Nutzung und Drittaufrufen/Webhooks gesucht.
• Backups und Migrationssequenz validiert.
• Debug-Routen, Test-Keys und temporäre Admin-Logins aus Produktion entfernt.

Schnelle Checkliste, bevor ihr etwas entfernt

Bevor ihr Code löscht, bestätigt, dass ihr nichts entfernt, das heimlich einen Ablauf zusammenhält.

Beginnt mit Erreichbarkeit. Wenn ein normaler Nutzer eine Seite nicht über normale Klicks erreichen kann (nicht durch direkte Eingabe einer versteckten URL), ist sie ein starker Kandidat. Bestätigt trotzdem, dass ihr keinen Nebenpfad wie Onboarding, Passwort-Reset oder Admin-Setup abschneidet.

Kurze Prüfungen:

• Kann ein normaler Nutzer die Seite ohne spezielle URLs, Testaccounts oder dev-only-Toggles erreichen?
• Wenn es ein API-Endpunkt ist: ist er geschützt (Auth) und abgesichert (grundlegende Eingabeprüfungen, Rate-Limits), oder ist er weit offen?
• Wenn es Daten berührt: findet ihr einen realen Codepfad, der die Tabelle in Produktion liest oder schreibt?
• Wird durch Entfernen Rollen, Berechtigungen, Einladungen, Billing-Zugänge oder Onboarding-Schritte verändert?
• Habt ihr Secrets, Beispiel-Keys und test-only-Konfigurationen entfernt, die mitkamen?

Plant ein schnelles Rollback. Selbst sorgfältige Löschungen können Builds, Migrationen oder Jobs brechen. Taggt ein Release, haltet Commits sauber und stellt sicher, dass ihr die vorherige Version schnell neu deployen könnt.

Beispiel: Aufräumen eines KI-erstellten MVP mit zusätzlichen Features

Ein Gründer verschickt ein KI-erstelltes MVP. Der Kern-Flow funktioniert (Signup, Projekt erstellen, Datei hochladen), aber das Repo enthält auch "Teams" und "Billing". Niemand hat sie angefordert, und niemand nutzt sie, trotzdem fügen sie Routen, Endpunkte und Tabellen hinzu, die später Probleme machen können.

Der erste Schritt ist zu beweisen, dass diese halluziniert und nicht nur versteckt sind. Prüft auf echte Nutzungsbelege:

• Keine Navigationslinks oder Buttons führen zu den Seiten (nur direkte URLs funktionieren).
• Backend-Logs zeigen keine Calls zu den zugehörigen Endpunkten in echten Sessions.
• Das Frontend ruft die APIs nie auf.
• Die Datenbanktabellen sind leer oder enthalten nur Seed-Daten.
• Der Code ist voller Platzhalter-Texte wie "TODO", "Coming soon" oder gefälschter Tarifstufen.

Wenn ihr sicher seid, entfernt die Oberfläche in einer sicheren Reihenfolge: UI zuerst, API zweitens, Schema zuletzt. Wenn ihr nicht alles löschen wollt, behaltet eine klar gekennzeichnete Stub-Seite (z. B. eine harmlose Seite mit der Meldung "Billing isn’t available yet") und vermeidet halb fertige Endpunkte oder Schreibvorgänge in die Datenbank.

Das Ergebnis ist sofort spürbar: weniger bewegliche Teile, kleinere Angriffsfläche, schnellere Code-Reviews und eine klarere Roadmap für das, was die App tatsächlich tut.

Nächste Schritte: Repo sauber halten und Risiko langfristig reduzieren

Das Löschen halluzinierter Funktionen ist ein Gewinn. Noch besser ist es, sie am Wiederauftauchen zu hindern.

Haltet eine kleine Aufräum-Backlog für alles, was ihr noch nicht gelöscht habt. Notiert, warum es blieb ("könnte später genutzt werden", "braucht Produktentscheidung", "blockiert durch fehlende Tests") und fügt eine klare nächste Aktion hinzu. Das verhindert, dass temporäre Scaffolds zur permanenten Schuld werden.

Ein paar leichte Guardrails helfen:

• CI fehlschlagen lassen bei offensichtlichen Platzhaltern (TODO-Routen, Sample-Keys, Demo-Daten-Flags).
• Jede neue Seite und jeder neue Endpunkt muss eine Nutzungsnotiz oder einen Test haben.
• Überprüft ungenutzte Routen/Endpunkte regelmäßig in Staging.
• Führt eine kurze Allowlist echter Tabellen und Migrationen und markiert alles außerhalb davon.

Wenn das Repo chaotisch ist, fangt nicht an, Dateien wahllos zu löschen. Erstellt eine Karte dessen, was in der UI erreichbar ist, was über das Netzwerk erreichbar ist und welche Daten tatsächlich genutzt werden. Diese Karte verhindert den klassischen Fehler, eine "tote" Funktion zu entfernen, die heimlich Auth, Billing oder Onboarding unterstützt.

Wenn ihr ein KI-generiertes Prototype geerbt habt und einen strukturierten Abbauplan braucht, kann FixMyMess (fixmymess.ai) bei Diagnose und Reparatur KI-erstellter Codebases helfen, einschließlich der Identifikation toter Seiten, riskanter Endpunkte und platzhalterhafter Schemata, bevor ihr etwas entfernt.