Umfang der Behebung für eine AI-generierte Codebasis einschätzen: rote Warnzeichen

Was du schätzt und warum es wichtig ist

Der Remediation-Umfang ist eine Schätzung dessen, was nötig ist, um eine Codebasis sicher, stabil und bereit für echte Nutzer zu machen. Er umfasst Aufwand (Stunden oder Tage), Risiko (was beim Fixen kaputtgehen könnte) und Unbekannte (Bereiche, denen du bis zur Inspektion oder zum Testen nicht vertrauen kannst).

Die erste echte Entscheidung ist selten „Welcher Bug zuerst?“ sondern eher „Reparieren wir das, was da ist, oder bauen wir die gleichen Features auf einer saubereren Grundlage neu auf?“ Die falsche Wahl kann dazu führen, dass du eine Woche damit verbringst, Probleme zu flicken, die wieder auftauchen, sobald du ein weiteres Feature hinzufügst.

AI-generierte Codebasen wirken in Demos oft gut, können aber inkonsistent sein. Eine polierte UI sitzt möglicherweise auf brüchiger Logik. Eine Datei folgt brauchbaren Mustern, die nächste hardcodiert Secrets, überspringt Eingabeprüfungen oder mischt Datenbankabfragen mit UI-Code. Das ist nicht automatisch „schlecht“, aber es kann scharfe Kanten verbergen.

Dieses Rubrik ist für Geschwindigkeit gedacht. Du versuchst, zwei frühe Fragen zu beantworten:

• Lässt sich das mit fokussierten Reparaturen production-ready machen, oder ist ein Neustart auf sauberer Basis schneller und sicherer?
• Wo wird die Arbeit wahrscheinlich hochgehen (Auth, Daten, Sicherheit, Architektur)?

Behandle das Ergebnis als Bandbreite, nicht als einzelne Zahl. Eine schnelle, ehrliche Umfangsschätzung hilft, Erwartungen zu setzen und zu entscheiden, ob du vor Wochen des Ratens noch eine zweite Meinung brauchst.

Eingaben und ein schneller, zeitlimitierter Ansatz

Für die Schätzung brauchst du nur genug Informationen, um eine Frage zu beantworten: Kann dieser Code sicher und zuverlässig gemacht werden, ohne alles neu zu schreiben?

Sammle die minimalen Eingaben (bevor du den Code öffnest)

Fordere diese Dinge vorher an. Fehlen wichtige Teile, ist deine Schätzung größtenteils Spekulation.

• Repo-Zugriff (vollständiger Quellcode, nicht ein Zip mit Build-Output)
• Environment-Setup (env vars, Vorgehen zum Umgang mit Secrets und eine Beispiel-.env-Vorlage)
• Datenbankdetails (Schema, Migrationen und eine kleine Beispieldatenmenge, falls vorhanden)
• Deployment-Target (wo es laufen muss und etwaige Einschränkungen wie Regionen oder VPC)
• Eine kurze Liste der „muss funktionieren“-Flows (Signup, Checkout, Admin etc.)

Timebox den ersten Durchgang. 60 bis 120 Minuten reichen normalerweise, um große Risiken zu erkennen, ohne in ein vollständiges Audit zu verfallen.

Ein einfacher Ablauf funktioniert gut: etwa 15 Minuten für das Starten, 30 Minuten, um den Kern-User-Pfad End-to-End zu durchlaufen, dann 15–45 Minuten zum Scannen nach großen roten Flaggen (Auth, Datenmodell, Sicherheit, Architektur).

Was „fertig“ bedeutet, ist eine einseitige Zusammenfassung: wichtigste Probleme, grobe Aufwandsspanne und ein klarer Aufruf (Refactor vs Rebuild).

Hard Stops sind wichtig. Wenn du den Quellcode nicht hast, ihn nicht lokal oder in einer sauberen Umgebung starten kannst oder niemand erklären kann, wie Produktionsdaten aussehen, pausiere und markiere die Schätzung als blockiert.

