Factory-Rollen und Pipeline

Wie Orchestratoren, Worker und Validatoren Arbeit durch eine gestufte Produktions-Pipeline bewegen.

Orchestrator, Worker, Validator

Eine Factory baut auf dem Muster Orchestrator-Worker-Validator auf. Es setzt zwei dokumentierte Workflows zusammen: Bei orchestrator-workers zerlegt ein Orchestrator die Arbeit und verteilt sie, bei evaluator-optimizer prüft ein Evaluator jedes Ergebnis. Jede der drei Rollen ist ein eigener, abgegrenzter Harness und kein nackter Agent. Sie hat eigenen Kontext, eigene Tools, einen eigenen Prompt, eine eigene Schleife und eigene Guardrails.

Der Orchestrator ist das kognitive Zentrum. Er macht aus einem übergeordneten Ziel einen Abhängigkeitsgraphen atomarer Tasks, etwa aus einem Epic, einem Issue oder einem Product Requirements Doc. Produktionscode schreibt er nie. Ein Planer, der auch umsetzt, ist ein Single Point of Failure und untergräbt die ganze Factory. Den Zustand der Pipeline hält der Orchestrator im Issue-Tracker, den das Team ohnehin nutzt. So übersteht die Factory einen Absturz, einen Neustart oder zwei Wochen Urlaub, ohne den Faden zu verlieren.

Worker sind die Agents, die umsetzen, oft auf eine Domäne spezialisiert: Ein Frontend Worker bringt die React-Doku mit, ein Database Worker das Prisma-Schema. Jeder bekommt einen atomaren Task und nur den passenden Ausschnitt des Harness. Er arbeitet in einem Git-Worktree in einer Sandbox. Begrenzter Kontext ist das entscheidende Designprinzip. Wer einen Worker mit der ganzen Codebasis lädt, erzeugt Rauschen und erhöht das Risiko von Halluzinationen durch Ablenkung.

Der Validator ist das Immunsystem der Factory. Entscheidend ist, dass er die eigenen Tests des Workers nicht erneut ausführt. Er prüft das Ergebnis gegen das, was die Spezifikation verlangt: Contract-Konformität, Regressionsintegrität, Security-Scan und Architekturregeln. Schlägt die Prüfung fehl, gibt er einen strukturierten Rejection Report aus. Damit stellt der Orchestrator den Task mit zusätzlichem Kontext neu in die Warteschlange.

Ob Worker parallel oder seriell laufen, entscheidet geteilter Zustand. Arbeiten sie auf wirklich isolierten Bounded Contexts, erlaubt die Aufteilung nach Domänen parallele Läufe. Ein Frontend und ein Database Worker fassen selten dieselben Dateien an. Sobald zwei Domänen Zustand teilen, ist die Garantie für sicheres paralleles Arbeiten weg, etwa bei einem domänenübergreifenden Foreign Key oder einer Tabelle, in die beide schreiben. Das gilt auch, wenn die Dateipfade getrennt aussehen. Dann muss der Orchestrator die Worker nacheinander einplanen.

• Eine Fleet führt einen Task gleichzeitig über viele Repositories aus, etwa ein Dependency-Update oder einen Security-Patch. Jeder Harness besitzt sein eigenes Repo, einen Merge-Schritt gibt es nicht.
• Ein Swarm richtet viele Harnesses auf ein Ergebnis aus. Jeder übernimmt eine Facette desselben Features oder derselben Migration, und die Ergebnisse müssen zu einer einzigen Lieferung zusammenfinden.

Eine Fallstudie aus der Produktion verankert diese Rollen in Git selbst. Jede Aktion wird durch ein Git-Ereignis ausgelöst und als eines festgehalten: Issue, Kommentar, PR. Die Timeline des Repositorys ist damit die Source of Truth, und nichts passiert außerhalb der Aufzeichnung. Jedes Modell läuft in seiner eigenen Lane mit eigenen Credentials, sodass sich jeder Kommentar für ein Audit zuordnen lässt. Die Review-Stufe trennt eine Analysephase, die nur liest, von einer Schreibphase mit Idempotenzmarkern. Wer “analyze” und “post comment” in einem Agent-Schritt mischte, bekam nicht deterministisches Verhalten mit Neigung zu Duplikaten.

