Guardrails für Coding-Agenten: nie der eigene Prüfer

Ein Coding-Agent darf seine eigene Arbeit nicht abnehmen. Die Prüfung gehört in eine Instanz, die er nicht steuert: deterministische Gates in der CI und ein Mensch, der bei Eingriffen in bestehenden Code das ganze Diff liest. Wie tief geprüft wird, bestimmt der Aufgabentyp, nicht der Confidence-Wert des Agenten.

Robert Pupel hat in KI schreibt den Code. Wer schreibt die Architektur? drei Regeln formuliert, die bei uns gelten. Dieser Beitrag beschreibt die Mechanik darunter: welche Gates in der Pipeline stehen, was sie auslöst und wo ein Mensch nicht ersetzbar ist. Guardrails für Coding-Agenten sind kein Prozessdokument, sondern Code im Repository.

Drei Quellen, die unabhängig zum selben Schluss kommen

Forschung, Beratung und Praxis kamen 2026 aus verschiedenen Richtungen zur selben Regel: Ein Agent darf nicht sein eigener Prüfer sein.

Der Thoughtworks Technology Radar Vol. 34 vom April 2026 führt „Putting coding agents on a leash” als eines von vier Themen. Die Begründung dort: Weil Agenten bessere Ergebnisse liefern, steigen Menschen zunehmend aus der Schleife aus, und Teams beginnen deshalb, in Harnesses zu investieren. Thoughtworks ist eine Beratungsfirma, die KI-Transformationsprojekte verkauft, und deklariert den Radar selbst als Praktikermeinung, nicht als Empirie.

Octomind, Anbieter eines Testwerkzeugs, hat im August 2026 die Selbstverifikation aus dem eigenen Agenten entfernt. Der Satz aus dem Release, der das Problem präzise trifft: „a model that wants to be done has a way to look done: advance the checklist, mark tasks complete, close the plan.” Ein externer Plan-Manager besitzt seither den Fortschritt, der Agent hat auf das Werkzeug keinen Zugriff mehr. Das ist eine Selbstauskunft eines Anbieters, aber eine mit nachvollziehbarer Mechanik.

Die dritte Quelle ist die interessanteste, weil sie zählbar ist.

Was 932’791 agentenerzeugte Pull Requests zeigen

Seit Februar 2026 existiert eine belastbare Datenbasis für Aussagen über Coding-Agenten. Der Datensatz AIDev (Li, Zhang, Hassan, arXiv:2602.09185) sammelt 932’791 agentenerzeugte Pull Requests aus 116’211 Repositories von 72’189 Entwickelnden, erzeugt von fünf Agenten: OpenAI Codex, Devin, GitHub Copilot, Cursor und Claude Code. Offen, akademisch, ohne ausgewiesene Anbieterfinanzierung.

Darauf aufbauend haben Ferdous, Banik, Chowdhury und Shamim 7’191 agentenerzeugte gegen 1’402 menschliche Pull Requests aus Python-Repositories verglichen und Breaking Changes über eine AST-Analyse erkannt (arXiv:2603.27524, eingereicht am 29.03.2026). Das Ergebnis ist kontraintuitiv:

Auf der grünen Wiese brechen Agenten die Kompatibilität also seltener als Menschen. Sobald sie bestehenden Code anfassen, kehrt sich das Bild um. Genau umgekehrt zu dem, was die meisten Teams intuitiv absichern.

Die Confidence Trap: warum der Selbstvertrauens-Wert als Filter ausfällt

Ein hoher Confidence-Wert des Agenten sagt nichts darüber, ob der Pull Request kompatibel bleibt. Dieselbe Arbeit von Ferdous et al. benennt das als „Confidence Trap”: Pull Requests mit hohem Selbstvertrauens-Wert enthalten trotzdem Breaking Changes. Die Autoren leiten daraus wörtlich die Notwendigkeit strengerer Prüfung bei Wartungsarbeiten ab, „regardless of reported confidence score”.

Das ist die praktisch wichtigste Zahl des Jahres, weil sie einen verbreiteten Kurzschluss zerstört. Wer Merge-Gates an einer Selbsteinschätzung aufhängt, hat den Agenten zum Prüfer seiner selbst gemacht, nur mit mehr Schritten.

Wenn Sie gerade einen Agenten auf ein bestehendes Go-Backend loslassen und nicht sicher sind, welche Gates dafür stehen müssen: Das ist ein 30-Minuten-Gespräch, kein Projekt. Wir schauen uns die Pipeline an, die Sie haben, und sagen, was fehlt.

Review-Tiefe nach Aufgabentyp, nicht nach Confidence

Die Ableitung aus den Daten ist eine Matrix mit zwei Spuren. Sie ersetzt die Frage „wie sicher ist sich der Agent?” durch die Frage „was fasst dieser Pull Request an?”.

