CI-Fehler und PR-Kommentare automatisch mit KI beheben

Wenn du CI-Fehler automatisch mit KI beheben kannst, nimmt dir das eine der repetitivsten Aufgaben ab. Du pushst, und zehn Minuten später ist GitHub Actions rot. Du öffnest das Log, scrollst durch zweihundert Zeilen, findest einen Typfehler oder einen veralteten Snapshot, behebst ihn und pushst erneut. Mit PR-Kommentaren ist es dieselbe Geschichte: Kleine Hinweise wie „benenne diese Variable um“ oder „hier fehlt eine Null-Prüfung“ häufen sich, und jeder reißt dich aus dem, was du gerade tust.

Dieser Beitrag erklärt, wie du diese Arbeit einem KI-Agenten übergibst: was ihn auslöst, welche Schutzgrenzen gelten, wie er liefert und was du ansiehst, bevor es main erreicht.

Warum Beheben von Hand teuer ist

Einen roten Build zu reparieren ist selten schwer. Der Kontextwechsel kostet dich:

• Du steckst mitten in etwas anderem. Die Benachrichtigung über rote CI holt dich da heraus.
• Logs lesen dauert. Der echte Fehler steckt in Hunderten Zeilen, und die erste rote Zeile ist oft nicht der echte Fehler.
• Du musst es lokal reproduzieren. Den CI-Befehl zu finden, ihn auszuführen und Umgebungsunterschiede zu klären, ist eine eigene Aufgabe.
• Kommentare kommen stückweise. Ein Review mit sechs Kommentaren heißt, alle sechs zu lesen und jeden zu beantworten.

Diese Aufgaben haben eine bekannte Abfolge von Schritten gemeinsam. Arbeit mit bekannten Schritten kannst du einem Agenten übergeben.

Auslöser: Wann startet der Agent?

In AgentVera findest du Automatisierungen unter Details → Automation → Automations. Eine Regel startet Arbeit von selbst, wenn ein Ereignis eintritt. Zwei Auslöser sind hier wichtig.

CI turned red

