Wie Sie einen KI-Agenten-PR prüfen und unnötige Änderungen entfernen

Ein Coding-Agent kann Fehler schnell beheben oder eine Funktion implementieren. Gleichzeitig kann er unbeteiligte Dateien formatieren, zusätzliche Abstraktionen einführen, Konfiguration ändern oder deutlich mehr Code umschreiben, als die Aufgabe verlangt. Vor dem Merge geht es nicht um die kleinstmögliche Zeilenzahl. Ziel ist ein Änderungssatz, bei dem jede wichtige Änderung einer akzeptierten Anforderung zugeordnet ist, von einem Maintainer erklärt und durch Tests oder andere Belege überprüft werden kann.

Ein Entwickler beschrieb auf X eine persönliche Arbeitsweise: Nachdem ein Agent einen PR geöffnet hat, startet er einen zweiten Agenten mit frischem Kontext und lässt ihn nach Kürzungsmöglichkeiten suchen. Der Autor nannte ausdrücklich zusätzlichen Aufwand und zusätzliche Tokens und stellte die Methode nicht als Garantie dar. Ein anderer Nutzer berichtete, Codex habe viele Fehler behoben, den Code aber so breit verändert, dass er ihn nicht mehr verstehe. Diese Berichte beschreiben das Problem; sie beweisen nicht, dass ein zweiter Agent jeden PR verbessert.

Im folgenden Ablauf ist der zweite Agent ein skeptischer Reviewer, keine Entscheidungsinstanz. Umfang, Belege, Risiko und Merge-Entscheidung bleiben beim Menschen.

Der Ablauf in sieben Schritten

1. Einen Abnahmevertrag schreiben: erwartetes Verhalten, unveränderliche Eigenschaften, erlaubter Umfang, Risiken und Prüfkommandos.
2. Den tatsächlichen Umfang über Conversation, Commits, Checks, Files changed und lokale Git-Befehle erfassen.
3. Einem Agenten mit frischem Kontext zunächst nur eine Review-Aufgabe geben und Änderungen verbieten.
4. Jeden Fund als Behalten, Vereinfachen, Entfernen, Aufteilen oder menschliche Entscheidung klassifizieren und Belege verlangen.
5. Nur menschlich freigegebene Kürzungen in kleinen, umkehrbaren Paketen anwenden.
6. Vor und nach der Kürzung denselben relevanten Satz an Tests und Checks ausführen.
7. Den finalen Diff vollständig neu lesen und nur mergen, wenn ein Maintainer alle Änderungen erklären kann.

1. Zuerst den Abnahmevertrag festhalten

„Mach diesen PR sauberer“ ist zu ungenau und kann eine weitere subjektive Neuschreibung auslösen. Der Vertrag sollte enthalten:

• Problem und beobachtbares Ergebnis: Was sehen Nutzer oder aufrufender Code?
• Zu erhaltendes Verhalten: bestehende Schnittstellen, Fehlerverhalten, Kompatibilität und Datensemantik.
• Erlaubter Umfang: erwartete Module, APIs, Schemas, Konfiguration und Tests.
• Explizite Nicht-Ziele: kein Framework-Upgrade, keine globale Formatierung, keine fremden Umbenennungen, keine spekulative Abstraktion oder unnötige Migration.
• Risikogrenzen: Sicherheit, Berechtigungen, Migrationen, Performance, Beobachtbarkeit, Rollback und Rückwärtskompatibilität.
• Validierung: die echten Format-, Lint-, Typ-, Test-, Build-, Migrations- oder E2E-Kommandos des Repositories.

Wenn das korrekte Ergebnis nicht beschrieben werden kann, lässt sich auch unnötiger Code nicht zuverlässig bestimmen. Klären Sie den Vertrag vor dem Löschen.

2. Den vollständigen Diff statt der Agentenzusammenfassung erfassen

GitHub verteilt die PR-Belege auf mehrere Ansichten. Conversation enthält Beschreibung und Diskussion, Commits den Verlauf, Checks die automatisierten Prüfungen und Files changed den tatsächlichen Diff. Der offizielle Review-Ablauf unterstützt Zeilenkommentare, Änderungsvorschläge, Viewed-Markierungen je Datei sowie Comment, Approve oder Request changes als Abschluss.

Für lokale Ausführung oder Bearbeitung dokumentiert GitHub:

gh pr checkout <PR_NUMBER>
git fetch origin

Ersetzen Sie origin/main durch den tatsächlichen Base-Branch und betrachten Sie die Änderungen vom gemeinsamen Vorfahren bis HEAD:

