Code-Review im Zeitalter der KI

• KI hat Code-Reviews nicht abgeschafft, sondern im Gegenteil die Beweislast klarer gemacht
• Änderungen sollten mit beigefügten Nachweisen wie manueller Verifikation oder automatisierten Tests ausgerollt werden; erst danach sollte das Review Risiken, Absicht und Verantwortlichkeiten klären
• Einzelne Entwickler verlassen sich auf Automatisierung, um mit dem Tempo der KI mitzuhalten, während Teams durch Reviews gemeinsamen Kontext und Verantwortungsbewusstsein aufbauen
• Wenn einem PR der Nachweis fehlt, dass etwas funktioniert, ist das keine schnelle Auslieferung, sondern nur ein Verschieben der Arbeit nachgelagert; nur Entwickler mit einem Validierungssystem sind bei KI-gestützter Hochgeschwindigkeitsentwicklung erfolgreich
• Der Engpass beim Code-Review hat sich vom Schreiben von Code hin zum Nachweis, dass er funktioniert verlagert; KI beschleunigt mechanische Arbeit, aber die Verantwortung bleibt beim Menschen

Veränderungen beim Code-Review im Zeitalter der KI

• Anfang 2026 deployen bereits mehr als 30 % der Senior-Entwickler überwiegend KI-generierten Code. KI ist stark beim Entwurf von Features, legt aber bei Logik, Sicherheit und Edge Cases Schwächen offen, darunter 75 % mehr Logikfehler
• Solo-Entwickler deployen schnell mit Inference Speed und nutzen Test-Suites als Sicherheitsnetz, während Teams aus Gründen von Kontext und Compliance an menschlichen Reviews festhalten
• Wenn es richtig gemacht wird, nutzen beide KI als Beschleuniger, aber der Unterschied entsteht dadurch, wer was wann verifiziert
• Wenn du nicht selbst bestätigt hast, dass der Code korrekt funktioniert, dann funktioniert er nicht korrekt
  • KI verstärkt diese Regel nur, sie hebt sie nicht auf

Wie Entwickler KI in Reviews einsetzen

• Ad-hoc-LLM-Checks: Vor einem Commit wird ein Diff in Claude, Gemini oder GPT eingefügt, um Bugs oder Stilprobleme schnell zu prüfen
• IDE-Integration: Mit Tools wie Cursor, Claude Code oder Gemini CLI werden Inline-Vorschläge und Refactorings während des Codens genutzt
• PR-Bots und Scanner: Mit GitHub Copilot oder eigenen Agenten werden potenzielle Probleme im PR automatisch markiert, ergänzt durch Sicherheitsprüfungen mit statischen und dynamischen Analysewerkzeugen wie Snyk
• Automatisierte Testing-Loops: KI erzeugt und führt Tests aus, wobei eine Abdeckung von über 70 % als Merge-Bedingung gesetzt wird
• Multi-Model-Review: Code wird durch mehrere LLMs geprüft, um modellspezifische Verzerrungen zu erkennen (z. B. Generierung mit Claude, Audit mit einem auf Security spezialisierten Modell)

Solo-Entwickler vs. Teams: Vergleich

• Solo-Entwickler
  • Fokus im Review: automatisierte Tests + begrenzte Spot-Checks
  • Speed-Trade-off: Tempo der Inference-Zeit, Probleme werden in Iterationsschleifen behoben
  • Zentrales Tool: agentisches Testing (z. B. Claude-Code-Loops)
  • Prinzip: Beweise es selbst
• Teams
  • Fokus im Review: Kontext und Sicherheit mit menschlichem Urteilsvermögen prüfen
  • Speed-Trade-off: PRs klein halten, um Review-Engpässe zu vermeiden
  • Zentrales Tool: Kombination aus Bots + Richtlinien (z. B. Kennzeichnung KI-generierter PRs)
  • Prinzip: Teile den Nachweis mit dem Team

Solo-Entwickler: Deployment mit „Inference Speed“