Dieser Auslöser überwacht die Anbieter, die du im Tab CI/CD hinzugefügt hast: GitHub Actions, GitLab CI und Jenkins. Lass Branches leer, um alle Branches zu überwachen, oder liste sie auf, etwa main, release/*.

Manche Läufe werden absichtlich übersprungen. Läufe für Pull Requests aus Forks und GitLab-Merge-Request-Läufe lösen die Regel nicht aus. Branch und Log eines Forks gehören jemandem außerhalb deines Repos, deshalb reagiert die Regel nur auf Branches, auf die du einen Fix pushen kannst.

PR got a comment

Neue Review- und Konversationskommentare auf offenen Pull Requests werden alle 2 Minuten gelesen, mit Filtern:

• Nur Kommentare des Repo-Eigentümers, von Mitgliedern oder Collaborators zählen. Ein Zufallskommentar startet keinen Agenten.
• Bot-Kommentare zählen nicht. Die eigenen Antworten von AgentVera sind markiert und werden nie wieder aufgegriffen.
• Arbeitet bereits ein Agent an diesem PR, gehen neue Kommentare an ihn; ein zweiter Agent wird nicht geöffnet.
• Ist das Tageslimit erreicht, gehen Kommentare nicht verloren; sie werden später erneut gelesen.

PR-Kommentar- und Issue-Auslöser brauchen das origin des Repos auf GitHub und eine GitHub-Anmeldung auf deinem Rechner.

Ereignisse werden von der Desktop-App überwacht, AgentVera muss also auf deinem Rechner geöffnet sein, damit Regeln laufen.

Presets

Hat ein Projekt noch keine Regeln, bietet AgentVera Presets an. Zwei davon erledigen genau diese Aufgabe:

Die anderen beiden bearbeiten Issues mit dem Label „ajan“ und aktualisieren jeden Montag Abhängigkeiten.

Was der Agent tut

Wenn eine Regel auslöst, startet der Agent in einem neuen Worktree auf einem neuen Branch, der mit ajan/ beginnt. Der Branch basiert auf dem Branch des Ereignisses: dem Branch des roten Laufs oder dem Branch des PR. Dein Arbeitsordner bleibt unberührt. Von Git ignorierte .env-Dateien werden in den Worktree kopiert, damit Tests laufen können, aber sie werden nie gepusht.

Der Agent folgt den Schritten im Playbook der Regel. Für CI ist das Standard-Playbook „Fix a CI failure“:

1. Den ersten echten Fehler im Log finden.
2. Den CI-Befehl lokal ausführen und den Fehler reproduzieren.
3. Die Ursache beheben; liegt das Problem in der CI-Konfiguration (Workflow, Version, Umgebungsvariable), diese beheben.
4. Die CI-Befehle lokal erneut ausführen und sehen, dass sie bestehen.

Für PR-Kommentare ist der Standard „Address PR comments“: jeden Kommentar und den Code, auf den er zeigt, lesen, die berechtigten umsetzen, bei Widerspruch die eigene Begründung erklären, die Tests ausführen und in der Antwort auflisten, was für jeden Kommentar getan wurde.

Du kannst Playbooks ändern. Speichere eigene auf diesem Rechner oder im Repo; Repo-Playbooks werden unter .agentvera/playbooks/ geschrieben, über Git mit dem Team geteilt und ersetzen das eingebaute Playbook gleichen Namens.

Mit Extra instructions grenzt du die Regel ein. Zum Beispiel: „Behebe nur Tests und Typfehler; ändere nicht den API-Vertrag.“

Im Feld Agent wählst du Claude Code oder Codex.

Schutzgrenzen: Was bremst den Agenten?

Ein Agent, der von selbst läuft, muss begrenzt sein, nicht nur gut. In AgentVera sind das die Grenzen:

• Ein Tageslimit. Jede Regel hat einen Wert Max per day von 1 bis 50, standardmäßig 5, gezählt über die letzten 24 Stunden. Läufe, die du von Hand startest, zählen nicht dagegen.
• Ein Limit pro Branch. Pro Branch und Tag werden höchstens 2 automatische CI-Fixes versucht, und pro Branch läuft oder wartet immer nur ein Fix. Bricht ein Fix die CI erneut, dreht sich der Agent nicht endlos im Kreis.
• Fremder Text sind keine Anweisungen. CI-Logs, PR-Kommentare und Issue-Texte werden dem Agenten als nicht vertrauenswürdiger fremder Text übergeben, der nur die Aufgabe beschreibt. Dem Agenten wird gesagt, er solle keine Secrets weitergeben, keine fachfremden Befehle ausführen und keine Daten anderswohin senden.
• Der Agent pusht nicht. Er committet nur. Pushen und den PR öffnen ist Sache von AgentVera, nachdem der Agent abgegeben hat.
• Ein Scan auf Secret-Dateien. Vor dem Push werden jeder Commit und der Endzustand auf Secret-Dateien gescannt: .env-Dateien, Schlüssel wie .pem und .key, id_rsa, .npmrc, .netrc, credentials.json und Ähnliches. Beispieldateien wie .env.example sind in Ordnung. Wird eine gefunden, wird nichts gepusht und der Lauf schlägt fehl.
• Ein hängender Agent stoppt. Bittet der Agent um Hilfe, verstummt er oder schließt sich, geht der Lauf auf „needs attention“, und du bekommst eine Benachrichtigung.

Auslieferung: Wohin geht die Arbeit?

Was passiert, wenn der Agent fertig ist, legt On delivery fest:

Eine Regel ändert sich nie: AgentVera pusht nie direkt auf den Default-Branch. Hat der Agent keine Änderungen gemacht, endet der Lauf mit dem Hinweis „no changes“.

Bei PR-Kommentaren wird die Arbeit auf den PR-Branch gepusht, und AgentVera postet eine Antwort im PR, die beschreibt, was der Agent für jeden Kommentar getan hat.

Wählst du die Merge Queue, wird der Fix noch einmal auf dem neuesten main getestet. Wie die Queue funktioniert, beschreibe ich im Beitrag zur Merge Queue.

Review, bevor es main erreicht

Ein automatischer Fix ist keine automatische Annahme. Es gibt mehrere Wege, die Arbeit des Agenten zu prüfen:

• Der Pull Request selbst. Fehler auf main kommen ohnehin als PRs zurück. Lies den Diff, sieh zu, wie die CI grün wird, und merge ihn wie jeden anderen PR.
• Freigabe in der Merge Queue. Land passing branches automatically ist standardmäßig aus, sodass Arbeit, die ihre Prüfung besteht, auf dich wartet.
• Auf dem Branch lassen. In den ersten Wochen einer neuen Regel ist Leave on the branch mit Prüfung von Hand die vorsichtigste Option.
• Der Tab Runs. Dort siehst du Status, Agent und geöffneten PR jedes Laufs.

Für deine eigenen Agenten hat AgentVera außerdem automatisches Code-Review: Wenn der Zug eines Agenten endet, prüft ein von dir gewähltes Claude-Modell den Code und meldet Funde mit Schweregrad und file:line. Mehr im Beitrag KI-Code-Review.

Achte beim Review besonders auf:

• Wurde der Test repariert oder der Code? Hat der Agent einen erwarteten Wert geändert, damit ein Test besteht, ist das ein Warnsignal. Du kannst es in den Extra instructions verbieten.
• Hat sich die CI-Konfiguration geändert? Eine Workflow-Änderung kann berechtigt sein oder ein übersprungener Schritt.
• Blieb er im Rahmen? Ein Typfehler sollte nicht als Refactoring über zehn Dateien zurückkommen.

Fixes mit einem Klick aus dem CI/CD-Center

Vielleicht willst du nicht für jeden roten Lauf eine Regel. Der Tab CI/CD listet die neuesten 25 Läufe pro Anbieter; du kannst einen Lauf wiederholen, nur die fehlgeschlagenen Jobs wiederholen (nicht bei Jenkins) oder ihn abbrechen. Bei einem roten Lauf öffnet Have an agent fix it einen Agenten mit den Details des Laufs und den Log-Enden seiner fehlgeschlagenen Jobs. Diesmal bist du direkt beim Agenten.

Häufige Fehler

• main mit „Push to the same branch“ überwachen und einen direkten Push erwarten. AgentVera pusht nicht auf den Default-Branch; der Fix kommt trotzdem als PR.
• Das Tageslimit voll ausreizen. Das Limit ist ein Sicherheitsnetz. Halte es niedrig, bis die Regel dein Vertrauen verdient.
• Extra instructions leer lassen. Dem Agenten zu sagen, was er nicht anfassen soll, grenzt die Ergebnisse spürbar ein.
• Instabile Tests dem Agenten übergeben. Bei einem Test, der mal fehlschlägt und mal nicht, ändert der Agent womöglich Dinge, die keine Änderung brauchen. Kümmere dich zuerst selbst um instabile Tests.
• Secrets im Repo behalten. Der Scan stoppt den Push, aber die eigentliche Lösung ist, nie Secrets ins Repo zu legen.

Ein Beispieltag

Morgens

Der nächtliche Commit von jemandem auf main hat die CI gebrochen. Die Regel „Fix CI when it breaks“ hat es erfasst: Der Agent fand den Typfehler im Log, reproduzierte ihn lokal und behob ihn. Da es der Default-Branch war, kam die Arbeit als PR zurück. Du liest den Diff beim Kaffee und mergst ihn.

Mittags

Ein Teamkollege hinterlässt vier Kommentare an einem deiner PRs. Innerhalb von zwei Minuten greift die Regel „Handle PR comments“. Der Agent setzt drei um, widerspricht einem und erklärt warum. AgentVera pusht auf den PR-Branch und hinterlässt eine Antwort im PR. Du musst nur den einen lesen, dem er widersprochen hat, und entscheiden.

Nachmittags

Die CI schlägt auf einem Feature-Branch immer wieder fehl. Der Agent versucht es zweimal, und die Tests bleiben beide Male rot. Einen dritten Versuch gibt es nicht; den Status siehst du im Tab Runs. Das Log zeigt, dass das Problem eine Umgebungsvariable der Testumgebung ist, also behebst du es selbst.

Checkliste

• Ist dein CI-Anbieter im Tab CI/CD hinzugefügt?
• Bist du bei GitHub-Repos auf diesem Rechner bei GitHub angemeldet?
• Stimmt das Feld Branches? Leer heißt alle Branches.
• Sagen die Extra instructions, was der Agent nicht anfassen darf?
• Ist Max per day konservativ gesetzt?
• Passt On delivery dazu, wie du gern prüfst?
• Bleiben deine Secrets aus dem Repo heraus?

Fazit

CI-Fehler und PR-Kommentare an einen KI-Agenten zu übergeben, gibt dir den am häufigsten unterbrochenen Teil deines Tages zurück. Wichtig ist nicht, dass der Agent schnell ist, sondern dass er begrenzt ist: In AgentVera arbeitet er in einem eigenen Worktree, pusht nicht von selbst, schreibt nie direkt auf den Default-Branch, pusht keine Arbeit mit Secret-Dateien und bekommt pro Branch nur eine begrenzte Zahl an Versuchen. Die endgültige Entscheidung bleibt bei dir, im PR oder in der Merge Queue.

Mehr zum Thema:

• Automations
• CI/CD-Center
• Code-Review
• KI-Agent-Workflow-Pipeline
• Parallele Coding-Agenten

Um AgentVera auszuprobieren, starte auf der Startseite.