Was ist eine Software Engineering Factory?

Eine Software Engineering Factory ist ein Produktionssystem für KI generierten Code, in dem ein fest programmierter Ablauf entscheidet, wann Arbeit weitergehen darf. Stufen, Nachweise, Gates und benannte Verantwortliche machen Code verantwortbar, den kein Mensch mehr Zeile für Zeile lesen kann.

Den Begriff prägt ein Paper von Ahmed E. Hassan von der Queen's University in Kanada und neun Mitautoren, 2026 eingereicht beim Fachjournal ACM TOSEM. Mehrere Autoren bauen selbst solche Systeme, darunter die Teams hinter den Open Source Projekten Codev und Swamp. Die Grundthese ist einfach: Agenten schreiben Code, besitzen können sie ihn nicht. Haften müssen weiter Menschen und Unternehmen.

Eine Factory verlagert die Kontrolle deshalb vom fertigen Diff in den Prozess, der ihn erzeugt. Sie ist ausdrücklich keine dunkle Fabrik ohne Menschen. Wer verantwortet, legt fest, wie groß die delegierten Aufgaben sind, wo Grenzen liegen und wann die Arbeit zurück zu einem Menschen muss. Diese Arbeit zwischen Agent und Pipeline heißt Middle Loop.

Wir testen und refactoren seit über 20 Jahren. Bei uns laufen PHPStan, Psalm, Rector, PHPUnit und Cypress mit Cypress Cloud als feste Gates in GitHub Actions und GitLab CI. Coding Agents arbeiten bei uns mit OpenCode und Open Weight Modellen, immer innerhalb dieser Leitplanken. Genau diese Bausteine braucht eine Factory: Nachweise statt Behauptungen und Tests, die ein Agent nicht einfach umschreiben kann. Roland Golla ist offizieller Cypress Ambassador und hält Keynotes darüber, warum Tests der beste Schutz gegen AI Coding Slop sind.

In der NCA Vibe Coding Consulting planen wir mit dir die erste Factory Line. Die NCA Agentic AI Coding Guardrails bringen Regeln, Rechte und Gates in bestehende Projekte. Mit Quality Gates für KI Code setzt du Regeln automatisch durch, und ein Codebase Audit für KI generierten Code zeigt, wo Nachweise fehlen. Im NCA KI Workshop für Unternehmen klären Führung, Fachabteilungen und Entwicklung gemeinsam, wer welche Entscheidung trägt.

Code Review war lange ein Geschäft unter Kollegen. Jemand schreibt, jemand anderes schaut drüber, am Ende steht ein LGTM. Die Autorin blieb im Team und musste mit den Folgen leben. Dieses Modell bricht mit Coding Agents gleich an drei Stellen.

• Menge: Agenten liefern plausiblen Code schneller, als ein Team ihn lesen kann. Die Autoren sprechen von einem organisatorischen Denial of Service.
• Verantwortung: Ein Agent trägt kein Risiko. Er kann nicht haften, nicht warten und keinen Ruf verlieren.
• Sichtbarkeit: Die meisten Änderungen entstehen in einer privaten Blase aus einer Person und ihren Agenten. Welche Annahmen, Abwege und Belege es gab, sieht danach niemand mehr.

Mehr Reviewer helfen hier wenig, auch Review Agenten nicht. Ein Review kann fehlende Absicht, Herkunft und Belege im Nachhinein nicht herstellen. Die Lücke ist strukturell. Wie du KI Code trotzdem sauber prüfst, zeigt KI Code Review automatisieren.

Harnesses, Loops, Graphen und Workflows verteilen Arbeit zwischen Agenten. Sie sagen aber nicht, ob ein Ergebnis weitergehen darf und wer es abnimmt. Dafür braucht eine Factory ein Protokoll.