Erste Triage: Läuft es und erfüllt es den Kernauftrag?

Bevor du bewertest, versuche die App wie ein echter Nutzer zu verwenden. Du versuchst nicht, jeden Fehler zu debuggen, sondern zu prüfen, ob die Codebasis grundsätzlich lebt oder bereits vor dem Hauptworkflow scheitert.

Starte mit einem End-to-End-Lauf: Kannst du den Server starten, die App öffnen, dich registrieren, einloggen und die Kernaktion abschließen (das Ding erstellen, buchen, senden)? Wenn ein Schritt durch einen Crash, einen leeren Bildschirm oder eine kaputte Route blockiert ist, steigt der Umfang meist, weil du an der Basis reparierst, nicht an der Oberfläche.

Wirf einen kurzen Blick auf die Konfiguration. Sind Environment-Variablen dokumentiert? Siehst du hardcodierte API-Keys, Tokens oder Passwörter in Dateien oder clientseitigem Code? Schon ein einziges exponiertes Secret kann aus einem „Quick-Fix“ ein größeres Security-Cleanup machen.

Achte auch auf Testsignale. Keine Tests sind bei Prototypen üblich, erhöhen aber das Risiko in deiner Schätzung. Selbst einige Smoke-Checks verringern das Rätselraten. Bedeutungsvolle Tests rund um Auth und Kern-Flows können die Remediation-Zeit verkürzen.

Halte Unbekanntes sofort fest, denn das treibt den Umfang oft mehr als sichtbare Bugs:

• Welcher Schritt ist fehlgeschlagen und welche Fehlermeldung gab es?
• Welche Teile des Kern-Workflows sind unklar oder inkonsistent?
• Welche Daten werden erstellt oder geändert und wo werden sie gespeichert?
• Was muss in Produktion funktionieren (Zahlungen, E-Mails, Datei-Uploads)?

Auth-Rote Flaggen, die den Umfang schnell vergrößern

Auth-Probleme sind selten „nur ein Bug“. Sie betreffen Routing, Daten, Session-Storage und jede geschützte Funktion. In AI-generierten Projekten zeigen sich hier oft Copy-Paste-Code und fehlende Server-Prüfungen.

Ein schnelles Signal ist, ob die Basics End-to-End funktionieren. Wenn Passwort-Reset-Mails nie ankommen, Sessions nach zufälligen Zeiten verfallen oder die UI „eingeloggt“ sagt, während die API Anfragen ablehnt, siehst du meist mehr als einen Quick-Fix. Solche Symptome bedeuten oft, dass Auth-State über Frontend, Backend, DB und Cookies verteilt ist, ohne Single Source of Truth.

Rote Flaggen, auf die du achten solltest

Diese Muster vergrößern den Umfang schnell:

• Kaputte Flows (Reset-Links funktionieren nicht, Logout loggt nicht wirklich aus, Sessions sterben nach Refresh)
• Fehlende oder inkonsistente Rollenprüfungen (normale Nutzer können Admin-Screens sehen oder Admin-Endpunkte aufrufen)
• Unvollständiges OAuth (Callback-Route-Fehler, Tokens an „irgendwo“ gespeichert, unklarer Refresh-Flow)
• Autorisierung nur in der UI durchgesetzt (Seiten werden versteckt, aber der Server liefert die Daten trotzdem)

Eine einfache Schweregrad-Einteilung hilft, die Schätzung ehrlich zu halten:

• Niedrig: Ein Flow bricht, der Ansatz ist konsistent (ein Bug)
• Mittel: Der Ansatz ist inkonsistent (gemischte Session- und JWT-Modelle, duplizierte Logik) und braucht ein Design-Fix
• Hoch: Rollen und serverseitige Autorisierung sind unsicher oder unklar (Rebuild-Kandidat)

