Pull-Request-Review mit KI: Codequalität und die Entwicklung von Junior-Entwicklern.

Das Problem unübersichtlicher Pull Requests ist in Gesprächen mit Kollegen immer wieder aufgekommen, bei ganz unterschiedlichen Gelegenheiten.

Die hier beschriebene Methode ist daraus entstanden und aus meiner Erfahrung als Senior-Entwickler und Teamleiter, zu der es seit jeher gehört, Junior-Entwickler zu schulen und zu begleiten.

In einem Projekt habe ich sie noch nicht angewendet. Um sie wirklich zu erproben, braucht es ein reales Team: mehrere Entwickler, Aufgaben unterschiedlicher Komplexität und einen Zeitraum, der lang genug ist, um eine Entwicklung zu erkennen. Sie ist Teil einer gemeinsamen Harness des Teams, die ich, wie auf der Seite Qualität und Coding-Agenten beschrieben, noch nicht aufgebaut habe. Was folgt, ist daher ein methodischer Vorschlag.

• Die Qualität des Codes sichern, der ins Produkt gelangt.
• Entwickler in der Ausbildung angemessen begleiten und erkennen, ob sie wirklich wachsen – auch wenn sie den Code mithilfe von KI schreiben.

Die Schwelle für die Freigabe eines Pull Requests wäre für alle gleich: Sicherheit, Korrektheit und wichtige Projektregeln blockieren die Freigabe, unabhängig davon, wer den Code geschrieben hat. Die KI würde ein erstes Review anhand der Richtlinien des Teams durchführen; das letzte Wort bliebe bei einem Menschen.

Autor und Prüfer sollten getrennt bleiben: Die Sitzung, die den Code prüft, darf nicht dieselbe sein, die ihn geschrieben hat. Ein Review ist nur so gut, wie die schriftlichen Regeln des Projekts klar sind.

Was sich ändert, ist der Weg zur Freigabe. Bei Junior-Entwicklern erklären die Kommentare das Warum und verweisen auf die Regel; kleinere Probleme wie Benennung oder Stil werden gemeldet, blockieren aber nicht. Bei Senior-Entwicklern genügen kurze Kommentare. Zu jedem blockierenden Problem erklärt die Person, die den Code geschrieben hat, in wenigen Zeilen, was sie geändert hat und warum; ist sie mit einem Kommentar nicht einverstanden, kann sie widersprechen – und ein begründeter Widerspruch ist ein gutes Zeichen.

Innerhalb eines einzelnen Pull Requests würde ich eine Höchstzahl an Runden festlegen: Ist sie erreicht, setzt man sich besser mit einem Senior-Entwickler zusammen, statt weiter zu iterieren.

Zu vermeiden ist ein Entwickler, der das Review besteht, ohne zu verstehen. Eine kontrollierte Studie von Anthropic mit 52 Entwicklern, überwiegend Junior-Entwicklern, ergab schlechtere Ergebnisse im Verständnistest bei denjenigen, die eine neue Bibliothek mit dem Assistenten lernten (50 % gegenüber 67 %), ohne signifikanten Zeitgewinn. Wer sich von der KI Konzepte erklären ließ, erzielte ähnliche Ergebnisse wie die Gruppe ohne KI. Die Studie ist klein und vorläufig, zeigt aber, worauf zu achten ist: nicht, ob ein Entwickler KI nutzt, sondern wie.

Mit jedem weiteren Pull Request, oder mit jedem Monat, erwartet man, dass neue Teammitglieder schneller zur Freigabe kommen. Am Anfang kann es normal sein, dass ein Senior-Entwickler unterstützen muss: Das hängt vom Projekt ab, von seiner Komplexität und davon, wie gut es dokumentiert ist. Wiederholt sich die Situation nach fünf oder sechs Pull Requests immer noch, gibt es etwas zu verstehen. Die Zahlen sind Richtwerte.

Das Problem liegt nicht unbedingt bei der Person: Auch die zugewiesenen Aufgaben, ein schlecht dokumentierter Teil des Codes oder eine unklare Regel können eine Rolle spielen.

Wenn mehrere Entwickler gleichzeitig eingearbeitet werden, lässt sich der Weg jedes Einzelnen kaum aus dem Gedächtnis verfolgen. Ein Review-Protokoll mit den gemeldeten Problemen, dem Bereich der Anwendung und den nötigen Runden zeigt, ob dieselben Fehler wiederkehren oder verschwinden und wie lange es dauert, bei den verschiedenen Aufgabenarten selbstständig zu werden.

