Autonome Software Factory: was sie voraussetzt und wo ihre Grenzen liegen

Was wir unter einer autonomen Software Factory verstehen

Mit dem Begriff meinen wir einen Ablauf, in dem Coding-Agenten klar abgegrenzte Aufgaben vom Issue bis zur gemergten Änderung übernehmen, nach Regeln, die Ihr Team schriftlich festgelegt hat. Eine schriftliche Spezifikation beschreibt die Aufgabe, der Agent arbeitet in einer isolierten Umgebung, und über den Merge entscheiden deterministische Checks und Menschen. Den größten Teil der Factory bildet alles rund um den Agenten: Aufgabeneingang, Queue, Umgebungen, Gates, Merge-Policy und Feedback.

Ältere Bedeutungen des Begriffs

Der Begriff ist älter als Coding-Agenten. Das US-Verteidigungsministerium beschreibt eine Software Factory als Zusammenspiel von Menschen, Tools und Prozessen, das kontinuierlich Software ausliefert, mit CI/CD-Pipelines als Fertigungsstraßen. Manche IT-Dienstleister verwenden das Wort für ein strukturiertes Modell ausgelagerter Softwareentwicklung. Schon zwischen den späten 1960er- und den späten 1970er-Jahren bauten Hitachi, Toshiba, NEC und Fujitsu Softwarefabriken auf, um ihre Prozesse zu standardisieren und bewährte Tools und Methoden unter ihren Mitarbeitenden zu verbreiten.

Die agentische Variante übernimmt von der klassischen Softwarefabrik die Pipeline und den standardisierten Prozess und ergänzt Agenten, die die Änderungen schreiben. Damit verlagert sich das schwierige Problem in die Verifikation, denn die Factory muss Arbeit prüfen, bei deren Entstehung niemand zugesehen hat.

Dark Factories in der öffentlichen Diskussion

Manche Veröffentlichungen gehen weiter. Im Januar 2026 stellte Dan Shapiro eine Stufenskala für KI-gestützte Entwicklung vor, deren oberste Stufe er Dark Factory nennt: eine Blackbox, die aus Spezifikationen Software macht, benannt nach Fabriken, in denen Roboter arbeiten und Menschen nicht gebraucht werden. Im Februar 2026 beschrieb StrongDM die Software Factory seines KI-Teams, in der Spezifikationen und Szenarien die Agenten steuern und die erklärte Regel gilt, dass Menschen den Code weder schreiben noch reviewen. Validiert wird dort mit End-to-End-Szenarien, die oft wie ein Holdout-Set außerhalb der Codebasis liegen, und mit Verhaltensnachbildungen der Drittanbieterdienste, von denen die Software abhängt.

Was eine Software Factory nicht verspricht

Wir bauen keine Dark Factories und versprechen keine Produktion ohne Menschen. In Aufgabentypen, die sich dafür eignen, übernehmen Agenten einen großen Teil des Schreibens. Menschen geben weiterhin die Richtung vor, tragen das Risiko jedes Aufgabentyps und verantworten, was in Produktion geht, einschließlich Incidents und Reverts.

• Welche Aufgabentypen die Factory übernehmen darf und welche nicht
• Die Spezifikation jeder Aufgabe, von einem Menschen geschrieben oder freigegeben
• Die Merge-Policy, ihr Owner und jede Änderung daran
• Das Review von Änderungen am Harness, an den Gates und an der Policy selbst
• Stichproben gemergter Arbeit, auch bei Aufgabentypen, die nach bestandenen Checks mergen
• Die Entscheidung, die Factory anzuhalten

Autonomie kann Aufgabentyp für Aufgabentyp wachsen. Gehen Patch-Updates von Abhängigkeiten über einen vereinbarten Zeitraum ohne Befund durchs Review, kann der Owner festlegen, dass sie nach bestandenen Checks ohne weitere Freigabe gemergt werden. Diese Entscheidung steht im Code, hat einen benannten Owner und lässt sich mit einer einzigen Änderung zurücknehmen.

Die Stufen davor

Auf dem Weg, den wir beschreiben, ist die Software Factory die letzte von vier Stufen. Beim Agentic Coding arbeiten Agenten an der Seite aller Engineers, mit Budget und einem gemeinsamen Harness in jedem Repository. In der optimierten Stufe wird jede Änderung an diesem Setup, vom Standardmodell bis zur Anweisungsdatei, an Ihrem eigenen Code gemessen. Die Factory betreibt dasselbe Setup, ohne dass ein Mensch jeden Lauf beobachtet, und erbt deshalb jede Lücke, die frühere Stufen offen gelassen haben.

