Warum ich AI-Agenten nicht mehr glaube, wenn sie sagen: „Alles ist grün“

Ein Coding Agent schreibt: „Alle Tests grün, Linter sauber, Review abgeschlossen.“ Das klingt beruhigend. Es ist aber zunächst nur eine Behauptung über einen Vorgang, den ich nicht gesehen habe.

Ich behandle solche Aussagen inzwischen wie den Statusbericht eines externen Dienstleisters: als Befund, nicht als Beweis.

Das ist keine grundsätzliche Skepsis gegenüber AI-Agenten. Agenten können Code sehr schnell ändern, Tests ausführen, Fehler eingrenzen und Reviews vorbereiten. Gerade deshalb müssen wir präziser werden: Je autonomer ein System arbeitet, desto wichtiger ist es, dass seine Aussagen an überprüfbare Artefakte gebunden sind.

Die entscheidende Frage lautet nicht: „Hat der Agent gesagt, dass alles grün ist?“ Sie lautet: Welcher konkrete Code-Stand wurde womit geprüft, unter welchen Bedingungen, und wo liegt das Ergebnis?

Ein Bericht beschreibt. Evidenz belegt.

Ein Agentenbericht kann nützlich sein. Er fasst zusammen, was der Agent getan haben will:

• Dateien geändert,
• Abhängigkeiten aktualisiert,
• Tests ausgeführt,
• Sicherheitsprobleme geprüft,
• einen Pull Request reviewed.

Das ist ein guter Einstieg für Menschen. Es reicht aber nicht für eine belastbare Freigabe.

Ein Beweis besteht aus Artefakten, die unabhängig vom Agenten überprüft werden können. Dazu gehören insbesondere:

• ein unveränderlicher Commit-SHA,
• der zugehörige Diff oder Pull Request,
• Ausgaben der ausgeführten Checks,
• Testreports und Coverage-Artefakte,
• Angaben zur Laufzeitumgebung,
• ein eindeutiger Exit-Code,
• gegebenenfalls ein Review-Kommentar mit Fundstellen.

Der Unterschied ist praktisch relevant. Der Satz „Unit Tests passed“ sagt nicht, ob Tests gegen den aktuellen Stand liefen, ob sie tatsächlich vollständig waren oder ob der Agent nach einem fehlgeschlagenen Lauf noch Änderungen vorgenommen hat. Ein CI-Lauf, der an Commit 8f3c… gebunden ist und einen maschinenlesbaren Testreport ablegt, beantwortet diese Fragen deutlich besser.

Der häufigste Fehler: Prüfung und Ergebnisstand entkoppeln

In Projekten mit Coding Agents sehe ich regelmäßig denselben Ablauf:

1. Der Agent ändert Code.
2. Der Agent führt Tests aus.
3. Ein Test schlägt fehl.
4. Der Agent korrigiert den Fehler.
5. Der Agent ändert noch eine Kleinigkeit.
6. Der Agent berichtet: „Tests erfolgreich.“

Möglicherweise stimmt das. Möglicherweise beziehen sich die erfolgreichen Tests aber auf Schritt 4 und nicht auf den finalen Stand aus Schritt 5.

Für Menschen passiert das ebenfalls. Bei Agenten wird es nur häufiger, weil sie schnell iterieren, mehrere Werkzeuge parallel nutzen und ihre Zusammenfassung den zeitlichen Ablauf stark verdichtet. Ein überzeugend formulierter Bericht verdeckt dann leicht, dass die Evidenzkette unterbrochen ist.

Die Mindestregel lautet daher:

Ein Prüfergebnis ist nur für genau den Commit gültig, auf dem der Check ausgeführt wurde.

Nicht für den Branch-Namen. Nicht für den Arbeitsordner. Nicht für „den aktuellen PR“. Sondern für einen konkreten, unveränderlichen SHA.

Die Evidenzkette für AI-gestützte Änderungen

Eine brauchbare Evidenzkette muss nicht kompliziert sein. Sie muss lückenlos sein. Für jede relevante Änderung sollte sie diese Verbindung herstellen:

Anforderung
  → Änderungssatz
  → Commit-SHA
  → reproduzierbarer Check
  → Ergebnisartefakt
  → Freigabeentscheidung

