Agentic Development Factory
Factory-Architektur für überprüfbare Änderungen mit Trennung von Modellausgabe und vertrauenswürdigem Ausführungscode – gewachsen aus einer agentischen Delivery-Pipeline im Produktivbetrieb.
Coding-Agenten sind schnell – aber ein Modell darf weder Berechtigungen noch Prüfergebnisse oder Merges bestimmen. Ein produktives ERP soll trotzdem zügig weiterentwickelt werden.
Entwurf und Umsetzung des gesamten Prozesses: zuerst die Delivery-Pipeline mit Planungs-, Review-, Umsetzungs- und Verifikationszyklen im Produktivbetrieb, dann die Factory mit Controller, Worker, Gate Runner und Review-Paket.
Das Modell erhält keinen direkten Datei-, Shell- oder Webzugriff – nur begrenzte UTF-8-Snapshots und ein festes Ausgabeformat. Ein unabhängiger Prüfer verifiziert den exakten Änderungskandidaten; die menschliche Freigabe ist daran gebunden.
Was das System im Betrieb leistet.
Gemessene Werte stehen als solche da. Wo es noch keine Baseline gibt, legt eine Modellrechnung ihre Annahmen offen.
der Änderungen im Produktiv-ERP agentengestützt – mit Review, Tests und Freigabe
Risiko-Einträge mit 148 Abschlussbelegen im ersten Agent-Loop
Werkzeuge für das Modell: nur Snapshot rein, Vorschlag raus
weniger manueller Dev-Aufwand bei standardisierbaren Workflows
Eigene Schätzung für standardisierbare Workflows in der eigenen Agent Delivery Pipeline. Messplan: aktive Zeit je Work Package gegenüber Schätzung ohne Agenten.
So funktioniert es im Alltag.
- 01Planen
Ein Agent zerlegt die Aufgabe in prüfbare Schritte mit Akzeptanzkriterien; Modellausgaben folgen festen Schemas.
- 02Umsetzen und prüfen
Ein Agent implementiert, ein zweiter prüft Code und Sicherheit nur lesend; Tests laufen rot, dann grün.
- 03Gate
Ein unabhängiger Prüfer verifiziert den exakten Änderungskandidaten: Pfade, Digests, Artefakte.
- 04Freigeben
Ein Mensch entscheidet über genau diesen geprüften Stand; danach geht die Änderung über Staging in Produktion.
Ebenen und Zuständigkeiten.
Aufgaben aus Spezifikationen und Risikoregister; Planer, Umsetzer und Reviewer mit getrennten Rechten – im Produktivbetrieb bewährt.
Persistenter Run-/Attempt-/Lease-/Recovery-State in PostgreSQL; unveränderliche Requests, Digests, frische Arbeitsumgebung je Versuch.
Das Modell läuft ohne Datei-, Shell- und Webzugriff – nur mit begrenzten UTF-8-Snapshots und validierten Änderungsvorschlägen.
Unabhängige Prüfung des exakten Kandidaten, daran gebundene menschliche Freigabe. Zugangsdaten außerhalb von Repo, Prompts, Logs und Artefakten.