Was ist eine Software Factory?

Eine Arbeitsdefinition

Eine Software Factory ist das Delivery-System, aus dem die Softwareänderungen kommen. Sie nimmt eine Absicht entgegen, macht daraus begrenzte Arbeit, stattet Agenten mit Kontext und Umgebung aus und nimmt Ergebnisse erst nach definierten Prüfungen an. Was entstehen soll, entscheiden Menschen. Sie verantworten die Grenzen und bleiben für die Produktion verantwortlich.

Die Factory reicht weiter als ein Coding-Agent. Der Agent bearbeitet eine Aufgabe. Die Factory koordiniert den Weg von dieser Aufgabe bis zur ausgerollten und beobachteten Änderung.

Diese Unterscheidung ist wichtig: Auch wenn die Implementierung schneller wird, bleiben Planung, Review, Deployment und Betriebsverantwortung. Es ändert sich, wo technische Aufmerksamkeit gebraucht wird.

Die Bestandteile des Systems

Die Bezeichnungen unterscheiden sich je nach Umsetzung, die Zuständigkeiten erkennt man trotzdem wieder.

Eine Intake-Schicht macht aus einer Idee, einem Issue oder einer Spezifikation Arbeit, die sich prüfen lässt. Sie bewahrt die ursprüngliche Absicht und hält die Bedingungen fest, die beim Zerlegen erhalten bleiben müssen.

Ein Orchestrator stellt den Ausführungsplan auf, verteilt begrenzte Aufgaben, kümmert sich um Abhängigkeiten und entscheidet, wie es nach Erfolg oder Fehlschlag weitergeht. Seinen Zustand sollte er nicht in einer einzelnen Konversation verstecken. Plan und Laufzustand müssen einsehbar bleiben.

Worker setzen eng zugeschnittene Änderungen in einer vorbereiteten Umgebung um. Diese Umgebung bringt Repository-Kontext, Befehle, Architekturregeln und Zugriffsgrenzen mit.

Validatoren übernehmen deterministische Prüfungen und gezielte Reviews. Build, Typen, Tests, Sicherheitsprüfungen, Verhaltensvergleiche und Deployment-Zustand liefern verschiedene Arten von Evidenz. Spricht die Evidenz dagegen, läuft die Arbeit zurück in eine begrenzte Korrekturschleife.

Eine Feedback-Schicht hält fest, was nach Merge und Deployment passiert. Korrekturen, die immer wieder nötig sind, können zu Tests, Repository-Regeln oder besseren Intake-Bedingungen werden. Auf diese Weise wird die Factory besser, statt denselben Fehler einfach schneller zu machen.

Agent, Harness, Pipeline und Factory

Ein Harness legt Kontext, Befehle, Berechtigungen und Feedback um eine bestimmte Art von Agentenarbeit. Eine Factory kombiniert mehrere Harnesses und reicht Arbeit zwischen ihnen weiter.

Eine Pipeline schickt eine Änderung durch eine definierte Abfolge von Schritten. Eine Factory enthält Pipelines, beobachtet darüber hinaus aber das Ergebnis und passt an, wie künftige Arbeit läuft.

Ein Agent kann auch ohne beides nützlich sein. Eine Factory wird relevant, sobald eine Organisation wiederholbare Delivery über Repositories, Teams oder Phasen des Lebenszyklus hinweg will.

Wo Menschen verantwortlich bleiben

Menschen legen die Absicht fest und entscheiden, was sich zu bauen lohnt. Architekturgrenzen, Produktionsrisiken und die Abnahmebelege für folgenreiche Änderungen bleiben in ihrer Verantwortung.

Automatisierung sollte dort wachsen, wo die Evidenz stark ist. Datenbankschemata, öffentliche Verträge, sensible Daten und irreversible Operationen brauchen meist engere menschliche Gates als ein lokales Refactoring. Die Grenze sollte sich nach den Kosten einer falschen Änderung richten, nicht nach der Begeisterung für Autonomie.

Laut OpenAIs Implementierungsbericht verbrachten die Engineers mehr Zeit mit Umgebungen, Spezifikationen und Feedback-Schleifen, als die Codeerzeugung zu den Agenten wanderte. Ona beschreibt eine ähnliche Verschiebung, hin zu eng zugeschnittenen Automatisierungen, die entlang des Delivery-Lebenszyklus verbunden sind. Beide Berichte zeigen, dass das Muster funktionieren kann. Dass dieselbe Autonomiestufe zu jeder Organisation passt, belegen sie nicht.

Woran ihr erkennt, ob es funktioniert

Codezeilen und Agentenaktivität beschreiben Volumen. Einen Delivery-Wert belegen sie nicht.

Eine Factory braucht eine Baseline und ein benanntes Ergebnis für den Wertstrom, den ihr gewählt habt. Auf der technischen Seite kommen die DORA-Kennzahlen mit der Durchlaufzeit von der Idee bis zu den ersten Nutzer:innen, Rework Rate, Nutzung des Ausgelieferten und Kosten pro Änderung infrage. Die geschäftliche Messgröße hängt von der Arbeit ab: Migrationsfortschritt, Vorlaufzeit bis zu einer Produktentscheidung, Supportkosten oder ein anderes Ergebnis, das die Organisation überprüfen kann.

Die erste nützliche Factory ist begrenzt. Ein einzelner Wertstrom bringt genug Realität mit, um Kontext, Gates, Ownership und Messung zu prüfen, bevor die Organisation das System ausbaut.