KOMMENTAR VON ANDRÉ M. BRAUN, GITLAB ARBEITSABLÄUFE WERDEN MIT AGENTISCHEN
DEV-TOOLS WENIGER NACHVOLLZIEHBAR
24.07.2026 Von André M. Braun 5 min Lesedauer
Anbieter zum Thema
Vor Kurzem habe ich mit einer Führungskraft aus dem Engineering Team eines
großen Finanzinstituts zusammengearbeitet, um die
DevSecOps-Plattform-Engineering-Roadmap des Teams zu prüfen. Das Team hatte
einen KI-Coding-Agenten in den Entwicklungs-Workflow eingebunden. Merge Requests
(MRs) wurden geöffnet, Pipelines liefen und Velocity-Metriken entwickelten sich
in die richtige Richtung.
Dann stellte das interne Audit- und Compliance-Team einige eigentlich einfache
Fragen. Es ging um einen bestimmten, vom Agenten geöffneten MR, der eine
Abhängigkeit in einem Payment-Service aktualisierte. Wer hat die Änderung
genehmigt, welche Eingaben und Prompts hat der Agent verwendet, welche
Policy-Checks wurden zum MR-Zeitpunkt ausgewertet, und wie ließe sich diese
exakte Arbeitseinheit reproduzieren oder rückgängig machen?
Das Team hatte keine Antworten. Der Agent produzierte Output, aber das
Delivery-System hatte kein Konzept der Agentenarbeit als abgegrenzte,
auditierbare Transaktion. Ein Diff, der CI besteht und eine Genehmigung erhält,
belegt, dass eine Änderung stattgefunden hat. Er belegt nicht, welchen Kontext
der Agent verwendet hat, welche Policy-Entscheidungen vor der MR-Erstellung
ausgewertet wurden oder ob das Ergebnis in einem nachfolgenden Pipeline-Lauf
reproduzierbar wäre. In regulierten Umgebungen sind das Wie und das Warum der
eigentliche Punkt.
Dieselbe Dynamik erlebe ich in jeder Plattform- und DevSecOps-Organisation, mit
der ich zusammenarbeite. Das Budget für agentische -Coding-Tools wird in wenigen
Wochen freigegeben. Doch das Budget für Agent Execution Records, Identity
Binding und Replay-Tooling erscheint entweder gar nicht oder wird als
Compliance-Overhead behandelt.
VIER WIEDERKEHRENDE AUSNAHMEN
Sobald Agenten in einer regulierten CI/CD-Umgebung MRs öffnen, tritt eine
vorhersehbare Klasse von Compliance-Ausnahmen auf. Die Typen variieren kaum
zwischen Accounts:
* Fehlende Provenienz: Niemand kann belegen, welche Eingaben der Agent
konsumiert hat: also die Task-Spezifikation, abgerufene Kontext-Referenzen,
Tool-Calls und den Repository-Zustand zum Aufrufzeitpunkt.
* Identity Attribution unklar: Niemand kann agentisch initiierte Änderungen von
menschlich initiierten unterscheiden, weil der Agent unter einem gemeinsamen
Service-Token agierte, ohne namentlich genannten menschlichen Sponsor der
Aktion.
* Entscheidungskette nicht rekonstruierbar: Niemand kann belegen, welche
Policy-Checks vor der MR-Erstellung ausgewertet wurden oder warum der Agent
eine Option gegenüber einer anderen wählte, weil das Reasoning nur in einem
kurzlebigen Trace festgehalten wurde.
* Rollback nicht abgegrenzt: Ein Rückgängigmachen wird zu manueller Archäologie
über Commits und Repos, weil die Edits des Agenten gekoppelt waren und keine
saubere Transaktionsgrenze zum Rückabwickeln existiert.
Behebung bedeutet Rekonstruktion: Chat-Logs durchsuchen, partielle CI-Ausgaben
sichten, Agent-Traces zusammensuchen, soweit noch vorhanden. In den meisten
Organisationen wird nicht erfasst, wie viele Stunden pro Woche damit verbracht
werden – genau deshalb bleibt der Kostenaufwand unsichtbar.
Ich habe einen einfachen Test dafür. Wir nehmen den letzten agentisch geöffneten
MR, der eine Abhängigkeit oder IaC berührt hat. Kann das Team innerhalb einer
Stunde ein einzelnes Evidence-Bundle vorlegen, das die exakte
Task-Spezifikation, die Repo-State-Referenz, die zum MR-Zeitpunkt ausgewerteten
Policy-Checks und die Identität des menschlichen Sponsors enthält, der die
Aktion verantwortet hat?
JE MEHR AGENTEN HANDELN, DESTO GRÖSSER DAS PROBLEM
Ein menschlich erstellter MR hat ein relativ abgegrenztes Evidence-Set: den
Diff, die Genehmigungen und die Pipeline-Ergebnisse. Ein agentisch erstellter MR
benötigt all das plus die Task-Spezifikation, abgerufene Kontext-Referenzen,
Tool-Aufrufe, Modellversion, Policy-Auswertungen und ausreichend Zustand, um die
Task mit fixierten Eingaben erneut auszuführen. CI-Logs decken das nicht ab. Sie
zeigen Pipeline-Schritte und Outputs, nicht den Kontext des Agenten, dessen
Tool-Calls oder die Policy-Entscheidungen, die vor der MR-Erstellung ausgewertet
wurden.
Mit zunehmendem Einsatz von Agenten wächst die Anzahl der Mikro-Entscheidungen
pro MR, während die Kapazität zur manuellen Dokumentation dieser Entscheidungen
konstant bleibt. An dieser Stelle versagt die Mathematik.
Sobald ein nicht-menschliches System beginnt, Änderungen zu erstellen, braucht
das Delivery-System einen dauerhaften Nachweis dessen, was es gesehen,
entschieden und getan hat – als Teil seines Workflows, nicht als separate
Ergänzung. Agenten erschweren das, weil ihre Eingaben nicht replizierbar sind.
Der abgerufene Kontext, die Modellversion und das Reasoning werden bei einem
erneuten Durchlauf nicht denselben Output produzieren. Das fehlende Bindeglied
ist die Bindung von Agentenkontext und Aktionen an den MR als persistentes
Artefakt anstatt als Side Channel.
WANN „SHIP FIRST“ FUNKTIONIERT – UND WANN NICHT
Ich habe erlebt, wie „Ship First, Governance Later“ funktioniert. Ein
Produktteam nutzt Agenten für enge Scopes – Test-Generierung, kleine
Refactorings, Dokumentation – mit einer starken menschlichen Review-Kultur,
begrenztem Blast-Radius und erfahrenen Engineers, die Probleme abfangen, bevor
sie gemergt werden. Wenn Agenten auf risikoarme Scopes beschränkt sind und jede
Änderung starke Reviews und Policy-as-Code-Gates durchläuft, bleiben Repo und
Pipeline oft das System of Record.
Ich habe allerdings auch spektakuläres Scheitern erlebt. Ein großes Unternehmen
versuchte, ein stabiles Workflow-Substrat für alle Automatisierungen aufzubauen,
bevor es die Nutzung skalierte. Das mündete in einen mehrere Quartale dauernden
Plattformaufwand mit Schema-Debatten, nicht eingehaltenen Replay-Versprechen und
einem neuen Datenretentionsproblem, sobald Prompts gespeichert wurden.
Produktteams umgingen die Plattform, um Deadlines einzuhalten, und nutzten
stattdessen leichtgewichtige Agenten mit strengen Guardrails. Das Audit war
zufrieden, aber der Plattformaufwand verzögerte die Adoption und schuf dabei
mehr Governance-Probleme.
JETZT NEWSLETTER ABONNIEREN
TÄGLICH DIE WICHTIGSTEN INFOS ZU BIG DATA, ANALYTICS & AI
Geschäftliche E-Mail
Bitte geben Sie eine gültige E-Mailadresse ein.
Abonnieren
Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und
Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details)
einverstanden und akzeptiere die . Weitere Informationen finde ich in unserer .
Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von
redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu
Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).
Aufklappen für Details zu Ihrer Einwilligung
Stand: 08.12.2025
Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit
Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von
Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden
Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer .
EINWILLIGUNG IN DIE VERWENDUNG VON DATEN ZU WERBEZWECKEN
Ich bin damit einverstanden, dass die Vogel IT-Medien GmbH,
Max-Josef-Metzger-Straße 21, 86157 Augsburg, einschließlich aller mit ihr im
Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel
Communications Group) meine E-Mail-Adresse für die Zusendung von Newslettern und
Werbung nutzt. Auflistungen der jeweils zugehörigen Unternehmen
können abgerufen werden.
Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen
aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und
Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und
Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere
(redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im
Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote.
Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die
Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der
vorgenannten Unternehmen und Marktforschung genutzt werden.
Meine Einwilligung umfasst zudem die Verarbeitung meiner E-Mail-Adresse und
Telefonnummer für den Datenabgleich zu Marketingzwecken mit ausgewählten
Werbepartnern wie z.B. LinkedIN, Google und Meta. Hierfür darf die Vogel
Communications Group die genannten Daten gehasht an Werbepartner übermitteln,
die diese Daten dann nutzen, um feststellen zu können, ob ich ebenfalls Mitglied
auf den besagten Werbepartnerportalen bin. Die Vogel Communications Group nutzt
diese Funktion zu Zwecken des Retargeting (Upselling, Crossselling und
Kundenbindung), der Generierung von sog. Lookalike Audiences zur
Neukundengewinnung und als Ausschlussgrundlage für laufende Werbekampagnen.
Weitere Informationen kann ich dem Abschnitt „“ in der Datenschutzerklärung
entnehmen.
Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich
deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte
Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen
Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu
redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die
hier genannten Zwecke verwendet werden. Dies gilt nicht für den Datenabgleich zu
Marketingzwecken.
Recht auf Widerruf
Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft
widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund
meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um
meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter abrufbare
Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht
mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters
eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem
Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde
ich in der .
Das Muster bricht, wenn Teams das „Ship First“-Ethos ohne dieselbe
Review-Disziplin übernehmen, wenn Prompt-Bibliotheken sich mit inkonsistentem
Logging vermehren und wenn gemeinsame Service- die Identity Attribution über das
gesamte Portfolio hinweg unmöglich machen. Eine tolerierbare lokale Lösung wird
zu einem Haftungsproblem, sobald ein Audit nach portfolioweiter
Evidence-Konsistenz fragt.
Wettbewerbsdruck belohnt Geschwindigkeit, Regulatoren belohnen
Rekonstruierbarkeit. Die Unternehmensführung muss beides im Auge behalten. Die
Kosten schnellen Vorgehens ohne eine aufgezeichnete Ausführungsschicht sind kein
fehlgeschlagener Build. Es ist eine während einer regulatorischen Prüfung
entdeckte Evidence-Lücke, eine wochenlange Remediation mit Sichtbarkeit auf
Vorstandsebene und ein Blast-Radius, der sich über jede agentisch initiierte
Änderung kumuliert, die nie ordnungsgemäß aufgezeichnet wurde.
Wie stark regulierte Unternehmen unter Druck stehen, ihre Software-Auslieferung
zu beschleunigen, zeigt sich in der Praxis. Bei Barclays etwa nutzen 24.000
Mitarbeiter eine zentrale DevOps-Plattform – ein Beleg dafür, wie schnelle und
komplexe Auslieferung in großen DevSecOps-Umgebungen skalieren kann.
DIESE AUFGABE BRAUCHT EINEN NAMEN, EINE BESETZUNG UND METRIKEN
Das Sinnvollste ist, diese Arbeit explizit zu benennen – „Recorded Execution for
Agentic CI/CD“ – und sie wie ein Produkt zu besetzen: mit Plattform-Engineering,
Security, Audit-Liaison und Developer Experience am Tisch. Die Deliverables
entsprechen direkt den vier oben genannten Rekonstruktionsversagen: ein
Execution-Record-Schema, das Eingaben, Outputs, Tool-Calls, Modellversion und
Policy-Outcomes erfasst; Identity Binding, das jede Agentenaktion an einen
menschlichen Sponsor bindet; Policy-Decision-Logs zum MR- und
Pipeline-Zeitpunkt; sowie Replay- und Rollback-Primitive, die die Arbeitseinheit
mit fixierten Eingaben erneut ausführbar machen.
Messen lässt sich das mit operativen Metriken: Compliance-Exception-Queue-Tiefe
für agentisch initiierte MRs, mediane Time-to-Evidence, Replay-Erfolgsrate und
Exception-Wiedereröffnungsrate nach Audit-Follow-ups. Wenn jemand nur eine Sache
tun kann, empfiehlt es sich, Execution Record und Replay-Pfad zunächst für die
risikoreichsten Use Cases aufzubauen – Abhängigkeitsänderungen,
IaC-Modifikationen, Sicherheitskonfiguration – und dann zu erweitern.
Als letzten Test würde ich empfehlen, einen bereits gemergten agentisch
erstellten Change auszuwählen und einen sauberen Rollback als einzelne
abgegrenzte Einheit durchzuführen – ausschließlich unter Verwendung
aufgezeichneter Artefakte. Wenn der Rollback eine Slack-Suche, lokale Clones
oder die Neuerstellung des Prompts erfordert, ist der Handlungsbedarf klar.
ARTIKELFILES UND ARTIKELLINKS
Link:
(ID:50859445)