Rollen und Wirtschaftlichkeit der Software Factory

Unsere Position. Wir zählen eine Änderung erst, wenn sie in Produktion läuft und Kund:innen sie nutzen, dafür zahlen oder sagen, dass sie geholfen hat. Ein gemergter Pull Request ist Output (A swarm is not throughput (öffnet in einem neuen Tab)). Ein Token-Budget ist eine Investitionsentscheidung. Es gehört zu den Menschen, die entscheiden, was gebaut wird, und fließt zuerst dorthin, wo schnellere Lieferung eine Geschäftskennzahl bewegt.

Diese Zählung geht einen Schritt über die Factory-Metrik der Praktiker:innen hinaus: den Anteil der Änderungen, die automatisch und zu bekannten Kosten ausgeliefert werden.

Wie verändert die Factory die Arbeit von Engineers?

Das Factory-Modell definiert die Arbeit von Engineers neu. Ihr schreibt nicht mehr das Produkt, ihr baut die Factory, die es baut. Flotten von Agents laufen parallel, jeder mit einer Aufgabe, Tools, Kontext und einer Feedback-Schleife. Der Mensch reviewt die Ergebnisse, schärft Specs nach und deployt neu.

Wer die Analogie ernst nimmt, sieht die eigentlichen Investitionen: Qualitätskontrolle, Prozessdokumentation, präzise spezifizierte Eingaben und verlässliche Umgebungen. Denn der Bottleneck liegt jetzt bei der Verifikation, die Generierung ist es nicht mehr (The Factory Model (öffnet in einem neuen Tab)).

Wie messt ihr den Erfolg einer Factory?

Der CEO von Warp macht aus dieser Neudefinition eine Metrik und eine Zeile in der GuV. Die Zahl der Features wird für ihn zu “a failure metric”. Den Erfolg einer Factory misst der Anteil aller Änderungen, die automatisch ausgeliefert werden, und zu welchen Kosten. Factory-Effizienz definiert er als ausgeliefertes Produkt im Verhältnis zu Inferenzkosten plus Kosten menschlicher Arbeitszeit.

Sein zehnstufiger Workflow rahmt die Implementierung ein. Davor arbeitet ein Triage-Agent, danach ein Monitor-Agent, der Issues anlegt und so die Schleife schließt. Jeder Rückfall auf einen interaktiven Agent mit Mensch in der Schleife gilt als “a failure to learn from”. Self-Improvement-Agents durchsuchen die eigenen Konversationen der Factory nach verschwendeten Token und evaluieren alternative Harnesses und Prompts. Sie sind “the golden path”.

Die genannte wirtschaftliche Folge: Softwareproduktion ist kein F&E-Aufwand mehr, sie erscheint als COGS in der GuV. Damit enden unbegrenzte Token-Budgets, und jeder Dollar für Automatisierung muss einen Renditetest bestehen. Als Beleg für ungenutzte Kapazität dient Warps eigene öffentliche Factory-Instanz. Dort warten 1.300 umsetzungsreife Issues (We Are Now Factory Engineers, Not Product Engineers (öffnet in einem neuen Tab), 24. Juni 2026).

Ein Podcast-Gespräch mit demselben Gründer, im Oktober 2026 veröffentlicht, setzt einen Schritt früher an. Eine gute Factory hat hohen Yield. Eine allgemeine Definition von Yield finden die Sprecher:innen nicht, weil er sich von Geschäft zu Geschäft unterscheidet. Ihre Leiter steigt von Pull Requests zu ausgelieferten Features, dann zu Kundenergebnissen und schließlich zu Geschäftswirkung. Ein Kundenergebnis ist ein Workflow, der früher 20 Minuten dauerte und jetzt 10. Jede Stufe sagt mehr aus und ist schwerer zu messen.

Vor dem Product-Market-Fit bricht die Leiter zusammen. Das einzige Signal kommt dann von einer Handvoll Nutzer:innen, so wenigen, dass ein Mensch jedes Session-Replay ansehen kann. Eine vollständig automatisierte Factory hat dann keinen Yield, auf den sie optimieren könnte. Bei großer Nutzung macht Telemetrie die Factory messbar. Eine Regression zeigt sich, sobald ein Teil der Nutzer:innen aktualisiert hat, und die Änderung lässt sich zurücknehmen.

