Anmerkung: wenn ich im Folgenden von "KI" rede, beziehe ich mich immer auf Tools, die auf einem LLM (Large Language Model) basieren und in Form einer Schnittstelle (Texteingabe via Chat) Fragestellungen entgegennehmen und die Antwort in Text- oder anderer aufbereiteter Form darstellen wie ChatGPT, Claude, Gemini etc.

Wenn man mich fragt, wie ich Code-Reviews durchführe, dann ist die Antwort "ohne Zuhilfenahme von KI-Tools". Warum? Ich kam bisher nicht auf die Idee.
Für mich sind Code-Reviews ein wichtiger und sogar spaßiger Teil meiner Arbeit. Mein Anspruch an KI war bisher immer, die lästigen Aufgaben zu automatisieren, sodass mehr Zeit für die interessanten bleibt. Code-Reviews gehören für mich – ähnlich wie das Entwerfen von Softwaresystemen oder das Finden von Bugs – zu den Aufgaben, die sich wie ein Rätsel anfühlen, das gelöst werden will. Entfällt dieser Aspekt als Teil des Entwicklungsprozesses, ist das ähnlich schlimm, wie das Spoilern meiner Lieblingsserie.

Doch während ich Code-Reviews als kreativen und analytischen Prozess und wichtigen Bestandteil meiner Arbeit betrachte, beobachte ich eine gegenläufige Entwicklung:
In den vergangenen Jahren – insbesondere seit KI vermehrt zum Generieren von Code verwendet wird – ist ein deutlicher Rückgang der Softwarequalität spürbar. Anwendungen, die ich regelmäßig nutze, weisen zunehmend Fehler auf, und bestehende Tools werden durch Änderungen oft "verschlimmbessert". Zudem werden KI-Assistenten flächendeckend integriert, ohne dass ein klarer Bedarf erkennbar ist.

Die Gründe dürften vielschichtig sein: Teilweise wird diese Entwicklung auf die wachsende Komplexität moderner Softwaresysteme und fehlende oder unvollständige Prozesse zur Qualitätssicherung zurückzuführen sein, andererseits lässt sie sich wohl auch durch eine unkritische Übernahme KI-basierter Lösungen und fehlende Regulierungen erklären.

Warum sind Code-Reviews gerade jetzt wichtiger denn je?
Im Folgenden nenne ich drei zentrale Gründe, die zeigen, warum dieser Prozess in Zeiten von KI unverzichtbar bleibt.

1. KI kann Kontext einer Anwendung nicht (vollständig) betrachten

Selbst erfahrene Entwickler können bei sehr großen und komplexen Anwendungen nicht den gesamten Kontext vollständig überblicken – und das ist auch nicht der Anspruch. Da es für Menschen schwierig ist, den Überblick zu behalten, könnte man annehmen, dass KI dies problemlos leisten kann.

Doch das ist nicht der Fall: Anforderungen entstehen durch Menschen, Systeme wachsen über Jahre und entwickeln Eigenheiten sowie Ausnahmen. Aktuelle KI-Tools sind nicht in der Lage, die Gesamtheit eines Systems zu erfassen und darauf basierend fundierte Entscheidungen zu treffen, die zusätzlich Absprachen mit Stakeholdern und technische Rahmenbedingungen berücksichtigen. Dies würde einen erheblichen Mehraufwand erfordern, der in der Praxis kaum realisierbar ist.

Vielleicht hast du bereits ähnliche Erfahrungen gemacht, wenn du versucht hast, mit KI Code zu generieren?
Typischerweise beginnt der Prozess mit der Eingabe einer Frage oder Problemstellung, woraufhin ein Code-Snippet erstellt wird. Häufig enthalten diese Snippets jedoch fehlerhafte oder „halluzinierte“ Imports oder Funktionen, die in der Form gar nicht existieren. Um brauchbare Ergebnisse zu erhalten, muss der Kontext immer weiter präzisiert werden – ein wiederholter Zyklus aus Eingabe, Anpassung und erneuter Generierung. Ein weiteres Problem ist die fehlende Konsistenz: Der generierte Code fügt sich oft nicht nahtlos in die bestehende Architektur oder Struktur ein. Beispielsweise passiert es in Webanwendungen gern, dass neue CSS-Styles erfunden werden, anstatt vorhandene zu nutzen, was den Code schnell zu einem unübersichtlichen „Frankenstein-Monster“ werden lässt.

Kurz gesagt: KI eignet sich hervorragend für Boilerplate-Code und einfache Aufgaben. Für komplexe Systeme hingegen ist sie weniger hilfreich – es sei denn, man stellt den gesamten Bestandscode zur Verfügung, um ein eigenes Modell zu trainieren, das den vollständigen Kontext der Anwendung "begreifen" kann. Selbst dann bleiben jedoch zentrale Faktoren wie menschliche Expertise, Stakeholder-Absprachen und Kundenanforderungen unberücksichtigt.

