Was ist eine Software Factory?

Eine Arbeitsdefinition

Eine Software Factory ist das Delivery-System, das Softwareänderungen produziert. Sie nimmt eine Absicht auf, macht daraus begrenzte Arbeit, versorgt Agenten mit Kontext und Umgebung und akzeptiert Ergebnisse erst nach definierten Prüfungen. Menschen entscheiden, was entstehen soll, verantworten die Grenzen und bleiben für die Produktion zuständig.

Die Factory ist größer als ein Coding-Agent. Ein Coding-Agent bearbeitet eine Aufgabe. Die Factory koordiniert den Weg von dieser Aufgabe bis zu einer ausgerollten und beobachteten Änderung.

Diese Unterscheidung ist wichtig. Schnellere Implementierung beseitigt weder Planung noch Review, Deployment oder operative Verantwortung. Sie verschiebt, wo technische Aufmerksamkeit gebraucht wird.

Die Bestandteile des Systems

Die Bezeichnungen unterscheiden sich, die Verantwortungen bleiben erkennbar.

Eine Intake-Schicht übersetzt Idee, Issue oder Spezifikation in prüfbare Arbeit. Sie erhält die ursprüngliche Absicht und hält die Bedingungen fest, die bei der Zerlegung nicht verloren gehen dürfen.

Ein Orchestrator erstellt den Ausführungsplan, verteilt begrenzte Aufgaben, verwaltet Abhängigkeiten und entscheidet, was nach Erfolg oder Fehler passiert. Plan und Laufzustand müssen einsehbar bleiben.

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

Validatoren wenden deterministische Prüfungen und fokussierte Reviews an. Build, Typen, Tests, Sicherheitsprüfungen, Verhaltensvergleiche und Deployment-Zustand liefern verschiedene Formen von Evidenz. Fehlende Evidenz schickt die Arbeit in eine begrenzte Korrekturschleife zurück.

Eine Feedback-Schicht hält fest, was nach Merge und Deployment geschieht. Wiederkehrende Korrekturen werden zu Tests, Repository-Regeln oder besseren Intake-Bedingungen. So verbessert sich die Factory, statt denselben Fehler nur schneller zu wiederholen.

Agent, Harness, Pipeline und Factory

Ein Harness umgibt eine Art von Agentenarbeit mit Kontext, Befehlen, Berechtigungen und Feedback. Eine Factory verbindet mehrere Harnesses und leitet Arbeit zwischen ihnen weiter.

Eine Pipeline führt eine Änderung durch eine definierte Folge. Eine Factory enthält Pipelines, beobachtet aber zusätzlich das Ergebnis und verändert zukünftige Abläufe.

Ein Agent kann ohne beides nützlich sein. Die Factory wird relevant, wenn eine Organisation wiederholbare Delivery über Repositories, Teams oder Lebenszyklusphasen hinweg braucht.

Wo Menschen verantwortlich bleiben

Menschen definieren die Absicht und entscheiden, was den Bau wert ist. Sie verantworten Architekturgrenzen, Produktionsrisiken und die Akzeptanzevidenz für folgenreiche Änderungen.

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 folgt den Kosten einer falschen Änderung, nicht der Begeisterung für Autonomie.

OpenAIs Implementierungsbericht beschreibt, wie sich die Arbeit der Engineers zu Umgebungen, Spezifikationen und Feedback-Schleifen verschob, als Agenten mehr Code erzeugten. Ona berichtet von einer ähnlichen Verschiebung hin zu eng begrenzten Automatisierungen entlang des Delivery-Lebenszyklus. Beide Berichte zeigen, dass das Muster lauffähig ist. Sie belegen nicht, dass dieselbe Autonomiestufe für jede Organisation passt.

Woran ihr erkennt, ob es funktioniert

Codezeilen und Agentenaktivität beschreiben Volumen. Sie belegen keinen Delivery-Wert.

Eine Factory braucht eine Ausgangslage und ein benanntes Ziel für den gewählten Wertstrom. Technische Messgrößen können PR-Durchsatz, Änderungsvertrauen, Fehlerrate, Review-Zeit und Wiederherstellungszeit umfassen. Die geschäftliche Messgröße hängt von der Arbeit ab: Migrationsfortschritt, Vorlaufzeit bis zu einer Produktentscheidung, Supportkosten oder ein anderes überprüfbares Ergebnis.

Die erste nützliche Factory ist begrenzt. Ein Wertstrom schafft genug Realität, um Kontext, Gates, Ownership und Messung zu prüfen, bevor das System erweitert wird.