Magische Konstanten aus KI-generiertem Code entfernen (sicher)

Warum magische Konstanten in KI-generiertem Code Probleme verursachen

Magische Konstanten sind Werte, die im Code verteilt stehen, ohne Namen oder Erklärung. Sie erscheinen als fest kodierte Zahlen (wie 7 oder 10000), eingefügte URLs (wie ein API-Endpunkt) oder Strings, die das Verhalten steuern (wie "beta", "admin" oder "enabled"). Wenn Sie sie später sehen, wissen Sie nicht, warum der Wert existiert oder was passiert, wenn man ihn ändert.

KI-generierte Prototypen verschärfen das Problem, weil der Code oft in kleinen, getrennten Stücken entsteht. Eine Komponente bekommt ein Timeout, eine andere ein anderes Timeout, und eine dritte kopiert eine URL mit leicht verändertem Pfad. Die App funktioniert ausreichend für eine Demo, aber dieselbe Regel ist an mehreren Stellen mit kleinen Abweichungen implementiert.

Deshalb wirkt das Entfernen magischer Konstanten riskant. Eine einfache Anfrage wie „Upload-Limit von 10MB auf 25MB erhöhen" wird zur Suche durch Controller, UI-Komponenten, Validierungshelfer und Hintergrundjobs. Vergisst man eine Stelle, liefert man einen Bug aus, der erst in Produktion auffällt.

Die Symptome sind meist schnell sichtbar:

• Inkonsistentes Verhalten zwischen Seiten (ein Screen erlaubt 25MB, ein anderer blockiert bei 10MB)
• Fixes, die in einem Flow funktionieren, aber woanders versagen
• Tests, die schwer zu schreiben sind, weil Regeln verstreut sind
• Hotfixes, die neue Edge-Cases erzeugen, während sich Werte im Laufe der Zeit auseinanderentwickeln
• Verwirrende Supportmeldungen („es funktioniert manchmal") ohne klares Muster

Ein realistisches Beispiel: Ihre App hat "https://api.example.com" im Login-Flow hartkodiert, eine andere Datei nutzt "https://api.example.com/" und eine dritte verweist auf "https://staging-api.example.com", übrig geblieben aus einem früheren Prompt. Sie ändern eine Stelle, die Auth schlägt für einige Nutzer fehl, und plötzlich jagen Sie Gespenster.

Das ist eines der häufigsten Probleme, die wir in kaputten, von KI erstellten Apps bei FixMyMess sehen. Der schnellste Weg zu sichereren Änderungen ist, wichtige Werte langweilig zu machen: ein Name, ein Ort, eine Quelle der Wahrheit.

Was als magische Konstante zählt (und was nicht)

Eine magische Konstante ist jeder Wert, der im Code festgelegt ist, dessen Bedeutung nicht offensichtlich ist und dessen Änderung später Suchen und Raten erfordert. In KI-generierten Prototypen steigt dieses Risiko, weil dieselben Werte oft in vielen Dateien wiederholt werden.

Was ist eine magische Konstante?

Magische Konstanten treten meist als magische Zahlen, magische Strings und hartkodierte URLs auf. Oft sind es „wichtige Defaults“, die still das Verhalten steuern.

Häufige Beispiele:

• Timeouts wie 3000 oder 30 (Millisekunden oder Sekunden?)
• Paginierungsgrößen wie 10, 20, 50
• Retry-Anzahlen wie 3 oder 5
• API-Basis-URLs wie https://api.example.com/v1
• Feature-Toggles verborgen als Strings wie "enableNewCheckout" = true

Das Problem ist nicht, dass diese Werte existieren. Das Problem ist, dass der Code nicht erklärt, was sie bedeuten. Sechs Wochen später sieht 3000 eher wie eine Vermutung als wie eine bewusste Entscheidung aus.

Warum „eine schnelle Änderung" nach hinten losgeht

In KI-generierten Prototypen wird dieselbe Konstante oft kopiert über Komponenten, Routen und Hilfsdateien. Sie ändern sie an einer Stelle, Tests laufen durch, und dann bricht ein anderer Screen, weil dort eine leicht andere Kopie existierte.

Versteckte Duplikate sind besonders tückisch: timeout = 3000 in einer Datei, timeout = 3500 in einer anderen und timeoutMs = 3000 irgendwo anders. Dieser Unterschied kann absichtlich sein oder versehentlich entstanden. So oder so hängt das Verhalten davon ab, welchen Pfad ein Nutzer trifft.

Was NICHT als magische Konstante zählt

Nicht jeder Literalwert muss zur Konfiguration werden. Manche Werte sind lokal, selbsterklärend und unwahrscheinlich zu ändern.

Gute Nicht-Magie-Beispiele:

• 0 oder 1 als einfacher Schleifenzähler
• 404, wenn ein HTTP-Status in einem Handler zurückgegeben wird
• Ein kleiner UI-Abstandswert, der klar lokal zu einer Komponente gehört

Eine nützliche Regel: Wenn eine Änderung eine bewusste Produktentscheidung sein sollte (Limits, URLs, Retries, Gating), gehört sie an einen benannten Ort.

Ein einfacher Weg, um zu finden und zu priorisieren, was zu fixen ist

Die eigentliche Schwierigkeit ist nicht die Änderung selbst. Es ist die Entscheidung, womit man zuerst anfängt, damit man keine neuen Bugs einführt.

Beginnen Sie mit einem schnellen Inventar. Nutzen Sie die Suche Ihres Editors, um nach wiederholten Werten zu suchen: dieselbe URL, dasselbe Timeout, dieselbe 10 oder 1000, dieselbe Status-Zeichenkette. Wenn ein Wert an 5+ Stellen auftaucht, ist er ein starker Kandidat. Wenn er nur an 2 Stellen auftaucht, aber Geld oder Login berührt, ist er trotzdem ein Kandidat.

Konzentrieren Sie sich auf Risiko, nicht auf Perfektion. Die Konstanten, die am meisten schaden, sind die, die Produktion kaputtmachen oder Sicherheitsprobleme erzeugen können, wenn sie falsch sind.

Eine schnelle Triage-Regel

Sortieren Sie, was Sie finden, in „jetzt fixen“ und „später fixen“. Zu „jetzt fixen" gehört normalerweise:

• Auth und Identity: OAuth-URLs, Callback-URLs, Token-Lifetimes, Cookie-Einstellungen
• Zahlungen und Webhooks: Provider-Endpunkte, Signing-Secret-Namen, Retry-Delays
• Ratenlimits und Quoten: max Requests, max Uploads, Paginierungsgrößen
• Timeouts und Retries: API-Timeout-Werte, Intervalle von Hintergrundjobs
• Externe Basis-URLs: alles, was auf staging, localhost oder einen persönlichen Server zeigt

Dann wählen Sie einen Punkt und schaffen eine einzige Quelle der Wahrheit, bevor Sie viele Dateien anfassen. KI-generierter Code hat oft denselben Wert in leicht unterschiedlichen Formen, und schnelle Editierungen werden zu halb fertigen Refactors.

Nennen Sie es so, dass jeder es errät

Verwenden Sie Namen, die die Absicht erklären. Vermeiden Sie CONST_1 oder DEFAULT_VALUE. Bevorzugen Sie AUTH_TOKEN_TTL_SECONDS oder PAYMENTS_WEBHOOK_BASE_URL. Geben Sie Einheiten im Namen an (Sekunden vs. Millisekunden), damit niemand raten muss.

Beispiel: Wenn Sie drei verschiedene Stripe-Webhook-URLs und zwei Timeout-Werte finden, erstellen Sie PAYMENTS_WEBHOOK_URL und PAYMENTS_API_TIMEOUT_MS an einer Stelle. Aktualisieren Sie dann die Aufrufstellen nacheinander und prüfen Sie das Verhalten.

Wenn Sie einen kaputten Prototypen von Tools wie Bolt, v0, Cursor, Lovable oder Replit übernommen haben, ist dies oft der erste Aufräumschritt, den wir bei FixMyMess durchführen: riskante Werte zentralisieren und dann den Rest auf etwas Stabilem reparieren.

Schritt-für-Schritt: Limits, URLs und Timeouts zentralisieren

Das Ziel ist simpel: „Dinge, die sich ändern“, an einem Ort mit klaren Namen ablegen, damit Sie sie ändern können, ohne das Repository zu durchforsten.

Ein praktischer Weg

Behandeln Sie das als Reihe kleiner, sicherer Änderungen, nicht als großen Rewrite.

1. Wählen Sie ein offensichtliches Zuhause für Konfiguration. Erstellen Sie ein einzelnes Modul (oder eine Datei), das die ganze App importieren kann, z. B. config oder settings.

2. Fügen Sie lesbare Namen und Defaults hinzu. Bevorzugen Sie Namen, die Zweck erklären, nicht Typ: API_BASE_URL, REQUEST_TIMEOUT_MS, MAX_UPLOAD_MB, PASSWORD_MIN_LENGTH. Verwenden Sie sichere Defaults, damit lokale Runs nicht brechen.

3. Ersetzen Sie Literale schrittweise. Wählen Sie einen Ordner oder ein Feature, ersetzen Sie dort Literale durch Config-Werte, committen Sie und machen Sie weiter. Kleine Schritte sind leichter zu reviewen und rückgängig zu machen.

4. Führen Sie nach jedem Abschnitt eine leichte Prüfung durch. Starten Sie die App und klicken Sie die Bereiche durch, die Sie berührt haben (Login, Upload, Checkout). Wenn Sie Tests haben, führen Sie sie aus. Ziel ist schnelles Feedback.

5. Halten Sie Commits fokussiert. Ein Commit für „Zentralisiere Timeouts“, ein anderer für „Zentralisiere API-URLs“. So erkennt man Fehler (Sekunden vs. Millisekunden) leichter.

Ein kleines Beispiel, das künftige Bugs verhindert

Angenommen, Ihre App ruft https://api.example.com in fünf Dateien auf, und jede Datei verwendet ein anderes Timeout: 2000, 5000, 15_000. Nach der Zentralisierung setzen Sie API_BASE_URL und REQUEST_TIMEOUT_MS einmal. Beim nächsten Wechsel auf einen Staging-Server oder bei längerem Traffic ändern Sie eine Datei, nicht fünf.

Wo Konfiguration speichern: Env-Variablen, Config-Dateien und Defaults

Wenn Sie Werte aus dem Code herausgezogen haben, brauchen sie ein klares Zuhause. Ziel: eine einzige Quelle der Wahrheit, die leicht zu ändern und sicher auszuliefern ist.

Was in Env-Variablen vs Code-Defaults gehört

Umgebungsvariablen eignen sich für Werte, die sich zwischen Umgebungen ändern oder nicht im Repo liegen sollten. Code-Defaults eignen sich für sichere, nicht sensitive Werte, die das lokale Setup erleichtern.

Eine praktische Aufteilung:

• Env-Variablen: API-Keys, Auth-Secrets, Datenbank-URLs, private Service-Endpunkte, Webhook-Secrets von Drittanbietern
• Config-Dateien (committed): nicht-geheime Einstellungen wie Feature-Verfügbarkeit, öffentliche URLs, Paginierungs-Defaults, Retry-Zahlen
• Code-Defaults: Fallback-Werte, die die App am Laufen halten, wenn eine Einstellung fehlt (niemals für Secrets)

Wenn ein Wert Produktion kaputtmachen oder Daten offenlegen kann, bevorzugen Sie Env-Variablen. Ist es nur ein sinnvolles Default (wie PAGE_SIZE=20), reicht ein Code-Default.

Lokal, Staging und Produktion ohne Überraschungen handhaben

Viele KI-erstellte Prototypen kodieren versehentlich „die eine Umgebung“, die der Ersteller getestet hat. Stattdessen machen Sie Config umgebungsbewusst: Lokal nutzt lokale Shell-Variablen (oder eine lokale Env-Datei), Staging seine Deployment-Settings, Produktion gesperrte Secrets.

Halten Sie die Regeln vorhersehbar:

• Dieselben Config-Schlüssel überall (nur Werte ändern sich)
• In Staging/Produktion beim Fehlen notwendiger Secrets schnell fehlschlagen
• Defaults nur für nicht-sensitive Werte erlauben

Beispiel: Lokal darf REQUEST_TIMEOUT_MS=8000 als Default gelten, aber DATABASE_URL und JWT_SECRET sollten vor dem Booten in Staging/Produktion erforderlich sein.

Config-Laden nicht mit Anwendungslogik vermischen

Eine häufige Falle ist, process.env... überall im Code zu verteilen. Das verwandelt Config in versteckte Anwendungslogik.

Laden und validieren Sie Config stattdessen einmal beim Start (in einem Modul) und übergeben Sie das Config-Objekt in die Teile der App, die es brauchen.

Feature-Toggles, die nicht zum Durcheinander werden

Feature-Toggles sind einfache Ein-/Aus-Schalter, mit denen Sie Code ausliefern können, ohne dass alle Nutzer ihn sofort sehen. In KI-generiertem Code treten Toggles oft als verstreute Booleans in Dateien auf — eine weitere Art magischer Konstanten.

Ein guter Toggle beantwortet in einfacher Sprache: „Sollen Nutzer X sehen?" Für riskante Rollouts ist das nützlich. Sie können einen neuen Anmeldefluss nur einem kleinen Nutzerkreis zeigen oder eine neue Preisseite verborgen halten, bis sie freigegeben ist. Wichtig ist, dass das Umschalten das Verhalten ändert, ohne mehrere Dateien editieren zu müssen.

Benennung und Struktur, die lesbar bleibt

Wählen Sie einen konsistenten Benennungsstil und halten Sie sich daran. Beschreibend ist besser als kryptisch. enableNewSignupFlow ist klarer als flag2, weil jeder im Hotfix-Fall erraten kann, was es tut.

Bewahren Sie Toggles an einem Ort auf (Ihr Config-Modul oder eine Settings-Datei). Wenn der Wert je nach Umgebung variieren muss, mappen Sie ihn auf eine Env-Variable, aber exponieren Sie ihn trotzdem über dasselbe Config-Objekt, sodass der Rest der App nicht wissen muss, woher er kommt.

Ein paar Regeln, die Toggle-Verwilderung verhindern:

• Bevorzugen Sie enableX oder useX, die dem Nutzer-verhaltensbezogen entsprechen
• Ein Toggle pro Feature, nicht pro Datei
• Fügen Sie ein Ablaufdatum oder einen Hinweis zur Entfernung für temporäre Toggles hinzu
• Default für riskante Änderungen auf „aus" setzen

Entscheiden, wer den Schalter umlegen darf

Toggles können Schaden anrichten, wenn jeder sie locker ändern kann. Legen Sie fest, wer sie ändern darf und wie Änderungen geprüft werden.

Beispiel: Ihre KI-erstellte App hat eine neue Checkout-Seite hinter einem Toggle. Ein Stakeholder will sie nach einem Support-Anstieg ausschalten. Wenn der Toggle zentral ist, können Sie einen Wert umlegen und sicher sein, dass Sie keine versteckte Kopie übersehen haben.

Ein realistisches Beispiel: eine Änderung, ein Ort

Stellen Sie sich ein Startup vor, das schnell einen KI-generierten Prototypen ausgeliefert hat. Für Demos funktioniert er, aber der Code hat dieselben Werte überall kopiert: API-URLs, Timeouts, Limits und einen „new checkout"-Schalter.

Vorher: kleine Änderung, viele riskante Edits

Sie sollen die App von einer Staging-API auf Produktion umstellen. Sie suchen nach https://api-staging... und finden es in sechs Dateien: Frontend-Fetch-Aufrufen, einem Backend-Client, einem Webhook-Handler und einem Background-Job. Sie ändern alle, deployen, und später stellt sich heraus, dass eine Datei noch auf Staging zeigt. Die eine Hälfte der App liest weiterhin alte Daten.

Dann schlägt echter Traffic ein. Ihr Ratenlimit muss von 10 auf 50 Requests pro Minute erhöht werden, und ein Timeout von 2s auf 8s. Diese Zahlen sind verstreut, und an einer Stelle werden Millisekunden, an einer anderen Sekunden verwendet. Eine einfache Anpassung wird zum Ratespiel.

Fehler treten in einem neuen Feature auf. Der KI-Code hat ENABLE_NEW_CHECKOUT = true in zwei verschiedenen Modulen gesetzt. Sie setzen einen auf false, aber Nutzer sehen trotzdem den kaputten Pfad, weil die andere Konstante noch true ist.

So sieht dieses unordentliche Muster oft aus:

// auth.js
const API_BASE_URL = "https://api-staging.example.com";

// orders.js
fetch("https://api-staging.example.com/orders", { timeout: 2000 });

// worker.js
const TIMEOUT_MS = 2000;
const RATE_LIMIT = 10;

// checkout.js
const ENABLE_NEW_CHECKOUT = true;

Nachher: eine Config-Änderung

Nach der Zentralisierung importiert der Rest der App aus einem Config-Modul (und verwendet Env-Variablen, wo sinnvoll).

// config.js
export const config = {
  apiBaseUrl: process.env.API_BASE_URL ?? "https://api.example.com",
  timeoutMs: Number(process.env.TIMEOUT_MS ?? 8000),
  rateLimitPerMin: Number(process.env.RATE_LIMIT ?? 50),
  features: {
    newCheckout: process.env.FEATURE_NEW_CHECKOUT === "true",
  },
};

// orders.js
fetch(`${config.apiBaseUrl}/orders`, { timeout: config.timeoutMs });

Jetzt bedeutet „API-Basis-URL ändern": eine Env-Variable updaten, nicht halb das Codebase editieren. „Timeout erhöhen" heißt, eine Zahl mit klarer Einheit ändern. „Feature deaktivieren" bedeutet, einen einzigen Flag umzulegen, wenn etwas schiefgeht.

Häufige Fehler und Fallen, die man vermeiden sollte

Das Ziel ist Sicherheit: weniger riskante Edits, weniger Überraschungen, einfachere spätere Änderungen. Die meisten Probleme entstehen, wenn der Refactor sauber aussieht, das Verhalten sich aber heimlich ändert.

Ein häufiger Fehler ist das Umbenennen einer Konstante und das Nicht-Aktualisieren aller Verwendungen. Das sieht man oft in KI-Projekten, in denen derselbe Wert unter leicht unterschiedlichen Namen dupliziert wurde. Die App baut noch, aber Limit, URL oder Timeout sind inkonsistent.

Mehrere Config-Dateien sind eine andere Falle. Es beginnt mit „eine für Server, eine für Client" und wächst zu drei oder vier Dateien, die auseinander driften. Wenn ein Wert sich ändert, aktualisiert ein Teil des Teams Datei A und vergisst Datei B.

Achten Sie auch auf „hilfreiche" Fallbacks, die Env-Variablen still überschreiben. Defaults sind ok, aber nur, wenn sie offensichtlich und sicher sind. Wenn Ihr Code „Env verwenden, falls vorhanden, sonst diese hartkodierte Produktions-URL" macht, können Sie ein Build ausliefern, das mit dem falschen Backend spricht.

Fehler, die am härtesten treffen:

• Konstanten umbenennen, aber nicht jeden Import und jede Nutzung aktualisieren, wodurch gesplittetes Verhalten entsteht
• Mehrere Config-Quellen erstellen (mehrere Dateien, mehrere Patterns), die mit der Zeit auseinanderdriften
• Hardcodierte Fallbacks, die Env-Variablen lautlos überstimmen, besonders in Produktions-Builds
• Secrets wie normale Konstanten behandeln (API-Keys in Constants-Dateien oder committete .env-Werte)
• Zu frühe Überabstraktion mit Config-Schichten, die während eines Ausfalls niemand mehr nachvollziehen kann

Wenn Sie einen KI-erstellten Prototypen übernommen haben und unsicher sind, ob Ihr Refactor das Verhalten verändert hat, überprüft FixMyMess genau diese Punkte: versteckte Duplikate, unsichere Defaults und Secrets in Konstanten-Dateien.

Quick-Checklist vor dem Ausliefern des Refactors

Nach der Zentralisierung können die Dinge sauberer aussehen, aber trotzdem riskante Lücken verbergen. Verwenden Sie diese schnelle Prüfung, bevor Sie mergen.

Config-Sanity-Check

Führen Sie einen „Single-Change"-Test durch. Wählen Sie einen Wert, von dem Sie erwarten, dass er später geändert wird (z. B. API-Basis-URL), ändern Sie ihn einmal und bestätigen Sie, dass die App den neuen Wert überall verwendet. Wenn Sie noch durch mehrere Dateien suchen müssen, haben Sie ihn nicht wirklich zentralisiert.

Stellen Sie außerdem sicher, dass keine Secrets mit normalen Einstellungen vermischt sind. Ihre Config kann sichere Defaults enthalten, aber alles Sensible (API-Keys, DB-Passwörter, JWT-Secrets) sollte ausschließlich aus Env-Variablen stammen. Ist ein Secret im Repo, gehen Sie davon aus, dass es früher oder später geleakt wird.

Eine kurze Pre-Ship-Checkliste:

• Ändern Sie eine Schlüssel-Einstellung (API-Basis-URL, Webhook-URL oder CDN-Host) an einer Stelle und verifizieren Sie, dass die ganze App ihr folgt.
• Suchen Sie nach verbleibenden Literalen, die benannt werden sollten (Timeouts wie 30000, Limits wie 50, Retry-Zahlen wie 3).
• Stellen Sie sicher, dass Limits und Timeouts klar benannt sind und kurz kommentiert werden (was sie schützen und warum diese Zahl).
• Stellen Sie sicher, dass Feature-Toggles einen Owner, ein sicheres Default und einen Plan zur Entfernung haben, wenn sie temporär sind.
• Führen Sie einen Smoke-Test aus: anmelden, Hauptbildschirme durchgehen und mindestens einen Fehlerpfad auslösen (falsches Passwort, fehlender Datensatz, Offline-Modus).

Finaler „Break-Glass"-Check

Während des Smoke-Tests schauen Sie in Logs oder Konsole. Sehen Sie eine fehlende Env-Variable, eine unerwartete Fallback-URL oder ein Toggle, das falsch defaultet ist, beheben Sie das vor dem Deploy.

Wenn Sie einen fragilen KI-erstellten Prototypen geerbt haben und unsicher sind, was sonst noch hartkodiert oder unsicher ist, kann FixMyMess (fixmymess.ai) mit einem kostenlosen Code-Audit starten, um riskante Konstanten, exponierte Secrets und Config-Pattern zu identifizieren, die in Produktion scheitern.

Nächste Schritte: sauber halten, wenn die App wächst

Der eigentliche Gewinn ist, magische Konstanten nicht wieder einzuschleppen. Kleine Teams bewegen sich schnell, und „nur noch eine harte Zahl" ist, wie man wieder verstreute, riskante Edits bekommt.

Ein praktischer nächster Schritt ist ein kurzer Cleanup-Sprint, der sich auf Konstanten konzentriert, die Ihnen wirklich schaden. Versuchen Sie nicht, alles zu reparieren. Wählen Sie die 10–20 Werte, die sich häufig ändern oder Produktion kaputtmachen können, wenn sie falsch sind (Timeouts, Ratenlimits, API-Basis-URLs, Preisschwellen, Upload-Größen), zentralisieren Sie sie und liefern Sie in kleinen Häppchen.

Machen Sie eine leichte Team-Regel: neue wichtige Werte brauchen einen Namen und ein Zuhause. Wenn es kein klarer One-Off ist (wie ein Schleifenindex), gehört es in Ihr Config- oder Constants-Modul.

Wenn Ihr Codebase KI-generiert und fragil wirkt, kann ein Experten-Audit vor tieferen Refactors viel Zeit sparen. Diese Projekte verbergen oft riskante Konstanten neben größeren Problemen wie exponierten Secrets, kaputten Auth-Flows oder unsicheren DB-Queries.