Beispiel: Wenn ein Prototyp Admin-Features durch versteckte Buttons „ schützt“, du aber trotzdem das Admin-API im Browser aufrufen kannst, behandle das als hohe Schwere. Das Beheben erfordert das Definieren von Berechtigungen, das Erzwingen serverseitig und erneutes Testen jeder Funktion, die Benutzerdaten berührt.

Datenmodell-Rote Flaggen: wo versteckte Komplexität liegt

Wenn eine AI-generierte App „meistens funktioniert“, aber auf seltsame Weise immer wieder bricht, ist oft das Datenmodell der Grund. Klein erscheinende Schema-Probleme sorgen für großen Umfang, weil jede Funktion von denselben Tabellen, Beziehungen und Regeln abhängt.

Ein schnelles Signal ist Schema-Mismatch: Der Code liest oder schreibt Felder, die es in der DB nicht gibt, oder die DB hat Spalten, die niemand nutzt. Du siehst fehlende Spalten-Fehler, Null-Werte, wo die UI einen Wert erwartet, oder „temporäre“ JSON-Blobs, die heimlich permanent wurden.

Ein weiterer Umfangs-Treiber ist, dass keine klare Quelle der Wahrheit für IDs, Beziehungen und Ownership existiert. Eine Bestellung könnte an einer Stelle einen Nutzer per E-Mail referenzieren, an anderer Stelle per userId und irgendwo anders per zufälligem „owner“-Feld. Dann sind Fixes nicht lokal. Du musst definieren, was die App meint, und dann Code, Queries und existierende Daten anpassen.

Duplikation und inkonsistente Benennung über Tabellen hinweg (users vs user vs app_users) bedeutet meist, dass das Modell durch Copy-Paste gewachsen ist. Das führt zu Reports, die nie übereinstimmen, Bugs, die nach „Fixes“ zurückkommen, und Logik, die in mehrere Versionen aufgespalten wird.

Fehlende Migrationsgeschichte ist ein weiteres rotes Flag. Gibt es keinen reproduzierbaren Weg, das Schema sicher zu ändern, wird jede Änderung zu einer riskanten manuellen Editierung und Deployments können die Produktion brechen.

Hochrisiko-Signale, die Schätzungen oft nach oben treiben, sind fehlende Validierung, Löschungen ohne Constraints, fehlende Tenant-Grenzen, Beziehungen, die nur im Frontend erzwungen werden, und „eine Tabelle macht alles“-Designs voll optionaler Felder. Wenn du mehrere dieser Punkte gleichzeitig findest, kann es billiger sein, die Datenebene sauber neu aufzubauen und die App wieder anzudocken, als Bugs Tabelle für Tabelle zu jagen.

Sicherheits-Rote Flaggen, die dich zum Rebuild treiben

Sicherheitsprobleme sind nicht alle gleich. Einige sind „Türen zuschließen“-Fixes, die du schnell ergänzen kannst. Andere signalisieren, dass das gesamte Projekt ohne grundlegende Grenzen gebaut wurde. In Umfangsschätzungen macht die zweite Kategorie häufig einen Rebuild sicherer (und manchmal schneller) als Patchen.

Beginne mit Secrets. Tauchen API-Keys oder Datenbank-Passwörter im Repo, in Logs oder im Frontend-Bundle auf, behandle sie als bereits geleakt. Das Rotieren der Keys ist nur Schritt eins. Wenn der Code weiterhin Secrets im Browser benötigt, ist das ein Designproblem, kein Cleanup-Task.

Injection-Risiko ist ein weiterer Umfangs-Multiplikator. Siehst du rohes SQL im Code, Queries, die per String-Konkatenation gebaut werden, oder „nimm alles an“-Inputs, kannst du nicht einfach einen Endpunkt fixen. Du brauchst ein konsistentes Muster für Validierung und DB-Zugriff über das gesamte Projekt.

Rebuild-anziehende Signale sind oft: clientseitige Secrets „weil es am einfachsten war“, Endpunkte ohne Access-Checks, Queries aus Benutzereingaben an mehreren Stellen, Session-Handling, das bei Refresh oder Timeouts bricht, und keine klare Grenze zwischen öffentlichen und privaten Daten.