• Solo-Entwickler vertrauen dem „Vibe“ von KI-generiertem Code, prüfen nur die kritischen Teile und liefern Features schnell aus, während Tests Probleme auffangen
• Coding-Agenten werden oft wie starke Praktikanten behandelt, die große Refactorings allein erledigen können
• Peter Steinberger sagte: „Ich lese inzwischen nicht mehr viel Code. Ich schaue auf den Stream und prüfe gelegentlich nur die kritischen Teile.“
• Der Engpass in der Entwicklung verlagert sich vom Tippen zur Inference-Zeit (dem Warten auf die KI-Ausgabe)
• Wichtig: Ohne starke Tests verschwindet der gefühlte Geschwindigkeitsgewinn
  • Ein ausgelassenes Review beseitigt Arbeit nicht, sondern verschiebt sie nur nach hinten
  • Der Schlüssel zu erfolgreicher KI-basierter Hochgeschwindigkeitsentwicklung ist nicht blindes Vertrauen, sondern der Aufbau eines Validierungssystems
• Verantwortungsbewusste Solo-Entwickler nutzen umfangreiche automatisierte Tests als Sicherheitsnetz und setzen sich mehr als 70 % Coverage als Ziel
• Sprachunabhängige und datenbasierte Tests spielen eine entscheidende Rolle
  • Wenn die Tests gut genug sind, kann ein Agent Implementierungen unabhängig von der Sprache erzeugen, ändern und verifizieren
  • Zu Projektbeginn erstellt die KI einen ersten Entwurf von spec.md; nach Freigabe wird ein Loop aus Schreiben → Testen → Korrigieren wiederholt
• Auch Solo-Entwickler führen in der letzten Phase manuelle Tests und kritisches Urteilsvermögen aus
  • Sie starten die Anwendung selbst, klicken durch die UI und nutzen die Funktionen
  • Bei höherem Risiko lesen sie mehr Code und führen zusätzliche Verifikation durch
  • Auch bei schneller Entwicklung wird unaufgeräumter Code bereinigt, sobald er entdeckt wird
• Das Kernprinzip lautet: Die Aufgabe des Entwicklers ist es, „Code zu liefern, dessen Funktionsfähigkeit er selbst nachgewiesen hat“

Teams: KI verschiebt den Review-Engpass

• Im Team ist KI ein starker Helfer beim Code-Review, kann aber das menschliche Urteilsvermögen, das für Qualität, Sicherheit und Wartbarkeit nötig ist, nicht ersetzen
• In Umgebungen, in denen mehrere Engineers zusammenarbeiten, sind die Kosten von Fehlern und die Lebensdauer des Codes viel wichtigere Faktoren
• Viele Teams setzen KI-Review-Bots in einer frühen PR-Phase ein, aber die finale Freigabe bleibt beim Menschen
• Greg Foster von Graphite sagte: „KI-Agenten werden niemals die PR-Freigabe durch echte menschliche Engineers ersetzen.“
• Das größte praktische Problem ist nicht, dass KI-Reviewer Stilfragen übersehen, sondern dass KI das Code-Volumen erhöht und die Review-Last auf Menschen abwälzt
  • Mit der Verbreitung von KI-Einsatz ist die PR-Größe um etwa 18 % gestiegen
  • Die Zahl der Incidents pro PR ist um etwa 24 % gestiegen
  • Die Change-Failure-Rate ist um etwa 30 % gestiegen
• Wenn die Ausgabe-Geschwindigkeit die Verifikationsfähigkeit überholt, wird der Review-Prozess zum geschwindigkeitsbegrenzenden Faktor im gesamten Entwicklungsfluss
• Foster sagte: „Code zu deployen, den kein menschlicher Kollege gelesen oder verstanden hat, ist ein großes Risiko.“
• In Teams erzeugt KI große Mengen an Output, daher ist inkrementelle Entwicklung nötig, und Agenten-Output sollte in überprüfbare Commit-Einheiten aufgeteilt werden
• Die finale menschliche Freigabe verschwindet nicht, sondern entwickelt sich dahin weiter, sich auf die Bereiche zu konzentrieren, die KI übersieht
  (Roadmap-Abgleich, organisatorischer und institutioneller Kontext, den KI nicht erfassen kann)

Sicherheit: vorhersehbare Schwachstellen der KI

• Sicherheit ist ein Bereich, in dem menschliches Urteilsvermögen unverzichtbar ist
• In etwa 45 % des KI-generierten Codes wurden Sicherheitsmängel gefunden
• Die Rate von Logikfehlern ist 1,75-mal höher als bei von Menschen geschriebenem Code
• XSS-Schwachstellen treten 2,74-mal häufiger auf
• Neben Problemen im Code selbst schaffen agentische Tools und KI-integrierte IDEs neue Angriffswege
  • Prompt Injection, Datenabfluss, RCE-Schwachstellen
