KI-Softwarefabrik: was sie ist und wie wir sie betreiben

Eine KI-Softwarefabrik ist ein wiederholbares System, in dem KI-Agenten schriftliche Aufgaben bis zu einem geprüften Pull Request bringen, während Menschen die Absicht vorgeben und entscheiden, was live geht. Die Agenten bauen. Die Fabrik ist alles um sie herum: die Vorgabe, die Prüfungen, die Preview und das Review-Gate.

So entwickeln wir selbst. Bei uns schreibt vor allem KI den Code. Jede Änderung prüft ein Senior, und er steht für die Produktion gerade. Unten lesen Sie, was der Begriff bedeutet, die helle und die dunkle Variante, was eine Fabrik braucht und wie ein Team mit 3 bis 30 Entwicklern anfangen kann.

Was ist eine Softwarefabrik?

Der Begriff hat zwei Bedeutungen, und die Suchergebnisse vermischen sie.

Die alte Bedeutung ist Jahrzehnte alt. Hitachi nannte seine Softwaresparte schon 1969 „Software Works“, und Wikipedia beschreibt eine Softwarefabrik als „eine strukturierte Sammlung zusammengehöriger Software-Assets, die bei der Herstellung von Softwareanwendungen hilft“. In der Praxis meinte das bald eine Firma, die Software im Auftrag nach einem Standardprozess baut: Vorlagen, feste Rollen, dieselben Schritte in jedem Projekt.

Die neue Bedeutung handelt von KI-Agenten. CircleCI definiert sie als „ein System, das technische Absicht über wiederholbare, zunehmend automatisierte Abläufe in Produktivsoftware verwandelt“. Agenten schreiben den Code, Maschinen prüfen ihn, Menschen steuern.

Helle oder dunkle Fabrik?

Dan Shapiro hat fünf Stufen von KI beim Programmieren vorgeschlagen, von der Autovervollständigung bis zur „Dark Factory“, benannt nach Werken, die mit ausgeschaltetem Licht laufen.

Manche Teams sagen, dass sie so arbeiten. Simon Willison schrieb über das KI-Team von StrongDM, zu dessen Regeln „Code darf nicht von Menschen geschrieben werden“ und „Code darf nicht von Menschen geprüft werden“ gehören. Menschliches Review ersetzen sie durch Vorgaben, Szenarien und umfangreiche automatische Tests. Das ist ein ernsthaftes Experiment und passt zu Teams, die Korrektheit fast vollständig maschinell messen können.

Eine helle Fabrik hat dieselbe Automatisierung und fügt eines hinzu: einen Menschen, der das Ergebnis liest, bevor es live geht.

Wo stehen wir? Auf den fünf Stufen von Dan Shapiro liegt unsere Arbeit für Kunden auf Stufe 3 bis 4: Agenten schreiben den Code, und ein Mensch prüft jede Änderung. Unser KI-Kollege bringt Aufgaben auf Stufe 4 bis zum Pull Request, vorerst in unseren eigenen Projekten. Stufe 5, die dunkle Fabrik, wollen wir nicht.

Warum betreiben wir keine dunkle Fabrik?

Weil die Software, die wir bauen, Preise berechnet, E-Mails an Kunden schickt und Unternehmensdaten hält. Tests prüfen, woran jemand gedacht und was er aufgeschrieben hat. Ein Reviewer fragt auch, ob die Änderung für dieses Unternehmen Sinn ergibt, ob sie zum Vereinbarten passt und was passiert, wenn die Daten unordentlich sind.

Bei uns schreibt vor allem KI den Code. Jede Änderung prüft ein Senior, und er steht für die Produktion gerade. Genau dieser zweite Satz ist der ganze Unterschied zwischen unserer Fabrik und einer dunklen.

Review heißt nicht, jede Zeile noch einmal von Hand zu lesen. Die Prüfungen sind schon gelaufen. Der Reviewer schaut auf Absicht, Risiko, Tests und auf die Teile, die eine Maschine nicht beurteilen kann. Deshalb braucht die Fabrik kleine Pull Requests: Fünfzig Zeilen prüft ein Mensch gut, zweitausend schlecht.

Was braucht eine KI-Softwarefabrik?

Die Agenten sind der leichte Teil. Dieselben Modelle kann morgen jeder mieten. Die Fabrik ist die Linie, über die die Arbeit läuft:

• Eine schriftliche Vorgabe mit Abnahmekriterien. Was sich ändern soll, woran Sie erkennen, dass es funktioniert, was nicht dazugehört. Ein Agent liest keine Gedanken, ein Reviewer auch nicht. Wie wir sie schreiben, steht in Spec-driven Development mit KI-Agenten.
• Ein Repository mit verlässlichem Setup und Prüfungen. Ein Befehl installiert, einer startet die Tests, einer baut. Braucht ein neuer Entwickler einen Tag, um das Projekt zum Laufen zu bringen, scheitert auch ein Agent.
• Tests, die vorher fehlschlagen und nachher bestehen. Ein neuer Test muss auf dem alten Code rot sein, sonst beweist er nichts. Mehr dazu in Red-Green-TDD mit KI-Agenten.
• Preview-Deployments. Jeder Pull Request bekommt eine eigene laufende Version, damit der Reviewer die Änderung durchklickt, statt sie sich vorzustellen.
• Ein Review-Gate. Erst automatisches Review, dann ein Mensch. Mergen darf nur ein Mensch.
• Kleine Pull Requests. Eine Aufgabe, eine Änderung, eine Sache zum Prüfen.

