TypeScript Strict-Modus schrittweise einführen für KI-generierte Apps

Welche Änderungen bringt der Strict-Modus (und warum AI-generierte Apps kaputtgehen)

TypeScript Strict-Modus ist nicht nur eine einzelne Regel. Es ist ein Bündel von Prüfungen, das den Compiler davon abhält, Annahmen schweigend zu akzeptieren. Ihn einzuschalten wirkt am besten, wenn man es wie bessere Rauchmelder behandelt, nicht wie einen kompletten Hausumbau.

Wenn du "strict": true in tsconfig setzt, aktiviert TypeScript mehrere Einstellungen, die in Prototypen oft ausgeschaltet sind. Die auffälligsten sind:

• strictNullChecks: zwingt dich, null und undefined bewusst zu behandeln
• noImplicitAny: stoppt stilles „alles ist erlaubt“-Typing
• strictFunctionTypes: fängt unsichere Funktionsparametertypen
• noImplicitThis: vermeidet das „this ist irgendwas“-Problem
• alwaysStrict: erzwingt JavaScript strict mode Regeln

AI-generierte Apps brechen oft unter diesen Prüfungen, weil sie „funktionieren“, indem sie sich auf schwache Typisierung und versteckte Annahmen verlassen: API-Antworten als any parsen, annehmen, dass ein Feld immer existiert, Benutzereingaben als richtigen Typ behandeln oder halb fertige Objekte zwischen Schichten durchreichen. Alles sieht gut aus, bis ein echter Nutzer einen Randfall trifft. Dann treten undefined-Fehler, kaputte Auth-Flows oder anders geformte Daten als erwartet auf.

Der Strict-Modus reduziert Laufzeitfehler, indem er diese Probleme während der Entwicklung laut macht. Er fängt häufig:

• Zugriff auf Eigenschaften von möglicherweise undefined-Werten
• Verwechslungen von Datenformen (z. B. { id: string } vs { id: number })
• Aufrufe von Funktionen mit fehlenden oder falschen Argumenten
• unsichere Nutzung von any, die echte Typfehler verdeckt

Das erste Aktivieren fühlt sich oft laut an. Das ist normal. Denk daran als kontrollierte Umstellung: Du fügst in kleinen Bereichen Klarheit und Schutz hinzu, statt die ganze App umzuschreiben.

Schnelle Bestandsaufnahme: finde die unordentlichen Stellen bevor du die Konfiguration änderst

Bevor du an Strict-Einstellungen drehst, verbringe eine Stunde damit, zu kartieren, wo Laufzeitfehler am ehesten versteckt sind. In KI-generierten Projekten kann eine Änderung in einer „Kern“-Datei Fehler im ganzen Repo auslösen.

Beginne damit, zu lokalisieren, wo Daten in die App gelangen und wiederverwendet werden. Schwache Typen verbreiten sich am schnellsten durch:

• API-Aufrufe und Client-Helper (fetch-Wrappers, axios-Instanzen, Response-Parsing)
• Authentifizierung und Session-Handling (Token-Speicherung, User-Objekte, Middleware)
• Datenbank-Schicht und Queries (ORM-Modelle, rohe SQL, Migrationen)
• gemeinsame Utilities und Konstanten (Datum-Helper, env-Zugriff, Feature-Flags)
• Verbindungs-Code zwischen Seiten/Komponenten und Services (JSON zu UI-State mappen)

Scanne als Nächstes nach Mustern, die der Strict-Modus aufdecken wird. Du reparierst noch nichts, du suchst nur: viel any, implizite any-Parameter, untypisiertes JSON, optionale Felder, die wie immer vorhanden verwendet werden, und „stringly typed“ IDs, die vermischt werden (userId vs orgId).

Lege den Umfang früh fest, damit die Arbeit überschaubar bleibt. Du kannst die Bereiche, die du typprüfst, stufenweise wählen: zuerst nur Quellcode der App, dann Tests, Skripte und Build-Tools. Ein gängiger Startpunkt ist „nur App-Source“, damit dich einzelne Dev-Scripts nicht blockieren.

Führe schließlich ein leichtgewichtiges Migrations-Notizdokument. Verfolge wiederkehrende Fehlertypen (z. B. „Object is possibly undefined“) und deine bevorzugte Lösung (Guard-Klausel, Default-Wert oder besserer Typ). Wenn du den 30. ähnlichen Fehler behebst, wirst du froh sein, dass du es dokumentiert hast.

Wähle eine Staging-Strategie, die die Arbeit überschaubar hält

