AI Code Review: Warum Loops ohne Tests gefährlich sind

In Folge 1 haben wir die drei Marktbegriffe sortiert: Context, Harness, Loop Engineering. Addy Osmani warnt aber selbst vor einem konkreten Risiko: Loops ohne Verification laufen weiter, auch wenn der Output falsch ist. „Wer den Loop schreibt, versteht das Problem oft nicht mehr im Detail." Hier geht es um die strukturell schwierigere Seite von AI Code Review: nicht die Tools, die Code prüfen, sondern das menschliche Prüfen von KI-generiertem Code. In der Projektarbeit kennen wir das Muster: KI-generierter Code sieht überzeugend aus, scheitert aber an Edge Cases, die ein Linter nie finden würde. Warum Verification Strukturprinzip ist und kein Nachgedanke, und wie das in der Praxis aussieht. Darum geht es hier.

Was ist AI Code Review? Eine kurze Einordnung

AI Code Review bezeichnet zwei Dinge: KI-Tools, die menschlichen Code automatisch prüfen, und das menschliche Prüfen von KI-generiertem Code. Beide Bedeutungen werden im Markt synonym verwendet, obwohl sie unterschiedliche Risiken haben. Wer das nicht trennt, baut die falsche Verification.

Sobald AI Code Generation in nennenswertem Umfang läuft, sind klassische Dev-Workflows der Engpass. Sie sind auf menschliche Reviews ausgelegt, nicht auf den Output eines Coding-Agents. Code entsteht schneller, als ihn jemand prüfen kann. Theory of Constraints nennt das den wandernden Engpass: mehr Durchsatz an einer Stelle legt die nächste lahm.

Die Antwort auf diesen Engpass ist ein Paradigmenwechsel: von Human-in-the-Loop zu Human-on-the-Loop. Human-in-the-Loop bedeutet, der Mensch ist in jedem Review-Cycle eingebunden. Human-on-the-Loop bedeutet, der Mensch überwacht auf Prozess-Ebene und greift nur bei Eskalation ein. Der Unterschied ist nicht Bequemlichkeit, sondern Notwendigkeit: Wer jeden Output manuell reviewt, erzeugt den nächsten Engpass selbst.

Tools, die Code automatisch reviewen, kennt man von Greptile, Cloudflare AI Review, GitLab Duo und einer wachsenden Zahl von Wettbewerbern. Sie nehmen einen Pull Request und liefern Kommentare, Risikohinweise und Verbesserungsvorschläge. Roborev geht einen Schritt früher: kontinuierliches Review per Git Hook bei jedem Commit, nicht erst beim PR. Das menschliche Prüfen von KI-generiertem Code passiert in jedem Team, das mit Claude, Cursor oder ähnlichen Werkzeugen arbeitet. Es ist die unsichtbarere, aber strukturell wichtigere Variante.

AI Code Review ist kein Ersatz für klassische Linter: Ein Linter prüft Syntax und Style-Regeln. AI Code Review prüft den Sinn: Semantik, Architektur-Passung, mögliche Edge Cases.

LLM-as-Judge hat seinen Platz. Ob er echte Verification leistet, hängt davon ab, wie er aufgesetzt ist. Mit vollem Kontext des Coding-Loops ist er White Box: Er teilt dieselben Annahmen. Isoliert, nur auf den Output und das Nutzerszenario gerichtet, kann er ein unabhängiger Prüfer sein.

Die Begriffsverwirrung führt zu falschen Erwartungen. Wer „AI Code Review eingeführt" verkauft und ein Tool meint, hat das menschliche Reviewer-Problem nicht adressiert. Wer „AI Code Review" sagt und das menschliche Prüfen meint, hat keinen Tool-Stack, der die Geschwindigkeit ausgleicht. Beide Bedeutungen brauchen unterschiedliche Antworten. Diese Folge konzentriert sich auf die zweite, weil sie das größere Strukturproblem ist.

Die drei Risiken aus Osmanis Warnung in der Praxis

Addy Osmani warnt im Original-Blogpost zu Loop Engineering vor drei Risiken, die ehrliche Kehrseite seiner These, kein Fußnotenthema. Wir bei codecentric arbeiten seit Monaten mit autonomen Loops in Kundenprojekten und können alle drei bestätigen.

Risiko 1: Mangelnde Verifikation unbeaufsichtigter Loops

Loops, die ihre eigenen Tests schreiben und gegen sie laufen, sind blind für Edge Cases jenseits der Spec. Das klingt offensichtlich, bis man es im Projekt erlebt. In einem Kundenprojekt hat ein autonom laufender Agent seine eigenen Tests gelöscht, weil sie ihm beim Refactoring im Weg waren. Aus seiner Sicht war das logisch: Ziel war „alle Tests grün", der Pfad dorthin war offen. Aus unserer Sicht war es das Symptom eines strukturellen Problems. Wenn der Agent die Verification selbst kontrolliert, ist sie keine Verifikation mehr, sondern Selbst-Bestätigung.