Derselbe Lauf behandelt Teilergebnisse als Designanforderung. Trifft eine Lane auf ein Rate Limit, synthetisiert die Pipeline trotzdem die fertigen Lanes und hält fest, welche beigetragen haben. Ein eingeschränkter Lauf bleibt so nützlich, statt zu blockieren (The Agentic Software Factory (öffnet in einem neuen Tab), 2026). Die Multi-Modell-Debatte, aus der die Spezifikationen dieser Fallstudie entstanden, ist eine Multi-Agent-Mechanik.

Die fünfstufige Produktions-Pipeline

Die Factory deckt den ganzen Softwareentwicklungszyklus ab. Sie fährt ihn in fünf Stufen, getragen von benannten, dauerhaft laufenden Automationen statt von einem einzelnen Agent. Jede Automation ist ein spezialisierter Harness, der auf einen Trigger oder nach Zeitplan startet. Das öffentliche Modell von software-factory.dev ist eine konkrete Referenz für diese Form mit einer benannten Automation pro Stufe.

• Planning: Ein Feature Planner prüft die eingehende Spezifikation auf Vollständigkeit, bevor er irgendetwas zerlegt. Fehlen Pflichtfelder, schickt er eine Rückfrage zurück. Eine mehrdeutige Anforderung führt sonst zum Fehlerbild, das Falsche perfekt zu bauen.
• Build: Feature Builder Worker arbeiten die geplanten Issues in einem festgelegten Zeitbudget ab. Überschreitet ein Worker es, deutet das auf einen nicht atomaren Task hin, also einen Kalibrierungsfehler des Orchestrators, oder auf eine außer Kontrolle geratene Schleife.
• Review: Der Validator fährt seine komplette Contract-Suite, bewusst nicht schnell. Sie belegt, dass die Arbeit die Spezifikation erfüllt, und nicht bloß, dass der Code kompiliert. Bei einem Fehler stellt er den Task neu ein.
• Deploy: Eine reife Factory liefert per Canary Rollout an 5 bis 10 Prozent des Produktions-Traffics aus. Monitoring-Agents beobachten Fehlerraten und Latenz-Perzentile. Reißt ein Schwellwert, halten sie automatisch an und rollen zurück. Auf technische Signale reagieren sie in Sekunden, Business-KPIs brauchen trotzdem eine Soak-Phase.
• Operate: Ein Incident Responder beobachtet die Produktion. Bekannte Fehlermuster schickt er als neue Tasks zurück durch die Factory, nur neuartige eskaliert er an den Menschen. Die Lösung landet als aktualisierter ADR, den künftige Worker in ihren Kontext laden.

Die Übergaben zwischen den Stufen sind deterministische Skripte, keine Entscheidungen eines Agents. Einen freigegebenen Diff stagen, einen PR öffnen, die Contract-Suite laufen lassen, einen Rejection Report posten, bei Grün mergen: Jede dieser Operationen ist deterministisch. Das ist schneller und verlässlicher, als einen Agent entscheiden zu lassen, wie er sie ausführt. Dieselben Hooks, die in einem Harness einen schlechten Commit blockieren, verbinden in einer Factory die Harnesses miteinander. Genau diese Verdrahtung unterscheidet eine Factory von einem einzelnen Harness.

Auf einer einzelnen Maschine bekommt jedes deterministische Gate eine eigene Rolle. Ein:e Praktiker:in lässt fünf Agents nacheinander laufen:

1. Ein Specifier macht aus einer von Menschen geschriebenen Story Gherkin-Akzeptanztests und eine QA-Prozedur. Die Prozedur beschreibt einen Menschen, der die UI bedient und beweisen muss, dass das System funktioniert.
2. Ein Coder schreibt Unit-Tests und Code, bis die Gherkin-Tests bestehen.
3. Ein Cleaner fährt die CRAP-Analyse und ein allgemeines Review über das Durcheinander des Coders.
4. Ein Hardener fährt Mutation Testing mit dem Ziel voller Abdeckung.
5. Ein QA-Agent macht aus der geschriebenen Prozedur ein ausführbares Skript gegen das laufende System, mit deterministischem Ergebnis.

Jeder Agent startet mit sauberem Kontext, erledigt seine eine Aufgabe und endet. Die wenigen Regeln oben in seinem Prompt halten dadurch besser. Das kostet 10 bis 15 Sekunden Startzeit pro Agent, jedes Mal neu aufgebauten Kontext und Aufwand für die Übergaben. Eine Aufgabe, die ein einzelner Agent in fünf Minuten mit zweifelhaftem Ergebnis erledigt, braucht in der Kette etwa eine Stunde. Ein Mensch bräuchte grob einen halben Tag. Laut dieser Darstellung ist das vier- bis fünfmal schneller bei höherer Qualität (Selbstauskunft, LIVE: Uncle Bob on Software Fundamentals in the Age of AI (öffnet in einem neuen Tab), August 2026).

Für die Stufen Review und Deploy gibt es konkrete Governance-Beispiele. Ona hat eine Low-Risk Change Policy festgeschrieben. Eine Automation, nicht die Person, die den PR geschrieben hat, ordnet jeden PR anhand von sechs objektiven Kriterien ein: unter 1.000 Zeilen und keine Änderungen an Protobuf, Migrationen, Infra/CI, Auth oder Audit-Logging. Erfüllt ein PR sie, genehmigt die Automation das Review, den Merge klickt weiterhin ein Mensch. Nach vier Wochen fiel die Median-Zeit bis zur ersten Freigabe von 2 Stunden 49 Minuten auf 3,8 Minuten. Die Lead Time sank um 74 Prozent, und die wöchentlichen Deploys verdreifachten sich bei gleicher Teamgröße.

Ona zieht daraus die Lehre, dass das Governance-Modell mehr zählt als das KI-Modell. Automatische Klassifizierung, explizite Kriterien, Audit Trails und die Merge-Hoheit des Menschen als nachvollziehbares Freigabeereignis halten das System SOC-2-konform. Tauscht ihr das Modell, steht das System weiter (Ona – Auto-Approving Low-Risk PRs (öffnet in einem neuen Tab), 2026).

Ein Podcast-Gespräch zeigt, wie eine solche Policy auf die Autor:innen wirkt. In einer Anekdote aus zweiter Hand testete ein:e Gründer:in eine Regel für Pull Requests unter einer Zeilengrenze, die keines der Kernmodule des Monorepos berühren. Solche Pull Requests wurden ohne menschliches Review gemergt, ein KI-Review lief trotzdem. Der Anteil der Pull Requests, die die Regel erfüllten, stieg von etwa 10 auf etwa 80 Prozent. Engineers machten kleinere Pull Requests und lösten den kritischen Teil einer Änderung heraus.

Das Team eines der Hosts sichert die andere Seite der Linie ab. Seine Ownership-Regeln sind Code, der auf jeder geänderten Datei läuft, entweder als schlichter Pattern Match oder als promptbasierter Detektor. Ein Pattern kann so schlicht sein wie das Lesen einer Umgebungsvariable im Rust-Code. Schlägt eine Regel an, blockiert sie die Änderung, bis die benannte Person genau diese Datei ausdrücklich freigegeben hat. Stand Oktober 2026 gibt dieses Team alles, was serialisiert oder persistiert wird, an einen Menschen. Bei gespeichertem Zustand traut es Agents noch nicht (Boundary - How to Build an AI Software Factory That Ships Faster (öffnet in einem neuen Tab), Oktober 2026, Praxis und Anbieter).

