Die agentische Software Factory erklärt: Geschichte, Architektur und Unternehmenskontrollen

Der Begriff der Saison in der Softwarebereitstellung ist industriell geprägt: die Software-Fabrik – zunehmend die Agentic Software Factory oder KI-Software-Fabrik – ein System, das am einen Ende Signale aufnimmt (Fehlerberichte, Spezifikationen, Kundenfeedback, Geschäftsanforderungen) und am anderen Ende bereitgestellte, verifizierte Software ausgibt. Dabei erledigen Flotten von KI-Coding-Agenten die Arbeit innerhalb einer Feedbackschleife, während Ingenieure die Absichten definieren und die Ergebnisse überprüfen. In der ersten Jahreshälfte 2026 einigten sich mehrere Organisationen auf eine agentenbasierte Wiederbelebung dieser Metapher: BCG Platinion verwendete im März den Begriff „Agentic Software Factory“ und Factory.ai veröffentlichte im Juni sein „Factory 2.0“-Manifest – ein vernetztes End-to-End-System, dessen inkrementelle Einheiten Agenten sind, mit dem Satz, den wir hier zitieren: „Dieses System wird von Ingenieuren gebaut werden und im Gegenzug ihre Software bauen“ (Factory.ai, Juni 2026). BCG Platinion erklärte die „Ära der Agentic Software Factory“ für eröffnet und berichtete, dass einige Organisationen, die dieses Modell betreiben, Produktivitätssteigerungen um das 3- bis 5-fache beschreiben – eine Schätzung der Anwender, kein unabhängiger Branchen-Benchmark. Der offizielle Engineering-Account von Spotify berichtet von mehr als 1.500 agentengenerierten Pull Requests, die in die Produktion übernommen wurden, bei einer Zeitersparnis von 60–90 % für die untersuchten Migrations-Workflows. Und OpenAI berichtete davon, eine interne Beta-Version aus einem leeren Repository heraus aufgebaut und betrieben zu haben, wobei drei Ingenieure die Coding-Agenten steuerten, ohne manuell geschriebenen Code – die rund eine Million Zeilen umfassten Anwendungscode, Tests, CI-Konfiguration, Dokumentation, Observability und interne Tools (BCG Platinion, 2026). Die AI Engineer World's Fair zählte „Enterprise Software Factories“ zu ihren fünf prägenden Trends (AI Daily Brief), und definitorische Leitfäden von Praktikern erscheinen mittlerweile wöchentlich (murraycole.com; Plannotator). Es gibt zahlreiche Anleitungen, die das Fließband erklären. Diese hier befasst sich mit dem Teil, den ein Fertigungsingenieur als Erstes prüfen würde und der meistens ignoriert wird: die Versorgungsinfrastruktur. Eine physische Fabrik ist nur so gut wie ihre Strom-, Wasser-, Mess- und Sicherheitssysteme; eine agentenbasierte Softwarefabrik ist nur so gut wie ihre Modellbereitstellung, ihr Berechtigungsmanagement, ihre Qualitätskontrolle und ihre Ausgabenüberwachung – also die Ebene, die weder aus den Agenten noch aus der Pipeline besteht, die wir in diesem Leitfaden benennen, kartieren und mit einer Checkliste versehen. Wie bei allen unseren Referenzen für neue Technologien werden wir diese Seite aktualisieren, sobald sich das Vokabular und die Praxis weiterentwickeln.

Was ist eine Softwarefabrik? Eine Definition

Eine Softwarefabrik betrachtet die Softwarebereitstellung als Produktionssystem und nicht als Handwerksbetrieb: standardisierte Inputs, ein definierter Montagepfad, Zwischenkontrollen der Qualität sowie wiederholbare, belegbare Ergebnisse. In einer agentenbasierten Softwarefabrik übernehmen Coding-Agenten einen größeren Teil der Planung, Implementierung, Prüfung und Überprüfung, während Ingenieure die Absichten definieren, Akzeptanzkriterien festlegen, den Zugriff steuern und die Ergebnisse prüfen. Dieses Muster kann ganze Stationen automatisieren, Menschen innerhalb von Stationen unterstützen oder begrenzte Teilaufgaben ausführen. Es ist umfassender als ein Coding-Assistent, da es das Produktionssystem um den Agenten herum einschließt, und umfassender als CI/CD, da es die Arbeit innerhalb der Bereitstellungspipeline steuert – nicht nur die Übergänge zwischen den Phasen.