Nach Anwendungsbereichen gelesen, verrät dasselbe Protokoll noch mehr: Stoßen mehrere Junior-Entwickler im selben Teil des Codes auf dasselbe Problem, liegt die Schwachstelle wahrscheinlich nicht bei ihnen, sondern in der Harness, also in der Dokumentation, den Regeln oder den Prüfungen dieses Teils. So lässt sich über die Zeit auch erkennen, ob die Harness funktioniert.

Review-Werkzeuge auf dem Markt erfassen diese Daten bereits: Die Dokumentation von CodeRabbit beschreibt zum Beispiel Kennzahlen, die sich nach einzelnen Entwicklern filtern lassen. Die Frage ist also nicht, ob es die Daten gibt, sondern wie man sie nutzt.

Ein unübersichtlicher Pull Request beginnt oft mit einer vagen Aufgabe. Die Arbeit vorzubereiten, bevor man sie zuweist, bringt zweierlei: Der Entwickler weiß, was er liefern soll und wie er es prüft, und der Agent arbeitet mit präzisen Anfragen, statt den Code ziellos zu durchsuchen, und verbraucht weniger. Das wird immer wichtiger, denn viele Unternehmen begrenzen inzwischen ihre Ausgaben für KI.

Werkzeuge und Zuständigkeiten im Team →

Das Werkzeug bewertet keine Menschen. Es liefert technische Daten zu den Pull Requests: Probleme, Runden, wiederkehrende Fehler, nach der Freigabe entdeckte Mängel und ihre Ursache. Diese Daten fließen in die Prozesse zur Bewertung der beruflichen Entwicklung ein, die das Unternehmen bereits hat; das Urteil bleibt bei einem Menschen.

Einige Bedingungen halte ich für notwendig:

• Entwickler sehen alles, was ihre Führungskraft über sie sieht, und können darauf antworten;
• keine Ranglisten zwischen Personen und keine Gesamtpunktzahlen;
• erfasst werden nur Daten zum technischen Inhalt der Pull Requests, weder Arbeitszeiten noch Gespräche mit der KI, und die ausgeschlossenen Daten werden schriftlich festgehalten;
• die Daten werden für einen festgelegten Zeitraum aufbewahrt.

Ein System, das die Arbeit einzelner Entwickler über die Zeit verfolgt, sollte vor der Einführung rechtlich geprüft werden. Dass es nicht selbst entscheidet, hebt die Pflichten nicht auf: Die europäische KI-Verordnung stuft auch Systeme, die die Leistung von Beschäftigten überwachen und bewerten, als hochriskant ein. In Italien sind mindestens diese Punkte zu prüfen:

• das Arbeitnehmerstatut (Statuto dei lavoratori, Art. 4);
• die DSGVO;
• das italienische KI-Gesetz (Gesetz Nr. 132/2025, Art. 11), das auf die Pflichten zur Information der Beschäftigten verweist;
• die KI-Verordnung (AI Act), deren Pflichten für diese Systeme nach der 2026 beschlossenen Verschiebung ab dem 2. Dezember 2027 gelten.

Dies ist keine Rechtsberatung.

Die Methode ist ein Vorschlag aus eigener Erfahrung und Gesprächen mit Kollegen; die Quellen stützen einzelne Punkte, nicht die Methode als Ganzes.

• Anthropic — How AI assistance impacts the formation of coding skills (öffnet in einem neuen Tab): kontrollierte Studie mit 52 Entwicklern, Januar 2026; kleine Stichprobe und vorläufige Ergebnisse, direkt nach der Aufgabe gemessen.
• Claude Code — Manage costs effectively (öffnet in einem neuen Tab): Vage Anfragen lassen den Agenten den Code durchsuchen und verbrauchen mehr; Planung und klare Prüfziele vermeiden Nacharbeit.
• CodeRabbit — Dashboard (öffnet in einem neuen Tab): nach einzelnen Entwicklern filterbare Review-Kennzahlen; Dokumentation des Anbieters, für ein Werkzeug, das ich nicht genutzt habe.
• TechCrunch — The token bill comes due (öffnet in einem neuen Tab): Unternehmen, die ihre KI-Ausgaben begrenzt haben, Juni 2026.
• Verordnung (EU) 2024/1689 (KI-Verordnung) (öffnet in einem neuen Tab): Anhang III Nummer 4 Buchstabe b, Systeme zur Überwachung und Bewertung der Leistung von Beschäftigten.
• Rat der EU — endgültige Annahme der Änderungen an der KI-Verordnung (auf Englisch) (öffnet in einem neuen Tab): Pressemitteilung vom 30. Juni 2026, neue Termine für Hochrisiko-Systeme.
• Gesetz Nr. 132 vom 23. September 2025 (auf Italienisch) (öffnet in einem neuen Tab): Art. 11, Einsatz künstlicher Intelligenz im Arbeitsleben.