Wie wir das von einem Issue bis zum Pull Request verbinden, steht in Harness Engineering in der Praxis. Unseren KI-Kollegen, einen Agenten, der Aufgaben aus dem Backlog bis zum Pull Request bringt, den dann ein Mensch merged, beschreibt diese Fallstudie.

Wo bricht eine KI-Softwarefabrik?

Meist an denselben Stellen wie ein menschliches Team, nur schneller.

• Vage Aufgaben. „Verbessern Sie den Checkout“ ergibt eine selbstbewusste Änderung, die niemand wollte. Eine Fabrik verstärkt unklare Absicht.
• Wackeliges Setup. Bestehen Tests auf einem Laptop und scheitern in der CI, kämpft der Agent mit der Umgebung statt mit der Aufgabe.
• Tests nach dem Code. Sie beschreiben, was der Code tut, nicht was er tun soll, und bestehen per Definition.
• Große Pull Requests. Das Review wird zum Stempel, und der Mensch im Loop ist keiner mehr.
• Regeln im Kopf einer Person. Konventionen, die nicht im Repository stehen, gibt es für einen Agenten nicht. Vieles davon löst eine gemeinsame Regeldatei, siehe Claude Code Best Practices fürs Team.

Wie starten Sie eine KI-Softwarefabrik in einem Team mit 3 bis 30 Entwicklern?

Klein anfangen und an echter Arbeit, nicht an einem Demo-Projekt. In der Reihenfolge, in der wir es tun würden:

Nach ein paar Wochen wissen Sie, wo die Linie hakt: bei den Vorgaben, beim Setup, bei den Tests oder beim Review. Beheben Sie das zuerst, dann kommt die nächste Aufgabenart. Die Fabrik wächst Schritt für Schritt, jeder davon verlässlich.

Ist Ihr Repository bereit für eine KI-Softwarefabrik?

Haken Sie ab, was Ihr Team heute hat.

Möchten Sie eine KI-Softwarefabrik in Ihrem Repository?

Wir richten sie direkt im Repository des Teams ein, als Teil von AI-native SDLC für Entwicklerteams: Regeln, Prüfungen, den Loop und das Review-Gate, an Ihrem echten Backlog. Alles bleibt bei Ihrem Team.

Wir melden uns innerhalb von zwei Arbeitstagen und wählen gemeinsam, was wir zuerst lösen.

Wenn Sie lieber zuerst sprechen möchten, buchen Sie ein 15-Minuten-Meeting mit Filip.

Wo hakt die Arbeit in Ihrem Team heute: bei der Vorgabe, beim Setup, bei den Tests oder beim Review?

Häufige Fragen

Was ist eine KI-Softwarefabrik?

Ein wiederholbares System, in dem KI-Agenten schriftliche Aufgaben bis zu einem Pull Request bringen, der automatische Prüfungen besteht, und Menschen die Absicht vorgeben und entscheiden, was live geht. Die Fabrik ist das System um die Agenten: Vorgaben, ein verlässliches Repository, Tests, Preview-Deployments und ein Review-Gate.

Was ist eine dunkle Softwarefabrik (Dark Factory)?

Das äußerste Ende der Skala, an dem kein Mensch den Code schreibt oder prüft: Vorgaben gehen hinein, Software kommt heraus. Dan Shapiro hat sie nach Fabriken benannt, die mit ausgeschaltetem Licht laufen. Manche Teams sagen, dass sie so arbeiten. Wir nicht, denn bei Software, auf der ein Unternehmen läuft, steht für jede Änderung ein Mensch gerade.

Ist eine Softwarefabrik dasselbe wie ein Softwarehaus?

In der alten Bedeutung ungefähr ja: eine Firma, die Software im Auftrag nach einem Standardprozess baut. Die neue Bedeutung beschreibt, wie Code in jedem Team entsteht: KI-Agenten bauen, Menschen steuern Absicht und Review.

Was braucht ein Team, bevor es eine KI-Softwarefabrik betreibt?

Schriftliche Aufgaben mit Abnahmekriterien, ein Repository, das sich verlässlich aufsetzen lässt und seine Prüfungen ausführt, Tests, die vor der Änderung fehlschlagen und danach bestehen, Preview-Deployments, ein Review-Gate und kleine Pull Requests. Ohne das erzeugen mehr Agenten nur mehr ungeprüften Code.

Wie groß muss das Team sein?

Nicht groß. Ein Team mit 3 bis 30 Entwicklern kann mit einem Repository und einer Art von Aufgaben beginnen. Sehr kleinen Teams mit ein oder zwei Personen reicht meist eine kurze Regeldatei für den Agenten, keine Fabrik.