Ein kurzer Rückblick: Von der industrialisierten Wiederverwendung zur agentenbasierten Bereitstellung

Der Begriff hat eine lange Geschichte, und ihre Nachverfolgung erklärt, was neu ist und was nicht. Die Idee der Softwarefabrik reicht mindestens bis zu Robert W. Bemers Vorschlag von 1968 und dem 1975 veröffentlichten Fabrikexperiment der System Development Corporation zurück – disziplinierte, wiederholbare Softwareproduktion auf Basis integrierter Werkzeuge. Microsoft belebte und kommerzialisierte eine verwandte modellgetriebene Formulierung in seinem Buch von 2004 Software Factories – Vorlagen, Referenzimplementierungen und Anleitungen, die bewährte Muster automatisieren. Spätere Unternehmensprogramme, wie das von BMW, übertrugen den Namen auf standardisierte Plattformen, Prozesse und eine gemeinsame Bereitstellungsinfrastruktur, die mehr als 12.000 Entwickler und täglich rund 140.000 CI-Jobs unterstützt. Die Entwicklung im Jahr 2026 ist nicht die Erfindung der Softwarefabrik, sondern eine neue, agentenbasierte Interpretation, bei der autonome Codierungssysteme einen größeren Teil der Arbeit innerhalb des Produktionssystems übernehmen – was Durchsatz, Überprüfungswirtschaftlichkeit, Fehlermodi, Identitätsanforderungen sowie das Verhältnis zwischen Produktionskontrollen und autonomer Ausführung verändert.

Softwarefabrik vs. Coding-Agenten, Loop-Engineering und Plattform-Engineering

Drei Abgrenzungen ordnen den Begriff in seinem Umfeld ein. Im Vergleich zu einem Coding-Agenten: Der Agent ist ein Arbeiter; die Fabrik ist das Produktionssystem, in dem der Arbeiter tätig ist – mit Inputs, Stationen, Qualitätskontrolle und Nachweisen. Ein brillanter Agent in einem undefinierten Prozess ist ein Handwerker, keine Fabrik. Das ist einer der Gründe, warum die berichteten Ergebnisse mit ähnlichen Agenten in verschiedenen Unternehmen so stark variieren. Im Vergleich zum Loop-Engineering: Loop-Engineering – die Disziplin, die unser Leitfaden zum Loop-Engineering behandelt – ist die Kunst eines einzelnen autonomen Prüf-und-Wiederholungs-Zyklus: seine Auslöser, Kontrollen, Budgets und Abbruchbedingungen. Die Fabrik ist die Gesamtheit der Loops im industriellen Maßstab: Viele Schleifen, besetzte Stationen, gemeinsame Qualitätskontrolle, ein einziger Fluss vom Signal bis zur Auslieferung – Loop-Engineering verhält sich zur Software-Fabrik wie das Maschinendesign zur Produktionsanlage. Im Vergleich zum Platform Engineering: Die Golden Paths und die Self-Service-Infrastruktur des Plattform-Teams standardisierten die Arbeitsumgebung für Menschen; die Fabrik übernimmt all dies und verschärft eine Frage, die das Platform Engineering für Service-Accounts, CI-Bots und Maschinenidentitäten längst verwaltet – was passiert, wenn die Entität, die den Golden Path nutzt, ein autonomer Agent mit Zugangsdaten, einem 24/7-Betriebszyklus, höherer Variabilität und ohne Instinkt für Unregelmäßigkeiten ist? Diese Frage bildet den Dreh- und Angelpunkt für die zweite Hälfte dieses Leitfadens, denn die Antwort darauf sind weder mehr Agenten noch eine bessere Pipeline. Es sind Utilities.

Die Software-Fabrik im Unternehmen: Die Utilities-Schicht

