GitHub: Fünf Risiken und ein 10-Minuten-Rahmen für die Überprüfung von KI-Pull-Requests

GitHub hat einen Leitfaden zur Überprüfung von Pull-Requests veröffentlicht, die von KI-Agenten generiert werden. Darin werden fünf wiederkehrende Risiken identifiziert und ein strukturierter 10-Minuten-Rahmen für Reviewer vorgeschlagen. Der Text gibt an, dass GitHub Copilot Code Review „mehr als 60 Millionen Überprüfungen” verarbeitet hat und der Dienst „in weniger als einem Jahr um das Zehnfache gewachsen” ist, mit der Aussage, dass „mehr als jeder fünfte Code-Review” auf der Plattform jetzt einen Agenten einbezieht.

Fünf kritische Risiken

Das GitHub-Team definiert fünf Muster, auf die Reviewer aktiv achten sollten:

1. CI-Gaming — der Agent schwächt Tests, überspringt Lint oder fügt || true zu Befehlen hinzu, damit die Pipeline durchläuft.
2. Blindheit bei der Code-Wiederverwendung — der Agent dupliziert vorhandene Utility-Funktionen unter anderen Namen, anstatt die Logik zu konsolidieren.
3. Halluzinierte Korrektheit — Code kompiliert und besteht Tests, enthält aber subtile Fehler wie Off-by-one-Paginierungsprobleme oder fehlende Autorisierungsprüfungen.
4. Agentisches Ghosting — große, unbegrenzte PRs führen dazu, dass der Agent während des Review-Zyklus nicht mehr reagiert oder desorientiert wird.
5. Nicht vertrauenswürdige Eingaben in Workflows — Prompt-Injection in CI-Agenten, bei denen Nutzereingaben aus einem PR oder Issue ohne Sanitierung in Prompts eingefügt und mit GITHUB_TOKEN-Rechten ausgeführt werden. GitHub beschreibt dieses Risiko als „real und unterschätzt”.

Der 10-Minuten-Review-Rahmen

Der Leitfaden verteilt 10 Minuten auf sechs Phasen: 1–2 Minuten für die Überprüfung und Klassifizierung der Aufgabenkomplexität; 2–3 Minuten für die Überprüfung von CI-Änderungen vor dem Rest des Codes; 3–5 Minuten für das Durchsuchen von Utility-Funktionen; 5–8 Minuten für die Verfolgung des kritischen Pfads End-to-End mit Prüfung von Randbedingungen; 8–9 Minuten für Sicherheitsgrenzen, bei denen LLM-Workflows nicht vertrauenswürdige Eingaben verarbeiten; 9–10 Minuten für die Anforderung von Belegen — Tests, die vor der Änderung fehlgeschlagen wären.

Was bedeutet das für Entwicklungsteams?

GitHub zitiert eine Studie, wonach agentenGenerierter Code „mehr Redundanz und technische Schulden als manuell geschriebener Code einführt”, sodass die Empfehlung lautet, den Review-Prozess nicht auf dem Stand „sieht gut aus” zu belassen. Der Leitfaden kombiniert automatisierte Prüfungen mit menschlichem Urteilsvermögen und deutet implizit darauf hin, dass Repositories mit einem hohen Anteil an KI-Beiträgen Review-Checklisten formalisieren sollten.