git diff --stat origin/main...HEAD
git diff --name-status origin/main...HEAD
git log --oneline origin/main..HEAD

Git definiert git diff A...B als Änderungen von der Merge-Base von A und B bis B. Lesen Sie nach der Übersicht den vollständigen Diff und verdächtige Pfade:

git diff origin/main...HEAD
git diff origin/main...HEAD -- path/to/suspicious-file

Löschen Sie während dieser Inventur noch nichts. Ordnen Sie die Dateien ein:

Gruppe	Leitfrage
Kernimplementierung	Setzt die Datei direkt einen Punkt des Abnahmevertrags um?
Notwendige Unterstützung	Sind Tests, Dokumentation, Migration oder Konfiguration wirklich nötig?
Verdächtige Ausweitung	Enthält der PR globale Formatierung, breite Umbenennungen, fremde Abstraktionen oder Upgrades?
Generierte Ausgabe	Muss sie mit der Quelle versioniert werden oder kam sie versehentlich hinzu?
Unsicheres Risiko	Berührt die Änderung Sicherheit, Daten, Kompatibilität oder ein unbekanntes Fachgebiet?

Komplexität allein beweist keine Redundanz. Defensive Prüfungen, Migrationen und Kompatibilitätspfade können lang und dennoch notwendig sein.

3. Frischer Kontext für einen reinen Review-Durchgang

Der Vorteil eines frischen Kontexts liegt nicht darin, dass der zweite Agent automatisch richtiger wäre. Er kann ein anderes Ziel erhalten: Umfang und Belege hinterfragen, statt die Implementierung fertigzustellen. Das ist eine begründete Review-Technik und ein Praxisbericht, keine offizielle Vorgabe oder gemessene Garantie.

Geben Sie Abnahmevertrag, vollständigen Diff, relevante Aufrufer, Tests und Repository-Regeln mit. Beispiel:

Du bist der Maintainer-Reviewer im zweiten Durchgang dieses Pull Requests. Dein Ziel ist nicht, den Code neu zu schreiben, sondern den kleinsten erklärbaren Änderungssatz zu finden, der den Abnahmevertrag weiterhin erfüllt.

Erster Durchgang: nur Review. Keine Datei ändern.
Lies PR-Ziel, vollständigen Diff, relevante Aufrufer, Tests und Repository-Einschränkungen.

Für jeden Fund ausgeben:
1. Datei und exakter Hunk oder Symbol;
2. die bediente Anforderung;
3. Beleg: Aufrufer, Test, Schnittstellenvertrag, Dokumentation oder fehlender Beleg;
4. Risiko beim Entfernen oder Vereinfachen;
5. Aktion: KEEP / SIMPLIFY / REMOVE / SPLIT / HUMAN DECISION;
6. exakte Validierung nach der Änderung.

Regeln:
- Löschen nicht nur wegen Länge oder anderem Stil empfehlen;
- grüne Tests sind nicht der einzige Beweis korrekter Anforderungen;
- fremde Formatierung, doppelte Abstraktionen, unbenutzte Helper, Refactorings außerhalb des Umfangs und unerklärte Dependency-/Konfigurationsänderungen priorisieren;
- Sicherheit, Kompatibilität, Migrationen, Fehlerbehandlung und Observability ohne Gegenbeleg erhalten;
- Unsicherheit kennzeichnen und keine Geschäftsregeln erfinden;
- mit einem Kürzungsplan von niedrigem zu hohem Risiko enden. Noch keinen Code schreiben.

Ein Bericht vor der Bearbeitung verhindert, dass der Reviewer unter dem Etikett „Kürzen“ eine weitere große Neuschreibung erzeugt. Jede Empfehlung muss Datei, Hunk und Beleg nennen.

4. Ein Mensch klassifiziert jeden Fund anhand von Belegen

Entscheidung	Wann sie passt	Zu bestätigende Belege
Behalten	Erfüllt Vertrag oder notwendige Sicherheit, Kompatibilität, Migration bzw. Betrieb	Anforderungsbezug, Aufrufpfad, Test, Schnittstelle oder dokumentierte Vorgabe
Vereinfachen	Verhalten ist nötig, aber Branches, Wrapper oder Schichten sind doppelt	Verhaltensgleichheit und Abdeckung wichtiger Randfälle
Entfernen	Fremd, unbenutzt, ohne Vertrag oder nur versehentliche Formatierung/Umbenennung	Suche, Build und relevante Tests zeigen keine Abhängigkeit
Aufteilen	Möglicherweise wertvoll, aber außerhalb des aktuellen Vertrags	Kann unabhängig beschrieben, getestet, reviewed und zurückgenommen werden
Eskalieren	Unbekanntes Fachgebiet, Sicherheitsgrenze, Migration oder verborgene Regel	Code Owner, Domain-Maintainer oder Charakterisierungstest nötig