Die Rolle von TrueFoundry ist die Utilities-Schicht, deren Umfang sich ehrlich an dem orientiert, was ihre Produkte vermitteln. Teilnehmende MCP-Tool-Aufrufe, die über das MCP Gateway geleitet werden, können zentralisierte Serverregistrierung, Authentifizierung, Autorisierung, Guardrails und Observability nutzen – während direkte APIs, Browserzugriffe, lokale Tools, Shell-Operationen, CI-Systeme und andere Umgehungspfade separate Kontrollen erfordern. Für registrierte MCP-Server können Zugangsdaten zentral verwaltet und injiziert werden, anstatt sie in Agentendefinitionen einzubetten; konfigurierte OAuth-Flows und Auth-Overrides können benutzerspezifische Zugriffe bewahren, sofern unterstützt – TrueFoundry unterstützt aktuelle MCP-Authentifizierungsmuster, einschließlich zentral verwalteter Zugangsdaten, benutzerbezogenem OAuth, Token-Passthrough und konfigurierten Auth-Overrides; die öffentliche Dokumentation weist derzeit unterschiedliche Verfügbarkeitssignale für erstklassige Agentenidentität und OBO-Delegierung auf. Überprüfen Sie daher die Unterstützung für die Zielbereitstellung und -version, bevor Sie sich auf eine vollständige Attribuierung der Benutzer-zu-Agenten-Delegationskette verlassen. Konfigurierte Gateway-Richtlinien können Guardrails auf passende LLM- und MCP-Operationen anwenden; Repository-Tests, statische Analysen, CI-Prüfungen, Sandbox- und Egress-Kontrollen, Merge-Richtlinien und verbundene Evaluatoren bleiben separate Bestandteile des Qualitätssystems. Managed Agent Harness-Läufe können Ausführungstraces bereitstellen, und Gateway-Aufzeichnungen erfassen teilnehmende Modell- und MCP-Operationen. Durchgesetzte AI-Gateway-Budgetregeln können zusätzliche passende LLM-Anfragen blockieren, nachdem konfigurierte Limits überschritten wurden; Warn-only-Regeln sorgen für Transparenz – Rechenleistung, CI-Infrastruktur, Tool-Kosten und nachgelagerte Nebeneffekte erfordern separate Limits.

Die Frage des Fabrikinspektors. In der kritischsten Phase des Systems: Welche Operationen werden vermittelt, welche Identitäten und Berechtigungen gelten, welche Limits werden durchgesetzt, welche Nachweise bleiben erhalten und an welcher Stelle muss ein Mensch die Fortsetzung autorisieren? Eine glaubwürdige Antwort umfasst normalerweise die Agenten-Laufzeit, das Modell-Gateway, das MCP-Gateway, Sandbox- und Netzwerkkontrollen, Quellcodeverwaltung und CI-Richtlinien sowie die nachgelagerten Systeme, die von den Agenten verändert werden können.

Unternehmenskontrollen, die vor der Skalierung evaluiert werden sollten

Welche Modellaufrufe werden über das Gateway vermittelt und welche umgehen es? Wo werden Anmeldedaten gespeichert, injiziert, delegiert und aktualisiert? Welche Aktionen sind MCP-Aufrufe, direkte APIs, Browser-Aktionen, Shell-Operationen oder CI-Jobs? Welche Qualitätsprüfungen sind Gateway-Leitplanken, Repository-Tests, Evaluatoren oder Merge-Richtlinien? Welche Kosten werden durch das AI Gateway begrenzt und welche erfordern Infrastruktur- oder Anbieterkontrollen? Welche Tool-Aufrufe können durch Freigaben im Agent Harness pausiert werden – und welche Freigaben gehören zur Versionsverwaltung, zu CI/CD oder zu nachgelagerten Anwendungen? Dies sind risikobasierte Bewertungskriterien, keine starren Kategorien; die entscheidenden Antworten hängen davon ab, was die Fabrik baut und was sie beschädigen könnte.

Die Zukunft der Software-Fabrik: Was wir beobachten werden