Das ist dieselbe Logik wie beim Holdout Set in ML. Ein Modell, das seinen eigenen Validierungsdatensatz sehen kann, validiert sich selbst. Der Validation Loop braucht eine Instanz, die nicht am Erzeugen beteiligt war.

Wes McKinney, Schöpfer von pandas, Apache Arrow und Ibis und selbst tief in agentic Workflows, bringt es auf den Punkt: „If all of your code isn't being automatically reviewed by adversarial agents, you've essentially got tons of bugs lurking that you can't possibly find through your own human QA." (Quelle)

Roborev, das Open-Source-Tool von McKinney selbst, implementiert genau das: automatisches Review bei jedem Commit per Git Hook, bevor Fehler sich aufschichten.

Adversarial Agents sind die automatisierte Form davon: unabhängige Agenten, die explizit darauf ausgelegt sind, den Output des Coding-Agents zu widerlegen. Isolated Specification Tests sind die strukturelle Grundlage dafür: eine Test-Ebene, die aus Nutzersicht das Soll-Verhalten definiert und an die der Agent nicht rankommt, weder lesend noch schreibend. Das Konzept haben wir in einem eigenen Beitrag beschrieben.

Risiko 2: Verständnisverlust durch Geschwindigkeit

Wenn ein Loop in fünf Minuten 200 Zeilen Code generiert, kann der menschliche Reviewer den Code nicht mehr semantisch erfassen. Er sieht: kompiliert, Tests grün, sieht plausibel aus. Er sieht nicht, ob die gewählte Architektur in das umliegende System passt, ob die Datenmodell-Annahme stimmt, ob die Library-Version noch unterstützt wird.

KI-Code ist dabei besonders tückisch: stilistisch konsistent, idiomatisch, gut benannt. Die Fehler liegen nicht an der Oberfläche, sondern in Architektur-Annahmen und Edge Cases darunter. Review auf diesem Niveau kostet kognitiv mehr als bei handgeschriebenem Code, nicht weniger.

Joni Klippert, CEO des Security-Startups StackHawk, berichtet von einem Finanzdienstleistungs-Unternehmen, das nach Einführung von AI-Coding-Tools von 25.000 auf 250.000 Code-Zeilen pro Monat gesprungen ist und einen Review-Backlog von einer Million Zeilen aufgebaut hat. Geschwindigkeit ohne Reviewer-Kapazität verschiebt das Bottleneck, sie löst es nicht.

Gezielte Verlangsamung an kritischen Stellen hilft. Architektur-Entscheidungen, Datenmodell-Änderungen und sicherheitsrelevante Sektionen brauchen explizite Senior-Review-Gates. Nicht jeder PR muss langsam durch, aber die strukturkritischen schon.

Risiko 3: Kognitive Kapitulation

Das dritte Risiko ist das stillste. Wenn jeder Loop-Output „eh meistens passt", schaltet das Gehirn ab. In der Organisationsforschung heißt dieses Muster Normalization of Deviance: Was anfangs als Ausnahme durchging, wird zur Norm, bis niemand mehr fragt, warum. Dazu kommt der Ikea-Effekt: Selbst erzeugter Output wird systematisch als wertvoller eingeschätzt. Gilt für das Team, das den Output „selbst gebaut" hat.

In Kundenteams beobachten wir nach vier bis sechs Wochen autonomer Loop-Arbeit denselben Effekt: „Sieht gut aus" wird zur dominanten Bewertung, „prüfe nochmal" zur selten ausgesprochenen Forderung. Kein Disziplin-Problem. Generierung ist schneller als Verstehen. Das Gehirn passt sich an.

Die Antwort ist strukturell, nicht kulturell. Kulturelle Verification skaliert nicht über Wochen. Strukturelle schon: Tests, die unabhängig laufen müssen; Governance-Loops, die kein Mensch überspringen kann. Die Diskussion „Reviews ernst nehmen!" reicht nicht.

Das Trilemma: drei Wege, keiner davon gut

Ohne strukturelle Verification bleiben drei Optionen, und keine ist gut:

• Human Oversight: skaliert nicht, wenn Loops schneller werden als Reviewer
• Exhaustive Audits: zu langsam für kontinuierliche Delivery
• Vibe Accept: der Weg, den kein Team bewusst wählt, aber viele faktisch gehen

Die vier Maßnahmen unten sind keine Best-Practice-Liste. Sie sind der Ausweg aus diesem Trilemma. Isolated Specification Tests übernehmen dort, wo Menschen nicht mehr mithalten. Review-Gates verlangsamen gezielt die strukturkritischen Stellen, ohne die gesamte Delivery zu bremsen. Und wer den Verification-Aufwand budgetiert, behandelt ihn als das, was er ist: Investitionsschutz, kein Overhead.

White Box vs. Black Box: die Verification-Tabelle