Fehlende Grundlagen wie Rate-Limiting, CSRF-Schutz und verlässliche Autorisierungsprüfungen lassen sich hartnäckig patchen, wenn die Architektur sauber ist. Wenn aber jede Route eine Spezialregel ist, wird Härtung zu Whack-a-Mole.

Architektur-Rote Flaggen: Refactor-Pain vs sauberer Neustart

Architektur ist der Ort, an dem Prototype-Abkürzungen zu Zeitfallen werden. Hier fällt oft die Entscheidung zwischen gezieltem Refactor und sauberem Rebuild.

Ein häufiges Warnzeichen ist „alles ist überall“: dieselbe Geschäftsregel taucht in einer UI-Komponente, einer API-Route und einem Helper auf, jeweils leicht unterschiedlich. Wenn Datenzugriff, Request-Handling und Rendering vermischt sind, riskiert jede Änderung, mehrere Stellen zu brechen.

Rote Flaggen, die meist Refactor-Schmerzen bedeuten

Achte auf Muster, die den Code schwer verständlich und schwer testbar machen:

• Kernlogik dupliziert über Dateien ohne Single Source of Truth
• DB-Calls verstreut in UI- oder Route-Handlern ohne klaren Datenlayer
• Mehrere Wege, dieselbe Aufgabe zu erledigen (zwei Auth-Checks, drei Billing-Helpers)
• Eingebaute langsame Pfade (wiederholte Fetch-Loops, schwere clientseitige Arbeit, offensichtliche N+1-Queries)
• Zustand im Speicher oder Singletons gehalten, mit Annahme eines einzelnen Servers

Wenn du mehrere dieser Probleme in einem Feature siehst, bläst ein Refactor oft auf. Du fixst einen Bug und entdeckst, dass die „wirkliche“ Logik woanders liegt.

Wann ein Rebuild die freundlichere Option ist

Ein Rebuild wird attraktiv, wenn es keine Grenzen gibt, die es wert sind, erhalten zu werden. Ein Prototyp, der „auf meinem Rechner funktioniert“, aber auf In-Memory-Sessions, DB-Schreibvorgängen in UI-Events und wiederholten Fetchs über Komponenten hinweg beruht, kann zwar gepatcht werden, aber jeder Patch fügt mehr Kleber hinzu.

Eine praktische Regel: Wenn du kein einfaches Box-Diagramm (UI, API, Datenlayer) zeichnen kannst und nicht zeigen kannst, wo jede Regel lebt, ist der Umfang wahrscheinlich größer als er scheint.

Eine einfache Bewertungsrubrik, die du in 30–60 Minuten anwenden kannst

Nutze diese Rubrik, wenn du schnell und vertretbar den Remediation-Aufwand schätzen musst. Das Ziel ist, überraschende Rebuilds zu vermeiden.

Schritt 1: Beurteile vier Risiko-Bereiche (1 bis 5)

Bewerte jede Area von 1 (sauber, vorhersehbar) bis 5 (hohes Risiko, sich verstärkende Probleme): Authentifizierung, Datenmodell, Sicherheit und Architektur.

• 1–2: Funktioniert größtenteils, Änderungen wirken lokal, wenige Überraschungen
• 3: Funktioniert teilweise, hat scharfe Kanten und versteckte Kopplungen
• 4–5: Bricht häufig, Fixes erzeugen neue Bugs, schwer verständlich

Schritt 2: Füge einen "Unbekanntes"-Score hinzu (1 bis 5)

Unbekannte sprengen Schätzungen. Bewerte fehlende Docs, fehlende Tests, schwer reproduzierbare Schritte oder ein Team, das Kernflüsse nicht erklären kann.

Schritt 3: Blocker von Ärgernissen trennen

Bevor du etwas zusammenzählst, markiere Findings als Blocker oder Ärgernis.