Manuelle Code-Reviews sind daher essenziell. Sie ermöglichen es, die entwickelte Funktionalität im Gesamtkontext der Anwendung zu verstehen, die Integration in bestehende Strukturen zu prüfen und sicherzustellen, dass kritische Edge Cases berücksichtigt werden. Darüber hinaus erlauben sie Entscheidungen, die KI nicht treffen kann: etwa einen alternativen Lösungsansatz zu wählen, ein Feature vorerst zurückzustellen, einen pragmatischen Workaround einzubauen oder ein Folgeticket für das Refactoring bestehender Funktionalitäten anzulegen. Durch das Wissen über Anforderungen, Architektur und eingesetzte Technologien können Menschen diese Entscheidungen fundiert treffen und so die langfristige Qualität und Wartbarkeit des Systems sichern.

2. Frühzeitiges Aufdecken von Mängeln in Entwurf und Architektur

Wie oft passiert es (insbesondere in agilen Prozessen), dass man denkt, Anforderungen wären klar definiert, nur um dann im Code-Review festzustellen, dass kritische Punkte nicht betrachtet wurden oder es für die erdachte Anforderung technische Hürden gibt, die bei der Umsetzung bisher nicht berücksichtigt wurden? Aus eigener Erfahrung: häufiger als man denkt.

Code-Reviews decken nicht nur solche Lücken auf, sondern auch grundlegende Mängel im Entwurf und in der Architektur, wie etwa fehlende Modularität, unzureichende Schnittstellendefinitionen, problematische Abhängigkeiten oder mangelnde Wart- sowie Skalierbarkeit. Sie helfen, frühzeitig Designfehler zu erkennen, bevor diese zu kostspieligen Refactorings oder Performance-Problemen führen.

Darüber hinaus können sie Usability-Aspekte sichtbar machen, die im reinen Implementierungsfokus oft übersehen werden: etwa unklare Interaktionsflüsse, inkonsistente Benennung, fehlende Barrierefreiheit oder eine Nutzerführung, die nicht den definierten Anforderungen entspricht. Durch diese ganzheitliche Betrachtung helfen Code-Reviews, sowohl technische als auch nutzerzentrierte Qualitätsprobleme frühzeitig zu identifizieren und zu beheben.

3. Verbesserte Kommunikation, Wissenstransfer und Gefühl von Teilhabe im Team

Code-Reviews schaffen eine Kultur, in der Fehler nicht als persönliches Versagen betrachtet werden. Das konstruktive Aufzeigen von Verbesserungsmöglichkeiten dient der frühzeitigen Vermeidung potenzieller Anpassungen und größerer Probleme.

Darüber hinaus fördern sie die Kommunikation im Team und reduzieren den Aufwand für mehrfache Iterationen: Probleme können gemeinsam gelöst werden, beispielsweise durch Pair Programming oder Pair Reviewing.

Ein weiterer zentraler Aspekt sind die Lerneffekte: Wenn erfahrene Entwickler den Code weniger erfahrener Kollegen prüfen, erfolgt ein direkter Wissenstransfer. Best Practices, Konzepte und fachliches Verständnis werden nicht nur vermittelt, sondern durch die unmittelbare Anwendung gefestigt. Zudem können alternative Lösungsansätze diskutiert werden, was die Qualität der Entscheidungen und die Kompetenzentwicklung im Team nachhaltig verbessert.

Dieses erworbene Wissen ist zwar nur ein Baustein, aber ein entscheidender: Es schafft die Voraussetzung, um KI-generierte Inhalte nicht nur syntaktisch, sondern auch fachlich und kontextbezogen zu bewerten. So können Lösungen gezielt angepasst und sicher in bestehende Systeme integriert werden, wodurch Fehler vermieden und Entwicklungsprozesse zugleich beschleunigt werden.

Grundregeln für Code-Reviews

Mir ist wichtig, dass Code-Reviews mehr sind als eine reine Kontrolle. Sie sollen Kommunikation stärken, Wissen weitergeben und jedem im Team das Gefühl geben, Teil des Prozesses zu sein. Als Reviewerin halte ich mich an bestimmte Grundregeln, die sowohl für mich als auch für die Entwickler gelten:

Wechselseitige Verantwortung: Die Grundregeln für Reviewer bedingen die Einhaltung der Grundregeln durch Entwickler – und umgekehrt.