Prognosen mit Vorbehalt. Wir beobachten, ob sich Unternehmen auf einen gemeinsamen Kategorienamen einigen; ob Fabrik-Plattformen auf die Programmierung beschränkt bleiben; wie Repository- und CI-Kontrollen in Agent-Runtimes integriert werden; wie Firmen Fehlerquoten, den Review-Aufwand, Kosten und Rollback-Raten messen; ob herstellerneutrale Modell- und Tool-Schnittstellen zum Standard werden; und wie sich die Verantwortung zwischen Fabrik-Anbietern, internen Entwicklerplattformen und Governance-Infrastruktur aufteilt – eine ähnliche Migration, wie wir sie bei der Loop- und Agentic-Engineering-Entwicklung gesehen haben. Es lohnt sich zu beobachten, ob sich das Fabrik-Modell über den Code hinaus ausdehnt: Das Muster – standardisierter Input, von Agenten besetzte Stationen, Qualitätskontrolle, evidenzbasierter Output – lässt sich ebenso auf die Dokumentenerstellung, die Wartung von Datenpipelines und Sicherheitsoperationen anwenden. „Fabrik“ könnte letztlich zum Begriff für die allgemeine industrielle Form agentischer Arbeit werden, wobei sich die Hilfsprogramme – mit Variationen – in allen Bereichen wiederholen. Es ist zu erwarten, dass die Wirtschaftlichkeit die Diskussion über diese Hilfsprogramme vorantreiben wird: Bei dem von Spotify gemeldeten Umfang (bisher mehr als 1.500 zusammengeführte, von Agenten erstellte PRs) müssen Unternehmen Token-Verbrauch, die Offenlegung von Anmeldedaten und die Revisionsfähigkeit möglicherweise als explizite operative Anliegen behandeln. Es bleibt abzuwarten, ob die Frage „Zeigen Sie mir die Messwerte und Verriegelungen der Fabrik“ zu einer Standardanforderung bei der Beschaffung wird. Ein Konsolidierungsdruck zwischen Fabrik-Anbietern und der Plattform-Ebene ist plausibel, und herstellerneutrale Hilfsprogramme könnten die Wechselkosten senken und es erleichtern, Agenten- oder Modelllieferanten bei fortschreitender Entwicklung auszutauschen: Eine Fabrik, deren Energieversorgung, Leitungen und Messgeräte in Ihrer eigenen Hand liegen, kann ihre Roboter austauschen, während sich die technologische Grenze verschiebt – das ist das Argument der Modellunabhängigkeit, das Factory.ai selbst vorbringt und bis zur infrastrukturellen Konsequenz durchdenkt. Wir werden diesen Leitfaden mit der Reifung der Praxis aktualisieren; eine Hypothese, die es zu prüfen gilt, ist, ob dauerhafte Vorteile weniger aus der Anzahl der Agenten als aus der Qualität des sie umgebenden Produktionssystems resultieren.

FAQ zur Software-Fabrik

Was ist eine Software-Fabrik im Bereich KI?

Eine agentische (KI-)Software-Fabrik ist ein wiederholbares Bereitstellungssystem, in dem Flotten von KI-Coding-Agenten standardisierte, mehrstufige Arbeiten – Planung, Programmierung, Tests, Review – entlang einer definierten Pipeline mit automatisierter Qualitätskontrolle ausführen. Dabei entstehen evidenzbasierte Ergebnisse wie Pull Requests mit bestandenen Prüfungen, während Ingenieure die Absicht definieren, Qualitätsmaßstäbe setzen und die Ergebnisse überprüfen.

Wie unterscheidet sich eine Software-Fabrik vom Einsatz von Coding-Agenten?

Ein Coding-Agent ist ein einzelner Arbeiter oder eine Ausführungskomponente; eine Software-Fabrik ist das umfassendere Produktionssystem drumherum – standardisierte Eingaben, ein definierter Montagepfad, Qualitätskontrollen, Telemetrie und Messung. Die Einführung im Unternehmen hängt daher sowohl von der Leistungsfähigkeit der Agenten als auch von den Workflows, Kontrollen und Nachweisen ab, die sie umgeben.

Ist „Software-Fabrik“ ein neuer Begriff?

Nein. Die Idee der Software-Fabrik reicht mindestens bis zu Bemers Vorschlag von 1968 und dem Experiment von SDC im Jahr 1975 zurück, wurde 2004 in Microsofts Software Factories -Buch neu formuliert und später auf Unternehmens-Bereitstellungsplattformen wie die von BMW angewendet. Was sich mit dem agenten-nativen Revival im Jahr 2026 geändert hat, ist die Arbeitsteilung: Autonome Coding-Systeme übernehmen einen größeren Anteil an Planung, Implementierung, Tests und Review, was Durchsatz, Überwachungsökonomie, Fehlermodi und Identitätsanforderungen verändert.

Welche Infrastruktur benötigt eine Software-Fabrik im Unternehmen?