Ein erfolgreicher Strict-Mode-Rollout wählt Arbeitseinheiten, die du abschließen kannst. KI-generierte Apps haben oft ungleichmäßige Qualität: ein Ordner ist in Ordnung, der nächste ist voller impliziter any, fehlender Null-Prüfungen und copy-pasteter Typen. Staging sorgt dafür, dass du Fortschritt machst, ohne den gesamten Code in eine Wand aus roten Fehlern zu verwandeln.

Wähle eine Migrationseinheit, die zur Projektorganisation passt: nach Ordner (geschichtete Projekte), nach Feature (Routes + UI + Services), nach Package (Monorepo) oder nach Entrypoint (ein Worker, Webhook oder Job Runner, der die meisten Abstürze verursacht).

Bleib lieferfähig während der Migration. Vermeide einen lange lebenden „strict mode“-Branch, der wochenlang abdriftet. Arbeite in kleinen PRs und merge oft. Wenn Strictness noch nicht überall aktiv ist, behandle den „strict area“ als geschützt: neue Dateien darin müssen sauber sein, und Änderungen außerhalb sollten die Typen nicht verwässern.

Bestimme außerdem eine Ansprechperson für Migrationsmuster. Es geht nicht um Hierarchie, sondern um Konsistenz. Jemand muss Entscheidungen fällen wie: wann unknown statt any, wie gemeinsame Typen heißen und wann eine schnelle Type-Guard-Lösung reicht oder eine Refaktorierung nötig ist.

Für jedes Chunk definiere „done“ klar: Strict-Prüfungen bestehen für diesen Bereich, Tests laufen (oder du fügst einen kleinen Test für den riskanten Pfad hinzu), temporäre Ausnahmen sind dokumentiert, und der Code bleibt lesbar.

Schritt-für-Schritt Rollout-Plan (kleine Schritte, weniger Überraschungen)

Starte damit, sicherzustellen, dass du erkennen kannst, ob du Verhalten gebrochen hast. KI-generierte Apps „funktionieren“ oft, weil nichts Randfälle prüft, nicht weil der Code sicher ist.

Freeze das heutige Verhalten mit einem Build, der immer gleich läuft. Füge ein paar Smoke-Checks hinzu, die die Hauptpfade abdecken: Anmelden, Laden einer wichtigen Seite, Absenden eines Formulars und Aufruf einer API-Route. Halte sie einfach, aber reproduzierbar.

Rolle dann die Strenge in überschaubaren Scheiben aus. Das Ziel ist weniger Laufzeitfehler, ohne alles in eine riesige Refaktorierung zu verwandeln.

1. Baseline der aktuellen App: Lass tsc in CI (oder lokal) laufen und stelle sicher, dass das Projekt in seinem aktuellen Zustand sauber baut. Füge ein kleines Smoke-Skript oder eine manuelle Checkliste hinzu, die in 2 Minuten durchführbar ist.
2. Beschränke die Strenge zunächst auf einen sicheren Bereich: Wende strengere Einstellungen auf einen einzelnen Ordner an (ein neues Feature, ein Package oder ein Modul), damit du die Fehlermuster lernst, ohne die gesamte Arbeit zu stoppen.
3. Behebe die risikoreichsten Laufzeit-Grenzen: Konzentriere dich auf Stellen, an denen unbekannte Daten ins System gelangen, wie API-Antworten, Request Bodies, env-Variablen, localStorage und DB-Lesezugriffe. Füge Parsing/Validierung hinzu und lasse die Typen die Realität widerspiegeln.
4. Erweitere schrittweise mit kleinen PRs: Halte Änderungen fokussiert (je PR ein Thema), z. B. „fix any im API-Client“ oder „füge Null-Checks im Auth-Flow hinzu.“ Kleine PRs sind leichter zu reviewen und ändern weniger wahrscheinlich Verhalten.
5. Schalte Strict global um, wenn die Fehlerzahl gering ist: Sobald du auf ein handhabbares Niveau gekommen bist, aktiviere strict global und räume die verbleibenden Hotspots auf.

Beispiel: Wenn dein Prototyp gelegentlich mit „Cannot read property 'id' of undefined“ abstürzt, zeigt dir Strictness meist die Kette, in der user null sein kann. Ein Fix an der Auth-Grenze entfernt oft eine ganze Klasse von Fehlern.

Welche Strictness-Flags zuerst aktivieren (und warum die Reihenfolge wichtig ist)