Grundregeln für Reviewer

  • Durchführung: mindestens ein erfahrener Entwickler sollte beteiligt sein
  • Standards und Best Practices prüfen: Fokus auf Konsistenz im Code und in der Architektur
  • Fokus auf das Wesentliche: „so wenig wie möglich, so viel wie nötig“ – keine übermäßige Detailkritik
  • Architektur- und Design-Aspekte prüfen: Wiederverwendbarkeit und Konsistenz, Schnittstellen
  • Usability-Aspekte berücksichtigen: Konsistente Bedienung, Einhaltung erlernter und bekannter Konzepte, Nutzerführung etc.
  • Sicherheitsaspekte prüfen: Input-Validierung, Zugriffskontrollen, sichere Datenverarbeitung
  • Performance und Wartbarkeit: Erkennen potenzieller Engpässe, unnötiger Komplexität, Abhängigkeiten
  • Clean-Code-Prinzipien (wo anwendbar) sicherstellen, u.a.:
    • DRY (Don’t Repeat Yourself): Vermeidung redundanter Logik – Wiederverwendung statt Neuimplementierung, wo möglich
    • KISS (Keep It Simple, Stupid): Lösungen so einfach wie möglich halten
    • YAGNI (You Ain't Gonna Need It): Keine Features implementieren, die (noch) nicht benötigt werden – dafür gibt es eine Versionsverwaltung
    • Lesbarkeit und Verständlichkeit: Klarer, gut strukturierter Code
    • Namenskonventionen einhalten: Verständliche, sprechende Namen für Variablen, Methoden und Klassen

Grundregeln für Entwickler

  • Funktionsfähigkeit sicherstellen: Code muss lauffähig sein
  • Vermeiden unzusammenhängender Änderungen: pro Umsetzungsstand (Branch, Pull-Anfrage) nur geforderte Anpassungen am Code – Keine zusätzlichen Refactorings kritischer Funktionalität innerhalb einer Feature-Implementierung
  • Automatisierte Checks ausführen: Linter und Formatierungstools vor dem Review ausführen – keine Entwickler-Logs, einheitlich formatierter Code, keine Type-Check-Fehler
  • Auf das Wesentliche beschränken: „so wenig Code wie möglich, so viel wie nötig“
  • Dokumentation: Kommentare und Hinweise ergänzen, wo notwendig
  • Tests bereitstellen: mindestens manuell getestet, bestenfalls Unit-Tests oder Integrationstests für neue Features (je nach Kunde, Projekt, Metriken Testabdeckung etc.)
  • Klare Commit-Nachrichten: aussagekräftig und nachvollziehbar
  • Clean-Code-Prinzipien anwenden: insofern sinnvoll (siehe Grundregeln Reviewer)

Bonus: Verringerte technische Schulden, Wartungsaufwand und Kosten

Ein Vorab-Integrationstest sollte integraler Bestandteil des Code-Reviews sein, insbesondere wenn Teile des Codes mithilfe von KI generiert wurden. Nur so lässt sich sicherstellen, dass der neue Code reibungslos mit dem bestehenden System interagiert und keine unbeabsichtigten Nebenwirkungen entstehen. Gerade KI-generierter Code kann versteckte Bugs, Unsauberkeiten, Sicherheitslücken oder Performanceprobleme enthalten, die sich erst im Zusammenspiel mit der Gesamtarchitektur zeigen. Code-Reviews und Tests sind daher entscheidend, um diese Risiken frühzeitig zu identifizieren.

Solche Maßnahmen reduzieren den Aufwand für nachgelagerte Softwaretests und die Behebung von Fehlern erheblich – ein wichtiger Faktor, da KI-Tools oft Code produzieren, der zwar syntaktisch korrekt ist, aber nicht alle funktionalen und nicht-funktionalen Anforderungen erfüllt. Wenn Anwendungen so gestaltet sind, dass sie sich einfach erweitern, migrieren und pflegen lassen, führt dies nicht nur zu geringeren Wartungskosten, sondern erhöht auch die Robustheit und Zukunftsfähigkeit des gesamten Systems – etwas, das KI allein nicht gewährleisten kann.

Zusammenfassung und Fazit

Die Durchführung von Code-Reviews ist ein zentrales Instrument zur Sicherstellung von Qualität, Konsistenz und Nachhaltigkeit in der Softwareentwicklung. In einer Entwicklungslandschaft, die zunehmend durch automatisierte Codegenerierung und steigende Systemkomplexität geprägt ist, sind manuelle Reviews unverzichtbar:
Sie decken Bugs, Sicherheitslücken, Performanceprobleme sowie Mängel in Architektur und Usability frühzeitig auf, reduzieren den Aufwand für nachgelagerte Tests und verhindern kostspielige Fehlerbehebungen. Darüber hinaus fördern sie die Einhaltung von Best Practices und Standards, schaffen eine Kultur des konstruktiven Feedbacks, ermöglichen Lerneffekte und verbessern die Kommunikation im Team.

Aus meiner Sicht sind Menschen aktuell klar im Vorteil, weil sie den Gesamtkontext einer Anwendung, die Anforderungen und die Perspektiven der Stakeholder berücksichtigen können – etwas, das KI-Tools derzeit nicht leisten. Ich bin gespannt, wie sich die Verwendung von KI-Tools in der Softwareentwicklung verändern wird. Vielleicht teste ich künftig KI-gestützte Code-Review-Tools wie CodeRabbit, um zu sehen, ob sie eine sinnvolle Ergänzung darstellen. Bis dahin bleibt für mich jedoch der menschliche Faktor entscheidend.