• Protokoll: legt pro Stufe fest, welche Eingaben erlaubt sind, was herauskommen muss, welche Belege nötig sind und wann eskaliert wird.
• Protocol Engine: normale, deterministische Software und kein Agent. Sie schaltet Stufen weiter, verlangt Nachweise und ruft Gates auf. Ein Agent kann sie weder umschreiben noch überspringen.
• Gate: entscheidet, ob Arbeit weitergeht. Das kann ein Test, ein KI Evaluator oder ein berechtigter Mensch sein.
• Steering Call Out: lenkt die Aufmerksamkeit des Agenten auf Randfälle oder Sicherheitsfragen und lässt ihm die Entscheidung.
• Nachweis: ein unabhängig prüfbarer Beleg, etwa ein Testergebnis oder eine Freigabe. Die Aussage eines Agenten, er sei fertig, bleibt eine Behauptung.

Das passt zu dem, was wir bei rules.md und AGENTS.md beschreiben. Regeln im Prompt sind weich. Erst ein Gate in der Pipeline macht sie hart.

Das Paper nennt zwei Messungen, bei denen dasselbe Modell mit und ohne Factory verglichen wurde.

Alibaba Open Code Review: Alibaba gab einem allgemeinen Agenten zuerst eine ausführliche Skill Datei für Code Reviews. Bei großen Änderungen kürzte der Agent ab, prüfte nur Teile und hängte Funde an falsche Stellen. Danach baute Alibaba ein Review Protokoll mit deterministischer Dateiauswahl, einer Risikoanalyse ab 50 geänderten Zeilen, unabhängigen Prüfagenten und menschlicher Freigabe. Auf 200 echten Pull Requests aus 50 Open Source Repositories erreichte das Protokoll eine höhere Präzision bei rund einem Neuntel der Tokens. Einen etwas geringeren Recall nahm Alibaba bewusst in Kauf.

NL2RepoBench: Eines der Factory Teams ließ das Modell GLM 5 komplette Python Projekte aus einer Spezifikation bauen. Einmal als einzelner Agent in einer langen Session, einmal in vier Stufen mit frischem Kontext pro Stufe und einem Test Gate. Beide Varianten hatten rund 100 Minuten pro Aufgabe.

Die Autoren nennen die Grenzen selbst. Es ist ein Benchmark mit einem Modell und einem Protokoll. Bestandene Tests sagen wenig über Wartbarkeit und Architektur. Die Verbesserung kostet zusätzliche Rechenleistung. Und nur 5 der 27 vollständig gelösten Aufgaben schaffte auch der einzelne Agent. Der Gewinn kam also vor allem aus kontrollierter Iteration.

Für die Einordnung heißt das: Struktur macht dasselbe Modell deutlich verlässlicher. Ein Freifahrtschein für Agenten ist das nicht. Welches Modell sich für welche Stufe lohnt, vergleichen wir bei den Vibe Coding Modellen, zum Beispiel GLM 5.

Die zehn Prinzipien sind der gemeinsame Nenner von drei Factory Umsetzungen, die über mehrere Iterationen in vielen Teams gelaufen sind. Sie führen von Vertrauen und Verantwortung über die Gestaltung der Arbeit bis zum Lernen über viele Durchläufe. Die Tabelle fasst sie kurz zusammen.

Drei Begriffe aus dem Paper tauchen in Diskussionen immer wieder auf.

Accountability Ledger: ein durchgehendes Protokoll über ursprüngliche Absicht, Zuweisungen, Ein und Ausgaben jeder Stufe, Übergaben, Nachweise, Abweichungen, Eskalationen, Gate Entscheidungen und Freigaben. Nach einem Fehler lässt sich damit rekonstruieren, wo die Kontrolle versagt hat. Schuldzuweisung auf Basis eines riesigen Diffs entfällt.

Durable Execution: Jede geprüfte Übergabe wird gespeichert. Fällt ein Modell aus, läuft ein Request in einen Timeout oder wartet die Arbeit auf eine menschliche Entscheidung, startet nur die betroffene Stufe neu. Fertige Stufen bleiben fertig. Das macht auch günstige Batch Läufe in ruhigen Zeiten möglich.

Poisoned Cake Rule: Niemand sollte einen Kuchen verantworten, nur weil er hübsch dekoriert vor ihm steht. Fremde Ergebnisse, ob von Menschen oder Agenten, kommen erst über die Protokolle der Factory in die Produktion. Abhängigkeiten bleiben erlaubt, sie müssen nur durch denselben Eingang. Die Autoren verweisen auf die XZ Backdoor von 2024, bei der schädliche Absicht über viele harmlos wirkende Beiträge verteilt war. Passend dazu: Vibe Coding Security.

