Software Factory
Agenten über den ganzen Software-Lebenszyklus koordinieren.
Ein Coding-Agent beschleunigt eine Person. Eine Software Factory koordiniert Agenten über Planung, Umsetzung, Review, Deployment und Betrieb. Menschen setzen die Absicht, verantworten die Regeln und tragen das Ergebnis.
Menschen kuratieren die Absicht | Gates prüfen deterministisch | euer Team betreibt das System
Beispielhafter Factory-Lauf
Factory-Lauf läuftIn 60 Sekunden
Die Factory ist das Delivery-System, nicht der Coding-Agent
Menschen setzen Absicht und Grenzen. Agenten bearbeiten begrenzte Schritte. Deterministische Gates liefern Evidenz. Euer Team besitzt das System und erweitert Autonomie nur dort, wo Feedback und Risiko es erlauben.
Der wandernde Engpass
Mehr Output macht den nächsten Engpass sichtbar
Deployment kommt zuerst: Wenn die Architektur keine häufigen Releases trägt, kann der restliche Flow nicht funktionieren. Steht diese Grundlage, wird Build zum Engpass. Agentic Engineering verschiebt ihn anschließend zu Review, Absicht und Lernen.
Absicht: Arbeit ist nicht klar genug begrenzt. Build: Umgebung und Kontext bremsen die Ausführung. Review: Plausibler Output übersteigt die Urteilskapazität. Deploy: Seltene Releases blockieren jede spätere Verbesserung. Lernen: Produktionsfeedback erreicht den nächsten Lauf zu spät.
- 01
Absicht
Arbeit ist nicht klar genug begrenzt.
Aktueller Engpass
- 02
Build
Umgebung und Kontext bremsen die Ausführung.
Aktueller Engpass
- 03
Review
Plausibler Output übersteigt die Urteilskapazität.
Aktueller Engpass
- 04
Deploy
Seltene Releases blockieren jede spätere Verbesserung.
Aktueller Engpass
- 05
Lernen
Produktionsfeedback erreicht den nächsten Lauf zu spät.
Aktueller Engpass
Der Unterschied
Schnellere Entwicklerinnen und Entwickler machen noch keine schnellere Organisation
Agenten im Editor verkürzen einzelne Coding-Sitzungen. Das Delivery-System darum herum kann trotzdem im alten Takt weiterlaufen.
Verstreute Agenten-Nutzung
Die Produkte sind da, aber jede Person nutzt sie anders.
- Kontext lebt in privaten Sitzungen und verschwindet mit ihnen.
- Der Agent schreibt Code. Planung, Review, Deployment und Betrieb bleiben unverändert.
- Mehr generierter Code trifft auf dieselbe Review-Kapazität. Der Engpass wandert nach hinten.
- Die Organisation kann nicht belegen, was sich in der Delivery verändert hat.
Die Investition verstärkt Lücken, die schon vorher da waren.
Eine laufende Software Factory
Menschen, Agenten, Quality Gates und Feedback arbeiten als ein System.
- Absicht, Kontext, Regeln und Gates liegen im Repository und gelten für jeden Lauf.
- Agenten arbeiten über Planung, Umsetzung, Review, Deployment und Betrieb zusammen.
- Deterministische Prüfungen entscheiden, was weitergeht. Menschen entscheiden, was entstehen soll.
- Delivery-Daten zeigen, was besser geworden ist und wo der nächste Engpass sitzt.
Das Tempo entsteht im System, das alle teilen.
AI schreibt den Code. Im Review staut er sich
Mehr Pull Requests können dieselbe Review-Kapazität überlasten. Eine Factory kann feste Prüfungen und Agenten-Review vor das menschliche Urteil setzen. So landet weniger vermeidbare Arbeit in der Warteschlange.
Der Weg
Individuelles Tempo ist noch keine organisatorische Geschwindigkeit
Coding-Sitzungen können kürzer werden, während Cycle Time, Delivery-Kennzahlen und Backlog sich kaum bewegen. Agenten-Nutzung ist eine frühe Stufe. Der weitere Weg koordiniert Systeme, parallele Läufe und die Delivery-Organisation darum herum.
- L1 Falscher Gipfel
Ad-hoc-Nutzung
- Technisch
- Entwicklerinnen und Entwickler kopieren Code in ein Chatfenster.
- Organisation
- Ein gemeinsames Setup fehlt. Die Ergebnisse hängen von einzelnen Personen ab.
- L2 Falscher Gipfel
Strukturierte Zusammenarbeit
- Technisch
- In jedem Editor arbeitet ein Agentic-Engineering-Produkt. Das Tippen wird schneller.
- Organisation
- Alle schreiben schneller. Das Team liefert trotzdem nicht früher.
- L3 Falscher Gipfel
Agenten steuern
- Technisch
- Agenten schreiben Code innerhalb eines festen Harness. Menschen steuern die Schleife, statt jeden Schritt selbst auszuführen.
- Organisation
- Reviews stauen sich und die Geschwindigkeit stagniert. Der Engpass ist nur weitergewandert.
- L4 Schritt 01
Systeme orchestrieren
- Technisch
- Agenten arbeiten asynchron über Repositories hinweg. Ein Issue löst die Arbeit aus, nicht eine Person an der Tastatur.
- Organisation
- Delivery wird planbarer. Gates fangen offensichtliche Fehler ab. Menschen beurteilen die schwierigen Fälle.
- L5 Schritt 02
Agenten-Flotten führen
- Technisch
- Eine Entwicklerin oder ein Entwickler steuert mehrere dieser Schleifen parallel.
- Organisation
- Eine Person bringt viele Pull Requests pro Tag durch den Merge, ohne jede Zeile selbst zu schreiben.
- L6 Schritt 03
Die Factory betreiben
- Technisch
- Die Pipeline führt Agenten hinter deterministischen Gates durch den ganzen Lebenszyklus.
- Organisation
- Die ganze Organisation liefert. Keine einzelne Person sitzt in jeder Schleife.
Ihr baut die Factory, die das Produkt baut
Eine Software Factory ist das System, das eure Software baut. Engineering-Aufmerksamkeit wandert vom Schreiben jeder Zeile zum Entwurf und zur Steuerung des Systems, das Änderungen erzeugt.
Ein Coding-Agent
Arbeitet in eurem Editor. Ihr startet ihn, beobachtet ihn und prüft jeden Diff, weil fast richtig weiterhin falsch ist. Das Tippen wird schneller. Der Engpass bleibt.
Eine Factory aus Agenten
Kann begrenzte Schritte im Lebenszyklus nach Zeitplan oder Trigger ausführen. Menschen lesen die Belege, steuern die Regeln und verantworten, was ausgeliefert wird.
Deterministische Orchestrierung
Code verbindet die Agenten, nicht improvisierte Prompts. Jeder Lauf ist wiederholbar.
Automatisierungs-Ratsche
Wiederholte Korrekturen können zu Regeln oder Tests werden. Spätere Läufe starten dann mit nützlicherem Kontext.
Der Lebenszyklus
Was zwischen Absicht und Produktion passiert
Die Kette beginnt mit kuratierter Absicht und endet nicht am Merge.
Absicht
Kuratierte Absicht und Planung
Menschen entscheiden, was entstehen soll, und schreiben es so auf, dass Agenten es lesen können. Anforderungen, Kontext und Grenzen werden zu einem Plan, den ein Mensch vor der Umsetzung prüft.
Umsetzung
Umsetzung und Tests
Agenten schreiben Code und Tests innerhalb der Architektur und der Regeln des Teams. Jede Änderung bringt den Nachweis mit, dass sie sich wie beabsichtigt verhält.
Konvergenz
Review und Konvergenz
Automatische Prüfungen, Agenten-Review und menschliches Review arbeiten an derselben Änderung. Was nicht den Standards des Teams entspricht, geht zurück in die Planung.
Betrieb
Deployment und Betrieb
Die Kette reicht bis ins Monitoring und in die Fehlerbehebung. Signale aus der Produktion fließen in die nächste Planung ein.
Technische Leitplanken
Die Kontrollen, die Agenten in sinnvollen Grenzen halten
Das Engineering-System um die Agenten herum bestimmt, wie viel Autonomie es tragen kann.
Kontext
Context Engineering
Domänenwissen, Standards, Beispiele und Grenzen liegen in Schichten im Repository. Jeder Lauf startet mit dem Kontext, den das Team in echter Delivery braucht.
Grenzen
Architekturgrenzen
Domänengrenzen, Module und API-Verträge begrenzen, was eine Änderung berühren darf. Kleine Änderungsradien machen die Arbeit der Agenten leichter prüfbar.
Nachweis
Tests
Tests sind ausführbare Spezifikationen. Sie zeigen Agenten und Menschen, ob eine Änderung hält, ohne allein auf Interpretation zu vertrauen.
Deterministisch
Quality Gates
Build, Typen, Linting, Tests, Sicherheitsprüfungen und Coverage wenden feste Regeln an. Ein Gate prüft Belege. Es stimmt nicht ab.
Lernschleife
Feedback
Wiederholte manuelle Korrekturen werden zu Regeln, Tests oder Beispielen. Jeder Lauf und jeder Vorfall verbessert den Kontext für den nächsten.
In der Factory
Eine klare Pipeline von der Planung bis in den Betrieb
Das Referenzdiagramm zeigt Agenten, menschliche Entscheidungen, Plattformen und Rückkopplungen eines möglichen Factory-Laufs. Es ist ein Entwurfsmodell und kein laufendes Kundensystem.
- Menschliche Absicht: Definiert die Produktabsicht, eröffnet Arbeit, beantwortet Eskalationsfragen und startet eine Remote-Session, wenn fortlaufendes Urteilsvermögen nötig ist.
- Feature-Planer: Sichtet neue Arbeit, prüft die Absicht, klassifiziert das Risiko und leitet ausreichend klare Aufgaben ins Backlog weiter.
- Feedback-Auswertung: Verbindet Feedback und Nutzungssignale und eröffnet daraus Verbesserungen oder priorisierte Fehler mit den zugehörigen Belegen.
- Produktverbesserung: Prüft das laufende Produkt. Verbesserungen mit geringem Risiko kommen ins Backlog, Änderungen mit hohem Risiko warten auf einen Menschen.
- Menschliche Klärung: Erkennt die menschliche Antwort auf eine eskalierte Aufgabe und führt sie erneut durch die Triage, statt sie blockiert liegen zu lassen.
- Prüfung blockierter Arbeit: Findet beanspruchte Arbeit, die nicht mehr vorankommt, gibt sie für einen neuen Lauf frei oder eskaliert wiederholte Fehler.
- Feature-Umsetzung: Übernimmt ein Feature, setzt es nach den Regeln des Repositories um, führt Tests aus und öffnet einen Pull Request.
- Fehlerbehebung: Übernimmt einen priorisierten Fehler, reproduziert ihn, behebt ihn, prüft das Ergebnis und öffnet einen Pull Request.
- Remote-Sessions: Ein Mensch und ein Agent arbeiten live an Architektur, Debugging, Refactoring oder anderer Arbeit, die fortlaufendes Urteilsvermögen verlangt.
- PR-Review: Prüft die Änderung gegen Absicht, Repository-Regeln und Testbelege und meldet die Ergebnisse vor dem Merge.
- PR-Begleitung: Findet festgefahrene Pull Requests, stößt ihre Prüfung an und schließt doppelte Arbeit, bevor die Warteschlange wächst.
- CI: Führt deterministische Builds, Tests, Sicherheitsprüfungen und weitere Fitness Functions aus und meldet den Status an das Review.
- Deployment-Plattform: Baut und veröffentlicht die gemergte Änderung in einer produktionsnahen oder produktiven Umgebung.
- Deployment-Workflows: Führt die Post-Merge-Workflows aus und informiert die Verifikation, sobald ein Deployment bereitsteht.
- Post-Merge-Prüfung: Prüft die ausgerollte Änderung direkt nach dem Merge und eröffnet einen priorisierten Fehler, wenn sie sich in Produktion falsch verhält.
- UI-Prüfung: Bedient die ausgerollte Oberfläche in einem echten Browser und macht sichtbare Regressionen zu bearbeitbarer Arbeit.
- Incident Response: Untersucht einen Incident, identifiziert die wahrscheinliche Ursache und führt Hotfix oder Folgearbeit zurück in die Planung.
- Performance-Monitoring: Beobachtet die Laufzeit-Performance und eröffnet belegte Arbeit, wenn eine Regression ihren Grenzwert überschreitet.
- Automationsprüfung: Findet wiederholte manuelle Korrekturen, aktualisiert Factory-Regeln und markiert festgefahrene Review-Pfade.
- Tägliche Metriken: Erfasst täglich Durchsatz, Autonomie und CI-Zustand, damit die Factory anhand von Belegen geprüft werden kann.
- Wöchentlicher Rückblick: Verbindet die täglichen Snapshots zu einem wöchentlichen Bericht darüber, was ausgeliefert wurde, fehlschlug und sich im System änderte.
- Update-Entwurf: Macht aus geprüften Delivery-Daten einen freigabefertigen internen oder öffentlichen Bericht, statt eine Erfolgsgeschichte zu erfinden.
Scrollt horizontal durch die statische Pipeline.Wischt horizontal durch die statische Pipeline.
Das Diagramm zeigt Entscheidungen und Grenzen. Es bildet kein laufendes System ab und verändert sich mit der Arbeit.
Snapshot aus dem Factory-Dashboard
Die Linie bleibt beobachtbar. Durchsatz, Autonomie und CI-Zustand zeigen, wo sich das System bewegt und wo es Aufmerksamkeit braucht.
Zeit bis zum Abschluss eines Issues
| <15m | 49 |
|---|---|
| 15-30m | 68 |
| 30-60m | 69 |
| 1-2h | 51 |
| 2-4h | 39 |
| 4-8h | 8 |
Zeit bis zum Merge eines Pull Requests
| <5m | 188 |
|---|---|
| 5-10m | 123 |
| 10-20m | 38 |
| 30-60m | 20 |
| 1-2h | 6 |
Autonomie und CI-Zustand
| Tag | Autonom % | CI erfolgreich % |
|---|---|---|
| Apr 14 | 97% | 98% |
| Apr 16 | 86% | 98% |
| Apr 18 | 85% | 98% |
| Apr 20 | 82% | 97% |
| Apr 22 | 87% | 98% |
| Apr 24 | 85% | 94% |
| Apr 26 | 85% | 50% |
| Apr 28 | 85% | 98% |
| Apr 30 | 85% | 98% |
Erfasst über neun Factory-Läufe im April. Dieser interne System-Snapshot ist weder Kundenergebnis noch Live-Feed.
Warum es funktioniert
AI verstärkt, was schon da ist
DORA beschreibt AI-gestützte Entwicklung als Verstärker des umgebenden Systems. Die Factory-Arbeit richtet sich auf dieses System: Kontext, Qualität, Feedback und Verantwortung.
- Vertrauen in AI
- Eine gute interne Plattform
- Daten, die Agenten lesen können
- Fokus auf Nutzerinnen und Nutzer
- Automatisierte Leitplanken
-
Für Modellwechsel entworfen
Wir trennen Kontext und Gates von einem einzelnen Modell, soweit die gewählten Integrationen das erlauben. Ein Wechsel braucht trotzdem eine Prüfung an eurem Code und euren Abnahmekriterien.
-
Eure freigegebene Grenze
Der Umgang mit Code, Datenstandort und Modellzugriff folgt Betriebsmodell, Anbietern, Datenklassifizierung und Sicherheitsregeln, die eure Organisation freigibt.
-
Wissen geht an euer Team über
Vereinbarter Kontext, Konfigurationen, Gates, Pipelines und Dokumentation bleiben in euren Repositories. Interne Verantwortliche lernen, sie zu betreiben und zu verbessern.
Organisation und Verantwortung
Das technische System braucht ein Operating-Modell
Eine Factory verändert, wer entscheidet, wer steuert und wer das Delivery-System nach dem Piloten besitzt.
Steuerung
Menschen kuratieren die Absicht
Produkt- und Engineering-Verantwortliche wählen Ergebnisse, Grenzen und akzeptable Risiken. Agenten können Pläne vorschlagen. Menschen bleiben für die Produktion verantwortlich.
Entscheidungsrechte
Regeln haben benannte Verantwortliche
Architekturgrenzen, Quality Gates und Eskalationswege brauchen Menschen, die sie ändern dürfen, wenn die Belege eine andere Entscheidung verlangen.
Übergabe
Euer Team besitzt die Factory
Kontext, Agenten-Konfiguration, Gates, Pipelines und Dokumentation bleiben in euren Repositories. Interne Verantwortliche lernen, das System ohne uns zu betreiben und zu verbessern.
Portabilität
Modelle können wechseln
Kontext und Gates sollten nicht von einem Modellanbieter abhängen. Modelle liefern unterschiedliche Ergebnisse. Deshalb muss jeder Wechsel an eurer echten Arbeit getestet werden.
Die Richtung
Eure Menschen steuern. Die Factory trägt begrenzte Arbeit
Mit einem stärkeren Feedback-System können Menschen weniger Aufmerksamkeit auf Routine-Diffs richten und mehr auf Absicht, Architektur, Risiko und Ergebnisse. Das sichere Maß an Autonomie hängt von Codebasis, Quality Gates, Betriebsmodell und Betriebsverantwortung ab.
Wir prüfen diese Praktiken in Produktionsarbeit und übertragen, was im Kontext des Kunden standhält.
Die hycle-Hypothese lesenEngagement-Folge
Von der Diagnose zur Factory in eigener Verantwortung
Das Assessment findet den ersten Engpass. Das Team-Training baut gemeinsame Praktiken auf. Ein Pilot prüft das System in einem echten Wertstrom. Der Rollout erweitert, was die Belege tragen. Die Community unterstützt Entwicklerinnen und Entwickler neben diesen Engagements.
-
01 | Diagnostizieren
Ein Entscheidungspunkt mit Belegen und priorisierter Roadmap.
Factory Readiness Assessment
Baseline erheben, den ersten Engpass identifizieren, eine Outcome-Hypothese formulieren und den nächsten Schritt entscheiden.
Assessment im Detail -
02 | Befähigen
Gemeinsame Praktiken und ein mögliches Pilot-Team.
Team-Training
Euer Team baut Kontext, Agenten und Quality Gates am eigenen Stack und Code. Die funktionierenden Artefakte bleiben in euren Repositories.
Training im Detail -
03 | Prüfen
Der Scope folgt den Belegen aus dem Assessment.
Factory Pilot
Ein Factory-Slice läuft in einem echten Wertstrom, mit Delivery-Daten und Betriebsgrenzen, die eure Organisation prüfen kann.
Pilot im Detail -
04 | Erweitern
Ein Programm aus den Belegen von Assessment und Pilot.
Rollout & Skalierung
Die Factory wächst in weitere Teams. Plattform-Verantwortung und Operating-Modell ändern sich dort, wo der Pilot den Bedarf belegt hat.
Rollout im Detail
Erfahrung hinter der Factory
Unsere Arbeit mit Engineering-Teams prägt, wie wir die Software Factory bauen. Die Organisationen unten haben mit h&w gearbeitet. Moonfare zeigt, wie sich Agentic Engineering in einem Team verbreitet hat. Beim Hamburg Innovation Award 2026 stand die Software Factory in der Kategorie START im Finale.
Wir sind von 2 Engineers, die mit Agentic Coding gespielt haben, auf 20 gestiegen, die es täglich nutzen. Wir haben 17 Skills und 9 Agenten entwickelt, die allen Engineers zur Verfügung stehen. Selbst die Skeptiker sind inzwischen dabei. Bis zum Sommer wollen wir tägliche Sprints über den gesamten Entwicklungszyklus hinweg erreichen.
Tom Hibbert VP Engineering, Moonfare
Finalist, Hamburg Innovation Award 2026 (START) Die Software Factory stand 2026 in der Kategorie START im Finale. Was ihr vor dem Bau einer Factory entscheiden solltet
Was unterscheidet einen Coding-Agenten von einer Software Factory?
Ein Coding-Agent arbeitet in der Sitzung einer Person. Eine Software Factory koordiniert Agenten über Planung, Umsetzung, Review, Deployment und Betrieb.
Der gemeinsame Kontext, die Regeln und die Gates gehören dem Team. Die Arbeit verändert damit das technische System und sein Operating-Modell.
Was verantworten Menschen weiterhin?
Menschen entscheiden, was entstehen soll. Sie setzen Grenzen, verantworten Architektur und Quality Gates, prüfen Risiken und tragen die Ergebnisse in Produktion.
Die Factory verschiebt die Aufmerksamkeit der Entwicklerinnen und Entwickler. Sie entfernt keine Engineering-Verantwortung.
Wie verhindert ihr, dass generierter Code die Qualität senkt?
Jede Änderung läuft durch feste Prüfungen wie Build, Typen, Tests, Linting und Sicherheitskontrollen. Menschen konzentrieren ihr Review auf die Entscheidungen, die diese Prüfungen nicht treffen können.
Autonomie wächst nur dort, wo das Feedback-System sie tragen kann. Compliance- und Sicherheitsanforderungen kommen weiterhin aus eurer Organisation.
Bindet uns die Factory an ein Modell?
Kontext, Regeln, Gates und Pipelines können unabhängig von einem Modellanbieter bleiben. Ein Wechsel ist damit möglich, ohne das ganze Delivery-System neu zu bauen.
Gleiche Ergebnisse sind nicht garantiert. Ein anderes Modell muss gegen euren Code, eure Grenzen und Abnahmekriterien getestet werden.
Womit sollten wir anfangen?
Beginnt mit einem echten Wertstrom, der zählt und genug Komplexität hat, um Grenzen sichtbar zu machen. Das Factory Readiness Assessment identifiziert den Kandidaten und den ersten Engpass.
Wie messt ihr, ob die Factory wirkt?
Wir messen PR Throughput, AI Utilization, Change Confidence und Change Failure Rate gegen eine Baseline. Die Organisation benennt zusätzlich das Geschäftsergebnis für den gewählten Wertstrom.
DORA beschreibt AI-gestützte Entwicklung als Verstärker des umgebenden Systems. Deshalb messen wir Delivery-Bedingungen und nicht allein die Produktnutzung.
Vertiefen
Forschung nachvollziehen
Die Wissensebene trennt Definitionen, unabhängige Forschung, Umsetzungsberichte, Methoden und Grenzen. Jeder Artikel zeigt die Quellen hinter seinen Aussagen.
- 01 Was ist eine Software Factory? Das System, seine Verantwortungen und wo Menschen verantwortlich bleiben.
- 02 Warum schnelleres Coding nicht automatisch schnellere Delivery bedeutet Was METR, DORA, CircleCI und DX messen und warum sich ihre Ergebnisse unterscheiden.
- 03 Verifikation in einer Software Factory Deterministische Gates, Agenten-Review, menschliches Urteil und sichere Betriebsmodi.
- 04 Evidenz für Software Factories und ihre Grenzen Was öffentliche Umsetzungen belegen, was nicht und wie h&w eigene Evidenz kennzeichnet.
Findet den ersten Engpass, bevor ihr baut
Das Factory Readiness Assessment erhebt eure Baseline, identifiziert den wichtigsten Engpass und empfiehlt die nächste Entscheidung für einen echten Wertstrom.