Die letzte Zeile ist kein Datenbefund, sondern Schweizer Recht. Art. 7 DSG verlangt Datenschutz durch Technik ab der Planung, Art. 2 DSV nennt Nachvollziehbarkeit als eines von vier Schutzzielen. Ein Merge, den niemand namentlich abgenommen hat, erfüllt das nicht. Was das für die Architektur bedeutet, steht in revDSG-konforme KI-Architektur.

Wie die zwei Spuren in einer CI-Pipeline aussehen

Die Zuordnung zur Spur muss deterministisch und ausserhalb der Reichweite des Agenten passieren. Sie darf nicht davon abhängen, wie der Agent seinen Pull Request betitelt.

Der Commit-Typ nach Conventional Commits ist ein brauchbarer Hinweis, aber kein Beleg: Den Titel schreibt der Agent. Das harte Kriterium liefert das Diff selbst. Gelöschte Zeilen bedeuten, dass bestehender Code angefasst wurde.

# .github/workflows/agent-gate.yml
name: agent-gate
on: pull_request

jobs:
  spur:
    runs-on: ubuntu-latest
    outputs:
      lane: ${{ steps.wahl.outputs.lane }}
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
      - id: wahl
        env:
          # Titel nie direkt in `run` interpolieren: Script Injection.
          TITEL: ${{ github.event.pull_request.title }}
          BASIS: ${{ github.event.pull_request.base.sha }}
        run: |
          case "$TITEL" in
            feat:*|"feat("*) LANE=neubau ;;
            *)               LANE=bestand ;;
          esac
          GEAENDERT=$(git diff --numstat "$BASIS"...HEAD | awk '$2 > 0' | wc -l)
          if [ "$GEAENDERT" -gt 0 ]; then LANE=bestand; fi
          echo "lane=$LANE" >> "$GITHUB_OUTPUT"

Unbekannt landet in der strengen Spur. Das ist der ganze Trick: Die Voreinstellung ist streng, nicht locker.

Zwei Gates, die im Go- und Kubernetes-Alltag tatsächlich greifen

Für die Spur Bestand braucht es Prüfungen, die Kompatibilitätsbrüche mechanisch sichtbar machen, statt sie einem Review zu überlassen.

Im Go-Modul erledigt das gorelease aus golang.org/x/exp/cmd/gorelease. Es vergleicht die öffentliche API des ausgecheckten Stands gegen eine Basisversion und beendet sich bei inkompatiblen Unterschieden ab Major-Version 1 mit einem Exit-Code ungleich null. Damit ist der AST-Befund der Studie exakt das, was das Gate misst.

  api-vertrag:
    needs: spur
    if: needs.spur.outputs.lane == 'bestand'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
      - uses: actions/setup-go@v7
        with:
          go-version-file: go.mod
      - run: go install golang.org/x/exp/cmd/gorelease@latest
      - run: gorelease -base=latest

Auf der Kubernetes-Seite ist das Äquivalent der gerenderte Manifest-Diff. Nicht das Chart vergleichen, sondern das Ergebnis: Ein Agent, der einen Wert umbenennt, hinterlässt im Chart eine harmlose Zeile und im Deployment eine fehlende Umgebungsvariable.

# Rendert Basis und PR-Stand und vergleicht das Ergebnis, nicht die Quelle.
helm template svc ./chart > /tmp/neu.yaml
git worktree add /tmp/basis "$BASE_SHA"
helm template svc /tmp/basis/chart > /tmp/basis.yaml
diff -u /tmp/basis.yaml /tmp/neu.yaml

Was die Pipeline nicht abfangen kann

Statische Analyse allein ist kein Sicherheitsgate. Firouzi und Ghafari haben 1’080 LLM-erzeugte Codebeispiele gegen eine von Menschen validierte Referenz gehalten (arXiv:2602.05868, 05.02.2026): Nur 65 % der Semgrep- und 61 % der CodeQL-Befunde trafen die Referenz. Auf aggregierter Ebene sahen beide Werkzeuge plausibel aus, pro Beispiel wichen sie erheblich ab.

Der Bedarf ist da. Peng, Wang und Zhu fanden bei 3’700 Snippets aus dem LLMSecEval-Benchmark, dass 68,8 % mindestens eine Sicherheitsanforderung verletzten, bei hartkodierten Zugangsdaten 79,1 % (arXiv:2607.12089). Ma et al. berichten über acht Modelle hinweg durchschnittliche Verwundbarkeitsraten über 56 % (arXiv:2607.23088, Poster). Die absoluten Werte sind zwischen den Arbeiten nicht vergleichbar, die Richtung ist über ein Dutzend unabhängiger Arbeiten hinweg konsistent.

Was messbar wirkt, ist nachgelagerte Reparatur statt besserer Prompts: Sriram, Pradhan und Saha kombinierten Compiler-Diagnostik, CodeQL und symbolische Ausführung und senkten die Sicherheitsdefekte von CodeLlama 7B in C-Code von 49 % auf 19 % (arXiv:2607.21641). Ein Reparaturlauf gehört also in die Pipeline, ein Freibrief daraus nicht.

Planung und Ausführung trennen

