Evidenz für Software Factories und ihre Grenzen

Was öffentliche Umsetzungen belegen

Öffentliche Factory-ähnliche Umsetzungen zeigen, dass der Ansatz machbar ist. Agenten können parallel arbeiten, Pull Requests öffnen, Prüfungen ausführen, auf Fehler reagieren, Änderungen ausrollen und auch nach dem Merge weiterlaufen.

Sie zeigen auch, wohin die Menschen wandern. Engineers verbringen mehr Zeit damit, die Absicht zu beschreiben, Umgebungen zu gestalten, das Feedback zu verbessern und zu entscheiden, welcher Output einen genaueren Blick verdient.

Was sie nicht liefern, ist eine Produktivitätszahl, die sich übertragen lässt. Die meisten Berichte kommen von Modell- oder Plattformanbietern, aus Produkten, die auf der grünen Wiese entstanden, und von Teams, die sich eigene Infrastruktur rund um ihre Agenten bauen können.

OpenAIs internes Produkt

Laut OpenAI entstand eine interne Beta in einem leeren Repository, ohne dass jemand Code von Hand schrieb. Nach fünf Monaten umfasste das Repository ungefähr eine Million Zeilen und rund 1.500 gemergte Pull Requests. Der Bericht nennt im Schnitt 3,5 Pull Requests pro Engineer und Tag und Hunderte interne Nutzerinnen und Nutzer, die das Produkt verwendet haben.

Am wertvollsten sind die Erkenntnisse zum Betrieb. Das Team musste Anwendung, Logs, Metriken und Entwicklungsumgebung für Agenten lesbar machen. Die QA-Kapazität der Menschen wurde zum Engpass. Statt selbst Code beizusteuern, arbeiteten die Engineers an Scaffolding und Feedback.

Einen kontrollierten Vergleich von Qualität oder Geschäftswert gibt es im Bericht nicht. OpenAI hat direkten Zugriff auf die eigenen Modelle und ein eigens für dieses Experiment ausgewähltes Team. Die Zahlen beschreiben, was dieses System hervorgebracht hat. Als Prognose für eine andere Organisation taugen sie nicht.

Onas zehntägige Factory

In zehn Tagen kam Ona nach eigenen Angaben auf 375 gemergte Pull Requests, mehr als 67.000 Zeilen, 1.067 Tests und 87 Prozent autonome Ausführung. Sechzehn eng zugeschnittene Automatisierungen übernahmen Planung, Implementierung, Review, Deployment, Monitoring und Incident-Behandlung.

Die Architektur zählt mehr als die Codemenge. Ona setzte nicht auf einen allgemeinen Agenten, sondern verknüpfte begrenzte Automatisierungen über klare Trigger und Übergaben.

Das Experiment war kurz und startete auf der grünen Wiese. Repository-Aktivität belegt weder, dass das Produkt sinnvoll genutzt wird, noch dass es langfristig änderbar bleibt oder in einem regulierten Unternehmen Ergebnisse bringt. Außerdem verkauft Ona genau die Plattform, mit der gearbeitet wurde.

Delivery-Forschung liefert den fehlenden Kontext

DORA und CircleCI untersuchen breitere Grundgesamtheiten statt einer einzelnen Factory. DORA bringt bessere Ergebnisse mit dem Organisationssystem rund um die Teams in Verbindung. Die Telemetrie von CircleCI zeigt: Beim Median-Team kann mehr Entwicklungsaktivität mit einem schwächeren Fluss auf dem Main-Branch und weniger Stabilität einhergehen.

Aus diesen Quellen folgt, dass Umsetzungsberichte neben Output-Messgrößen auch Delivery-Messgrößen brauchen. Eine Factory kann viele akzeptierte Änderungen erzeugen und den Engpass trotzdem in Review, Integration, Recovery oder Produktentscheidungen verschieben.

Wie hackers&wizards diese Evidenz nutzt

Für hackers&wizards sind externe Berichte Evidenz für die Kategorie und ihre Mechanismen. Für ein Kundenergebnis von hackers&wizards taugen sie nicht als Evidenz.

Unsere öffentlichen Kundenstimmen kommen aus Training, Pilot und Rollout, und jede nennt das Engagement, aus dem sie stammt. Aus einem Assessment ist noch keine darunter.

Jedes Kundenprojekt braucht eine eigene Ausgangslage, eine benannte Datenquelle und ein geschäftliches Ergebnis. Externe Benchmarks können in die Fragen einfließen. Für den Kunden beantworten können sie sie nicht.

Wie stärkere Evidenz aussehen würde

Stärkere Evidenz für eine Factory würde einen definierten Wertstrom über die Zeit mit Delivery- und Geschäftsmessgrößen verknüpfen. Sie würde die Ausgangslage erhalten, den Eingriff zeigen, Review- und Fehlerverhalten dokumentieren und offenlegen, was sich im selben Zeitraum sonst noch verändert hat.

Sie würde auch negative oder neutrale Ergebnisse veröffentlichen. Eine glaubwürdige Evidenzbasis muss zeigen, wo eine Factory den Fluss nicht verbessert hat, wo die Kosten den Nutzen überstiegen und wo menschliche Koordination der bindende Engpass blieb.