Bei einem meiner letzten Agentenläufe endete der Dokumentationscheck mit Exit-Code 0. Alle lokalen Links funktionierten. Der Agent hatte seinen Teil erledigt.

Ich war jedoch noch nicht fertig. Erst nachdem der übertragene Commit zum Remote-Branch passte und sieben öffentlich erreichbare Dateien denselben Hash wie meine lokalen Fassungen hatten, konnte ich „veröffentlicht“ statt „vorbereitet“ schreiben.

Bei Codeänderungen mache ich inzwischen dieselbe Trennung. Ich gehe durch den Diff, prüfe Datenwege und Berechtigungen, suche neue Abhängigkeiten und lese nach, was der Agent tatsächlich getestet hat. Sein Tempo hilft mir nur bei Änderungen, die ich nachvollziehen, prüfen und später noch warten kann.

Der Status „done“ gehört dem Agenten

Ein Agent kennt seinen Auftrag, den bereitgestellten Kontext und die Rückmeldungen seiner Werkzeuge. Daraus kann er ableiten, dass ein Patch geschrieben wurde und ein Testprozess mit Exit-Code 0 endete. Das ist Evidenz für die Fertigstellung. Für eine Abnahme reicht mir das jedoch nicht.

Ein Test kann grün sein, obwohl er nur den Happy Path abdeckt. Eine neue Bibliothek kann das Problem lösen und gleichzeitig zusätzliche Wartung mitbringen. Eine kleine Änderung an einem Parser kann später Daten aus einer Quelle akzeptieren, die beim Test nie vorkam. Bei Authentisierung und Autorisierung reicht ein funktionierender Zugriff nicht aus. Idealerweise zeigt der Test auch, was abgewiesen wird.

Der Agent kann diese Fragen vorbereiten, indem er negative Tests ergänzt, Datenflüsse beschreibt und seine Unsicherheit notiert. Die Verantwortung für den Merge bleibt trotzdem bei der Person, die mit den Folgen leben muss.

In meinen lokalen Workflows trenne ich deshalb Erzeugung und Abnahme. „Done“ bedeutet zunächst, dass der Agent sein Ergebnis zur Prüfung abgelegt hat. Der Auftrag ist erst abgeschlossen, wenn die reale Änderung und ihre Wirkung geprüft wurden.

Review wird zur knappen Ressource

Ein im Juli 2026 veröffentlichter Preprint hat 25.264 agentische Pull Requests aus 2.361 populären GitHub-Repositories untersucht. Der Median lag während des dreimonatigen Beobachtungszeitraums bei ein bis zwei agentischen Pull Requests pro Repository. Intensive Nutzung konzentrierte sich auf einen kleinen Teil der Projekte.

Mich interessiert daran vor allem das Aufsichtsmodell. Meist prüfte oder veränderte eine einzelne Person den Agentenbeitrag. Mehrere Menschen arbeiteten deutlich seltener gemeinsam an derselben agentischen Änderung.

Der Preprint misst frühe Adoption und sichtbare Zusammenarbeit auf GitHub. Er misst keine langfristige Codequalität und keine späteren Sicherheitsvorfälle. Für mich passt dazu trotzdem die Security-Baseline „Trust but verify“. Ein Modell kann mehrere Änderungen vorbereiten, während Aufmerksamkeit, Architekturwissen und Verantwortung bei wenigen Menschen bleiben.

Darum lasse ich in einem Arbeitsstrang nicht beliebig viele Agentenänderungen auflaufen. Eine offene Prüfung wird nicht dadurch kleiner, dass schon der nächste Patch danebenliegt. Mehr parallele Erzeugung kann den Rückstand sogar verdecken, weil jedes einzelne Ergebnis ordentlich aussieht.

Grün ist nur die Farbe der vorhandenen Tests

Der Benchmark SUSVIBES trennt funktionale und sicherheitsbezogene Tests. Er enthält 200 Aufgaben aus 108 Open-Source-Projekten und deckt 77 CWE-Klassen ab. Die Aufgaben beruhen auf Änderungen, bei denen in realen Projekten bereits Schwachstellen entstanden waren.

Bei einer im Paper untersuchten Kombination aus SWE-Agent und Claude 4 Sonnet waren 61 Prozent der Lösungen funktional korrekt. Nur 10,5 Prozent bestanden zugleich die Sicherheitsprüfung.

Diese Zahlen gelten für diesen Benchmark und diese Kombination. Sie sind keine allgemeine Fehlerquote für Coding-Agenten. Der Datensatz sucht bewusst in schwierigen, sicherheitsrelevanten Aufgaben. Als Produktionsprognose wäre er ungeeignet.

Für meine Arbeit bleibt eine nüchterne Konsequenz. Ein funktionaler Test beantwortet die Frage, die in diesem Test steht. Er prüft keine Tenant-Grenze, wenn dafür kein negativer Fall existiert. Er findet keine unzulässige Dateioperation, wenn nur der erfolgreiche Schreibvorgang getestet wird. Und er schützt kein Secret, das im Testaufbau gar nicht vorkommt.

Bei Änderungen an Authentisierung, Parsern, Dateioperationen, Abhängigkeiten und produktiven Datenwegen verlange ich deshalb stärkere Evidenz. Dazu gehören negative Tests, ein Blick auf neue Vertrauensgrenzen und eine zweite Prüfung, die nicht vom selben Agentenlauf abhängt.

Ich begrenze die Arbeit vor der Erzeugung

In meinem lokalen Agenten-Setup bekommt eine Änderung zuerst einen klaren Wirkungsrahmen. Der Auftrag benennt das Ziel, die betroffenen Dateien oder Komponenten und die Nachweise, die vor einer Abnahme vorliegen müssen.

Sobald Secrets, Berechtigungen, externe Empfänger, produktive Daten oder irreversible Aktionen berührt werden, steigt die Risikoklasse. Der Agent darf dafür weiterhin einen Patch vorschlagen. Die Freigabe und die technische Wirkung bleiben getrennt.

Mein Prüfpaket ist bewusst klein:

beabsichtigte Änderung
betroffene Dateien und Datenwege
ausgeführte Tests und negative Fälle
neue Abhängigkeiten
offene Unsicherheiten
Rollback oder Rückweg

Fehlt ein Punkt, ist die Änderung nicht automatisch schlecht. Sie ist nur noch nicht bereit für den nächsten Übergang.

Wenn die Prüfung länger dauert als erwartet, starte ich nicht einfach weitere Agenten, um den Durchsatz hochzuhalten. Das würde den Engpass verstecken. Ich verkleinere den Patch, ergänze die fehlende Evidenz oder verwerfe die Änderung.

NIST beschreibt im Secure Software Development Framework denselben Grundgedanken ohne speziellen Coding-Agenten-Prozess. Integrität, Provenienz, Review und reproduzierbare Sicherheitsprüfungen gehören in den Entwicklungsablauf. Ein Agent verändert die Geschwindigkeit dieses Ablaufs. Er hebt die Anforderungen nicht auf.

Kurz gesagt

Coding-Agenten verkürzen den Weg zu einem plausiblen Patch. Für einen verantwortbaren Merge brauche ich weiterhin Verständnis, passende Tests und einen benannten Owner. Ich nehme lieber weniger Änderungen ab, für die ich einstehen kann, als einen wachsenden Stapel grüner Ergebnisse mit ungeklärter Wirkung.

Quellen

Gregor Lyttek ist Security Architect & AI Strategist und Threat Hunter im Versicherungsumfeld.

lyttek.org · gregor@lyttek.org