• Weil KI die Angriffsfläche vergrößert, ist ein hybrider Ansatz effektiv
  • KI markiert Probleme, der Mensch übernimmt die finale Verifikation
• Regel: Code für Authentifizierung, Zahlungen, Secrets oder nicht vertrauenswürdige Eingaben
  sollte so behandelt werden, als wäre KI ein Hochgeschwindigkeitspraktikant; vor dem Merge sind menschliches Threat-Model-Review und Security-Tool-Prüfungen Pflicht

Wissensweitergabe durch Reviews

• Code-Reviews sind ein zentrales Mittel, mit dem Teams Systemkontext teilen
• Wenn KI den Code geschrieben hat, ihn aber niemand erklären kann, steigen die On-Call-Kosten
• Werden KI-generierte Änderungen eingereicht, ohne dass sie vollständig verstanden werden, bricht der Mechanismus der Wissensweitergabe zusammen, der die Resilienz eines Teams aufbaut
• Wenn der Autor nicht erklären kann, warum der Code funktioniert, kann der On-Call-Engineer ihn um 2 Uhr morgens nicht debuggen
• Es gab einen Fall, in dem ein OCaml-Maintainer einen 13.000 Zeilen großen KI-generierten PR ablehnte
  • Die Codequalität war nicht unbedingt schlecht, aber es fehlte an Review-Bandbreite, um Änderungen dieser Größenordnung zu prüfen
  • Reviews von KI-generiertem Code verursachen eine höhere kognitive Last als Reviews von menschlich geschriebenem Code
• Die Lehre daraus: KI kann große Mengen Code erzeugen, aber Teams müssen den Umfang von Änderungen steuern, um Review-Engpässe zu vermeiden

So nutzt man KI-Review-Tools

• Die Nutzererfahrungen mit KI-Review-Tools gehen deutlich auseinander
• Positiv: In manchen Fällen wurden mehr als 95 % der Bugs erkannt, darunter Null-Pointer-Exceptions, fehlende Testabdeckung und Antipatterns
• Negativ: Manche Entwickler empfinden KI-Review-Kommentare als wertlose, allgemeine Beobachtungen – als „Text-Rauschen“
• Die Lehre: KI-Review-Tools brauchen sorgfältige Konfiguration
  • Empfindlichkeit anpassen, wenig hilfreiche Kommentartypen deaktivieren, klare Opt-in-/Opt-out-Richtlinien festlegen
• Bei guter Konfiguration können KI-Reviewer 70–80 % der einfachen Probleme erkennen, sodass sich Menschen auf Architektur und Geschäftslogik konzentrieren können
• Viele Teams empfehlen kleine, stapelbare PRs, auch wenn KI große Änderungen auf einmal erzeugen kann
• Änderungen sollten häufig committet und jeweils als in sich abgeschlossene Einheiten mit klarer Nachricht in separaten Commits und PRs verwaltet werden
• Teams halten klare Grenzen menschlicher Verantwortung aufrecht
• Unabhängig davon, wie stark KI beigetragen hat, liegt die Endverantwortung beim Menschen
• Ein Lehrsatz von IBM lautet: „Ein Computer kann niemals Verantwortung übernehmen. Verantwortung liegt beim Menschen im Loop.“

Der PR-Vertrag: Pflicht des Autors gegenüber dem Reviewer

• Ob Solo-Entwickler oder Team: Eine gemeinsame Best Practice ist, KI-generierten Code als nützlichen Entwurf zu behandeln, der verifiziert werden muss
• Die erfolgreichsten Teams nutzen dafür ein gemeinsames, einfaches Framework

• Bestandteile des PR-Vertrags

  1/. What/Why: Absicht und Grund der Änderung in 1–2 Sätzen zusammenfassen
  2/. Funktionsnachweis: bestandene Tests und manuelle Verifikationsschritte (Screenshots, Logs)
  3/. Risiko + KI-Rolle: Risiko der Änderung und Kennzeichnung der von KI erzeugten Teile (z. B. Zahlungsfunktion = hohes Risiko)
  4/. Review-Fokus: 1–2 Bereiche benennen, die menschliche Prüfung brauchen (z. B. Architektur)
• Das ist keine Bürokratie, sondern ein Mittel, die Zeit des Reviewers zu respektieren und die Verantwortung des Autors klar zu machen
• Wenn du das nicht aufschreiben kannst, verstehst du deine Änderung nicht gut genug, um jemand anderen um Freigabe zu bitten