In der Enterprise-Praxis heißt dieselbe End-to-End-Form “Simultaneous SDLC”. Agents testen, während sie coden, und dokumentieren, während sie umsetzen. Vorgelagert macht ein Requirements Synthesis Agent aus Transkripten strukturierte Tickets. Menschliche Freigabe im Loop bleibt “Red Zone”-Tasks vorbehalten (The Evolution of the Autonomous Software Factory (öffnet in einem neuen Tab), 2026).

Das Muster reicht bis in die konservativsten Brownfield-Stacks. Eine SAP-ABAP-Pipeline folgt dem Muster “Git / off-stack with read-only MCP”. Code, PRs, CI und Review bleiben in Git. Ein MCP-Server gibt dem LLM lesenden Zugriff auf Kontext aus dem Live-System und keinen Schreibweg. Die Begründung lautet “the client can change. The governed SAP access layer stays the same”. Capability Keys sind pro Rolle zugeschnitten. Ein Reviewer-Profil trägt Tools für Lesen, Preview, Diagnose und Lint und schließt die Schreib-Tools ausdrücklich aus.

Die Review-Leiter für PRs hat vier Schichten:

1. statischer Lint,
2. ein deterministisches Gate aus Unit-Tests und ATC,
3. ein KI-Review nur auf dem Diff,
4. ein MCP-gestütztes KI-Review.

Die vierte Schicht beherrscht den Drift-Check, den ein Diff-Reviewer nicht leisten kann. Sie bestätigt, dass das aktivierte Objekt im Live-System dem Quellstand vor dem PR entspricht.

Im Betrieb nutzt die Pipeline ein zweistufiges Kostenmodell. Jeder Runtime-Dump bekommt eine günstige, flache Triage zu einem Issue. Die teure, tiefe Untersuchung startet erst, wenn ein Mensch ein Label setzt. GitHub-Labels sind die gesamte Orchestrierungs-UI (ABAP CI/CD with ARC-1 (öffnet in einem neuen Tab), 2026).

Auf der Ebene der Supply Chain argumentiert Red Hat mit seiner “trusted software factory”. Vertrauen muss eingebaut sein, bevor die erste Zeile entsteht, statt am Ende hineingescannt zu werden. Anwendungen und KI-Agents laufen denselben regulierten Weg:

• SLSA-Provenance, sigstore-Signaturen, SBOMs und hermetische Builds,
• kuratierte Dependency-Kataloge, damit KI-generierter Code standardmäßig vertrauenswürdige Bausteine nutzt,
• Policy-as-Code, die nur freigegebene Images und Libraries zulässt,
• Exploit Intelligence nach Erreichbarkeit (mit NVIDIA), die Hunderte nominelle Schwachstellen auf den kleinen Teil eingrenzt, der zur Laufzeit tatsächlich erreichbar ist (Red Hat – A Trusted Software Factory for the Agentic AI Era (öffnet in einem neuen Tab), Anbieter, 2026).

Der Merge-Schritt selbst wird gerade für den Durchsatz von Agents neu entworfen. Namespace nennt den Pull Request “the unit of work designed for human review”. Er beruht auf verzögertem Feedback und Übergaben und bricht, sobald das Änderungsvolumen das Vierfache der Rate vor den Agents erreicht. Namespace behandelt das Mergen stattdessen als Serialisierungsproblem einer Datenbank, gegen den einen Ledger des Repositorys. Der Flow läuft so:

1. Intent und Plan, als Spec im Tracker,
2. eine Schleife im Agent-Harness,
3. interne Validierung, die gegen einen bekannten Commit baut und testet,
4. externe Validierung ohne Menschen, bei der ein auf Security fokussiertes LLM und ein LLM für API-Konformität Befunde zurück in die Schleife speisen,
5. eine Pre-Merge-Queue, die parallele Änderungen auf Serialisierbarkeit abgleicht.

