KI schreibt guten Code, aber baut schlechte Systeme

KI schreibt guten Code, aber baut schlechte Systeme — das ist die nüchterne Erfahrung aus der Architektur-Praxis. Bittet man sie um eine Funktion, liefert sie eine ausgezeichnete Funktion; muss dieselbe Funktion aber in eine Architektur aus dreißig anderen Modulen passen, stößt sie an eine fundamentale Grenze: Sie optimiert lokal, während das System global auseinanderläuft.

Dafür, den KI-Hebel trotzdem konsequent zu nutzen, spricht die Vorbereitungs-Arbeit: Aus den Anforderungen des fachlichen Grobkonzepts erzeugt die KI in Stunden statt Wochen mehrere Architektur-Varianten samt Trade-off-Analysen, und der „Kernel-to-ADR”-Ansatz verwandelt knappe Entscheidungs-Notizen in vollständige Architecture Decision Records in Minuten statt Stunden. Salesforce hat so ein zweijährig veranschlagtes Architektur-Refactoring über 3.537 Dateien in vier Monaten umgesetzt. Die KI liefert den Optionsraum — die Entscheidung selbst bleibt beim Menschen.

Dagegen — beziehungsweise als Beleg für die Grenze selbst — steht der Qodo-Report: 65 Prozent der Entwickler nennen fehlenden Kontext als Hauptproblem bei KI-generiertem Code, häufiger noch als Halluzinationen. Das ist kein KI-Problem, sondern ein Architekturproblem: Die KI kennt die impliziten Konventionen und Abhängigkeiten eines Projekts nicht, wenn niemand sie ihr gibt. Genau deshalb wächst laut GitClear-Daten die Code-Duplikation in unkontrollierten KI-Projekten um das Vierfache.

Der Architekt wird dadurch wichtiger, nicht überflüssig: ADRs und ausführbare Fitness Functions sind die Leitplanken, in denen die KI ihre lokale Stärke gefahrlos ausspielen kann.

→ Mehr zum Buch und zum Kapitel „Technisches Grobkonzept und Architektur”