Den Blocker verorten die Sprecher:innen im Organigramm. Besitzt Engineering einen Teil der Schleife und Product den anderen, teilen sich zwei getrennte Organisationen den Yield. Dort sehen die Sprecher:innen keine schnelle Factory. Sie nennen das ein strukturelles Problem der Menschen, keines der Tools (Boundary - How to Build an AI Software Factory That Ships Faster (öffnet in einem neuen Tab), Oktober 2026, Praktiker und Anbieter).

Die eigene Plattform des Gründers zeigt als Anbieter-Demo, wie so ein Maß standardmäßig aussieht. Ihr Automation Index zählt menschliche Interaktionen pro Pull Request. Diese Zahl soll sinken, ein Ja-oder-Nein-Zustand ist sie nicht. Daneben stehen DORA-Lead-Time und Volumen sowie Kosten, aufgeschlüsselt nach Engineer und nach Factory-Stufe.

Als Voraussetzung nennt die Demo, jeden Lauf aufzuzeichnen. Das erlaubt Online-Evals über eine Stichprobe vergangener Läufe. Dort bewertet ein LLM-Judge zum Beispiel den Anteil der Läufe, die redundante Tests schreiben. Andere Judges markieren Sackgassen, Weitschweifigkeit und Agents, die sich neu erarbeiten, was ein Skill schon enthalten sollte. Die Befunde fließen in bessere Skills. Nach Modell aufgeteilt, ersetzt so ein Score Meinungen über ein Modell durch eine Messung.

Der Onboarding-Rat schränkt die frühere Regel ein, jeder interaktive Rückfall sei ein Fehlschlag. Bisher lässt sich wenig Arbeit vollständig automatisieren. Deshalb leiten Teams zuerst alle Arbeit durch die gemeinsame Cloud-Schleife, auch Prompts aus dem Chat, dem Issue-Tracker oder einem MCP-Client. So wird die Arbeit erfasst und messbar, und ein wachsender Anteil dieser Prompts wird danach zu Automationen. Ein Co-Host vertritt die umgekehrte Reihenfolge: Erst kommen Menschen aus der bestehenden Schleife, dann wird die Arbeitsweise der besten Engineers als Pipeline kodiert. Beide Seiten lehnen es ab, den ganzen Prozess auf einmal neu zu entwerfen (gleiche Quelle).

Wo laufen die Praxisberichte zusammen?

Das Framing vom “third age” beschreibt eine goldene Ära, in der sich die Arbeit von Entwickler:innen verschiebt: weg vom Schreiben von Instruktionen, hin zum Definieren von Absicht. Bis März 2026 war es zum gemeinsamen Vokabular einer Welle von Praxisberichten geworden, die auf dieselbe Form hinauslaufen.

StrongDM definiert eine Software Factory als “non-interactive development where specs and scenarios drive agents that write code, run harnesses, and converge without human review”. Dazu gelten zwei harte Regeln: Kein Mensch darf Code schreiben, und kein Mensch darf Code reviewen (Software Factories and the Agentic Moment (öffnet in einem neuen Tab), 6. Februar 2026).

Der Bericht zur “Dark Factory” leiht sich den Begriff aus der Fertigung für denselben Betrieb bei ausgeschaltetem Licht. Seine wiederkehrende Warnung gilt der wachsenden Lücke zwischen Vorreitern und Nachzüglern. Block hat die Belegschaft von über 10.000 in Richtung unter 6.000 reduziert und beruft sich auf “a new way of working”. Cursor berichtet, dass inzwischen 35 Prozent der intern gemergten PRs von Agents in Cloud-VMs kommen (The Dark Factory (öffnet in einem neuen Tab), 5. März 2026).

Am deutlichsten formuliert Ona die These in seinem öffentlichen Memo-Experiment: “you don’t build Memo, you build a factory to build Memo”. Das Ergebnis widerspricht der Intuition, denn die Betriebsseite brauchte mehr Automationen als die Build-Seite (Ona – Software Factory: the Memo experiment (öffnet in einem neuen Tab)).