Kernprinzipien

• Belege statt Versprechen verlangen: „Funktionsfähiger Code“ ist die Baseline. KI-Agenten sollten nach der Code-Erzeugung den Code ausführen oder Unit-Tests starten; Logs, Screenshots und Ergebnisse müssen als Nachweise geprüft werden. Kein PR ohne neue Tests oder eine Funktionsdemo
• KI nicht als finalen Schiedsrichter, sondern als First-Reviewer einsetzen: KI-Review-Output wird als Beratung behandelt; eine KI schreibt den Code, eine andere prüft ihn, und Menschen steuern die Korrekturrichtung. KI-Reviews sollten auf dem Niveau einer Rechtschreibprüfung genutzt werden, nicht als Editor
• Menschliche Reviews konzentrieren sich auf das, was KI übersieht: etwa ob Sicherheitslücken eingeführt wurden, ob bestehender Code dupliziert wird (ein häufiger KI-Fehler) und ob der Ansatz wartbar ist. KI filtert die einfachen Probleme, Menschen treffen die schwierigen Entscheidungen
• Inkrementelle Entwicklung umsetzen: Arbeit in kleine Einheiten zerlegen, damit KI sie leicht generieren und Menschen sie leicht reviewen können. Kleine Commits mit klaren Nachrichten dienen als Checkpoints. Committe niemals Code, den du nicht erklären kannst
• Hohe Testing-Standards beibehalten: Entwickler, die Coding-Agenten effektiv einsetzen, pflegen starke Testing-Praktiken und lassen sich von KI Testentwürfe für Edge Cases, die Menschen leicht übersehen, erzeugen

Ausblick: Der Engpass verschiebt sich

• KI verschiebt Code-Reviews von zeilenweiser Gatekeeping-Arbeit zu übergeordneter Qualitätskontrolle, aber menschliches Urteilsvermögen bleibt sicherheitskritisch unverzichtbar
• Das ist eine Weiterentwicklung des Workflows, nicht die Abschaffung von Code-Reviews
• Der Umfang von Code-Reviews umfasst nicht mehr nur Code-Diffs, sondern auch Gespräche oder Pläne zwischen KI und Autor
• Die Rolle menschlicher Reviewer nähert sich zunehmend der eines Editors oder Architekten an: Fokus auf wichtige Entscheidungen, Vertrauen auf Automatisierung bei Routineprüfungen
• Für Solo-Entwickler ist der weitere Weg spannend, aber auch mit neuen Tools gilt für kluge Entwickler weiter: „Vertrauen, aber verifizieren“
• In großen Teams ist mit stärkerer KI-Governance zu rechnen
  • Richtlinien für KI-Beiträge werden formalisiert, inklusive Freigaben mit Bestätigung, dass Mitarbeiter selbst geprüft haben
  • Rollen wie „AI Code Auditor“ könnten entstehen
  • Enterprise-Plattformen entwickeln sich dahin weiter, Multi-Repository-Kontext und Durchsetzung kundenspezifischer Richtlinien besser zu unterstützen
• Das Kernprinzip bleibt unverändert: Code-Reviews stellen sicher, dass Software Anforderungen erfüllt, sicher, robust und wartbar ist
• KI ändert dieses Fundament nicht, sie verändert nur den Weg dorthin
• Der Engpass der Entwicklung verschiebt sich vom Schreiben von Code hin zum Nachweis, dass er funktioniert
• Gute Code-Reviewer im KI-Zeitalter akzeptieren diesen Wandel, lassen KI mechanische Arbeit beschleunigen und halten dennoch die Grenze der Verantwortung aufrecht
• KI kann Prozesse beschleunigen (accelerate), darf aber nicht dazu führen, dass Verantwortung abgegeben wird (abdicate)
• Engineers werden zunehmend „Proof over Vibes“ priorisieren
• Code-Reviews sind nicht verschwunden, sondern entwickeln sich zu einer strategischeren Rolle
• Ob Solo-Entwickler, der um 2 Uhr morgens deployt, oder Team-Lead, der eine kritische Systemänderung freigibt: Die finale Verantwortung für KI-erzeugte Ergebnisse liegt beim Menschen
• Nutze KI, aber behalte die Gewohnheit bei, die Arbeit noch einmal zu prüfen