KI‑gestütztes Code‑Review und das Write‑Only‑Code‑Problem

KI-gestützte Codeanalyse verkürzt die Durchlaufzeiten von Pull-Requests messbar. Kontrollierte Benchmarks wie Peng et al. (2023) belegen eine deutliche Beschleunigung isolierter Programmieraufgaben. In produktiven Entwicklungsteams reduzieren automatisiertes PR-Triage und semantisches Linting die Review-Dauer von mehreren Tagen auf unter 24 Stunden. Der wesentliche architektonische Vorteil liegt in der Komprimierung der Continuous-Integration-Feedbackschleifen, wodurch Schnittstellenverletzungen bereits vor dem menschlichen Architektur-Review sichtbar werden.

Diese Zahlen sind real. Ebenso real ist das Problem, das sie verdecken: KI‑generierter Code häuft sich in Codebases schneller an, als Teams ihn verstehen können. Das Ergebnis ist eine neue Kategorie technischer Schulden – Code, der heute funktioniert, den aber morgen niemand sicher ändern kann. Sobald ein Entwickler nicht mehr nachvollziehen kann, welche Annahmen einer Implementierung zugrunde liegen, steigt das Risiko, dass jede Modifikation unvorhergesehene Seiteneffekte erzeugt.

Das Write‑Only‑Code‑Problem

„Write‑only code“ ist ein Begriff, der vom Write‑only‑Memory entlehnt ist – ein Konzept, das so absurd ist, dass es zum Scherz wurde. Im Kontext von KI‑generiertem Code beschreibt er jedoch etwas, das tatsächlich passiert: Code, der erzeugt, im Review akzeptiert und gemergt wurde, den aber kein Ingenieur im Team vollständig versteht.

Dies ist keine Hypothese. Es folgt direkt aus der Funktionsweise von KI‑Codegenerierung:

1. Ein Entwickler gibt einem KI‑Assistenten eine Aufgabe.
2. Der Assistent produziert eine plausible Implementierung.
3. Der Entwickler prüft, ob sie die Tests besteht und ob sie vernünftig aussieht.
4. Die Änderung wird gemergt.

Das Problem liegt in Schritt 3. „Sieht vernünftig aus“ ist nicht dasselbe wie „Ich verstehe, was das tut und warum“. Wenn der Code geändert werden muss – weil sich Anforderungen verschieben, ein Bug auftritt oder eine Abhängigkeit aktualisiert wird – stellt das Team fest, dass niemand ihn sicher modifizieren kann. Der Code ist dann effektiv write‑only.

Eine Analyse von GitClear aus dem Jahr 2024, die 153 Millionen Codezeilen untersuchte, zeigte, dass KI‑unterstützte Codebases eine messbare Zunahme von Code‑Churn (Code, der innerhalb von zwei Wochen hinzugefügt und dann zurückgesetzt oder geändert wird) und gleichzeitig eine Abnahme von Code‑Verschiebungen und -Updates aufweisen. Das deutet darauf hin, dass KI‑Tools eher Wegwerf‑Code produzieren und weniger bewusstes Refactoring fördern.

Was KI‑Review‑Tools tatsächlich tun

KI‑gestützte Code‑Review‑Tools (z. B. CodeRabbit, GitHub Copilot Code Review, Sourcery, Amazon CodeGuru) analysieren Pull‑Requests und markieren:

• gängige Fehlermuster (Null‑Dereferenzierungen, Off‑by‑One‑Fehler, fehlende Fehlerbehandlung);
• Sicherheitsprobleme (hartcodierte Anmeldedaten, Injektionsrisiken, unsichere Abhängigkeiten);
• Stil‑ und Konsistenzabweichungen;
• fehlende Testabdeckung für geänderte Pfade;
• Dokumentationslücken.

Das ist genuiner Nutzen. Sie fangen mechanische Probleme ab, die menschliche Reviewer bei Müdigkeit oder Zeitdruck leicht übersehen. Außerdem arbeiten sie konsistent – sie kennen keine schlechten Tage.

Was sie jedoch nicht können:

• verifizieren, dass der Code das tatsächlich zu lösende Problem adressiert;
• beurteilen, ob das Design zur bestehenden Systemarchitektur passt;
• abschätzen, ob eine neue Abstraktion ihren Komplexitätspreis wert ist;
• den geschäftlichen Kontext erfassen, der eine korrekt aussehende Implementierung falsch macht;
• Fehler erkennen, die das Verständnis systemweiter Invarianten über mehrere Dateien hinweg erfordern.

Das Muster der Schuldenakkumulation

Das Write‑only‑Code‑Problem verstärkt sich mit der Zeit. Jede gemergte KI‑generierte Funktion, die niemand vollständig versteht,

• macht die nächste Änderung schwieriger, weil der Ingenieur erst das fremde Vorgehen reverse‑engineeren muss;
• reduziert die Fähigkeit des Teams, das Gesamtverhalten des Systems zu beurteilen;
• erhöht das Risiko, dass eine zukünftige Änderung unerwartet etwas bricht;
• erschwert das Onboarding neuer Kolleg*innen, die keine mentale Karte des Codes besitzen.