Das Framing aus der Praxis kommt von den einzelnen Entwickler:innen her am selben Punkt an. Die Leiter der Entwicklerevolution hatte ursprünglich acht Stufen, die oberste hieß “building your own orchestrator”. Inzwischen hat sie elf, weil Betreiber:innen dauerhaft laufende Agent-Crews deployt haben. Dazu kamen shepherd, das Hüten einer Herde von Agents, und garden, eine deployte Multi-Agent-Crew, die 24x7 einen Geschäftsprozess betreibt. Die dritte neue Stufe heißt factory builder: einen vollständigen eigenen Orchestrator bauen, als Architekt:in, Kurator:in und Shepherd.

Die schärfste Factory-These des Gas-City-Berichts ist ökonomisch. Ein Team aus drei bis fünf Engineers mit Agent-“Packs” kann glaubwürdig siebenstellige SaaS-Rechnungen ersetzen. Dafür holt es die 20 Prozent der Features ins Haus, die ein Unternehmen tatsächlich nutzt. Die Fähigkeit bleibt als Asset im Haus, das mit der Zeit wächst, mit git-versioniertem Audit-Trail, statt dass laufend Miete fließt. “Dark” deutet der Bericht als bloße Hintergrundarbeit um: Observability ist eine Designentscheidung und kein Auftrag, das Licht auszulassen (Welcome to Gas City (öffnet in einem neuen Tab)). Die Mechanik der Orchestrierung selbst gehört zur Multi-Agent-Koordination.

Verwandte Seiten

• Das Software-Factory-Pattern: das dauerhaft laufende System, zu dem diese Rollen und Kosten gehören.
• Software Factories in Produktion: Belege: die Durchsatz- und Kostenzahlen, die laufende Factories berichten.
• Impact messen: wie ihr KI-Metriken mit den Delivery-Metriken koppelt, die zeigen, ob es wirkt.
• Qualitäts- und Produktivitätsmetriken: warum Volumenmetriken beim agentischen Coding schädlich werden.
• Inference-Kosten und Infrastruktur: was die Token-Rechnung treibt, die eine Factory rechtfertigen muss.

Quellen

Factory-Messung

• How to Build an AI Software Factory That Ships Faster (öffnet in einem neuen Tab) - Podcast-Folge mit dem Gründer eines Anbieters von Terminal-Agents über die Definition von Factory-Yield, Standardmetriken, Factory-Definitionen als Code und risikobasiertes Review.

Artikel

• Software Factories and the Agentic Moment (öffnet in einem neuen Tab) - StrongDMs Definition einer Software Factory als nicht-interaktive Entwicklung, mit zwei Regeln: kein von Menschen geschriebener und kein von Menschen reviewter Code.
• The Dark Factory (öffnet in einem neuen Tab) - Blog-Essay, das den Begriff aus der Fertigung für Engineering-Teams bei ausgeschaltetem Licht übernimmt und vor einer wachsenden Lücke zwischen Vorreitern und Nachzüglern warnt.
• The Factory Model (öffnet in einem neuen Tab) - Essay, das die Arbeit von Engineers als Bau der Factory beschreibt, die das Produkt baut, mit der Verifikation als Bottleneck statt der Generierung.
• We Are Now Factory Engineers, Not Product Engineers (öffnet in einem neuen Tab) - LinkedIn-Artikel, der den Anteil automatisch ausgelieferter Änderungen zur Factory-Metrik macht und Softwareproduktion von F&E in die Herstellungskosten verschiebt.
• Welcome to Gas City (öffnet in einem neuen Tab) - Essay mit der These, dass ein kleines Team mit Agent-Packs siebenstellige SaaS-Rechnungen ersetzen kann, indem es die tatsächlich genutzten Features ins Haus holt.

Posts

• A swarm is not throughput (öffnet in einem neuen Tab) - LinkedIn-Post, der eine Änderung erst zählt, wenn Kund:innen sie nutzen, und ein Token-Budget als Investitionsentscheidung behandelt.

Tools und Repositories

• Software Factory: the Memo experiment (öffnet in einem neuen Tab) - Onas öffentliches Experiment, die Memo-App über eine Factory zu bauen. Die Betriebsseite brauchte dabei mehr Automationen als die Build-Seite.