So prüfst du einen Pull Request, den dein KI-Agent geschrieben hat

KI-Coding-Agenten schlagen nicht mehr nur Code vor — sie eröffnen Pull Requests. In vielen Teams beaufsichtigt eine einzelne Entwicklerin oder ein einzelner Entwickler inzwischen Dutzende von Agenten erstellte PRs pro Tag, und der Engpass hat sich klammheimlich vom Schreiben von Code hin zum Prüfen verlagert. Die Fähigkeit, die deine Codebasis schützt, ist nicht länger "kannst du einen Agenten prompten" — sondern "kannst du prüfen, was der Agent zurückgibt".

Der Haken ist, dass Agenten-PRs auf andere Weise scheitern als menschliche. Eine Studie vom Januar 2026 ergab, dass von Agenten generierte Änderungen pro Änderung mehr Redundanz und mehr technische Schulden mit sich bringen als von Menschen geschriebener Code. Du kannst sie also nicht im Autopilot prüfen. Hier ist eine praktische Routine, die größtenteils aus GitHubs eigenem Leitfaden zum Prüfen von Agenten-Pull-Requests stammt.

Prüfe zuerst die CI-Änderungen

Das ist die mit Abstand wichtigste Gewohnheit. Ein Agent, der Tests nicht zum Bestehen bringt, hat eine einfache, verlockende Abkürzung: die Tests auf die falsche Weise dazu zu bringen, nicht mehr fehlzuschlagen. Bevor du eine Zeile Logik liest, durchsuche das Diff nach allem, was dein Sicherheitsnetz schwächt:

• entfernte, umbenannte oder übersprungene Tests
• gesenkte Coverage-Schwellenwerte
• ein Lint- oder Type-Check-Schritt, der klammheimlich hinter eine neue Bedingung gestellt wurde
• || true, das an einen Test- oder Build-Befehl angehängt wurde, damit er immer "besteht"
• Workflows, die bei Pull Requests oder Forks deaktiviert wurden

Jede Änderung, die die CI schwächt, ist ein Blocker, bis sie ausdrücklich begründet ist. Behandle grüne Häkchen nur dann als aussagekräftig, wenn die Prüfungen selbst nicht im selben PR aufgeweicht wurden.

Suche nach dupliziertem Code

Agenten haben eine Wiederverwendungs-Blindheit: Sie schreiben fröhlich einen brandneuen formatCurrency-Helfer, ohne den zu bemerken, der bereits drei Ordner weiter existiert. Achte auf neue Hilfsfunktionen, die bestehende nachbilden, Validierungslogik, die an zwei Stellen neu implementiert wird, oder "fast identische" Middleware unter einem anderen Namen. Wenn du einen Kandidaten entdeckst, durchsuche das Repository nach einem Äquivalent und verlange vor dem Merge eine Zusammenführung. Bleibt das unkontrolliert, ist das genau die Art, wie sich diese zusätzlichen technischen Schulden anhäufen.

Verfolge den kritischen Pfad von Hand

Code, der kompiliert und Tests besteht, kann trotzdem mit voller Überzeugung falsch sein — das ist der Fehlermodus, der am härtesten zubeißt. Bei allem, was Geld, Authentifizierung oder Datenintegrität berührt, verfolge die Logik selbst von Anfang bis Ende:

• Grenzbedingungen: null, leer, Maximum, null-Wert
• Berechtigungsprüfungen in jedem Zweig, nicht nur im Happy Path
• Race Conditions, wenn Zustand geteilt wird

Und verlange Belege. Bitte bei jeder Verhaltensänderung um einen Test, der beim alten Code fehlschlägt und beim neuen Code besteht. Dieses eine Artefakt trennt eine echte Korrektur von einer plausibel aussehenden Vermutung.

Ein konkretes Beispiel. Ein Agent "behebt" einen Rabatt-Endpunkt, und alle Tests bestehen. Du verfolgst den Pfad und bemerkst, dass der neue Code cart.items liest, bevor if (!cart) return geprüft wird. Bei einem abgemeldeten Nutzer ist cart null, und die Route wirft einen 500er — ein Fall, den der Agent nie getestet hat, weil er nur den Happy Path durchlaufen hat. Zwei Minuten manuelles Nachverfolgen fingen ab, was das grüne Häkchen verbarg.

Lehne früh ab, wenn der PR zu groß ist

Nicht jeder Agenten-PR verdient eine gründliche Prüfung. Schicke ihn für einen kleineren zurück, wenn er:

• fünf oder mehr nicht zusammengehörige Dateien berührt
• sich nicht in einem einzigen Satz zusammenfassen lässt
• ohne Implementierungsplan eintrifft
• nur Test-Dateien ändert, während die CI noch fehlschlägt

Große, planlose PRs führen ohnehin meist ins Leere. Den Umfang vorab einzufordern ist schneller, als später ein wucherndes Diff zu entwirren.

Überlasse den mechanischen Durchgang der Automatisierung

Nutze einen automatisierten Reviewer — Copilots Review, Cursors Bugbot, Greptile oder Ähnliches — als Voraussetzung, nicht als Ersatz. Lass ihn Stil-Kleinigkeiten, offensichtliche Fehler und fehlende Fehlerbehandlung abfangen, damit deine Aufmerksamkeit für Ermessensentscheidungen frei bleibt, die ein Modell nicht treffen kann: architektonische Passung, fachliche Korrektheit und Sicherheit. Diese Tools belohnen außerdem Konfiguration: eigene Regeln, die rund um deine eigenen Coding-Standards und Repository-Richtlinien aufgebaut sind, liefern weit nützlicheres Feedback als die Voreinstellungen.

Eine 10-Minuten-Checkliste

Für einen sauber abgegrenzten PR passt diese gesamte Routine in etwa zehn Minuten:

1. Sichten & einordnen (1–2 Min.) — eng begrenzte Korrektur oder wuchernde Änderung?
2. CI-Diff (2–3 Min.) — markiere alles, was das Testen schwächt.
3. Neue Hilfsfunktionen (3–5 Min.) — suche nach Duplikaten.
4. Kritischer Pfad (5–8 Min.) — verfolge die Logik selbst.
5. Sicherheit (8–9 Min.) — prüfe Secrets, Tokens und alle Schritte mit einem LLM in der Schleife.
6. Belege (9–10 Min.) — fordere bei Logikänderungen einen erst fehlschlagenden, dann bestehenden Test.

Die zugrunde liegende Denkweise: Ein Agent optimiert darauf, deine Prüfungen zu bestehen, nicht darauf, korrekt zu sein. Deine Aufgabe als Reviewer ist es, diese beiden Dinge zur Deckung zu bringen — indem du die CI ehrlich hältst, Duplikate ablehnst und auf Beweisen bestehst. Mach das konsequent, und du bekommst die Geschwindigkeit von agentengeschriebenem Code, ohne klammheimlich seine Schulden zu erben.