Pull Requests mit Agenten
Auf GitHub weist du einem Agenten ein Issue zu, und er öffnet einen Pull Request. Wie das mit Copilot, Claude und Codex funktioniert – und wie du prüfst, ohne dass etwas ungelesen im Hauptzweig landet.
Boaz LichtensteinFakten geprüft am 10. November 2026
Bisher lief der Agent auf deinem Rechner, und du hast den Unterschied im Terminal angesehen. Auf GitHub verschiebt sich der Ablauf dorthin, wo Teams ohnehin prüfen: in den Pull Request.
Der Ablauf
- Du schreibst ein Issue – im Format der vorigen Station.
- Du weist es einem Agenten zu.
- Der Agent arbeitet in einer eigenen Umgebung auf einem eigenen Branch.
- Er öffnet einen Pull Request und bittet dich um Prüfung.
- Du kommentierst, er überarbeitet.
- Du gibst frei und übernimmst.
Was GitHub heute anbietet
Copilot nimmt Issues direkt an: Die Zuweisung öffnet immer einen Pull Request, und der Agent fordert nach getaner Arbeit deine Prüfung an. Wichtig für die Praxis: Er kennt das Issue im Stand der Zuweisung. Was du später im Issue ergänzt, sieht er nicht – Nachträge gehören in den Pull Request. Aufgabe an Copilot übergeben
Agenten anderer Anbieter lassen sich ebenfalls auf GitHub starten. Die Dokumentation nennt Anthropic Claude und OpenAI Codex, beide als öffentliche Vorschau für bezahlte Copilot-Tarife. Sie müssen zuerst in den Konto- oder Organisationseinstellungen freigeschaltet werden und lassen sich dann auf drei Wegen anstoßen: im Reiter „Agents“ des Repositories, durch Zuweisung eines Issues oder durch eine Erwähnung in einem Pull-Request-Kommentar. Agenten von Drittanbietern
Zwei Dinge aus derselben Dokumentation gehören in deine Planung: Der erzeugte Code wird vor Abschluss des Pull Requests automatisch auf Sicherheitsprobleme geprüft – Code-Scanning, Suche nach Geheimnissen, Abgleich neuer Abhängigkeiten. Und jede Sitzung verbraucht GitHub-Actions-Minuten und KI-Guthaben; was über das Inklusivvolumen hinausgeht, kostet extra.
Die eigentliche Sicherung: der geschützte Hauptzweig
Die automatische Prüfung ersetzt deine nicht. Was wirklich verhindert, dass ungeprüfter Code live geht, ist der Schutz des Hauptzweigs. In den Einstellungen des Repositories legst du fest:
- Pull Request ist Pflicht. Niemand schreibt direkt auf
main. - Prüfungen müssen bestanden sein. Build und Tests als erforderlicher Check.
- Kein Force-Push, kein Löschen.
Damit kann ein Agent beliebig viel vorschlagen, aber nichts
durchdrücken. Prüf die Einstellung einmal von außen: Versuch, direkt auf
main zu pushen. Wird der Versuch abgelehnt, hält der Schutz.
Prüfen in drei Durchgängen
1. Die Beschreibung. Passt sie zum Issue? Steht dort, was getan und was bewusst nicht getan wurde? Ein Pull Request, der mehr behauptet, als das Issue verlangte, verdient Misstrauen.
2. Der Diff. Jede geänderte Datei, nicht nur die erwarteten. Achte auf vier Dinge:
- Geänderte oder gelöschte Tests. Wurde ein Test angepasst, damit er besteht?
- Neue Abhängigkeiten. Jedes zusätzliche Paket ist fremder Code in deinem Projekt.
- Änderungen außerhalb des Auftrags. Umformatierte Dateien, „nebenbei“ aufgeräumte Funktionen.
- Konfiguration und Rechte. Alles, was Zugriffe, Geheimnisse oder den Deploy betrifft.
3. Die Checks. Grün heißt: Die vorhandenen Tests bestehen. Es heißt nicht, dass die Änderung richtig ist. Fehlt für das neue Verhalten ein Test, ist der grüne Haken wertlos.
Nachbessern per Kommentar
Schreib Änderungswünsche als Kommentar in den Pull Request, so konkret wie ein Auftrag: Datei, gewünschtes Verhalten, Abnahme. Der Agent überarbeitet auf demselben Branch.
Nach der zweiten Runde ohne Fortschritt gilt dieselbe Regel wie lokal: Pull Request schließen, Issue schärfen, neu zuweisen.
Was du nie tust
Einen Pull Request freigeben, den du nicht gelesen hast. Die Freigabe ist deine Unterschrift – nach ihr ist es dein Code, egal wer ihn geschrieben hat.