Prüfen Sie, ohne automatisch zu löschen: mehrere generische Schichten für einen Aufrufer; alter und neuer Pfad ohne erklärten Kompatibilitätszeitraum; fremde Formatierung, Imports, Namen oder Verschiebungen; unerklärte Dependency-, Lockfile- oder Konfigurationsänderungen; Tests interner Form statt sichtbaren Verhaltens; lautloses Verschlucken aller Exceptions; Helper ohne Aufrufer; „vielleicht später“-Code.

Fehlende Tests beweisen ebenfalls keine Nutzlosigkeit. Sie können eine Abdeckungslücke anzeigen. Ergänzen Sie einen Charakterisierungstest oder fragen Sie den Modulverantwortlichen, bevor unsicheres Verhalten entfernt wird.

5. In kleinen Paketen kürzen und einen Wiederherstellungspunkt behalten

Prüfen Sie vor der Bearbeitung den Working Tree und erstellen Sie eine lokale Backup-Referenz:

git status --short
git branch backup/ai-pr-before-trim

Um eine ganze Datei auf den Basiszustand zurückzusetzen:

BASE=$(git merge-base origin/main HEAD)
git restore --source="$BASE" -- path/to/unrelated-file

Für ausgewählte Hunks:

git restore -p --source="$BASE" -- path/to/file

Die Git-Dokumentation weist darauf hin, dass ein getrackter Pfad entfernt wird, wenn er in der Restore-Quelle nicht existiert, damit der Zustand der Quelle entspricht. Prüfen Sie $BASE und den Pfad und kontrollieren Sie sofort den Diff. Manuelles Editieren ist ebenfalls möglich; vermeiden Sie nur ein weiteres fremdes Refactoring.

Verarbeiten Sie jeweils eine freigegebene Gruppe:

git diff
git add -p
git diff --cached
git commit -m "Remove unrelated changes from AI-generated PR"

Kleine Commits zeigen, was entfernt wurde, warum und mit welcher Prüfung. Verbergen Sie den Ablauf während des Reviews nicht durch destruktives Umschreiben der Historie.

6. Vorher und nachher vergleichbare Validierung ausführen

Tests sollen zeigen, dass das akzeptierte Verhalten erhalten blieb, nicht dass der Diff kürzer ist. Zeichnen Sie nach Möglichkeit eine Baseline des ursprünglichen PRs auf und wiederholen Sie nach jedem Paket dieselben relevanten Prüfungen:

<format-check-command>
<lint-command>
<typecheck-command>
<targeted-unit-test-command>
<relevant-integration-test-command>
<build-or-e2e-command>

Nutzen Sie Befehle aus Repository-Dokumentation oder CI, keine Vermutungen des Agenten. Decken Sie Normalpfad, wichtige Grenzen, Fehler, Berechtigungen, leere Werte, Parallelität, Timeouts, Retries, öffentliche Schnittstellen, serialisierte Formate, Migrationen, Build, Typen, Lint, Sicherheit und erforderliche Checks des neuesten Commits ab.

Wenn eine Kürzung einen Test bricht, nehmen Sie dieses Paket zurück oder stellen Sie es aus dem Backup wieder her und untersuchen Sie die Ursache. Ändern Sie Test und Implementierung nicht gemeinsam nur für Grün, außer der Vertrag erklärt die alte Erwartung ausdrücklich für falsch und ein Mensch genehmigt das neue Verhalten.

Grüne Tests sind wichtige Belege, können aber unvollständig sein. Menschliches Verständnis bleibt erforderlich.

7. Den finalen Diff neu prüfen und ausdrücklich entscheiden

Öffnen Sie nach der Kürzung Files changed erneut und prüfen Sie alle Dateien von Anfang an. GitHub entfernt die Viewed-Markierung, wenn eine bereits geprüfte Datei verändert wird. So erkennen Sie, was erneut gelesen werden muss. Prüfen Sie Commits und Checks erneut und stellen Sie sicher, dass sie zur neuesten Revision gehören.

Ein letzter Review mit frischem Kontext kann nur Vertrag und finalen Diff betrachten, aber mit Stoppbedingung: nur belegte Probleme, keine endlose Stil-Schleife. Danach sendet ein Mensch:

• Approve: Vertrag erfüllt, Änderungen erklärbar, Risiken behandelt, erforderliche Validierung erfolgreich.
• Request changes: fremder Umfang, undurchsichtige Logik oder fehlgeschlagene Checks bleiben. Ob dies den Merge blockiert, hängt von Repository-Regeln und Branch Protection ab.
• Comment: nützliches Feedback, aber weder Freigabe noch formelle Änderungsanforderung.

Checkliste vor dem Merge

• Jede geänderte Datei gehört zur aktuellen Anforderung, einem nötigen Test oder klarer Unterstützung.
• Ein Maintainer erklärt jeden wichtigen Hunk ohne die Agentenzusammenfassung nachzusprechen.
• Unerklärte Dependencies, Konfiguration, Berechtigungen, Migrationen und generierte Dateien wurden entfernt, getrennt oder eskaliert.
• Ursprünglicher und gekürzter PR erhielten vergleichbare Validierung.
• Lokale Tests, Build und Checks des neuesten Commits erfüllen die Projektregeln.
• Unsicherheit bei Sicherheit, Daten und Kompatibilität wurde vom passenden Verantwortlichen geprüft.
• Bleibt der Diff breit, wurde unabhängige Arbeit aufgeteilt.
• Review-Entscheidung und Follow-ups sind dokumentiert.

Häufige Fehler und Wiederherstellung

Der zweite Agent schreibt das Modul erneut um

Stoppen Sie die Ausführung. Kehren Sie zum Bericht ohne Bearbeitung zurück, begrenzen Sie Dateien und verlangen Sie Hunk, Anforderung und Validierung pro Vorschlag. Ästhetische Refactorings ohne Beleg werden abgelehnt.

Die Agenten widersprechen sich

Nicht abstimmen. Vergleichen Sie Aufrufer, Verträge, Fehlerpfade, Tests und historische Einschränkungen. Bei schwachen Belegen Code vorläufig behalten, Abdeckung ergänzen oder Domain-Maintainer fragen.

Tests sind grün, der Code bleibt aber unverständlich

Testabdeckung ist nicht gleich verständliches Design. PR aufteilen, dokumentieren oder eine Erklärung des kritischen Pfads verlangen. Undurchsichtigen Code nicht nur wegen grüner CI mergen.

Verlässliche Tests fehlen

Einen minimalen Charakterisierungstest oder eine wiederholbare manuelle Prüfung mit protokolliertem Ergebnis hinzufügen. Bei hohem Risiko ist fehlender Beleg ein Grund zum Stoppen, keine Erlaubnis zum Raten.

Der PR ist zu groß

Kernverhalten, Refactoring, Dependency-Upgrades, Formatierung und Migrationen in unabhängig prüfbare Änderungen teilen. Kleine Einheiten sind leichter zu verifizieren und zurückzunehmen.

Ausführungs-Prompt für freigegebene Funde

Implementiere nur diese freigegebenen Finding-IDs: [LISTE].
Ändere keine Datei außerhalb der Liste und führe kein opportunistisches Refactoring aus.
Für jede logische Gruppe:
1. tatsächlichen Diff zeigen;
2. zugewiesene Validierungskommandos ausführen;
3. Kommando, Exit-Status und Fehlerzusammenfassung melden;
4. verbleibende Unsicherheiten auflisten.
Stoppen und menschliche Entscheidung anfordern, wenn ein Punkt Abnahmevertrag, öffentliche Schnittstelle, Sicherheit oder Migration verändert.

Die Kernidee lautet nicht „mehr Agenten einsetzen“. Generation und Review werden getrennt: Ein Kontext schlägt die Implementierung vor, ein zweiter hinterfragt Umfang und Belege, und ein Mensch besitzt Entscheidung und Abnahme. Das richtige Ergebnis ist nicht der kürzeste Diff, sondern die kleinste erklärbare und verifizierte Änderung, die die Aufgabe löst.

Quellen und Grenzen

• Praxisbericht: X-Post und Antworten von Arnav Gupta über Kürzungsreview mit frischem Kontext; anekdotisch, keine allgemeine Statistik.
• Nutzerbericht: Ein Entwickler verstand den Code nach einer breiten Codex-Änderung nicht mehr; der Originalpost enthält kein Repository, keinen Diff und keine Testergebnisse.
• GitHub-Dokumentation: Vorgeschlagene Änderungen prüfen, PR lokal auschecken, Pull-Request-Referenz.
• Git-Dokumentation: git diff und git restore.