Blocker verhindern Produktion: Nutzer können sich nicht einloggen, Daten werden corrupt, Secrets sind exponiert.

Ärgernisse sind tolerierbar: inkonsistente UI, langsame Seiten, unordentliche Ordnernamen.

Schritt 4: Mappe die Summe auf eine Aktion

Addiere die fünf Scores (Auth + Data + Security + Architecture + Unknowns) und nutze diese grobe Regel:

• 5–9: Quick Fix (eng gefasste Änderungen, bald deploybar)
• 10–14: Refactor (Struktur verbessern und Kern behalten)
• 15–19: Teilweiser Rebuild (ein Subsystem neu aufbauen, den Rest behalten)
• 20–25: Volles Rebuild (schneller als ständigem Fehlerjagen)

Schritt 5: Formuliere eine Scope-Aussage

Schreibe drei kurze Zeilen: Fix jetzt, Aufschieben, Außerhalb des Umfangs.

Beispiel: „Fix jetzt: Login-Flow, Secret-Handling, DB-Constraints. Aufschieben: Admin-UI-Polish. Außerhalb des Umfangs: neue Billing-Features.“

Übliche Fallen, die Schätzungen falsch machen

Eine saubere UI kann eine brüchige Grundlage verbergen. AI-generierte Apps sehen oft fertig aus, weil Bildschirme einfach zu generieren sind, aber riskante Teile liegen dahinter: Auth, Berechtigungen, Datenregeln und Secret-Handling.

Ein weiterer Fehler ist, „es läuft lokal“ als Beweis für geringen Aufwand zu werten. Lokaler Erfolg kann von gecachten Sessions, einer lokalen DB ohne echte Daten, fehlenden Rate-Limits oder hardcodierten Keys abhängen, die ein reales Deployment nicht überstehen.

Sicherheit killt Schätzungen oft. Wenn du planst, „Security am Ende zu patchen“, rutscht der Zeitplan meist, weil Sicherheit Auth, Datenzugriff, API-Design und Storage berührt.

Es ist außerdem leicht, zu früh zu refactoren. Wenn du Ordner umorganisierst oder die Architektur „aufhübschst“, bevor du verstehst, wer welche Daten besitzt und welche Rolle was darf, machst du den Code hübscher, während die Kernregeln kaputt bleiben.

Ein schneller Bauchcheck:

• Nutze UI-Polish nicht als Qualitäts-Signal für Backend-Logik
• Vertraue lokalen Runs nicht auf Produktionsreife
• Schiebe Sicherheitsentscheidungen nicht auf
• Refactore nicht, bevor das Berechtigungsmodell klar ist
• Ignoriere nicht die Deployment-Arbeit

Deployment-Prep wird oft unterschätzt: Environment-Variablen, Build-Schritte, DB-Migrationen, grundlegendes Logging und einfache Überwachung. Diese Arbeit kann aus einem „Zwei-Tage-Fix“ eine Woche machen.

Schnelle Checkliste: die schnellsten Signale für Umfang

Wenn du eine schnelle Schätzung brauchst, suche nach Signalen, die Wiederarbeit vorhersagen, nicht nur Bugs. Kannst du eine Frage nicht sauber beantworten, behandle sie als Umfangs-Multiplikator.

• Erstelle einen brandneuen Nutzer und schließe den Kern-Workflow End-to-End ab (nicht nur einen Happy-Path-Demo).
• Suche im Repo und im Client-Code nach Secrets (API-Keys, DB-URLs, JWT-Secrets).
• Bestätige, dass Autorisierung serverseitig durchgesetzt wird (nicht nur versteckte Buttons).
• Prüfe, ob Migrationen sauber laufen und Tabellen/Felder dem Code entsprechen.
• Erkläre die Architektur in fünf einfachen Sätzen: wo Anfragen eintreten, wo Auth lebt, wo Geschäftsregeln leben, wo Daten gespeichert sind und wie Deployments ablaufen.

