KI-Agenten töten Code-Reviews – Das Prinzipal-Agent-Problem erklärt

Der branchenübliche Code-Review-Prozess – Review-then-Commit, bekannt durch GitHub-PRs – wurde für die Zusammenarbeit mit geringem Vertrauensniveau entwickelt. Ein Mensch macht eine Änderung, ein anderer Mensch überprüft sie, Iterationen finden statt, und die Änderung wird übernommen. Dies funktionierte, weil Prüfer aus dem Lesen des Codes günstig auf Aufwand und Verständnis schließen konnten. KI-Agenten brechen das völlig.

Das Agent-in-der-Mitte-Desaster

Der beste Fall mit KI-Agenten: Ein Mensch veranlasst eine Maschine, Code zu schreiben, der Mensch überprüft ihn und sendet ihn dann an einen zweiten Menschen zum traditionellen Review. Das verdoppelt die Review-Last. Schlimmer noch, Agenten erhöhen das gesamte Änderungsvolumen. Das Ergebnis: Die Review-Bandbreite ist erschöpft, bevor auch nur ein Bruchteil der Produktivitätsgewinne durch Agenten realisiert wird.

Doch die Realität ist noch schlimmer. Das tatsächliche Muster ist: Ein Mensch tippt eine kurze Eingabeaufforderung, testet die Ausgabe leicht, verpackt sie als PR und leitet dann die Kommentare des Prüfers zur Behebung an den Agenten zurück. Dies ist ein klassisches Principal-Agent-Problem: Der Prüfer (Principal) kann aus dem Code keinen Aufwand oder Verständnis mehr ableiten, da der Code von einer Maschine generiert wurde. Der Mensch, der den Agenten steuert, hat keinen Anreiz, den Code tatsächlich zu lesen oder kritisch über das Feedback des Prüfers nachzudenken. Sie verbringen 5 Minuten und erzeugen erheblichen Review-Aufwand für einen anderen Entwickler.

Das ist es, was Open Source tötet – „Slop-PRs“ von Menschen, die keinerlei Verständnis für das Projekt, seine Einschränkungen oder seine Werkzeuge haben.

Ein Weg nach vorn für kleine Teams

Für kleine Teams mit hohem Vertrauen gibt es einen einfacheren Prozess: Mensch veranlasst Agenten → Mensch überprüft Code → Mensch setzt direkt bereit (kein zweiter Prüfer). Der Mensch, der die Maschine steuert, übernimmt die volle Verantwortung, indem er die Bereitstellung selbst durchführt. Das Principal-Agent-Problem verschwindet, weil der Mensch sowohl der Treiber als auch der Bereitsteller ist.

Bei exe.dev verwendet ein Team von neun Personen diesen Ansatz erfolgreich. Wichtige Praktiken: wesentlich mehr Integrationstests und E2E-Tests schreiben, agentenbasierte Workflows zur Analyse von Commits auf Sicherheits-, Leistungs- und Nutzbarkeitsfehler entwickeln und sicherstellen, dass ein Mensch für die endgültige Bereitstellung verantwortlich ist.

Das traditionelle Code-Review-Modell ist mit Agenten nicht zu retten. Kleine Teams können sich anpassen; große Organisationen und Open-Source-Projekte stehen vor einem schwierigeren strukturellen Problem.