Code Review 2.0 – Wenn KI den Engpass verschiebt

Code Review 2.0 – When AI Shifts the Bottleneck

Ausgangslage

Diese Ideen sind Inspiration, kein Fahrplan. Ihr könnt völlig andere Wege gehen

Code Reviews gehören seit Jahrzehnten zu den wichtigsten Qualitätssicherungsmaßnahmen in der Softwareentwicklung. Das Prinzip ist einfach und bewährt: Bevor Code in die Produktivumgebung gelangt, prüft mindestens eine zweite Person die Änderungen. Das schützt vor Fehlern, verbessert die Codequalität und fördert den Wissenstransfer im Team.

In der Praxis passiert das über Pull Requests: Ein Entwickler stellt seine Änderungen bereit, ein Reviewer liest den Code, hinterlässt Kommentare und gibt am Ende seine Freigabe – oder fordert Nachbesserungen ein. Die gängigen Plattformen dafür sind GitHub, GitLab oder Gitea. Ein neuer Prozess könnte auf diesen Tools aufbauen und sie erweitern – oder sie in Teilen durch etwas Besseres ersetzen.

Problemstellung: Der neue Flaschenhals

KI-gestützte Coding-Tools wie Claude Code, Codex, Cursor und GitHub Copilot haben die Produktivität von Entwicklern drastisch verändert. Was früher Stunden oder Tage dauerte, wird heute in Minuten generiert. Die Menge an produziertem Code pro Entwickler ist explodiert.

Doch der Code Review Prozess ist manuell geblieben. Das Ergebnis: Ein einzelner Reviewer steht plötzlich vor einem Vielfachen der bisherigen Codemenge. Reviews stauen sich, Wartezeiten wachsen, und Teams stehen vor einem Dilemma, entweder die Qualitätskontrolle aufweichen oder den Geschwindigkeitsvorteil der KI wieder verlieren.

KI generiert Code → Pull Request → ⚠ Manueller Review → Merge → Deploy
(Bottleneck)

Die Challenge

Entwickelt Ideen, Konzepte oder Prototypen, die den Code Review Prozess so optimieren, dass er mit der neuen KI-gestützten Entwicklungsgeschwindigkeit Schritt halten kann.

Die zentrale Bedingung: Das Vier-Augen-Prinzip muss erhalten bleiben. Eine zweite Person soll die Arbeit weiterhin kontrollieren – aber intelligenter, effizienter und gezielter als heute.

Denkanstöße

  • KI-gestütztes Pre-Review: Kann eine KI den Code vor dem menschlichen Review analysieren und nur die kritischen Stellen hervorheben, sodass der Reviewer sich auf das Wesentliche konzentrieren kann?
  • Risiko-basierte Reviews: Muss wirklich jede Zeile gleich intensiv geprüft werden? Wie könnte man Änderungen nach Risiko klassifizieren und den Review-Aufwand entsprechend skalieren?
  • Review-Unterstützungstools: Welche Werkzeuge könnten den Reviewer bei seiner Arbeit unterstützen, etwa durch automatische Zusammenfassungen, Kontexterklärungen oder Impact-Analysen?
  • Neue Review-Formate: Muss ein Review immer eine Zeile-für-Zeile-Prüfung sein? Welche alternativen Formate könnten schneller und trotzdem effektiv sein?
  • Prozess-Innovation: Wie könnte man den Gesamtprozess umgestalten,  etwa durch kontinuierliche Reviews statt großer Pull Requests oder durch kollaborative Echtzeit-Reviews?
  • Vertrauens-Modelle: Wie könnte ein System aussehen, das den Review-Aufwand an das Vertrauen in den Code-Autor (Mensch oder KI) anpasst?
  • Prompt statt Code reviewen: Was wäre, wenn nicht der generierte Code geprüft wird, sondern der Prompt, der ihn erzeugt hat? Wenn KI den Großteil des Codes schreibt, verschiebt sich die kreative Leistung auf die Aufgabenstellung. Könnte ein Review des Prompts, also der Intention, effektiver sein als ein Review des Outputs?

Background

Code reviews have been one of the most important quality assurance practices in software development for decades. The principle is simple and proven: before code reaches production, at least one other person reviews the changes. This protects against bugs, improves code quality, and promotes knowledge sharing within the team.

In practice, this happens through pull requests: a developer submits their changes, a reviewer reads the code, leaves comments, and either approves, or requests revisions. The common platforms for this are GitHub, GitLab, or Gitea. A new process could build on these tools and extend them, or partially replace them with something better.

The Problem, A New Bottleneck

AI-powered coding tools like Claude Code, Codex, Cursor, and GitHub Copilot have drastically changed developer productivity. What used to take hours or days is now generated in minutes. The volume of code produced per developer has exploded.

But the code review process has remained manual. The result: a single reviewer is suddenly facing several times the previous volume of code. Reviews pile up, wait times grow, and teams face a dilemma, either compromise on quality control or lose the speed advantage that AI provides.

AI generates code → Pull Request → ⚠ Manual Review → Merge → Deploy
(Bottleneck)

The Challenge

Develop ideas, concepts, or prototypes that optimize the code review process so it can keep pace with the new AI-powered development speed.

The core constraint: The four-eyes principle must be preserved. A second person should still review the work, but in a smarter, more efficient, and more targeted way than today.

Additional Requirements

These ideas are inspiration, not a roadmap. You are free to take entirely different approaches.

  • AI-Powered Pre-Review: Can an AI analyze the code before the human review and highlight only the critical sections, so the reviewer can focus on what truly matters?
  • Risk-Based Reviews: Does every line really need the same level of scrutiny? How could changes be classified by risk to scale review effort accordingly?
  • Review Support Tools: What tools could assist the reviewer, such as automated summaries, context explanations, or impact analyses?
  • New Review Formats: Does a review always have to be a line-by-line inspection? What alternative formats could be faster yet still effective?
  • Process Innovation: How could the overall process be redesigned, for example, through continuous reviews instead of large pull requests, or through collaborative real-time reviews?
  • Trust Models: What would a system look like that adjusts review effort based on trust in the code author (human or AI)?
  • Review the Prompt, Not the Code: What if instead of reviewing the generated code, you review the prompt that produced it? If AI writes most of the code, the creative work shifts to the task definition. Could reviewing the intent be more effective than reviewing the output?