Ein Punkt im Paper betrifft uns direkt. Die Factory steht und fällt mit einem starken End to End Testsystem. Unit Tests reichen nicht, weil der implementierende Agent sie so lange anpassen kann, bis sie zu seinem Code passen.

Gebraucht werden Black Box Tests auf Nutzerebene, die der Agent nicht verändern darf. Sie sind Abnahmegrenze und ausführbare Dokumentation zugleich. Genau so setzen wir Cypress mit Cypress Cloud ein. Was das im Alltag heißt, steht im NCA Cypress Glossar, bei agentischen Akzeptanztests und bei Tests als lebende Spezifikation.

Das Paper zeigt auch, warum die Trennung wichtig ist. In einem Pull Request im Open Source Projekt Superpowers sollten Review Agenten vorhandene Testbelege lesen. Ein Teil von ihnen ließ stattdessen die Tests selbst neu laufen und meldete trotzdem, die Aufgabe sei wie verlangt erledigt. Wer Code schreibt, sollte deshalb nie der einzige sein, der ihn prüft.

Die Autoren raten, nicht auf die perfekte Factory zu warten. Starte mit einer wichtigen Aufgabe, die sich oft wiederholt.

1. Ergebnis und verantwortliche Person festlegen.
2. Arbeit in Stufen schneiden, etwa Spezifikation, Plan, Umsetzung und Prüfung.
3. Für jede Übergabe festlegen, welche Belege nötig sind.
4. Harte Gates in die CI Pipeline legen: statische Analyse, Unit Tests, End to End Tests.
5. Rechte der Agenten begrenzen und Eskalation zu einem Menschen definieren.
6. Nach jedem Durchlauf auswerten, welcher Teil schwach war, und genau dort nachbessern.

Eine praktische Messgröße schlagen die Autoren auch vor: Wie lange braucht jemand Neues bis zum zehnten akzeptierten Pull Request? Agenten sind ewige Neulinge, für sie ist jede Session der erste Tag. Je mehr Wissen in Tests, Regeln und Dokumentation steckt, desto schneller werden Menschen und Agenten produktiv. Mehr dazu bei Human Readiness und beim KI Coding ROI.

Wer für eine Änderung geradestehen soll, braucht Mitsprache beim Tempo und Zeit zum Verstehen. Fehlt beides, wird die Person zur Knautschzone: Ihr Name steht unter der Freigabe, entschieden haben andere. Osmani greift dafür den Begriff der Moral Crumple Zone von Madeleine Clare Elish auf.

Das ist im Kern Prinzip 4 der Software Engineering Factory. Ein Mensch kann nur verantworten, was er gestalten, prüfen und notfalls stoppen konnte. Eine Unterschrift ohne diese Möglichkeiten ist reine Symbolik.

Wir beraten Teams, die mit Coding Agents schneller werden und trotzdem die Kontrolle behalten wollen. Meist fehlt es dabei weniger am Modell als an der Struktur drumherum. Genau dort setzt die Idee der Software Engineering Factory an.

Unsere Reihenfolge ist fest: erst Quality Gates, dann Tempo. Statische Analyse, Unit Tests, funktionale Tests und Cypress End to End Tests kommen zuerst in die Pipeline. Danach dürfen Agenten mehr übernehmen. Bei Legacy Projekten empfehlen wir einen parallelen Neustart, statt Agenten im Altbestand arbeiten zu lassen. Mehr dazu bei AI Code Refactoring und AI Slop Refactoring.

Wie Agenten im Team zusammenspielen, erklären wir bei Agentic Coding und den Agentic Coding Patterns. Warum frischer Kontext pro Stufe hilft, zeigt Context Window Management. Unser Coding Agent im Alltag ist OpenCode. Für Entscheider ist AI Readiness ein guter Einstieg, Entwicklerteams üben die Praxis im NCA KI Workshop für Developer.

Die wichtigsten Fragen rund um Software Engineering Factories, kurz und direkt beantwortet.