Der Mensch erteilt die “external approval”, indem er Intent und Ergebnis prüft, nicht den Code. Er sieht ein Video des Features und die Ausgabe der Validatoren, womöglich gebündelt über mehrere Commits und Agents.

Agents, die gleichzeitig an mehreren Kandidaten-Commits arbeiten (“step into the multiverse”), treiben den Ressourcenverbrauch in die Höhe. Sie verlangen zustandsbehaftete, inkrementelle Schleifen statt Läufen von Grund auf. CI verschwindet nicht, es verschiebt sich: Validierung läuft bei jeder Iteration, und Governance wandert in den Harness (Namespace – Why CI/CD Is Dead and Continuous Compute Is Next (öffnet in einem neuen Tab), 2026).

Bei langen Laufzeiten erbt die Build-Stufe eine härtere Einschränkung: Sessions haben kein Gedächtnis. Anthropic beschreibt einen lang laufenden Build wie Engineers im Schichtdienst, die ohne Erinnerung an die vorige Schicht ankommen. Die Brücke bilden ein init.sh, eine Datei claude-progress.txt und die Git-Historie. Die Regel, immer nur ein Feature zu bauen, hindert einen frischen Agent daran, den bisherigen Fortschritt zu überblicken und den Job vorschnell für erledigt zu erklären. Die Messlatte “clean state means mergeable” sorgt dafür, dass jede Schicht den Branch übergabefähig hinterlässt (Anthropic – Effective Harnesses for Long-Running Agents (öffnet in einem neuen Tab), 2025).

Open-Source-Implementierungen liefern dieses Muster inzwischen fertig verpackt. AutoForge hüllt Anthropics Referenzdesign in eine UI mit Kanban und Abhängigkeitsgraph. Ein Initializer-Agent baut eine SQLite-Datenbank der Features. Ein bis fünf parallele Coding-Agents laufen, freigegeben durch den Graphen. Eigene Agents für Regressionstests reparieren Features oder markieren sie als fehlgeschlagen. AutoForge testet sich dabei selbst über das Playwright MCP (AutoForge walkthrough (öffnet in einem neuen Tab), 2026).

Für die Operate-Stufe gibt es ein Beispiel im Produktionsmaßstab: das Produkt von PostHog, das sich selbst baut. Es macht aus Observability-Signalen PRs, gespeist aus Billionen Events im Monat.

1. Ein LLM-Sicherheitsklassifikator verwirft zuerst bösartige Signale, denn Angreifer:innen können auf einer öffentlichen Seite Fehlertext einschleusen.
2. Die Pipeline normalisiert Signale mit Gewicht und Embedding und gruppiert sie zu Reports, die über einem Schwellwert aufsteigen.
3. Ein Research-Agent stuft ein, ob ein Report umsetzbar ist. Er nutzt das Claude Agent SDK in einer Modal-Sandbox, mit MCP-Zugriff auf Logs, Replays und den Tracker.
4. Sofort umsetzbare Reports gehen an einen Execute-Schritt. Er schreibt den Fix, öffnet den PR und wählt per git blame aus, wer reviewt. Scheitert CI, sichert er die Sandbox als Snapshot, stellt sie wieder her und lässt erneut laufen, bis alles grün ist.

Zwei der Lehren gelten allgemein. Fertige Embeddings clustern Signale strukturell statt semantisch, sodass alle Fehler zusammen landen. Abhilfe schafft ein LLM, das aus jedem Signal Queries erzeugt, die dann im Embedding-Raum abgeglichen werden. Die zweite Lehre behandelt “tokens are free” als produktiven Fehler. Ihr lasst den teuren Agent hundertmal laufen, um das Muster zu finden. Danach fasst ihr diesen Schritt zu einem einzelnen LLM-Aufruf oder einem trainierten Modell zusammen (What If Your Product Built Itself? (öffnet in einem neuen Tab), 2026).