1. Änderungssatz eindeutig identifizieren

Der Agent arbeitet idealerweise in einem eigenen Branch oder Worktree. Am Ende steht ein Commit, nicht nur ein veränderter Arbeitsordner.

git status --short
git rev-parse HEAD
git show --stat --oneline HEAD

Der Bericht sollte den vollständigen SHA nennen und klar markieren, ob der Arbeitsbaum sauber war. Ein Test auf einem Working Tree mit uncommitted Änderungen ist nicht wertlos, aber schlechter nachvollziehbar. In einer Pipeline sollte er nicht die letzte Instanz sein.

2. Checks als ausführbare Definition festhalten

„Tests ausführen“ ist zu ungenau. Relevant ist der konkrete Befehl einschließlich Kontext:

pnpm install --frozen-lockfile
pnpm test -- --reporter=junit --outputFile=artifacts/junit.xml
pnpm lint
pnpm build

Für kritische Systeme gehören zusätzlich Versionen und Umgebungsdaten dazu:

node --version
pnpm --version
git rev-parse HEAD
sha256sum pnpm-lock.yaml

Das Ziel ist nicht, jede Shell-Ausgabe dauerhaft aufzubewahren. Das Ziel ist, einen Check mit vertretbarem Aufwand wiederholen zu können. Ohne feste Abhängigkeiten, bekannte Tool-Versionen und einen dokumentierten Aufruf ist ein „grüner“ Testlauf oft nur ein lokales Ereignis.

3. Maschinenlesbare Artefakte speichern

Ein grünes Häkchen in einer Chat-Antwort oder in einer Terminal-Zusammenfassung ist kein ausreichend gutes Artefakt. Besser sind Dateien, die Werkzeuge weiterverarbeiten können:

• JUnit XML oder vergleichbare Testreports,
• SARIF für SAST- und Security-Scanner,
• Coverage-Dateien,
• Build-Manifeste und Checksummen,
• Container-Image-Digests,
• Playwright-, Cypress- oder Screenshot-Artefakte für End-to-End-Tests.

Diese Artefakte sollten an den CI-Run und damit an den Commit gebunden sein. Ein Link auf „latest pipeline“ ist absichtlich bequem, aber für Audits und Fehleranalyse ungeeignet: „latest“ verändert sich.

4. Logs mit Kontext statt Log-Müll

Vollständige Logs sind hilfreich, aber nicht automatisch gute Evidenz. Ein Log ohne SHA, Startzeit, Command und Exit-Code beweist wenig. Umgekehrt muss ein Report nicht mehrere Megabyte Terminal-Ausgabe zitieren.

Ein kompakter Agentenbericht kann etwa so aussehen:

Geprüfter Stand: 8f3c9d1e0b7a…
Arbeitsbaum: clean
CI-Run: https://ci.example/runs/4812
 
Ausgeführt:
- pnpm test: Exit 0, 428 Tests, junit.xml
- pnpm lint: Exit 0
- pnpm build: Exit 0
- SAST: 0 neue Findings, report.sarif
 
Nicht geprüft:
- Lasttest
- Browser-Matrix außerhalb Chromium

Das ist wesentlich wertvoller als „Alles ist grün“, weil es den Umfang sichtbar macht. Vor allem der letzte Block verhindert eine gefährliche Fehlinterpretation: Grün bedeutet immer nur grün innerhalb eines definierten Prüfrahmens.

Reviews brauchen Fundstellen, keine Vertrauensformeln

Auch AI-Reviews werden oft zu großzügig gelesen. „No issues found“ kann bedeuten, dass der Agent den Diff sorgfältig analysiert hat. Es kann aber ebenso bedeuten, dass ihm die Architekturregeln unbekannt waren, das relevante Laufzeitverhalten nicht rekonstruierbar war oder der Kontext zu groß wurde.

Ein brauchbares Review liefert deshalb mindestens:

• den geprüften Commit oder Diff-Bereich,
• die verwendete Review-Checkliste oder Policy,
• konkrete Findings mit Datei und Zeile,
• ausdrücklich benannte Grenzen der Prüfung.

