Pull Requests, die prüfbereit ankommen.
Wenn Entwürfe schneller entstehen, staut sich die Arbeit vor der Prüfung. Der Ausweg ist nicht, das Review abzuschaffen, sondern den mechanischen Teil davor zu erledigen — beim Autor, bevor der PR überhaupt aufgeht.
Erstgespräch 30 Minuten, direkt mit jemandem, der Review-Prozesse in Multi-Team-Organisationen verantwortet hat.
In den meisten Teams ist das Code-Review der Ort, an dem Arbeit liegen bleibt — nicht weil niemand prüfen will, sondern weil Prüfen Aufmerksamkeit verlangt, die zwischen zwei Terminen nicht zu haben ist. Sobald Entwürfe schneller entstehen, verschärft sich das: Die Änderungen kommen zügiger an, die Prüfkapazität bleibt gleich.
Der naheliegende Reflex — „dann soll die KI eben das Review machen" — führt in die Irre. Ein Agent kann nicht beurteilen, ob eine Änderung fachlich richtig ist; er kennt die Absicht dahinter nicht. Was er kann, ist die mechanische Durchsicht: alles, wofür es eine nachvollziehbare Regel gibt. Genau das macht in menschlichen Reviews die meisten Kommentare aus und bringt die wenigsten Erkenntnisse.
Diese Seite beschreibt, wie wir das zuschneiden, woran es in der Praxis scheitert und woran man erkennt, ob es etwas gebracht hat. Weitere Fälle stehen unter Anwendungsfälle.
Was ein Agent im Review übernimmt — und was beim Menschen bleibt.
Die Trennlinie verläuft nicht zwischen „schwierig" und „einfach", sondern zwischen überprüfbar und abwägbar. Alles, wofür es eine nachvollziehbare Regel gibt, kann ein Agent zuverlässig durchsehen. Alles, was eine Entscheidung verlangt, nicht.
Die mechanische Durchsicht
Konventionen, tote Importe, fehlende Fehlerbehandlung, vergessene Übersetzungen, Protokollierung an den falschen Stellen. Langweilig, zuverlässig prüfbar — und der Teil, der in menschlichen Reviews die meisten Kommentare erzeugt und die wenigsten Erkenntnisse.
Die Testlücke benennen
Welche Zweige der Änderung keine Abdeckung haben — konkret auf die geänderten Stellen bezogen, nicht als Prozentzahl über das ganze Projekt. Das ist der Hinweis, mit dem ein Autor etwas anfangen kann.
Den PR erklären
Eine Zusammenfassung der Änderung, die betroffenen Bereiche und erkennbare Risiken bei Migrationen oder Schnittstellen. Der Prüfer spart sich das Einlesen und steigt dort ein, wo es inhaltlich wird.
Was beim Menschen bleibt
Ob die Änderung fachlich richtig ist. Ob der Entwurf trägt. Ob der eingegangene Kompromiss der richtige war. Und die Freigabe — die erteilt bei uns grundsätzlich kein Agent.
Wann sich das lohnt.
Das passt, wenn …
- Pull Requests regelmäßig länger als einen Tag auf die erste Rückmeldung warten
- mehrere Runden je PR die Regel sind, oft wegen immer derselben Anmerkungen
- Tests und Linting bereits in der CI laufen — darauf setzt das Ganze auf
- es Konventionen gibt, auch wenn sie bisher nur in den Köpfen der Senioren stehen
Das passt nicht, wenn …
- es keine automatisierten Tests gibt — dann fehlt die Leitplanke, und wir fangen dort an
- Reviews heute schon in Stunden erledigt sind; dann ist der Engpass woanders
- das Ziel ist, Review-Aufwand einzusparen statt ihn auf das Wesentliche zu lenken
- niemand bereit ist, Regeln wieder zu entfernen, die sich als Lärm erweisen
Drei Schritte, ein Repository.
Eingebettet in das AI-Pipeline-Programm; als einzelner Anwendungsfall lässt es sich auch kleiner schneiden.
-
Messen, was heute gilt
Zeit bis zur ersten Rückmeldung, Runden je Pull Request, Größe der Änderungen, Fehler nach dem Release. Die Zahlen stehen in Ihrer Forge und in der Versionsverwaltung — wir ziehen sie dort heraus, statt das Team zu befragen. Dazu lesen wir die Review-Kommentare der letzten Monate: Sie sind die ehrlichste Regelsammlung, die Ihr Team besitzt.
-
Pilot an einem Repository
Der Agent läuft zuerst beim Autor, vor dem Pull Request, mit einem knappen Regelsatz aus Schritt 1. Er kommentiert, er gibt nicht frei. Danach ergänzend im PR selbst — in dieser Reihenfolge, weil Lärm beim Autor billiger ist als Lärm im Team-Review.
-
Verankern und erneut messen
Was trägt, kommt in die CI, in die Definition of Done und ins Onboarding. Was ignoriert wird, fliegt raus. Dann dieselben Kennzahlen noch einmal, mit derselben Methode — und ehrlich auch dann, wenn sich wenig bewegt hat.
Der Fehlschlag, den wir am häufigsten sehen: Lärm.
Agentisches Review scheitert selten daran, dass der Agent zu wenig findet. Es scheitert daran, dass er zu viel sagt. Dreißig Anmerkungen an einem Pull Request, von denen fünf stimmen, erzeugen keine Qualität — sie erzeugen die Gewohnheit, Kommentare wegzuklicken. Nach drei Wochen ist das Werkzeug aus, und im Haus gilt als erwiesen, dass „KI im Review nicht funktioniert".
Deshalb bauen wir eng und messen die Annahmequote je Regel: Wie viele Kommentare einer Kategorie führen tatsächlich zu einer Änderung? Was unter die vereinbarte Schwelle fällt, wird abgeschaltet — nicht nachjustiert, nicht verteidigt. Zehn Anmerkungen, von denen acht sitzen, verändern ein Team. Hundert mit derselben absoluten Trefferzahl verbrennen es.
Der zweite Grund, warum wir beim Autor anfangen und nicht im Pull Request: Dort kostet eine überflüssige Anmerkung eine Minute und niemanden sonst. Im Team-Review kostet sie die Aufmerksamkeit aller Beteiligten.
- Der Agent kommentiert, der Mensch gibt frei — kein Auto-Merge, keine Freigabe durch den Agenten
- Regelsatz aus Ihren eigenen Review-Kommentaren, nicht aus einer Standardliste
- Annahmequote je Regel wird gemessen, schwache Regeln werden entfernt
- Erst beim Autor, dann im Pull Request
- Repositories, Pfade und Kundenprojekte, die ausgenommen bleiben
Was das kostet.
Als Teil des AI-Pipeline-Programms folgt der Preis dessen Stufen: fest je Stufe, genannt nach dem Erstgespräch, schriftlich fixiert vor dem Start. Als einzelner Anwendungsfall ist der Zuschnitt kleiner — dann nennen wir den Preis nach der Durchsicht Ihrer Kennzahlen.
Wie wir die Rechnung aufmachen (Beispielzahlen, kein Kundenergebnis): 40 Pull Requests pro Woche, im Schnitt 2,4 Runden je PR, davon eine Runde für wiederkehrende mechanische Anmerkungen. Fällt diese Runde weg, sind das 40 vermiedene Zyklen pro Woche — bei je 20 Minuten Autor- und Prüferzeit rund 13 Stunden. Ob Ihre Zahlen so aussehen, wissen wir nach Schritt 1; vorher wäre es geraten.
Keine Provisionen von Werkzeug-Anbietern. Wir empfehlen, was trägt — nicht, was uns bezahlt.
Der Gewinn liegt selten darin, dass ein Agent Fehler findet. Er liegt darin, dass die immer gleichen Anmerkungen gar nicht erst in den Pull Request kommen.
Was Entwicklungsteams uns dazu fragen
Ersetzt das unsere Reviews?
Nein, und es soll es auch nicht. Der Agent macht die erste Durchsicht, nicht das Urteil. Die Freigabe erteilt ein Mensch — wir bauen bewusst kein automatisches Zustimmen ein, auch nicht für kleine Änderungen. Was sich ändert, ist der Inhalt der menschlichen Reviews: weniger Formalien, mehr Entwurf und Fachlichkeit.
Geht unser Quellcode dabei an einen Anbieter?
Das klären wir, bevor etwas gebaut wird: welche Daten wohin fließen, welche Anbieter Verarbeitung in der EU und keinen Trainingszugriff zusichern, und welche Repositories oder Kundenprojekte vollständig ausgenommen bleiben. Für Dienstleister mit Kundenverträgen haben wir das auf einer eigenen Seite beschrieben: Was antworten Sie, wenn Ihr Kunde fragt?
Was passiert, wenn der Agent Unsinn kommentiert?
Dann fliegt die Regel raus, die den Unsinn erzeugt. Wir messen je Kategorie, wie viele Anmerkungen zu einer Änderung führen; was unter der vereinbarten Schwelle liegt, wird abgeschaltet. Dieses Aufräumen ist kein Nebenprodukt, sondern der Hauptteil der Arbeit nach der ersten Woche.
Funktioniert das in einer alten Codebasis ohne saubere Konventionen?
Oft sogar besonders gut, weil die Konventionen dort implizit in den Köpfen einiger Senioren liegen. Der Weg ist derselbe: Wir leiten die Regeln aus den tatsächlichen Review-Kommentaren der letzten Monate ab und machen sie damit explizit. Was fehlt, sind meistens Tests — dann fangen wir dort an, nicht beim Review.
Was ist mit Sicherheitsprüfungen?
Die bleiben. Statische Analyse und Abhängigkeits-Scans finden andere Dinge als ein Agent, der den Kontext einer Änderung liest — etwa eine fehlende Berechtigungsprüfung in einem neuen Endpunkt. Das ergänzt sich; ersetzen würde beides schwächer machen.
Wie lange dauert es, bis man etwas sieht?
Die ersten brauchbaren Kommentare entstehen in Tagen. Eine belastbare Aussage über Durchlaufzeit und Runden je Pull Request braucht etwa sechs Wochen, weil diese Werte stark streuen — einzelne schnelle Wochen sagen nichts. Wer früher eine Zahl verspricht, rät.
Wie lange wartet bei Ihnen ein Pull Request auf die erste Rückmeldung?
Wenn Sie die Zahl nicht kennen, ist das ein guter Grund für ein Gespräch. Dreißig Minuten, direkt mit jemandem, der Review-Prozesse verantwortet hat und heute selbst agentisch baut.
Kein Foliensatz. Wenn Ihr Engpass woanders liegt, sagen wir das.