Alles auf einmal zu aktivieren bei unordentlichem Code führt oft zu einer Wand aus Fehlern ohne klaren Ausweg. Besser ist, Prüfungen in einer Reihenfolge einzuschalten, die Fixes lokal hält und Reviews verständlich macht.

Eine praktische Reihenfolge für unordentliche Codebasen ist:

• noImplicitAny: zwingt dich, unklare Typen zu benennen statt still any zu nutzen
• strictNullChecks: stoppt die klassischen „cannot read property of undefined“-Fehler
• strictBindCallApply: fängt falsche Funktionsaufrufe (häufig in kopiertem Utility-Code)
• noImplicitThis: verhindert verwirrende this-Verwendung in älteren Mustern
• useUnknownInCatchVariables: macht Fehlerbehandlung sicherer als das Annahmen-any

Nach jedem gesetzten Flag behebe die neuen Fehler, bevor du zum nächsten übergehst. So bleiben die Änderungen klein und du lernst, welche Teile der App tatsächlich fragil sind.

Ob du "strict": true setzen solltest, hängt von deiner Situation ab. Wenn du starke Tests und eine kleine Codebasis hast, ist das in Ordnung. Für KI-generierte Apps mit unklaren Grenzen ist das schrittweise Aktivieren meist sicherer.

Du kannst die Einschlagsbreite auch mit include und exclude steuern. Mit src/ zu starten und problematische Bereiche vorübergehend zu überspringen, macht oft den Unterschied zwischen „Fortschritt“ und „Feststecken."

Behandle einige Ordner unterschiedlich:

• generierte Ausgaben: schließe sie aus und typprüfe stattdessen die Quelle
• Vendor-Code: editier ihn nicht; wickle ihn mit getypten Adaptern ein
• Legacy-Ordner: isoliere sie und füge Typen nur dort hinzu, wo sie neuen Code berühren
• gemischtes JS/TS: konvertiere Entrypoints zuerst, nicht jede Datei auf einmal

Fix-Muster, die Fehler entfernen ohne Over-Engineering

Die schnellsten Erfolge kommen vom konsequenten Beheben weniger Fehlerklassen.

Beginne mit implizitem any. Tippe Grenzen zuerst: Funktions-Inputs, Rückgabetypen und alles, was ein Modul überschreitet (API-Client, DB-Helper, Event-Handler). Sobald die Kanten typisiert sind, verschwinden viele interne any-Fehler, weil TypeScript mehr inferiert.

Null- und undefined-Fehler brauchen meistens weniger Arbeit, als sie aussehen. Bevorzuge Narrowing statt komplexer Typen: prüfe den Wert, return früh und halte den „happy path“ sauber. Wenn ein Default sinnvoll ist, setze ihn einmal (z. B. name ?? "" für die Anzeige) statt überall Non-Null-Assertions (!) zu verteilen.

Beim Umgang mit KI-geformtem JSON verwende unknown statt any. unknown zwingt zu einer Prüfung, bevor du den Wert nutzt — genau das, was du für nicht vertrauenswürdige Payloads willst.

Praktische Fixes, die du schnell anwenden kannst

• Tippe Inputs und Outputs zuerst (API-Funktionen, Utilities, Komponenten), fülle Interna nur dort, wo Fehler bleiben.
• Engere Nullable-Werte mit if (!value) return ... und kleinen Guards wie typeof x === "string".
• Nutze unknown für JSON- und Parse-Ergebnisse, dann mit einfachen Checks eingrenzen, bevor du Eigenschaften liest.
• Validere oder engere API-Antworten nur auf das Notwendige, statt dem ganzen Payload blind zu vertrauen.

React und Formulare sind häufige Schmerzpunkte. Tippe Events (React.ChangeEvent<HTMLInputElement>), halte State-Typen konsistent und definiere Komponenteneigenschaften explizit. Ein korrektes Event-Typing kann überraschend viele nachgelagerte Fehler entfernen.

Leitplanken: verhindere, dass Strictness wieder verloren geht

Strictness einzuschalten ist nur die halbe Miete. Die eigentliche Herausforderung ist, sie einzuhalten, wenn die nächste „Quick-Fix“-Verlockung auftaucht — besonders in KI-generiertem Code, wo man leicht mit any überdecken kann.

Setze Leitplanken, die den sicheren Weg zum einfachen Weg machen. Du brauchst kein riesiges Regelwerk. Fang mit ein paar Regeln an, die zum tatsächlichen Fehlerverhalten deines Teams passen:

• lint gegen any und „unsichere“ Type-Assertions (as unknown as X) außer in wenigen erlaubten Dateien
• markiere schwebende Promises, damit async-Fehler nicht ignoriert werden
• erfordere explizite Rückgabetypen an Schlüsselgrenzen (API-Handler, Auth, Datenzugriff)
• verbiete // @ts-ignore, außer es gibt einen Grund und ein Ablaufdatum im Kommentar
• achte auf Workarounds zu noUncheckedIndexedAccess, die reale Null-Fälle verbergen

Halte Ausnahmen sichtbar. Wenn eine Datei eine Woche locker bleiben muss, markiere und verfolge das, statt „temporär“ dauerhaft werden zu lassen.

Füge ein einfaches CI-Gate hinzu: Builds schlagen fehl, wenn neue TypeScript-Fehler auftauchen. Während einer gestuften Migration ist die einfachste Version, Prüfungen auf den Ordner zu beschränken, den du gerade verschärfst, und diesen Bereich dann schrittweise zu erweitern.

Du kannst auch leichte „Type-Tests“ für wichtige Shapes hinzufügen. Das sind Compile-Zeit-Prüfungen für Schlüsseldatenstrukturen, z. B. „eine Session muss userId enthalten“ oder „die API-Antwort für /me enthält email und role.“ Halte sie klein.

Schließlich reduziere Duplikation, indem du einen kleinen gemeinsamen Types-Ordner für wiederkehrende Shapes erstellst: User, Session, Role, ApiError. Leben diese Typen an einem Ort, bleibt die Strictness-Arbeit konsistent und generierter Code hat ein klares Ziel.

Häufige Fehler, die Migrationen zum Stillstand bringen (und wie man sie vermeidet)

Migrationen stocken, wenn das Team den Compiler ruhig stellt, aber nicht dem Laufzeitverhalten vertraut. Ziel ist nicht „Fehler verschwinden lassen“, sondern weniger Produktions-Bugs, während du die Typen verschärfst.

Der schnellste Weg, dieses Vertrauen zu verlieren, ist, den Compiler zu beruhigen statt die Ursachen zu beheben.

Die Abkürzungen, die nach hinten losgehen

• Echte Fixes durch as-Assertions ersetzen. Wenn du ständig as any oder as SomeType schreibst, frage, was der Wert zur Laufzeit sein kann. Validieren oder eingrenzen.
• Die Non-Null-Assertion (!) überall verwenden. Sie verwandelt Compile-Zeit-Warnungen in Laufzeitabstürze, besonders bei Auth-State, async-Daten und optionalen env-Variablen.
• Riesige Union-Types bauen, um chaotische Inputs zu modellieren. Sie mögen korrekt sein, aber wenn niemand sie lesen kann, verfallen sie. Normalisiere Daten an der Grenze und nutze intern eine saubere Form.
• Typing-Änderungen, die auch Verhalten ändern. Kleine Bearbeitungen wie || gegen ?? tauschen, Defaults ändern oder Checks umordnen können Outputs verändern. Trenne Typ-Änderungen von Logik-Änderungen, damit Reviews klar bleiben.
• Alles in einem riesigen PR migrieren. Sieht effizient aus, bis eine harte Datei den Merge blockiert. Teile Arbeit in abschließbare Scheiben.

Eine praktische Gewohnheit: Wann immer du ein Cast oder ! hinzufügst, hinterlasse eine Notiz und versuche, es vor dem nächsten Meilenstein zu entfernen. Wenn es nicht entfernbare ist, brauchst du wahrscheinlich eine echte Laufzeitprüfung.

Ein schnelles Beispiel

Angenommen, ein AI-generierter Signup-Flow liest req.body.email und du beruhigst Fehler mit as string und email!.trim(). Es kompiliert, aber ein leerer Payload wirft jetzt. Sicherer ist es, den Typ zu prüfen und frühzeitig einen klaren Fehler zurückzugeben.

Checkliste bevor du Strict für einen größeren Bereich aktivierst

Bevor du die Strict-Einstellungen im ganzen Repo weiterschaltest, stelle sicher, dass die Grundlagen stabil sind. Strict verändert, wie sicher du in jeden Wert der App sein kannst.

Wenn das Projekt nur auf einem Laptop baut oder von einer nicht festgelegten TypeScript-Version abhängt, verschwendest du Zeit mit Fehlern, die nichts mit deinem Code zu tun haben.

Pre-Flight-Checks, die Rollouts vorhersagbar machen:

• Die App baut heute sauber mit einer fixierten TypeScript-Version und dem gleichen Befehl in CI.
• Du kannst die 2–3 häufigsten Laufzeitfehlerquellen benennen (oft null-Werte, API-Mismatch, Auth-Randfälle) und weißt, wo sie auftreten.
• Deine Hauptgrenzen sind getypt, auch wenn das Innere noch unordentlich ist: API-Calls, DB-Zugriffsschicht und Umgebungsvariablen.
• Du kannst Änderungen klein halten: jeder PR ist in einem Tag machbar und hat ein klares Thema.
• Du hast eine klare Regel, wann any akzeptabel ist, und sie ist selten und dokumentiert.

Ein einfaches Szenario hilft: Stell dir vor, dein Prototyp loggt Benutzer nach einem Refresh aus. Wenn dein Auth-Helper User | null zurückgibt, der restliche Code ihn aber immer als vorhanden behandelt, bekommst du zufällige Abstürze. Bevor du die Strictness erweiterst, bestätige, dass du einen typisierten Ort hast, an dem „user kann null sein“ behandelt wird, und der Rest der App daraus liest.

Beispiel: Einen Prototyp verschärfen, ohne Feature-Arbeit zu verlangsamen

Ein Gründer übernimmt einen Lovable- oder Bolt-Prototyp. Lokal läuft er, aber in Produktion stürzt er nach Login ab und manche Seiten zeigen leere Daten. Der Code „funktioniert“, bis ein echter Nutzer einen Randfall trifft: fehlendes Feld, null von der API oder eine Zahl, die als String ankommt.

Statt strict: true überall umzuschalten und in einer Flut von Fehlern zu ertrinken, behandle den Strict-Modus wie eine Reihe kleiner, wirkungsvoller Fixes.

Beginne dort, wo Laufzeitfehler am meisten weh tun: API-Schicht und Auth. In diesem Prototyp gibt getSession() manchmal undefined zurück, die UI geht aber davon aus, dass es immer existiert. Strict-Prüfungen machen das schnell sichtbar.

// Before
const userId = session.user.id

// After
const userId = session?.user?.id
if (!userId) throw new Error("Not authenticated")

Als Nächstes geh zu gemeinsamen Utilities, wo ein Fix viele Bildschirme schützt. Ein typisches Beispiel ist numerisches Parsen. Die API sendet "42", aber die App behandelt es als Zahl und macht später Mathe, die zu NaN wird.

Ein gestufter Pfad, der meist Feature-Arbeit flüssig hält:

• schalte Strictness zuerst nur für API/Auth-Dateien ein
• behebe die Top-Fehler, die echten Abstürzen entsprechen
• verschärfe gemeinsame Helfer (Parsing, Datumshandling, Config)
• erweitere Strict-Prüfungen zuletzt auf UI-Komponenten

Unterwegs triffst du typische generierte-Code-Fehler: optionale Felder werden wie vorhanden angenommen (profile.name), Typen gemischt (string | number) oder Teilobjekte zurückgegeben. Die Lösung ist selten komplex: einfache Guards, korrekte Rückgabetypen und Daten an der Grenze normalisieren (API rein, saubere App-Typen raus).

Was „gut“ nach dem Rollout aussieht: weniger Produktionsabstürze, klarere Regeln, was undefined sein kann, und wenige Owner für Kern-Dateien (Auth, API-Client, gemeinsame Types).

Nächste Schritte: Erstelle einen klaren Migrationsplan (und Hilfe wenn nötig)

Strict-Modus funktioniert, wenn du ein Tempo wählst, das du halten kannst. Bevor du loslegst, definiere, was „done“ für deine App bedeutet: weniger Produktions-Bugs, sichere Auth- und Datenhandhabung oder eine Codebasis, die dein Team ohne Angst ändern kann.

Wenn du immer wieder dieselben „unmöglichen“ Bugs siehst (zufällige Logouts, Auth-Logik, die zwischen Umgebungen variiert, Secrets im Repo), ist das ein Zeichen, dass Grenzen Aufmerksamkeit brauchen. Ein weiteres Warnsignal ist Spaghetti-Architektur: Dateien, die alles machen, keine klare Trennung und Typ-Fixes, die sich über Dutzende Module verteilen.

Wenn du einen AI-generierten Prototyp geerbt hast und einen externen Blick willst, bietet FixMyMess (fixmymess.ai) Unterstützung beim Transformieren von AI-Builds in produktionsbereite Software: Codebasis diagnostizieren, Logik reparieren, Sicherheit härten, unsichere Bereiche refactoren und Deployments vorbereiten. Ein praktischer erster Schritt ist ein kostenloses Code-Audit, damit du einen gestuften Strict-Mode-Plan bekommst, ohne zu raten.