Agentic Continuous Delivery

Unsere Position. Wir verdrahten die Checks der Pipeline zusätzlich in die Hooks des Agenten, denn eine Pipeline antwortet erst nach dem Push (öffnet in einem neuen Tab). Grüne CI und eine funktionierende deployte Website sind für uns zwei verschiedene Aussagen, also braucht eine Factory eine Prüfkomponente, die prüft, ob die Live-Website in der Realität funktioniert (öffnet in einem neuen Tab).

Sobald Code schnell entsteht, verschiebt sich der Bottleneck in die Delivery-Infrastruktur. Jede Pipeline-Stufe setzt dann einen Teil eines Delivery-Vertrags pro Änderung durch, von Pre-Commit-Checks bis zum Canary-Rollback.

Welche Delivery-Regeln gelten für Änderungen von Agenten?

Die Continuous-Delivery-Community schreibt die Bedingungen hinter Structural Trust als Delivery-Regeln auf. Ihre Ausgangsregel: Eine Änderung, die ein Agent erzeugt hat, muss mindestens dieselbe Qualitätslatte nehmen wie eine menschliche, und zwar durch dieselbe Pipeline. Sobald Code schnell entsteht, verschiebt sich der Bottleneck zu Koordination, Sicherheitsarchitektur und Delivery-Infrastruktur. Zu den minimalen CD-Praktiken kommen harte Regeln für Agenten:

• Ein Mensch verantwortet die Absicht, bevor eine Änderung beginnt.
• Absicht und Architektur werden als Delivery-Artefakte mit dem Code versioniert und deployt.
• Das beabsichtigte Verhalten wird getrennt von der Implementierung spezifiziert.
• Die Pipeline prüft, ob Absicht, Tests, Code und Architektur übereinstimmen.
• Ein Agent bringt seine eigene Änderung nie selbst in Produktion.
• Solange die Pipeline rot ist, darf ein Agent nur Änderungen erzeugen, die sie reparieren (MinimumCD.org and DojoConsortium.org - Agentic Continuous Delivery (öffnet in einem neuen Tab), Stand September 2026).

Dieselbe Quelle legt eine Reihenfolge fest: Continuous Integration, Testgrundlagen, Build-Automatisierung, kleine Arbeitspakete, Infrastructure as Code, ein einziger deterministischer Weg in Produktion und erst dann Agenten. Spezialisierte Validierungs-Agenten (Expert Validation Agents) ersetzen das manuelle Review Schritt für Schritt, nie auf einen Schlag. Das zentrale Artefakt ist ein Delivery-Vertrag pro Änderung mit Absicht, Verhalten, Randbedingungen und Akzeptanzkriterien. Ein Mensch entwirft ihn, ein Agent kritisiert ihn, der Mensch entscheidet, und der Agent verfeinert und implementiert (MinimumCD.org and DojoConsortium.org - Agentic Continuous Delivery (öffnet in einem neuen Tab), Stand September 2026).

Was prüft jede Pipeline-Stufe?

Laut demselben Leitfaden prüft jede Pipeline-Stufe ein Artefakt des Delivery-Vertrags. Pre-Commit-Gates fangen die mechanischen Fehler ab, die Agenten am häufigsten machen: Stil, Typfehler und eingebettete Secrets. Die erste CI-Stufe führt die von Menschen definierten Tests aus. Schlägt ein Test fehl, ist die Implementierung falsch, egal wie plausibel sie sich liest. Contract- und Schema-Tests sichern die Systemvorgaben an den Integrationsgrenzen, die Agenten-Code häufig verletzt. Mutation Testing, Performance-Benchmarks und Security-Integrationstests finden Code, der seine Tests besteht, aber eine nichtfunktionale Anforderung verletzt oder einen Grenzfall ungetestet lässt. Akzeptanztests spielen die BDD-Szenarien in einer produktionsnahen Umgebung durch. Canary-Deployments und SLO-Monitore rollen eine Agenten-Änderung automatisch zurück, wenn sich die Produktionsmetriken verschlechtern (MinimumCD.org and DojoConsortium.org - Pipeline Enforcement and Expert Agents (öffnet in einem neuen Tab), Stand September 2026).

Die Referenzarchitektur dahinter nennt eine Basis von neun Gates. Sie müssen bei jedem Commit grün sein, bevor Feature-Arbeit beginnt:

• Linting und Formatierung
• statische Typen
• Secret Scanning
• SAST für Injection-Muster
• der Build
• Unit-Tests
• Contract-Tests an jeder Integrationsgrenze
• Scans auf verwundbare Abhängigkeiten
• die Validierung von Schema-Migrationen

Die Stufen haben Zeitbudgets: CI-Build und schnelle Tests unter 5 Minuten, Contract-Tests und Prüfungen an den Integrationsgrenzen unter 10, breitere Verifikation unter 15 und Akzeptanztests unter 20. Überzieht eine Stufe ihr Budget, verzögert sie die Integration und verdeckt Defekte. Die günstigsten und schnellsten Gates laufen zuerst. Checks, die von Live-Systemen abhängen, etwa Integrationstests gegen echte Services, laufen nach dem Deploy und blockieren nie einen Commit. Die Architektur wächst über drei Topologien: ein Team mit einem Deployable, mehrere Teams, deren Sub-Pipelines in eine schlanke Integrations-Pipeline für ein Deployable münden, und unabhängige Teams, bei denen die Verifikation der API-Contracts das Integrationstesten ersetzt (MinimumCD.org and DojoConsortium.org - Pipeline Reference Architecture (öffnet in einem neuen Tab), Stand September 2026).

Welcher Agent, welcher Prompt und welche Absicht eine Änderung erzeugt haben, wird als Provenienz festgehalten. Das beschreibt Agent Observability.

Verwandte Seiten

• Qualität und Verifikation: die anderen Checks rund um den Output von Agenten.
• Das Qualitätssystem rund um den Coding-Agenten: warum eine fragile Pipeline unter KI häufiger bricht.
• Qualitäts- und Produktivitätsmetriken: die Kennzahlen, die Änderungen von Agenten an der menschlichen Baseline messen.
• Creator- und Verifier-Rollen: warum kein Agent seine eigene Änderung freigeben sollte.
• Software Factories und Harness Engineering: wie die Pipeline zu den Stationen einer Factory wird.

Quellen

Delivery-Praxis

• Agentic Continuous Delivery (öffnet in einem neuen Tab) - Community-Leitfaden, der Minimum Continuous Delivery um Regeln für von Agenten erzeugte Änderungen, Voraussetzungen und einen Delivery-Vertrag pro Änderung erweitert, CC BY 4.0.
• Pipeline Reference Architecture (öffnet in einem neuen Tab) - Community-Referenz mit allen Quality Gates von Pre-Commit bis Produktion, mit Zeitbudgets und drei Team-Topologien, CC BY 4.0.