Bei einer Freigabe ist eine knappe Begründung sinnvoll: „Keine Änderung an Authentifizierung, Datenmodell oder Berechtigungsprüfung; API-Vertrag durch Contract-Test abgedeckt.“ Das ist keine Formalität. Es macht nachvollziehbar, warum die Tiefe des Reviews zur Risikoklasse der Änderung passt.

Für kritische Bereiche sollte ein Agent keine finale Freigabe erteilen. Er kann Evidenz sammeln, Findings priorisieren und einen menschlichen Review effizienter machen. Die Verantwortlichkeit für die Entscheidung bleibt jedoch bei einer benannten Person oder Rolle.

Governance heißt: Aussagen mit Kontrollpunkten verbinden

AI Governance wird häufig als Sammlung von Richtlinien formuliert: zulässige Tools, Datenklassifikation, Prompt-Regeln, Freigaben. Das ist notwendig, aber unvollständig.

Für Coding Agents braucht Governance auch technische Kontrollpunkte. Sonst bleibt sie vom guten Willen und von der Selbstbeschreibung des Agenten abhängig.

Praktische Kontrollen sind zum Beispiel:

• Branch Protection mit verpflichtenden CI-Checks,
• CI-Ausführung auf dem gepushten Commit, nicht auf einem lokalen Agenten-Report,
• signierte Commits oder attestierte Build-Provenance, wenn das Risikoprofil es verlangt,
• getrennte Berechtigungen für Code-Änderung, Deployment und Secret-Zugriff,
• verpflichtende Artefaktaufbewahrung für regulierte oder sicherheitskritische Änderungen,
• Policy-as-Code für Mindestchecks je Repository oder Risikoklasse.

Wichtig ist dabei die Reihenfolge: Der Agent darf einen Check anstoßen und dessen Ergebnis zusammenfassen. Die Pipeline muss unabhängig bestätigen, dass der relevante Check auf dem richtigen Stand erfolgreich war.

Ein kleines, wirksames Betriebsmodell

Teams müssen nicht mit einer vollständigen Compliance-Plattform anfangen. Für die meisten Produktteams reichen zunächst vier Regeln:

1. Kein Merge ohne SHA-gebundene CI. Ein Agentenbericht ersetzt keinen Pipeline-Status.
2. Keine Aussage ohne Umfang. „Tests grün“ wird ergänzt um Testart, Anzahl, Befehl und nicht geprüfte Bereiche.
3. Keine Review-Freigabe ohne Diff-Bezug. Reviews nennen Commit, PR oder Vergleichsbereich.
4. Keine kritische Entscheidung ohne menschliche Verantwortung. Das gilt besonders für Security, Datenschutz, Berechtigungen, Zahlungen und Produktionszugriffe.

Diese Regeln erzeugen kaum zusätzliche Bürokratie, wenn sie in Templates und Pipelines eingebaut werden. Der entscheidende Schritt ist kulturell: Agentenberichte werden nicht als Autorität behandelt, sondern als Navigation zu überprüfbarer Evidenz.

Was „grün“ dann tatsächlich bedeutet

Ein gutes Ergebnis lautet nicht mehr einfach „Alles ist grün“. Es lautet beispielsweise:

Der Commit 8f3c9d1e… wurde in CI unter Node 22.4.1 gebaut. Unit-, Integrations- und Lint-Checks sind erfolgreich. Die Reports liegen im CI-Run 4812. Nicht Bestandteil der Prüfung waren Lasttest und Safari. Der PR benötigt wegen einer Änderung an der Rollenprüfung noch menschliches Security-Review.

Das ist weniger elegant als eine Erfolgsmeldung. Aber es ist belastbar.

AI-Agenten werden in der Softwareentwicklung bleiben und immer mehr Arbeitsschritte übernehmen. Die richtige Reaktion ist nicht, ihren Berichten grundsätzlich zu misstrauen. Die richtige Reaktion ist, ihnen den Platz zu geben, den sie verdienen: als nützliche Zusammenfassung einer Arbeit, deren Qualität durch nachvollziehbare Artefakte belegt wird.

Ein Agent kann sagen, dass alles grün ist. Vertrauen sollte erst entstehen, wenn ich sehen kann: welcher Stand, welcher Check, welches Ergebnis, welche Grenze.