Warum ich eine Code Factory gebaut habe
Ich habe Coding-Agenten zunächst so genutzt, wie ich auch andere Entwicklungswerkzeuge nutze: Projekt öffnen, eine Aufgabe beschreiben, das Ergebnis ansehen und den nächsten Schritt anstoßen. Damit konnte ich kleine Apps und Websites entwickeln. Gleichzeitig saß ich oft daneben, während der Agent arbeitete. Ich lieferte Kontext nach, reagierte auf Rückfragen und übertrug Ergebnisse zwischen verschiedenen Werkzeugen.
Mich interessierte, wie sich dieser Ablauf weitergeben lässt. Ein Agent auf meinem Laptop ist an meine aktuelle Sitzung gebunden. Für länger laufende Aufgaben wollte ich eine Umgebung, die unabhängig davon erreichbar bleibt, ob mein Rechner gerade aufgeklappt ist. Dort sollten Aufträge, Projektwissen und Ergebnisse einen festen Platz haben.
Aus ersten Experimenten mit einem persönlichen Assistenten auf einem virtuellen Server entstand deshalb ein größeres System: meine Code Factory. Sie verbindet die Aufnahme einer Aufgabe mit Analyse, Implementierung, Tests und unabhängiger Prüfung. Das Ergebnis soll eine nachvollziehbare Änderung sein, die sich anhand ihrer Anforderungen beurteilen lässt.
Ich nutze dafür vorhandene Werkzeuge. Mein eigener Beitrag liegt darin, sie zu verbinden, Zuständigkeiten festzulegen und die Übergänge so zu gestalten, dass Arbeit weiterlaufen kann. Dazu gehören auch die unbequemen Fragen: Wer darf welchen Zustand ändern? Was passiert bei einem Fehler? Und wann gilt eine Aufgabe wirklich als erledigt?
Die Inspiration: OpenAIs Software Factory
Ein Bezugspunkt war der Artikel Inside OpenAI’s agentic software factory von Gergely Orosz und die dazugehörige Einordnung von Owain Lewis. Der beschriebene Ablauf verbindet Coding, CI, spezialisierte Reviews und die Begleitung einer Änderung bis in den Betrieb. Risiken bestimmen dabei, welche zusätzlichen Prüfungen nötig sind.
Für mich war vor allem die Verbindung dieser Schritte interessant. Ein implementierter Codeabschnitt ist erst ein Zwischenstand. Danach müssen Tests laufen, Rückmeldungen ausgewertet und Ergebnisse übergeben werden. Die Automatisierung sollte diese Übergänge mitdenken.
Mein Aufbau hat einen wesentlich kleineren Rahmen. Ich arbeite mit meinen eigenen Projekten, verfügbaren Agenten-Werkzeugen und einem selbst verwalteten Server. OpenAIs Infrastruktur, Leistungszahlen oder Freigabemechanismen lassen sich daraus nicht auf mein System übertragen. Der Artikel lieferte die Inspiration; die konkrete Umsetzung musste zu meinen Aufgaben und Ressourcen passen.
Wie das System zusammenspielt
Das System läuft auf einem virtuellen Linux-Server. Docker-Container trennen verschiedene Dienste und Laufzeitumgebungen. So können die Komponenten unabhängig von meiner lokalen Entwicklungsumgebung laufen. Diese Trennung erleichtert die Organisation; welche Rechte ein Agent tatsächlich besitzt, hängt weiterhin von seiner Konfiguration und seinen verfügbaren Werkzeugen ab.
Hermes ist mein persönlicher Ansprechpartner. Darüber kann ich Aufträge geben und Ergebnisse erhalten. Paperclip bildet die gemeinsame Arbeitsebene: Aufgaben, Zuständigkeiten und Status werden dort für die beteiligten Rollen zusammengeführt. GitHub bleibt der Ort für Repository, Issue, Codeänderung und Pull Request.
Für Entwicklungsaufgaben ist die CTO-Rolle zuständig. Sie koordiniert den Factory-Ablauf und gibt einzelne Arbeitsschritte an spezialisierte Agenten weiter. Analyse, Implementierung, Test und Review bekommen jeweils einen eigenen Auftrag. Die QA-Rolle übernimmt zusätzliche Prüfaufgaben auf Organisationsebene. Die übergeordnete CEO-Rolle verantwortet operative Freigaben und Eskalationen.
Diese Rollennamen beschreiben Zuständigkeiten in meiner Konfiguration. Die eigentliche Entwicklungsarbeit leisten vorhandene Coding-Agenten wie Claude Code und Codex. Mein Projekt besteht in der Integration dieser Bausteine: gemeinsame Aufgabenwege, Kontext, Übergaberegeln und ein definierter Weg zurück zum Ergebnis.
Vom Issue zum Pull Request
Am Anfang steht eine Aufgabe: zum Beispiel ein Fehler, eine fehlende Funktion oder ein Test, der einen wichtigen Fall noch nicht abdeckt. Bevor ein Agent etwas implementiert, muss klar werden, was sich verändern soll und woran ein korrektes Ergebnis erkennbar ist.
Die Analyse prüft dafür das vorhandene Repository und übersetzt die Aufgabe in einen Arbeitsauftrag mit überprüfbaren Akzeptanzkriterien. Der Implementierungsagent arbeitet anschließend in einem getrennten Git-Arbeitsbereich. Das begrenzt Konflikte mit anderen Änderungen und macht den entstandenen Unterschied nachvollziehbar.
Danach folgt die Testphase. Der Testagent prüft die Anforderungen und darf Tests ergänzen. Seine Rolle ist so begrenzt, dass er den Produktcode nicht selbst passend zu einem grünen Ergebnis repariert. Falls die Umsetzung scheitert, geht der Befund zurück an die Implementierung. Ein weiterer Agent übernimmt das unabhängige Review und verändert den Code ebenfalls nicht selbst.
Erst nach diesen Schritten veröffentlicht die Publisher-Rolle den Pull Request. Die CI führt die im jeweiligen Repository konfigurierten Prüfungen aus. Fehler und Review-Befunde müssen wieder in den Arbeitsablauf zurückfinden. Die Factory definiert dafür begrenzte Korrekturschleifen, damit ein problematischer Auftrag nicht unbegrenzt weiterläuft.
Die Grenze ist ausdrücklich festgelegt: Die Code-Factory-Pipeline merged nicht selbst. Sie liefert eine reviewbare Änderung. In meiner darüberliegenden Organisation liegt die finale operative Freigabe bei der CEO-Rolle und außerhalb des Implementierungsablaufs. Einen Pull Request zu erzeugen, ihn freizugeben und eine Änderung auszurollen sind getrennte Entscheidungen.
Kontext, der die Sitzung überlebt
Ein wiederkehrendes Problem in meiner frühen Arbeit mit Agenten war der Kontext. In einer Sitzung war eine Entscheidung klar; in der nächsten musste ich sie erneut erklären. Sobald mehrere Agenten an einer Aufgabe beteiligt sind, wird eine saubere Übergabe besonders wichtig.
Deshalb gehören Projektregeln, Arbeitsaufträge und Prüfergebnisse zum System. Skills beschreiben wiederkehrende Abläufe. Repository-Dokumentation erklärt den jeweiligen Projektzusammenhang. Aufgaben und Kommentare halten fest, was untersucht wurde, welche Befunde offen sind und was als Nächstes passieren soll.
OpenAI beschreibt in Harness engineering einen dazu passenden Ansatz: eine kurze Orientierung mit Verweisen auf strukturiertes Wissen im Repository. Das hilft mir als Gestaltungsprinzip. Ein Agent braucht einen Einstieg und auffindbare Quellen, damit er Details gezielt nachlesen kann.
Dauerhaft gespeicherte Informationen müssen dabei überprüfbar bleiben. Eine ältere Notiz kann die Absicht beschreiben, während der heutige Code etwas anderes tut. Deshalb behandle ich Dokumentation, Quellcode, CI und beobachtetes Verhalten als unterschiedliche Belege. Ein geschlossener Vorgang allein reicht beispielsweise nicht aus, um sicherzustellen, dass die zugehörige Änderung im Hauptbranch angekommen ist.
Prüfungen und klare Grenzen
Die Rollentrennung soll verhindern, dass eine einzige Agentensitzung ihre eigene Arbeit uneingeschränkt bestätigt. Wer implementiert, ist nicht gleichzeitig der unabhängige Reviewer. Wer einen Pull Request veröffentlicht, erhält dadurch keine Merge-Freigabe. Diese Regeln sind Teil der Agenten-Aufträge; technische Berechtigungen und Repository-Regeln müssen dazu passen.
Auch ein erfolgreiches Review ist kein Beweis für Fehlerfreiheit. Die CI liefert zusätzliche, reproduzierbare Prüfungen, deren Aussage vom jeweiligen Testumfang abhängt. Eine grüne Testsuite kann einen nicht erfassten Fehler übersehen. Deshalb sollte zu jedem Ergebnis erkennbar sein, was geprüft wurde und welche Fragen offen bleiben.
Für den Betrieb gibt es einen eigenen Kommunikationsweg. Routinemeldungen und ungelöste technische Störungen sollen innerhalb der Organisation an die zuständige Rolle gehen. Mein Wake-Gateway kann wiederholte Meldungen zusammenführen und einen internen Vorgang für die CEO-Rolle erzeugen. Die untersuchte Benachrichtigungsroute schickt dabei keine Telegram-Nachricht an mich.
Das ist für den Alltag relevant: Eine Automatisierung, die ständig Bestätigungen verlangt oder dieselbe Störung mehrfach meldet, bindet weiterhin Aufmerksamkeit. Der Aufbau braucht deshalb neben Ausführungsrechten auch Regeln für Rückmeldungen. Schwerwiegende Ausnahmen, neue erhebliche Verpflichtungen oder eine notwendige persönliche Anmeldung bleiben Gründe, mich einzubeziehen.
Ein konkretes Ergebnis aus der Praxis
Ein Beispiel aus einem meiner Lern-App-Repositories zeigt, wie klein ein sinnvoller Factory-Auftrag sein kann. Dort sollte die tatsächliche Funktion zur seitenweisen PDF-Textextraktion direkt testbar werden. Ein Test sollte den Produktcode aufrufen können und nicht nur eine nachgebaute Variante prüfen.
Die entstandene Änderung machte diese Funktion gezielt für Tests zugänglich. Laut Pull-Request-Dokumentation blieb ihr Ablauf erhalten; die Änderung betraf die Benennung und die Kennzeichnung für den Testzugriff. Dazu gehörte ein separates Review, das unter anderem prüfte, ob der Test wirklich die Produktionsfunktion verwendet.
Der Pull Request wurde am 9. Oktober 2026 gemergt. Bei der Recherche für diesen Artikel waren neun erfolgreiche Prüfungen am zugehörigen PR-Stand dokumentiert, darunter Flutter-Tests, Web-Release-Build, Functions-Prüfungen, Rules-Tests und Secret Scan. Zusätzlich wurde geprüft, dass der Merge-Commit weiterhin in der Historie des Hauptbranches liegt.
Das Beispiel belegt eine konkrete gelieferte Änderung und die zugehörigen Prüfresultate. Es sagt nichts über die Fehlerquote aller Factory-Aufträge oder die Qualität der gesamten Anwendung aus. Gerade diese Begrenzung macht den Nachweis brauchbar: Es lässt sich benennen, was geändert wurde, welche Prüfungen liefen und wo das Ergebnis angekommen ist.
Was das System noch nicht beweist
Die Factory ist mein eigener Entwicklungsaufbau. Aus dem bisherigen Einsatz leite ich keine belastbare Prozentzahl für Zeitersparnis oder Qualitätssteigerung ab. Dafür bräuchte es vergleichbare Aufgaben, eine saubere Messung und ausreichend viele Durchläufe. Auch Betriebskosten und Betreuungsaufwand gehören in eine solche Rechnung.
Für diese Fallstudie wurden vorhandene Notizen mit ausgewählten Server-Dateien und einem tatsächlichen Pull Request abgeglichen. Der Paperclip-Health-Endpunkt antwortete bei der Prüfung erfolgreich. Das belegt die Erreichbarkeit dieses Dienstes zu diesem Zeitpunkt. Es ersetzt keinen vollständigen neuen End-to-End-Lauf durch alle Agenten.
Außerdem hängt der Ablauf von seiner Umgebung ab: Modelle haben Limits, externe Dienste können ausfallen, Speicher kann knapp werden und Rollen können zu weitreichende Rechte erhalten. Container allein lösen diese Fragen nicht. Mein System benötigt weiterhin Wartung, überprüfbare Zustände und Entscheidungen darüber, welche Aufgaben es übernehmen soll.
Für die Übertragung in ein Unternehmen müssten dessen Daten, Zugriffsrechte, Infrastruktur und Freigabeprozesse gesondert betrachtet werden. Meine eigene Umgebung ist ein praktischer Ausgangspunkt für solche Gespräche. Ein erfolgreiches Nebenprojekt ist noch kein Nachweis, dass derselbe Aufbau unverändert in einer anderen Organisation funktioniert.
Was ich daraus mitnehme
Für mich steckt der größte Erkenntnisgewinn in der Gestaltung der Übergaben. Eine präzise Aufgabe hilft dem nächsten Agenten. Ein nachvollziehbarer Testbefund hilft dem Reviewer. Ein klarer Status hilft der koordinierenden Rolle. Wenn diese Übergänge fehlen, muss ich selbst wieder die Verbindung herstellen.
Damit verschiebt sich ein Teil meiner Entwicklungsarbeit hin zu Architektur und Prozessgestaltung: Anforderungen konkretisieren, Zuständigkeiten begrenzen, Kontext zugänglich machen und Ergebnisse anhand von Belegen einordnen. Das technische Verständnis bleibt dabei notwendig. Ich muss beurteilen können, ob die Aufgabe sinnvoll zerlegt wurde und ob ein vorgeschlagener Nachweis zur behaupteten Wirkung passt.
Als nächsten Schritt möchte ich abgeschlossene Aufträge systematischer auswerten: Welche Aufgaben laufen ohne zusätzliche Rückfragen? Wo entstehen wiederholt Korrekturen? Welche Prüfungen entdecken tatsächlich Fehler? Diese Beobachtungen sollen bestimmen, wie ich die Factory weiterentwickle.
Das Projekt verbindet deshalb zwei Bereiche, an denen ich gern arbeite: Software selbst entwickeln und Abläufe so gestalten, dass andere Menschen oder Agenten darin sinnvoll weiterarbeiten können.