Einen Coding-Agenten in CI einzusetzen ist ein Berechtigungs-Design-Problem im Kostüm der Produktivität. Die Mechanik ist Nachmittagsarbeit: Der Headless-Modus ist seit Claude Code 2.0 im September 2025 verfügbar, und anthropics/claude-code-action@v1 verpackt das Ganze in eine GitHub Action. Du kannst noch vor dem Mittagessen einen Agenten haben, der Pull Requests kommentiert. Ob er auch Commits pushen sollte, ist eine andere Frage, und es ist die einzige, die zählt.

Die Regel, die das sicher hält, ist einfach: ein Agent in CI schlägt vor, er merged nicht. Jedes der folgenden Muster ist nur eine Variation davon, wo genau du diese Linie ziehst.

Headless-Modus, kurz erklärt

Das Flag -p (oder --print) schaltet Claude Code aus dem interaktiven REPL in einen einzelnen Batch-Aufruf um, was es überhaupt erst skriptfähig macht. Die Flags, die daraus mehr als eine Demo machen, nämlich etwas, das du unbeaufsichtigt laufen lassen kannst, sind die einschränkenden:

claude -p "Fix the failing unit tests. Do not change public APIs." \
  --output-format json \
  --max-turns 8 \
  --allowedTools "Read,Edit,Bash(npm test)" \
  --model claude-haiku-4-5

Jedes davon leistet echte Arbeit. --output-format json liefert ein Objekt mit result, model, usage und stop_reason, sodass deine Pipeline anhand des Ergebnisses verzweigen kann, statt Fließtext zu grep-en. --max-turns ist deine Sicherung. --allowedTools ist die Allowlist, und es ist das mit Abstand wichtigste Flag in der Zeile.

Die drei Muster, in aufsteigender Reihenfolge des Wagemuts

Teams landen an einem von drei Punkten. Die sind nicht gleichwertig, und die meisten Teams sollten beim zweiten haltmachen.

  • Beratend. Der Agent liest den Diff und kommentiert. Er hat auf nichts Schreibzugriff. Jeder Fund kostet einen Menschen dreißig Sekunden, um ihn anzunehmen oder abzulehnen. Hier fängt man an, und für viele Teams ist es auch der Punkt, an dem man bleibt.
  • Vorschlagend. Der Agent behebt etwas und öffnet einen Pull Request gegen den Branch. Er schreibt Code, aber der Merge-Button bleibt menschlich. Das Review-Gate, dem du ohnehin schon vertraust, leistet genau die Arbeit, für die es gebaut wurde. Das ist der Sweet Spot.
  • Autonom. Der Agent committet auf einen Branch, der deployt wird. Das ist das Muster, das man gerne demonstriert, und dasjenige, das Incidents produziert, weil CI der einzige Ort in deinem Stack ist, an dem ein fehlerhafter Akteur ohne Menschen im Loop zu einem deployten Artefakt wird.

Beachte, was sich zwischen ihnen ändert: nicht die Fähigkeit des Agenten, nur der Blast Radius eines Fehlers. Die Wahrscheinlichkeit, dass der Agent falschliegt, ist in allen drei Fällen gleich. Der Unterschied liegt darin, was danach passiert.

Der Fehlermodus, den niemand einplant

Die naheliegende Sorge ist, dass der Agent schlechten Code schreibt. Das ist abgedeckt: Deine Tests und deine Reviewer fangen schlechten Code ab, genau dafür sind sie da.

Der eigentliche Fehler ist subtiler. Ein Agent, dem gesagt wird, er solle den Build grün machen, hat genau ein Ziel, und es gibt mehr als einen Weg dorthin. Die fehlschlagende Assertion zu löschen macht den Build grün. skip zum Test hinzuzufügen macht den Build grün. Einen Typ auf any zu erweitern lässt den Typfehler verschwinden. Keins davon ist eine Fehlfunktion des Agenten. Der Agent tut genau das, worum du gebeten hast, nur nicht so, wie du es gemeint hast, weil deine Anweisung das Symptom beschrieben hat und nicht das Ziel.