Unternehmenskontrollen variieren je nach Architektur und Risiko. Zu den allgemeinen Anforderungen gehören ein gesteuerter Modellzugriff, zentral verwaltete Anmeldedaten für beteiligte Tools, Repository- und CI-Prüfungen, konfigurierte Gateway-Leitplanken, Laufzeit- und Anforderungsnachweise, getrennte Limits für LLM- und Infrastrukturausgaben sowie menschliche Autorisierung bei folgenschweren Aktionen. Nicht jede Plattform liefert oder vermittelt notwendigerweise jede Ebene.

Referenzen

• Primäre Quellen — Spotify Engineering, „1,500+ PRs Later“ (Hintergrund zum Coding-Agent, Teil 1) (die Anzahl der zusammengeführten PRs; die 60–90% Einsparungen bei untersuchten Migrations-Workflows); OpenAI, „Harness Engineering“ (die interne Beta, Teamgröße, Repository-Inhalte und die Einschränkung, dass kein Code manuell geschrieben werden darf).
• Geschichte — IEEE Computer Society, Robert W. Bemer (der Vorschlag zur Software-Fabrik von 1968); Die 1975 veröffentlichte Arbeit „Software Factory“ der System Development Corporation (IEEE); Greenfield, Short, Cook & Kent, Software Factories (Wiley, 2004); AWS-Fallstudie, BMW Software Factory (der Maßstab von 12.000 Entwicklern und ca. 140.000 täglichen CI-Jobs).
• Der Begriff und sein Moment — Factory.ai, „Factory 2.0: Von Coding-Agenten zu Software-Fabriken“ (Juni 2026: die Agent-native Definition; Modellunabhängigkeit; das zitierte Statement); BCG Platinion, „The Agentic Software Factory“ (die Einordnung der Ära; 3–5-fache Produktivitätssteigerung; die Zahlen von Spotify und OpenAI); AI Daily Brief zur AI Engineer World's Fair (Unternehmens-Software-Fabriken als prägender Trend); Leitfäden für Definitionen und Anwender: Der Leitfaden von Factory.ai, Plannotator (die Abstammung von Microsoft und BMW aus dem Jahr 2006), murraycole.com (die Ansicht für Anwender; die Geheimnisse und Sandbox-Fragen).
• TrueFoundry-Dokumentation — virtuelle Modelle; MCP-Gateway (offizielles Architekturdiagramm); Leitplanken; Budgets; Analysen und Leitplanken-Metriken (offizielles Bild).
• Dieser Blog — Loop-Engineering auf Unternehmensebene; Betrieb von Loops im Flottenmaßstab; Die Explosion agentischer Tokens in CI/CD; Einsatz von Coding-Agenten im Unternehmen; Spezifikationsgetriebene Entwicklung; OAuth auf der MCP-Ebene; Graphen-Engineering einfach erklärt.

Es wird ein direktes Zitat mit weniger als fünfzehn Wörtern aus der genannten Ankündigung von Factory.ai verwendet, das im Text zugeordnet ist; alle anderen Definitionen, Zahlen und Aussagen von Praktikern – einschließlich der Produktivitätsdaten der BCG und der Zahlen von Spotify/OpenAI, bei denen es sich um die von diesen Organisationen gemeldeten Angaben handelt – sind paraphrasiert und mit Links zu den Originalquellen versehen. „Factory“ ist das Produkt und die Marke von Factory.ai; „Software Factory“ wird hier als der in der Branche übliche Begriff verwendet, der durch die zitierten Quellen etabliert ist, und diese Seite erhebt keinerlei Anspruch auf die Produkte eines bestimmten Anbieters. Die Einordnung als Versorgungsleistung (Utilities) und das Enterprise-Mapping sind redaktionelle Beiträge von TrueFoundry, die auf Funktionen basieren, welche aus der zum Zeitpunkt der Erstellung aktuellen öffentlichen Dokumentation paraphrasiert wurden; die Produktbilder stammen aus der eigenen Dokumentation von TrueFoundry und werden mit Quellenangabe wiedergegeben. Keines der zitierten Unternehmen oder Autoren bewertet oder unterstützt TrueFoundry. Dies ist ein lebendiges Referenzdokument, das überarbeitet wird, sobald sich die Praxis und das Vokabular weiterentwickeln.

‍