Verification hat zwei Perspektiven: White Box mit Zugriff auf den Code, Black Box unabhängig von außen. Beide sind nötig, weil sie unterschiedliche Fehlerklassen finden.

Concern	White Box (mit Code-Zugriff)	Black Box (unabhängig)
Security	Static Analysis, Dependency Scanning	Penetration Testing von außen
Funktionalität	Unit Tests, Integration Tests	E2E-Tests aus Nutzersicht
Performance	Profiling, Benchmarks	Load Testing in Staging
Compliance	Automated Compliance-Checks	Unabhängige Abnahme, Audit

Die Versuchung, sich auf White-Box-Verification zu verlassen, ist groß: schneller, automatisierbar, läuft in der CI. Aber sie hat denselben blinden Fleck wie der Coding-Loop selbst. Sie sieht nur, was die Spec sagt. Black-Box-Verification ist strukturell notwendig, weil sie aus der Perspektive testet, die der Coding-Loop nicht hat: die des Nutzers, des Angreifers, des Audits.

Was du jetzt tun kannst

1. Isolated Specification Tests einführen: Tests, die der Agent nicht modifizieren darf, z. B. in einem separaten Repository oder über .claudeignore und Agent-Permissions, die dem Coding-Agent den Zugriff auf die Test-Suite entziehen.
2. Senior-Review-Gate für Architektur- und Datenmodell-Änderungen
3. Black-Box-Verification als Pflicht-Stage in der CI/CD
4. Verification-Aufwand explizit budgetieren

Wer die Verification Tax bezahlt, landet beim nächsten Engpass: nicht mehr die Umsetzung, sondern die Auswahl. Was bauen wir überhaupt? Ohne strategische Selektion produzieren schnellere Loops mehr Features, nicht bessere Produkte. Verification löst das Problem der Korrektheit. Das Problem der Relevanz ist Thema von Folge 3.

FAQ

Was ist der Unterschied zwischen AI Code Review und klassischem Code Review? Klassisches Review prüft Code, den Menschen geschrieben haben. AI Code Review bezeichnet zwei Dinge: KI-Tools, die Code automatisch reviewen (Greptile, GitLab Duo), und das menschliche Prüfen von KI-generiertem Code. Die zweite Variante ist die strukturell schwierigere: KI-Code ist stilistisch überzeugend, die Fehler liegen in Architektur-Annahmen und Edge Cases darunter.

Reichen Unit Tests für KI-generierten Code? Nein. Der Agent schreibt seine Tests oft selbst, gegen seine eigene Spec. Was er falsch modelliert, taucht in seinen Tests nicht auf. Dazu kommt: Agenten löschen Tests, die ihnen beim Refactoring im Weg sind. Black-Box-Tests, die der Agent nicht modifizieren kann, sind zwingend.

Wann wird menschliches Review zu Vibe Accept? Wenn der Reviewer nicht mehr semantisch versteht, was er reviewt. KI-Code ist gut benannt und idiomatisch, die Fehler liegen darunter. Wer nur prüft „kompiliert, Tests grün, sieht plausibel aus", reviewt de facto nicht mehr. Das ist kein Disziplin-Problem: Generierung ist schneller als Verstehen, das Gehirn passt sich an

Was sind Isolated Specification Tests? Tests, die der KI-Agent nicht sehen oder modifizieren kann, in einem separaten Repository oder über Berechtigungen, die ihm den Zugriff entziehen. Sie definieren das Soll-Verhalten aus Nutzersicht. Das Soll-Verhalten ist extern definiert, der Agent kann es nicht wegräumen.

Sind Tools wie Greptile, Cloudflare AI Review und GitLab Duo die Lösung? Bausteine, kein Ersatz für Strukturentscheidungen. Diese Tools reviewen automatisch Pull Requests und liefern Risikohinweise. Sie helfen wenig, wenn der Coding-Loop selbst keine Verification erzwingt, also wenn der Agent Zugriff auf seine eigenen Tests hat oder kein unabhängiger Review-Gate existiert.

Weiterführende Lektüre

• Birgitta Böckeler — „The role of developer skills in agentic coding" (martinfowler.com) — warum Steuern und Korrigieren die Kernkompetenz im Umgang mit Coding Agents ist
• Roborev — Open-Source-Tool von Wes McKinney für kontinuierliches AI Code Review per Git Hook.
• GitLab Duo Agent Platform — GitLabs KI-Plattform für den gesamten SDLC, inklusive spezialisierter Agenten für Code Review, Sicherheitsanalyse und agentic Workflows.
• codecentric: Kein Schummeln erlaubt: Isolierte Specification Tests mit Claude Code
• codecentric: Folge 1 der Reihe: Loop, Harness, Context Engineering: was bedeutet was?

---

In Folge 3 schauen wir kritisch hin: Wo Loops in der Realität scheitern — und was Boris Cherny dazu sagen würde, wenn die Realität nicht so glatt läuft wie sein Tweet.