Wer eine Stufe überspringt, scheitert meist auf erkennbare Weise. Ohne gemeinsamen Harness können Agenten nicht aus einem sauberen Checkout bauen und testen, und die Factory liefert plausible Änderungen, die niemand verifizieren kann. Ohne Messung kann niemand sagen, ob Änderungen aus der Factory weniger kosten als die eines Engineers oder mehr Nacharbeit verursachen, und so läuft die Factory entweder ungeprüft oder wird nach der ersten schlechten Woche abgeschaltet.

Der DORA-Report 2025, im September 2025 von Google Cloud vorgestellt, fand weiterhin einen negativen Zusammenhang zwischen KI-Einsatz und der Stabilität der Softwareauslieferung. Die Autoren schreiben, dass ohne starke automatisierte Tests, ausgereifte Versionskontrolle und schnelle Feedback-Schleifen ein höheres Änderungsvolumen zu Instabilität führt. Eine Factory erhöht das Änderungsvolumen bewusst, deshalb müssen diese Kontrollen stehen, bevor sie startet.

Agentic SDLCEinführung von Coding-Agenten

Bausteine einer KI-Software-Factory

In einer agentischen Software Factory ist der Agent der kleinste Baustein. Jede Aufgabe durchläuft dieselben Stationen in derselben Reihenfolge, und jede Station braucht einen Owner in Ihrem Team.

1. 1

   Aufgabeneingang mit schriftlicher Spezifikation

   Eine Aufgabe kommt als Issue mit Spezifikation an: erwartetes Verhalten, betroffene Dateien, Art der Verifikation und was nicht dazugehört. Code prüft die Zulässigkeit anhand von Labels, Pfaden und Aufgabentyp, und Issues ohne Spezifikation bleiben bei Menschen.

2. 2

   Queue und Orchestrierung

   Eine Queue hält zulässige Aufgaben bereit. Der Orchestrator startet Läufe, wiederholt sie innerhalb fester Grenzen und bricht jeden Lauf ab, der sein Zeit- oder Kostenbudget überschreitet.

3. 3

   Eine isolierte Umgebung pro Lauf

   Jeder Lauf bekommt einen frischen Workspace, auf die Aufgabe begrenzte Zugangsdaten und nur den Netzwerkzugriff, den er braucht. Nichts wird von einem Lauf in den nächsten übernommen.

4. 4

   Der Harness

   Anweisungen, Build- und Test-Befehle, Tools und Berechtigungen bestimmen, was der Agent sieht und was er tun darf. In unbeaufsichtigten Läufen übernehmen die Berechtigungen die Aufgabe, die sonst ein zuschauender Engineer hätte.

5. 5

   Verifikations-Gates

   Tests, aufgabenspezifische Evaluierungen und ein Review durch eine separate Agenten-Session in frischem Kontext prüfen genau den Kandidaten-Commit. Diese Session bekommt Spezifikation, Diff und Testausgabe, ohne den Verlauf, in dem die Änderung entstanden ist.

6. 6

   Merge-Policy in deterministischem Code

   Ein Programm vergleicht den reviewten Commit mit dem Kandidaten, prüft die geforderten Ergebnisse und holt entweder eine menschliche Freigabe ein oder mergt selbst, wenn der Aufgabentyp dafür freigegeben ist. Der Agent hat an dieser Entscheidung keinen Anteil. Auf GitHub kann Branch Protection genehmigende Reviews, bestandene Status-Checks auf einem aktuellen Branch und eine Merge Queue verlangen und auch für Administratoren gelten.

7. 7

   Feedback in Spezifikation und Harness

   Jeder abgelehnte oder gescheiterte Lauf bekommt eine dokumentierte Ursache, etwa eine unklare Spezifikation, fehlenden Kontext, einen schwachen Test oder eine falsche Berechtigung. Die Korrektur fließt in die Spezifikationsvorlage, den Harness oder einen neuen Check.

Kostenkontrolle, Observability und Audit

• Obergrenzen pro Lauf, pro Aufgabentyp und pro Tag, außerhalb des Agenten durchgesetzt
• Kosten pro akzeptierter Änderung, einschließlich Wiederholungen, abgebrochener Läufe und Review-Zeit
• Ein Log jedes Laufs: Eingaben, Befehle, Tool-Aufrufe, Ergebnisse und die Entscheidung der Policy
• Ein Audit-Trail von jedem Merge zurück zu Issue, Spezifikation, Checks und Freigabe

# Illustrative only: one task type, not a specific tool's format
task_type: dependency-patch-update
eligibility:
  labels: [factory, dependencies]
  allowed_paths: [package.json, pnpm-lock.yaml]
  blocked_paths: [.github/, infra/, AGENTS.md]
  max_files_changed: 4