Der Plan muss vor dem Code stehen und von einem Menschen abgenommen sein. Boris Tane beschreibt das als das am häufigsten geteilte Arbeitsmuster überhaupt: „The separation of planning and execution is the single most important thing I do”, und daraus folgend „never let Claude write code until you’ve reviewed and approved a written plan” (boristane.com, Februar 2026).

Das ist die Schnittstelle zwischen dem Agenten und Ihrem Team. Ein abgenommener Plan ist prüfbar, ein fertiges Diff von 2’000 Zeilen nicht mehr. Wo der Plan eine Architekturentscheidung enthält, gehört er ohnehin ins Repository, siehe Entscheidungen, die man in zwei Jahren noch versteht.

Ein Wort zu Kontextdateien, weil hier viel Aufwand versickert: Gloaguen, Mündler, Müller, Raychev und Vechev von der ETH Zürich haben AGENTS.md-Dateien systematisch evaluiert (arXiv:2602.11988, revidiert am 23.06.2026). Befund: Kontextdateien verbessern die Erfolgsrate generell nicht und erhöhen die Inferenzkosten um über 20 %. Anweisungen werden befolgt, Repository-Übersichten bringen nichts. Schreiben Sie also Konventionen und Fallstricke hinein, keine Verzeichnisbäume.

Wovon wir abraten

Bauen Sie kein Merge-Gate, das nur wahr oder falsch kennt. Ein einzelner grüner Haken über allen Aufgabentypen ist entweder für den Neubau zu teuer oder für die Wartung zu billig, meistens beides.

Setzen Sie keinen zweiten Agenten als alleinigen Reviewer ein. Ein Review-Agent ist nützlich, um ein Diff zu strukturieren und Kandidaten zu markieren. Er ist kein Prüfer, weil er dieselben Fehlerklassen teilt wie der Agent, den er prüft, und weil die Kette dann wieder in einer Selbstauskunft endet.

Und der ehrliche Trade-off: Die lockere Spur beim Neubau lässt Fehler durch. Die 3,45 % sind besser als der menschliche Wert, aber sie sind nicht null. Wer diese Staffelung übernimmt, entscheidet sich bewusst dafür, Prüfaufwand dorthin zu verschieben, wo er statistisch mehr bringt. Für ein Team mit zwei Entwicklern und einem Prototypen lohnt sich der ganze Apparat nicht. Für ein Produkt mit externen API-Konsumenten und einem Cluster in Produktion schon.

Häufige Fragen

Warum sollen Agenten bei Wartung strenger geprüft werden als bei Neubau?

Weil die Daten es so zeigen. In der Vergleichsstudie von Ferdous et al. über 7’191 agentenerzeugte Pull Requests lag die Breaking-Change-Rate bei Neubau bei 3,45 %, bei Refactoring bei 6,72 % und bei Chore-Änderungen bei 9,35 %. Wartung setzt Kenntnis bestehender Verträge voraus, die im Kontextfenster oft nur teilweise vorliegen. Neubau definiert die Verträge selbst.

Kann ich den Confidence-Wert des Agenten als Merge-Kriterium nutzen?

Nein. Dieselbe Studie beschreibt eine „Confidence Trap”: Pull Requests mit hohem Selbstvertrauens-Wert enthalten trotzdem Breaking Changes. Der Wert ist eine Selbstauskunft des Systems, dessen Arbeit geprüft werden soll. Nutzen Sie stattdessen Kriterien, die der Agent nicht beeinflusst: Wurde bestehender Code geändert, bricht die öffentliche API, ändert sich das gerenderte Manifest.

Reicht ein Security-Scanner in der Pipeline als Gate?

Als alleiniges Gate nicht. Firouzi und Ghafari fanden auf 1’080 validierten Beispielen, dass nur 65 % der Semgrep- und 61 % der CodeQL-Befunde der menschlich validierten Referenz entsprachen. Scanner gehören in die Pipeline, ihre Befunde sind Hinweise. Wirksamer ist ein nachgelagerter Reparaturlauf, der Compiler-Diagnostik und statische Analyse zusammenführt und das Ergebnis erneut prüft.

Wie klassifiziere ich Pull Requests, wenn der Agent den Titel schreibt?

Über das Diff, nicht über den Titel. Ein Pull Request, der Zeilen löscht, hat bestehenden Code angefasst und gehört in die strenge Spur. git diff --numstat liefert das in einer Zeile. Der Commit-Typ nach Conventional Commits bleibt ein nützlicher Hinweis für Menschen, taugt aber nicht als Gate, weil ihn der Prüfling selbst setzt.

---

Ihre Pipeline durchgehen, nicht Ihre Strategie. 30 Minuten mit einem unserer Go-Engineers: welche Gates Sie heute haben, welche Aufgabentypen bei Ihnen ungeprüft durchlaufen und was sich davon in einer Woche nachrüsten lässt. Ohne Verkaufsgespräch.

Termin buchen · Kontakt aufnehmen · Wie wir KI-Systeme und Agenten-Infrastruktur bauen, steht unter Künstliche Intelligenz & Machine Learning.