Warum Senior Code Review im Zeitalter der KI weiterhin zählt

Im KI-Entwicklungsbereich kursiert eine verlockende Erzählung: Je besser Modelle Code schreiben, desto weniger braucht es erfahrene menschliche Prüfer. Die Logik wirkt einleuchtend. Wenn eine KI in Sekunden funktional korrekten Code erzeugen kann, warum soll ein Senior-Ingenieur dreißig Minuten mit dem Review verbringen?

Wir haben zwei Jahre lang mit Daten aus unserer eigenen Delivery-Pipeline auf diese Frage geantwortet – und die Antwort ist eindeutig: Senior Code Review ist im Zeitalter der KI wichtiger, nicht unwichtiger. Hier der Grund.

Was KI richtig macht (und warum das nicht reicht)

Moderne KI-Codegenerierung ist tatsächlich beeindruckend. Bei klar abgegrenzten Aufgaben kann ein gutes Modell in Sekunden lauffähigen Code produzieren, für den ein menschlicher Entwickler fünfzehn Minuten bis eine Stunde brauchen würde. Der Code:

• Erfüllt die genannten Anforderungen in der Regel korrekt
• Folgt gängigen Mustern für Sprache und Framework
• Enthält sinnvolle Fehlerbehandlung für offensichtliche Fehlerszenarien
• Besteht die im Prompt beschriebenen Tests

Für viele Organisationen wirkt dieses Niveau ausreichend. Ausliefern, weitermachen, schneller werden. Die Probleme tauchen später auf, oft viel später, und lassen sich nur schwer auf den generierten Code zurückführen.

Die fünf blinden Flecken von KI-generiertem Code

1. Architekturerosion

KI-Modelle erzeugen Code isoliert. Sie sehen den Prompt, nicht das System. Jedes generierte Modul kann intern gut strukturiert sein – die Gesamtheit der Module kann aber die beabsichtigte Architektur des Systems auf subtile Weise verletzen: z. B. zirkuläre Abhängigkeiten, Duplizierung von Logik, die geteilt werden sollte, oder Kopplung zwischen Komponenten, die unabhängig sein sollten.

Ein Senior-Reviewer sieht den Code im Kontext. Er weiss, dass das Zahlungsmodul nicht aus dem Benachrichtigungsmodul importieren darf, auch wenn es das aktuelle Problem löst. Er wahrt die Architektur-Invarianten, die ein System bei Wachstum wartbar halten. Kein Modell kann das ohne ein umfassendes Verständnis der Designabsicht des Systems, und aktuelle Modelle haben dieses Verständnis nicht.

2. Nicht offensichtliche Sicherheitslücken

KI-Modelle wurden mit grossen Mengen Code trainiert – auch Code mit Sicherheitslücken. Sie wurden ausserdem darauf trainiert, Code zu produzieren, der „richtig aussieht“, was nicht dasselbe ist wie sicherer Code. Typische Punkte, die wir im Review finden:

• Timing-Angriffe in Authentifizierungscode, der String-Vergleich statt zeitkonstantem Vergleich nutzt
• SQL-Injection-Vektoren, die technisch parametrisiert sind, die Parametrisierung aber durch String-Interpolation in einer Wrapper-Funktion verlieren
• Zu permissive CORS-Konfigurationen, die in der Entwicklung funktionieren, in Produktion aber APIs exponieren
• Unsichere Standardeinstellungen bei kryptographischen Operationen, z. B. ECB-Modus für AES oder unzureichende Schlüssellängen
• Informationsleckage durch ausführliche Fehlermeldungen, die Systeminterna preisgeben

Das sind keine Anfängerfehler. Es sind subtile Punkte, die Erfahrung brauchen, um erkannt zu werden, und die jede denkbare automatisierte Testsuite passieren.

3. Performance unter Last

KI-generierter Code funktioniert typischerweise korrekt bei kleinen Eingaben und geringer Parallelität. Was oft fehlt:

• N+1-Abfrage-Muster, die bei 10 Datensätzen unsichtbar, bei 10 000 katastrophal sind
• Speicherallokationsmuster, die unter Last Garbage-Collection-Pausen auslösen
• Lock-Kontention in nebenläufigem Code, die erst bei hoher Parallelität sichtbar wird
• Unbeschränkte Datenstrukturen, die unbegrenzt wachsen, weil das Modell Cache-Eviction nicht bedacht hat

Senior-Ingenieure haben diese Muster schon erlebt. Sie haben ein Gespür für Code, der „riecht“, als würde er nicht skalieren – auch ohne Benchmark. Diese aus Jahren Produktionsincidents gewonnene Mustererkennung fehlt KI-Modellen.

4. Operative Blindheit

KI-Modelle betreiben keine Software. Sie werden nicht um 3 Uhr nachts geweckt, weil ein Dienst ausfällt. Sie haben nie vor einem Dashboard gestanden und versucht zu verstehen, warum die Latenz in die Höhe ging. Daher vernachlässigen sie konsequent die operativen Aspekte, die den Unterschied ausmachen zwischen Software, die funktioniert, und Software, die zuverlässig betrieben werden kann:

• Aussagekräftige Logmeldungen mit dem für das Debugging nötigen Kontext
• Metriken und Traces in der richtigen Granularität
• Health-Check-Endpunkte, die echte Bereitschaft abbilden, nicht nur Prozess-Liveness
• Graceful Shutdown, der laufende Anfragen sauber abarbeitet
• Konfiguration, die ohne Neudeployment geändert werden kann

Ein Senior-Reviewer ergänzt diese Punkte, weil er die Folgen ihrer Abwesenheit erlebt hat.

5. Das „funktioniert, ist aber falsch“-Problem

Vielleicht der tückischste blinde Fleck: Code, der alle Tests besteht, alle genannten Anforderungen erfüllt und funktional korrekt ist, aber die falsche Abstraktion implementiert. Er löst das heutige Problem so, dass das morgige schwieriger wird.

Das ist eine Ermessensfrage, die nicht nur das aktuelle Ticket, sondern die Produkt-Roadmap, die Teamgeschwindigkeit und die Kosten zukünftiger Änderungen berücksichtigen muss. Ein Senior-Ingenieur könnte sagen: „Das funktioniert, aber wenn wir es so bauen, erfordert Multi-Tenancy im nächsten Quartal einen Rewrite. Ich schlage einen anderen Ansatz vor, der jetzt zwei Stunden mehr kostet, aber später zwei Wochen spart.“ Kein KI-Modell trifft solche strategischen Trade-offs.

Die sich wandelnde Rolle des Senior-Reviewers

Im traditionellen Entwicklungsablauf deckt Code Review alles ab – von Stil-Kleinigkeiten bis zu Architekturfragen. KI erledigt Ersteres gut genug, sodass Senior-Reviewer sich voll auf Letzteres konzentrieren können. Das ist eine bessere Nutzung ihrer Zeit, keine geschrumpfte Rolle.

Wir haben unseren Review-Prozess auf fünf Fragen ausgerichtet:

1. Passt dieser Code zur Architektur des Systems? Nicht nur „funktioniert er“, sondern „gehört er hierher, in dieser Struktur?“
2. Was passiert, wenn dies fehlschlägt? Nicht der Happy Path, sondern Netzwerk-Timeouts, fehlerhafte Eingaben, Ressourcenerschöpfung und Teilausfälle.
3. Woher wissen wir, ob das in Produktion kaputt ist? Sind die richtigen Signale für Monitoring und Alerting vorhanden?
4. Welche Annahmen trifft dieser Code? Jeder Code macht Annahmen über seine Umgebung. Sind sie dokumentiert und validiert?
5. Was muss der nächste Entwickler verstehen? Code wird weit öfter gelesen als geschrieben. Erzählt dieser Code eine klare Geschichte?

„Das beste Code Review geht es nicht um das Finden von Bugs. Es geht darum, sicherzustellen, dass der Code die ingenieurtechnischen Werte und das Systemwissen verkörpert, die eine Codebasis über Jahre gesund halten – nicht nur heute korrekt.“

Umsetzung in der Praxis

Code Review als zentrale Wertschöpfung zu etablieren, braucht organisatorische Unterstützung:

• Zeitbudget. Senior-Ingenieure brauchen fest eingeplante Review-Zeit, nicht Review zwischen Feature-Arbeit. Wir planen 25–30 % der Senior-Kapazität für Reviews ein.
• Anerkennung. Review-Qualität sollte gemessen und honoriert werden. Wir erfassen Gründlichkeit (nicht nur Geschwindigkeit) und berücksichtigen sie in Leistungsbeurteilungen.
• Tooling. Automatisierte Prüfungen für Stil, Formatierung und bekannte Anti-Patterns entlasten Reviewer für die Einschätzungen, die nur Menschen treffen können.
• Wissensweitergabe. Review-Kommentare sind eine Form von Mentoring. Wir fördern ausführliche Begründungen – nicht nur „ändere das“, sondern „ändere das, weil …“.

Fazit

KI-Codegenerierung ist ein Kraftmultiplikator für Softwareteams. Multiplizieren ohne Richtung erzeugt aber keine Qualität – es erzeugt mehr von dem, was Sie schon haben, nur schneller. Senior Code Review ist die Richtungskraft, die sicherstellt, dass KI-gestützte Geschwindigkeit zu echtem Fortschritt in der Technik wird statt zu beschleunigter technischer Schuld.

Die Unternehmen, die sich durchsetzen werden, sind nicht die, die am schnellsten Code erzeugen. Es sind die, die die robustesten, wartbarsten und betreibbarsten Systeme bauen. Dafür braucht es menschliches Urteilsvermögen, Erfahrung und Gespür – Eigenschaften, die KI ergänzt, aber nicht ersetzen kann.