runs:
  max_parallel: 2
  timeout_minutes: 30
  budget_per_run: from measured baseline
gates:
  - build_and_unit_tests
  - integration_tests
  - fresh_context_review
  - reviewed_commit_equals_candidate
merge:
  mode: human_approval    # the owner may switch to checks_only later
  approvers: [payments-maintainers]
on_failure: record_cause_and_requeue_once

Spec-Driven DevelopmentKI-Code-ReviewSicherheit von Coding-Agenten

Parallele Läufe und fertige Workflows

Den größten Teil ihres Durchsatzes gewinnt eine Factory, wenn mehrere Agenten gleichzeitig laufen, und genau dort wachsen Kosten und Review-Last am schnellsten. Parallele Läufe helfen, wenn sich Arbeit sauber aufteilen lässt: unabhängige Aufgaben aus einer Queue oder mehrere Versuche an einer Aufgabe, von denen der beste bleibt. Wenig bringen sie, wenn die Teile voneinander abhängen, und bei schwachen Gates wird jeder zusätzliche Lauf zu zusätzlichem Review.

Fertige Workflows bringen diese Muster in die Tools, die Engineers ohnehin nutzen. pstack, ein Cursor-Plugin von Lauren Tan, veröffentlicht im Repository cursor/plugins unter der MIT-Lizenz, bündelt mehrere davon. Seine Skills können mehrere Versuche an derselben Aufgabe starten und die stärksten Teile in eine Basis übernehmen, Arbeit auf parallele Worker mit einem gemeinsamen Bericht verteilen oder Reviewer auf verschiedenen Modellen einen Diff angreifen lassen, ohne ihn zu ändern. Ein Setup-Skill schreibt eine Regel, die jeder Rolle ein Modell zuweist. Ein Playbook bringt unabhängige Pull Requests bis zum Merge, mit je einem Agenten als Owner pro Pull Request, der erst nach einem sauberen Urteil paralleler Prüfer und einer ausdrücklichen Freigabe durch die Person mergt, die das Playbook betreibt.

All das sind Anweisungen an den Agenten, die für sich genommen nichts durchsetzen. Ob etwas ohne Menschen gemergt wird, hängt von Ihrer Branch Protection, den erforderlichen Freigaben, der CI und den Zugangsdaten des Agenten ab. Die Zahl paralleler Worker wird pro Aufgabe festgelegt oder aus der Arbeit abgeleitet, also müssen Grenzen für parallele Läufe und Ausgaben aus Ihrem Setup kommen.

• Eine Obergrenze für gleichzeitige Läufe pro Repository und pro Team
• Ein Modell pro Rolle, ausgewählt nach Ergebnissen auf Ihren eigenen Aufgaben
• Kosten pro akzeptierter Änderung für jeden Workflow, verglichen mit einem einzelnen Agentenlauf
• Eine Grenze dafür, wie viele Kandidaten-Änderungen ein Reviewer lesen soll

pstack-Workflowspstack auf CursorKosten von Multi-Agent-Workflows

Welche Arbeit sich zuerst eignet

Beginnen Sie mit Aufgabentypen, die häufig vorkommen, gut spezifiziert sind und sich maschinell prüfen lassen. Ein falsches Ergebnis sollte billig zu erkennen und billig zurückzunehmen sein.

• Updates von Abhängigkeiten, mit gelesenen Release Notes und vollständigem Testlauf
• Mechanische Migrationen, etwa eine umbenannte API oder ein geändertes Konfigurationsformat
• Testabdeckung für Code, dessen Verhalten bereits abgestimmt ist
• Gut spezifizierte Wartung: Lint-Befunde, Deprecation-Warnungen, kleine Bugs mit fehlschlagendem Test

Andere Arbeit bleibt bei Engineers, die dafür weiterhin interaktiv mit Agenten arbeiten können. Unklare Produktarbeit braucht jemanden, der die Anforderung erst beim Bauen herausfindet. Sicherheitskritische Änderungen an Authentifizierung, Autorisierung, Kryptografie oder dem Umgang mit Secrets brauchen einen Menschen, der das Risiko trägt. Architekturentscheidungen prägen alles, was die Factory danach tut, und gehören zu den Menschen, die das Ergebnis warten werden.

Checkliste vor dem Start und was Sie messen sollten

Vor dem ersten unbeaufsichtigten Lauf prüfen wir das Repository, in dem die Factory arbeiten soll. Jeder der folgenden Punkte sollte zutreffen.