Zwei Dinge helfen. Formuliere das Ziel als Einschränkung, nicht als Vorgabe: "Repariere die Implementierung so, dass die bestehenden Tests bestehen, ohne Testdateien zu ändern" ist eine andere Anweisung als "repariere den Build". Und erzwinge es strukturell, statt dem Fließtext zu vertrauen, denn Fließtext ist eine Bitte und eine Tool-Allowlist ist eine Regel.

Leitplanken, die wirklich tragen

  • Begrenze die Tool-Allowlist auf die Aufgabe. Ein Agent, der Tests repariert, muss Dateien lesen, Quellcode bearbeiten und den Testbefehl ausführen können. Er braucht keinen Netzwerkzugriff, er muss nicht an die CI-Konfiguration ran, und er braucht nicht die Deploy-Credentials, die zufällig in der Umgebung des Runners liegen.
  • Schütze die Dateien, die Korrektheit definieren. Tests, Lockfiles, CI-Workflows und IAM-Policies gehören auf eine Pfad-Denylist. Wenn der Agent den Test nicht bearbeiten kann, kann er ihn auch nicht löschen, um ihn zu bestehen.
  • Begrenze Turns und Tokens. Eine Schleife, die nicht konvergieren kann, sollte anhalten und das auch sagen. Ein unbegrenzter Agent, der sich an einer unlösbaren Aufgabe abarbeitet, ist eine Rechnung und eine Warteschlange festhängender Jobs.
  • Gib dem Runner eine eigene Identität. Nicht eine breite Admin-Rolle, die zufällig verfügbar ist. Der Job des Agenten läuft mit einer eng begrenzten Rolle, die genau die Berechtigungen dieser einen Aufgabe hat, damit ein verwirrter Agent nicht nach etwas greifen kann, das er nie haben sollte.
  • Behandle Agenten-Commits als nicht vertrauenswürdigen Input. Dieselben Pflichtprüfungen, dasselbe Review, derselbe Branch-Schutz wie bei jedem anderen Contributor. Der Agent bekommt keinen Fast Path, denn der Fast Path ist die Schwachstelle.
  • Protokolliere die ganze Session. Wenn eine vom Agenten verfasste Änderung um drei Uhr morgens einen Incident auslöst, braucht die Frage "was wurde ihm gesagt und was hat er getan" eine Antwort, die kein Achselzucken ist. Der JSON-Output plus das Session-Transkript sind dein Audit Trail. Bewahre ihn auf.

Die Wirtschaftlichkeit stimmt tatsächlich

Man sollte der Idee gerecht werden: Die Zahlen sprechen dafür. Ein automatisierter Review-Durchlauf über einen mittelgroßen Diff kostet ein paar Cent und ist in unter einer Minute fertig. Verglichen mit den Kosten eines Kontextwechsels beim Reviewer geht diese Rechnung bei fast jedem Pull-Request-Volumen auf, und genau deshalb verbreitet sich das Muster.

Das ist zugleich die Falle. Billig genug, um bei jedem PR zu laufen, heißt auch billig genug, um es ohne Nachdenken zu tun, und die Grenzkosten, eine weitere Berechtigung zur Allowlist hinzuzufügen, sind in dem Moment, in dem du sie hinzufügst, immer null. Die Kosten kommen später, auf einen Schlag. Entscheide die Grenze, solange sie noch theoretisch ist.

Das Fazit

Ein Agent in deiner Pipeline ist ein Contributor ohne Urteilsvermögen, mit unendlicher Geduld und mit genau den Credentials, die du dem Runner gegeben hast. Gib ihm die schmalen Werkzeuge für eine Aufgabe, schütze die Dateien, die festlegen, was korrekt bedeutet, begrenze die Schleife, und lass ihn wie jeden anderen einen Pull Request öffnen. Die Produktivität ist real. Sie kommt daher, dass der Agent den mühsamen ersten Durchgang übernimmt, nicht daher, dass der Mensch wegfällt, der Ja sagt.

Weiterlesen

Für die Pipeline-Seite davon: warum automatisierte Tests in deiner CI/CD-Pipeline unverzichtbar sind beschreibt die Prüfungen, die der Output eines Agenten bestehen muss, drüben auf ercan.cloud. Der Hub ist auf ercanermis.com.