Die falsche Metrik

Die meisten Gespräche über die Qualität von KI-generiertem Code konzentrieren sich auf Korrektheit zum Zeitpunkt der Generierung. Kompiliert die Ausgabe? Besteht sie die Tests? Entspricht sie der Spezifikation?

Das sind Grundvoraussetzungen. Sie sagen nichts über die tatsächlichen Kosten aus.

Die eigentliche Metrik ist Ersetzbarkeit: Wie günstig lässt sich dieser Code löschen und hinter demselben Contract neu implementieren, wenn sich die Anforderungen ändern?

Wenn die Antwort „trivial“ lautet, potenziert sich der KI-Geschwindigkeitsvorteil. Wenn die Antwort lautet „wir müssen erst sechs implizite Abhängigkeiten nachverfolgen“, hat man den Geschwindigkeitsvorteil, den man zu erkaufen glaubte, bereits verloren.

Warum KI-Code zur Kopplung neigt

Große Sprachmodelle optimieren für die unmittelbare Anfrage. Sie optimieren nicht für zukünftige Änderungen.

Wenn man nach einem Login-Flow fragt, bekommt man einen Login-Flow, der funktioniert. Man bekommt keinen Login-Flow hinter einem Auth-Interface, das von Firebase zu Supabase zu einem eigenen JWT-Dienst gewechselt werden kann, ohne einen einzigen Screen zu berühren, der es konsumiert.

Das ist kein Modellfehler. Es ist ein Kontextfehler. Das Modell wurde nicht gebeten, für Ersetzbarkeit zu optimieren, also hat es das nicht getan.

Das Ergebnis: KI-generierter Code neigt standardmäßig zu enger Kopplung. Nicht weil das Modell schlecht ist, sondern weil Isolation für einen Next-Token-Predictor niemals der Weg des geringsten Widerstands ist.

Ersetzbarkeit ist eine Architekturentscheidung

Ersetzbarkeit passiert nicht zufällig. Sie ist eine bewusste strukturelle Entscheidung:

  • Jede externe Abhängigkeit sitzt hinter einem Interface, das die Anwendung besitzt.
  • Generierte Module exponieren einen Contract, keine Implementierung.
  • Jede optionale Fähigkeit wird injiziert, niemals direkt importiert.
  • Jede Kompositionsentscheidung lebt in einem einzigen Composition Root, nicht verstreut über fünfzig Dateien.

Das ist nicht neu. Es ist grundlegende Dependency Inversion. Was neu ist: KI-generierter Code macht das Verletzen dieser Prinzipien mühelos und unsichtbar – bis man etwas ändern muss.

Der Zinseszinseffekt

Wenn alle Module ersetzbar sind:

  • Schlechte Generierungen kosten Minuten, nicht Tage.
  • Anbieterwechsel sind Interface-Tausch, keine Rewrites.
  • KI-Geschwindigkeit bleibt über Iterationen hinweg linear, nicht logarithmisch.
  • Das Team kann sagen „regeneriere das hinter demselben Contract“ und es auch so meinen.

Wenn Module verflochten sind:

  • Jede Änderung erfordert das Verständnis des gesamten Abhängigkeitsgraphen.
  • Jeder KI-gestützte Refactor riskiert, unzusammenhängende Systeme zu brechen.
  • Das Team hört allmählich auf, KI-Ausgaben zu vertrauen, weil der Wirkungsradius unvorhersehbar ist.
  • Die Geschwindigkeit fällt auf Vor-KI-Niveau zurück, aber nun mit mehr Code in der Wartung.

Der praktische Test

Bevor man KI-generierten Code in eine Codebase übernimmt, sollte man einen Test anwenden:

Kann ich diese Datei löschen und von Grund auf neu implementieren, ausschließlich unter Verwendung des Interface, das sie exponiert, ohne einen einzigen Konsumenten zu modifizieren?

Wenn ja, ausliefern. Wenn nein, die Grenze korrigieren, bevor man ausliefert.

Das ist günstig durchzusetzen. Ein Composition Root plus Interface-First-Design gibt einem diese Eigenschaft strukturell. Man braucht keine aufwendige Governance. Man braucht eine einzige Architekturregel, konsequent angewandt.

Die Verbindung zu AI-native-Architektur

Ich habe über dieses umfassendere Problem in Stanford CS146S Is Right About AI Coding — The Missing Subject Is Architecture geschrieben. Das Ersetzbarkeits-Prinzip ist der spezifische Mechanismus, der AI-native-Codebases über Version Eins hinaus überlebensfähig macht.

Stanford lehrt Entwicklern, wie man KI-Werkzeuge effektiv nutzt. Das ist wichtig. Aber Werkzeugkompetenz ohne Ersetzbarkeit ist eine Falle: Man liefert schneller aus, bis die Codebase teuer zu ändern wird, und dann liefert man langsamer aus als Teams, die KI nie eingesetzt haben.

Die Disziplin ist nicht „besser prompten“. Die Disziplin ist „so architekturieren, dass Prompting-Fehler günstig rückgängig zu machen sind.“

FAQ

Was bedeutet „ersetzbare Architektur“ für KI-generierten Code?

Ersetzbare Architektur bedeutet, dass KI-generierte Module hinter einem Interface sitzen, von dem der Rest des Systems abhängt – nicht von den Implementierungen selbst. Wenn sich Anforderungen ändern oder eine Generierung falsch ist, löscht man den betreffenden Code und implementiert ihn neu, ohne Konsumenten zu berühren.

Wie setzt man Ersetzbarkeit in einer KI-generierten Codebase durch?

Drei Mechanismen: Interfaces, die der Anwendung gehören (nicht der Abhängigkeit), ein einzelner Composition Root, in dem alle Implementierungen verdrahtet werden, und eine CI-Prüfung, die fehlschlägt, wenn Teile des Systems die Interna anderer Module direkt importieren.

Verlangsamt Ersetzbarkeit die anfängliche Entwicklung?

Nein. Ein Interface zu definieren, bevor man eine Implementierung generiert, kostet Sekunden. Die Kosten des Unterlassens zeigen sich Wochen später, wenn ein Anbieterwechsel oder Refactor sich in einen vollständigen Rewrite verwandelt.

Ist das dasselbe wie Dependency Injection?

Dependency Injection ist ein Mechanismus zur Erreichung von Ersetzbarkeit, aber nicht das vollständige Bild. Ersetzbarkeit erfordert auch Contract Tests, Boundary Validation und einen Composition Root – nicht nur Konstruktor-Parameter.