• Ein sauberer Checkout baut und testet mit einem Befehl, in der Umgebung, die der Agent nutzt
• Die Tests sind schnell und stabil genug, dass ein Fehlschlag etwas bedeutet
• Harness-Dateien liegen mit Owner in der Versionskontrolle, und Änderungen daran werden reviewt
• Issues des gewählten Aufgabentyps folgen einer Spezifikationsvorlage
• Branch Protection und erforderliche Checks gelten für alle, auch für Administratoren und Bot-Konten
• Ausgaben werden pro Lauf zugeordnet und außerhalb des Agenten begrenzt
• Eine benannte Person kann die Factory anhalten und weiß, wie

Was Sie messen sollten

• Akzeptierte Änderungen pro Aufgabentyp und der Anteil der Läufe, die zu einer führen
• Review-Zeit pro akzeptierter Änderung
• Nacharbeit und Reverts innerhalb eines vereinbarten Zeitraums nach dem Merge
• Fehler in Produktion, die auf Änderungen aus der Factory zurückgehen
• Kosten pro akzeptierter Änderung, einschließlich Wiederholungen, abgebrochener Läufe und Review-Zeit

Verfolgen Sie außerdem die Lieferkennzahlen weiter, die Ihr Team bereits erhebt, etwa Change Fail Rate und Deployment Rework Rate aus DORA. Steigt der Durchsatz, während sich diese Werte verschlechtern, verschiebt die Factory Probleme nur in spätere Phasen.

Klein anfangen: ein Repository, ein Aufgabentyp, eine Queue

1. 1

   Aufgabentyp wählen

   Wählen Sie aus der Liste oben einen Typ, der in einem einzelnen Repository häufig vorkommt. Schreiben Sie seine Spezifikationsvorlage und seine Zulässigkeitsregeln.

2. 2

   Unter Aufsicht laufen lassen

   Lassen Sie die Factory Pull Requests öffnen, während Menschen jeden davon wie gewohnt reviewen. Halten Sie fest, warum ein Lauf akzeptiert, nachgebessert oder abgelehnt wurde.

3. 3

   Ursachen beheben

   Führen Sie jede Ablehnung in die Spezifikationsvorlage, den Harness oder einen Check zurück. Lassen Sie dieselben Aufgaben erneut laufen, um die Korrektur zu bestätigen.

4. 4

   Merge-Policy festlegen

   Halten die Zahlen über einen vereinbarten Zeitraum, entscheidet der Owner, ob dieser Aufgabentyp nach bestandenen Checks mergen darf oder eine menschliche Freigabe behält. In beiden Fällen steht die Entscheidung im Code.

5. 5

   Nächsten Aufgabentyp hinzufügen

   Erst dann kommt ein zweiter Aufgabentyp oder ein zweites Repository dazu, jeweils mit eigenen Obergrenzen und Messungen.

Runmill, ein öffentliches Projekt unseres Gründers, folgt der Regel, die wir auch bei Kunden anwenden: Der Agent schlägt vor, deterministische Checks und Menschen entscheiden. Es nimmt ein zulässiges Issue aus Linear und lässt Claude Code oder Codex in einem isolierten Workspace daran arbeiten. Genau der Kandidaten-Commit muss die erforderlichen Checks und ein Review in frischem Kontext bestehen, bevor ein Pull Request auf GitHub geöffnet wird. Über Pushes, Pull Requests und Merges entscheidet deterministischer Code, nie der Agent, und das automatische Mergen ist in dieser Developer Preview experimentell.

Runmill auf GitHub

Wie wir unterstützen

Wir arbeiten in Ihren Repositories mit den Engineers, die die Factory später verantworten. Zuerst prüfen wir, wo Ihr Team auf dem Weg steht, denn eine Factory auf einem ungemessenen Setup erbt dessen Lücken. Dann richten wir mit Ihrem Plattformteam einen Aufgabentyp vollständig ein: Spezifikationsvorlage, Harness, isolierte Läufe, Gates, Merge-Policy im Code, Kostengrenzen und Messung.

Was Ihr Team behält

• Spezifikationsvorlagen und Zulässigkeitsregeln für jeden Aufgabentyp
• Harness-Dateien und die Merge-Policy in der Versionskontrolle, jeweils mit Owner
• Runbooks, um die Factory anzuhalten, Obergrenzen zu ändern und Aufgabentypen hinzuzufügen
• Messungen pro Aufgabentyp, einschließlich der Kosten pro akzeptierter Änderung

Workshops finden remote oder vor Ort in Deutschland und Polen statt, auf Englisch, Deutsch oder Polnisch, als Team-Sessions in Ihren eigenen Repositories. Danach kann Ihr Plattformteam die Factory ohne uns betreiben und weitere Aufgabentypen hinzufügen.

Harness EngineeringEvaluierungen auf Ihren RepositoriesLLM-Kostenoptimierung