Code-Review ist der neue Flaschenhals

Worum es geht

In einem Podcast-Gespräch nimmt sich Florian Buetow, AI Engineer bei Xebia, den größten Engpass der heutigen Software-Entwicklung vor: das Code-Review. Die Modelle schreiben Code zehnmal schneller als früher, doch geprüft wird er weiter von Hand. Das Ergebnis sind überlastete Senior-Engineers und eine wachsende „kognitive Schuld", weil niemand mehr die ganze Codebasis im Kopf hat.

Der Engpass hat sich verschoben

Bei Google stammten 2025 bereits 50 Prozent des Codes von der KI, intern wird auf 75 Prozent gedrängt. Auf der Google I/O räumten die Leute offen ein: Review ist der Flaschenhals, und eine saubere Lösung gibt es noch nicht. Amazon hat nach Ausfällen und Umsatzverlusten durch KI-Code reagiert und Regeln eingeführt, dass kritische Systeme vor dem Merge von Senior-Engineers geprüft werden müssen. Wer schnell Code erzeugen kann, schiebt den Druck einfach flussabwärts auf alle, die danach kommen.

Zwei Wege, KI-Engineering zu skalieren

Buetow trennt eine horizontale von einer vertikalen Achse. Horizontal heißt: bestehende Prozesse automatisieren, etwa jeden Pull Request automatisch von Copilot prüfen lassen. Das machen viele, sagen aber selten, ob die Qualität dadurch steigt. Vertikal heißt: ein kleines, spezialisiertes Team baut sich eine eigene Umgebung für seine Coding-Agenten, zugeschnitten auf das Produkt, statt einen Standard-Bauplan überzustülpen.

Die radikale Idee: gar keine Reviews

Ein Antwortversuch lautet, überhaupt keine manuellen Reviews mehr zu machen. Der Trick liegt darin, die Umgebung so zu bauen, dass die Agenten ihr Feedback automatisch bekommen, möglichst nah an der Stelle, wo der Code entsteht. Also auf dem Laptop der Entwicklerin, nicht erst nach dem Commit auf GitHub. Manches davon kennt man schon: automatischer Formatter, Linter, ein Security-Check wie SonarQube. Neu ist, dass dieses Feedback jetzt die KI aufnimmt und sich selbst korrigiert, statt dass ein Mensch es liest und einarbeitet.

Feedback automatisieren mit Stop-Hooks

Bei den CLI-Tools gibt es einen Stop-Hook: Ist der Agent fertig, löst das Harness ein Event aus. Daran hängt man ein Shell-Skript, das die Testsuite und die eigenen Guardrails laufen lässt. Die Guardrails geben ihr Ergebnis als natürlichsprachigen Text zurück („das ist verboten, mach es so"), also genau den Prompt, den sonst ein Mensch geschrieben hätte. Kombiniert mit einem Ralph-Loop oder dem goal-Kommando von Codex und Claude läuft der Agent so lange weiter, bis das Problem behoben ist.

Welche Guardrails am meisten bringen

Buetows Favorit ist semantisches Grep (semgrep): Damit fängt man per Regex und Code-Pattern bestimmte Konstrukte ab. Sein Standardbeispiel sind Default-Werte für Methodenparameter in Python, eine seiner größten Frust-Quellen beim späteren Debuggen. Eine Regel verbietet das Muster, fertig. Ein zweites Beispiel: niemals Fehler verschlucken, jeder Fehler muss durchgereicht werden.

Dazu kommen Architektur-Unit-Tests. Die prüfen nur die Abhängigkeiten zwischen Modulen und laufen dadurch extrem schnell. So lässt sich erzwingen, dass die UI nie direkt auf die Datenbank zugreift, sondern immer über die Business-Logik geht. Lässt man die KI ein System bauen und zeichnet danach das Diagramm, sieht man die kuriosesten Querverbindungen, die ein Mensch nie ziehen würde. Genau die kodiert man als zusätzliche Regel.

Code-Qualität zählt auch für die KI

Sauberer, modularer Code mit klaren Grenzen und festen Schnittstellen hilft den Agenten. Code ist Kontext: Wird einfach drauflos „gevibed", verheddert sich die KI früher oder später in ihrem eigenen Wildwuchs. Eine messy Codebasis bremst also nicht nur Menschen.

Das Harness zählt mehr als das Modell

Aus Buetows Erfahrung wiegt das Harness schwerer als das Modell. Es liefert die Werkzeuge, das Prompting und die Memory-Schicht. In einem Experiment wollte er ein Tool allein aus Spezifikation und Tests bauen. Mit demselben Spitzenmodell klappte es im einen Harness, im anderen nicht. Welches gerade am besten ist, wechselt ständig: erst Claude Code, dann Codex für Implementierungsarbeit. Genau deshalb sollte man sich per Policy nicht auf ein einziges Tool festnageln. Beim nächsten Release kann alles anders aussehen.

Spec-driven oder TDD?

Der reine Spec-driven-Ansatz scheiterte bei ihm: der perfekte Prompt, und das Modell tut trotzdem etwas anderes. Was funktionierte: alle Tests vorab generieren und sie dem Agenten als Feedback geben, während er der Spezifikation folgt. Die Spezifikation bleibt wichtig, aber als Dokument für gemeinsames Verständnis, nicht als zweite Codebasis. Eine feingranulare Beschreibung des Verhaltens bringt mehr als eine Spec, die so behandelt wird, als wäre sie selbst schon Code.

Was beim Menschen bleibt

Die Architektur. Was bauen wir, wie bauen wir es, wie halten wir es wartbar. Die Modelle können das noch nicht allein. Buetows Arbeit beginnt heute damit, genau zu verstehen, was er will, und das System zu skizzieren: Services, Module, Schnittstellen, Funktionen. Alles außer der Implementierung. Sobald das steht, lässt es sich als Regeln kodieren. Wer die Architektur nicht mehr versteht, verliert den Überblick über die eigene Codebasis. Dagegen hilft nur, die harte Denkarbeit nach vorne zu ziehen.

Burnout und kognitive Schuld

Das ständige Kontext-Wechseln ist real. Der Agent braucht zwanzig Minuten für eine Antwort, man springt dauernd hin und her und ist abends leer. Buetows Gegenmittel ist Disziplin und das Verschachteln von Aufgaben im selben Projekt: Während ein Agent arbeitet, befragt er in einer zweiten Session denselben Code, statt das Projekt komplett zu wechseln. Riskanter ist die „kognitive Kapitulation": Der Agent übernimmt das Steuer, und bei Problemen war es eben der Agent. Verantwortung lässt sich so nicht abgeben.

Konkret anfangen

Der erste Schritt sind statische Checks: Formatter, Linter, ein paar semgrep-Regeln für die Anti-Patterns der eigenen Codebasis. Man kann die KI direkt fragen, welche Anti-Patterns im Code stecken, und daraus Tests bauen. Das läuft alles lokal, auch wenn das Team noch nicht mitzieht. Wichtig ist, den Unterschied mit und ohne diese Regeln zu messen. Wer einmal gesehen hat, wie viel weniger er babysitten muss, geht nicht mehr zurück. Ein zweiter Tipp: die eigenen Session-Logs unter ~/.claude durchsuchen lassen nach Stellen, an denen man das Modell immer wieder an dieselbe Sache erinnern musste. Genau die wird zum nächsten statischen Check.

Quelle: Podcast-Gespräch „How Top Engineers Are Solving the Code Review Bottleneck" mit Florian Buetow (AI Engineer, Xebia). Video auf YouTube.