Die Ironie besteht darin, dass KI‑Tools auch lesen können – sie können erklären, was eine Funktion Zeile für Zeile tut. Erklärung ist jedoch nicht dasselbe wie tiefes Verständnis. Eine KI kann beschreiben, welche Anweisungen ausgeführt werden, aber sie kann nicht beurteilen, ob diese Funktion überhaupt nötig ist, ob ihre Abstraktion sinnvoll ist oder ob sie zur Design‑Intention des Gesamtsystems passt.

Warum die Schulden still akkumulieren

Das Write‑only‑Code‑Problem ist schwer zu erkennen, weil es in den Kennzahlen, die Teams typischerweise verfolgen, nicht auftaucht. Test‑Pass‑Raten bleiben grün, PR‑Zykluszeiten sinken, und die Deployment‑Frequenz kann sogar steigen. Die Schuld bleibt unsichtbar, bis jemand den Code ändern muss – dann muss er die gesamte Logik erst verstehen, bevor er sicher modifizieren kann. Dieser Aufwand fällt häufig unter Zeitdruck an und kostet das Team wertvolle Ressourcen.

Deshalb ist der GitClear‑Befund über erhöhten Code‑Churn bedeutsam: Churn ist ein nachlaufender Indikator für Write‑only‑Code. Code, der generiert, gemergt und dann innerhalb von zwei Wochen zurückgesetzt oder neu geschrieben wurde, ist Code, der beim ersten Mal nicht gut genug verstanden war, um korrekt zu sein. Die Churn‑Rate ist somit das sichtbare Signal der bislang verborgenen Schuld.

Wie gutes KI‑gestütztes Review aussieht

Teams, die KI‑Review‑Tools am effektivsten einsetzen, behandeln sie als ersten Durchgang, nicht als abschließende Prüfung.

Mechanisches von architektonischem Review trennen

KI‑Tools übernehmen die mechanische Schicht: Stil, gängige Fehlermuster, Sicherheitsmuster und Testabdeckung. Die menschliche Review‑Zeit reserviert das Team für architektonische Fragen:

• Passt das Design zur bestehenden Systemarchitektur?
• Ist die neue Abstraktion ihren Komplexitätspreis wert?
• Gibt es nicht offensichtliche Nebeneffekte, die erst später sichtbar werden?

Verständnis fordern, nicht nur Genehmigung

Ein Reviewer, der nicht erklären kann, was ein Stück Code tut, sollte es nicht genehmigen. Das klingt selbstverständlich, wird aber ständig verletzt, wenn KI‑generierter Code plausibel erscheint und die Tests bestehen. Die Genehmigungsstufe muss verlangen, dass der Reviewer die Frage beantworten kann: „Wenn das in Produktion bricht, was würden Sie ändern und warum?“

In Akzeptanzkriterien vor der Generierung investieren

Die wirksamste Abhilfe gegen Write‑only‑Code ist das Schreiben präziser Akzeptanzkriterien, bevor eine KI etwas implementiert. Eine Funktion mit einem klaren Vertrag – Eingaben, Ausgaben, Invarianten, Randfälle – lässt sich wesentlich leichter reviewen und warten als eine, die aus einer vagen Anfrage entsteht.

/**
 * Calculates the prorated refund amount for a cancelled subscription.
 *
 * @param subscription - Must be in ACTIVE or TRIAL status; throws for others.
 * @param cancellationDate - Must be within the current billing period.
 * @returns Refund amount in cents, rounded down. Returns 0 if less than 1 day remains.
 *
 * Edge cases:
 * - Same-day cancellation: full period refund
 * - Last day of period: 0 refund
 * - Trial period: always full refund regardless of day
 */
function calculateRefund(subscription: Subscription, cancellationDate: Date): number {
  // implementation generated from the above spec is reviewable
  // implementation generated from "calculate refund" is not
}

Der breitere Wandel in der Review‑Kultur

KI‑gestützte Entwicklung verändert den Zweck von Code‑Reviews. Wenn KI die Implementierung generiert, besteht die Aufgabe des Reviewers weniger darin, Tippfehler zu finden, sondern vielmehr darin:

• zu validieren, dass die Spezifikation korrekt war;
• sicherzustellen, dass der generierte Code tatsächlich der Spezifikation entspricht;
• zu beurteilen, ob die Spezifikation selbst vollständig war;
• zu entscheiden, ob das Team diesen Code langfristig besitzen und warten kann.

Das ist eine anspruchsvollere Aufgabe als das traditionelle Review, nicht eine leichtere. Teams, die KI‑Tools lediglich als Mittel zur Reduktion des Review‑Aufwands einsetzen, werden Write‑only‑Code anhäufen. Teams, die sie als Möglichkeit sehen, den Review‑Aufwand auf höherwertige Fragen zu verlagern, können die Produktivitätsgewinne genießen, ohne die Schuld zu erhöhen.