Wenn Signup funktioniert, aber API-Autorisierung fehlt und Secrets exponiert sind, bist du bereits in „Security-Hardening plus Refactor“-Territorium.

Beispiel: Refactor vs Rebuild entscheiden für einen Prototyp, der ständig bricht

Eine nicht-technische Gründerin bringt einen Lovable-Prototyp, der „meistens funktioniert“, außer dass das Login zufällig fehlschlägt und Leute ausgeloggt werden. Ziel ist, den Umfang zu schätzen, ohne Tage damit zu verbringen, jede Datei zu lesen.

Ein 30-minütiger Durchgang kann vier Fragen beantworten: Läuft es, kann sich ein Nutzer registrieren und einloggen, sind sensible Daten exponiert, und passt die DB zu dem, was die App erwartet?

Was wir zuerst prüfen

Starte die App lokal (oder im aktuellen Host) und wiederhole den Login-Flow ein paar Mal: signup, logout, wieder einloggen. Verfolge dann Auth End-to-End: Frontend-Formular, API-Route, Session- oder Token-Erstellung, Cookie-Einstellungen, Middleware.

Scanne als Nächstes nach exponierten Secrets (API-Keys im Repo, hardcodierte JWT-Secrets, öffentliche DB-URLs) und verifiziere das Schema: Tabellen, Relationen, Migrationen und Typen (insbesondere user, org, permissions).

Hier ein Beispiel-Score (0 = gut, 3 = schwerwiegend):

Total: 10/12. Das deutet meist darauf hin, die Grundlage (Auth + Datenzugriff) neu aufzubauen und UI-Screens und Copy wiederzuverwenden.

Sofortige Fixes (jetzt erledigen): Auth auf einen konsistenten Ansatz bringen, exponierte Secrets rotieren und entfernen, grundlegende Validierung hinzufügen und Hochrisiko-Endpunkte schützen, Migrationen reproduzierbar machen und minimales Logging rund um Login und Nutzererstellung ergänzen.

Nach Stabilisierung der App aufschieben: strukturelles Aufräumen (Ordnernamen, tiefere Refactors), Performance-Tuning und Nice-to-have-Admin-Tools.

Die Überraschung ist oft versteckte Kopplung: „schnelle“ Login-Bugs verursacht durch Schema-Drift oder zwei verschiedene User-IDs.

Nächste Schritte: Mach aus dem Rubrik einen klaren Plan

Mach aus deinem Score eine einseitige Umfangsübersicht, die du mit Team, Gründer oder Kunde teilen kannst. Halte es einfach: was ist kaputt, was ist riskant und was machst du zuerst.

Füge hinzu:

• Die Top-3-Risiken (kaputter Auth-Flow, unklarer Datenmodell, exponierte Secrets)
• Die Top-5-Fixes (als Outcomes formuliert, nicht als Tasks)
• Deine Entscheidung: gestufter Refactor oder Rebuild
• Den ersten Meilenstein, den du sicher ausliefern kannst
• Was du vorerst nicht anfasst (um die Timeline zu schützen)

Wenn dein Score hoch ist, plane einen Rebuild, aber halte ihn klein. Definiere einen minimalen production-ready Kern: ein Happy-Path, echte Authentifizierung, sauberes DB-Schema und grundlegendes Logging. Features kommen erst, wenn die Basis stabil ist.

Liegt dein Score im Mittelfeld, wähle einen gestuften Refactor. Beginne mit Sicherheit und Auth, weil sie alles beeinflussen und später schwer zu patchen sind. Dann kümmere dich um das Datenmodell und erst danach um Architektur-Aufräumarbeiten.

Wenn du eine AI-generierte App geerbt hast und in Unbekannten versinkst, kann eine externe Diagnose der schnellste Weg sein, mit dem Raten aufzuhören. FixMyMess (fixmymess.ai) konzentriert sich darauf, AI-generierte Prototypen production-ready zu machen durch Codebase-Diagnose, Logik-Reparatur, Sicherheits-Härtung, Refactoring und Deployment-Vorbereitung.