Einführung des Software-Fabrik-Modells: Kriechen, Gehen, Laufen

Der Software-Factory-Ansatz (ein geschlossener agentischer Kreislauf, der in der Cloud läuft) gewinnt zunehmend an Popularität, doch seine Einführung kann einschüchternd wirken. In diesem Beitrag stelle ich die Schritte „Krabbeln, Laufen, Rennen“ vor, um den Übergang von lokalen, interaktiven Agenten zur automatisierten Cloud-Entwicklung zu meistern.

Krabbeln

Viele Engineering-Leiter und Plattform-Ingenieure, mit denen ich spreche, haben bereits mit dem „Krabbeln“ beim Aufbau einer Software-Factory begonnen, indem sie einfache Automatisierungen unter Verwendung von Cloud-Agenten erstellen.

Stell dir diese Automatisierungen als Trigger → Agent-Aktivität vor.

Beispiele:

• Issue-Reproduktion und Triage: Ein Agent prüft alle neu eingereichten Issues, reproduziert sie und versieht sie mit Labels.
• Code Review: PRs werden automatisch bei ihrer Erstellung überprüft und kommentiert.
• Monitoring: Ein Agent reagiert auf Sentry-Alerts, debuggt und behebt Probleme.
• Selbstheilendes CI: Kaputte CI-Pipelines werden repariert, indem PRs identifiziert werden, die zurückgerollt oder Merge-Konflikte gelöst werden müssen.
• Automatische Dokumentationsupdates: Benutzerdokumentationen werden aktualisiert und Changelogs generiert.
• Verifizierung: Browser-Use- und Computer-Use-Agenten führen visuelles QA durch und verifizieren Änderungen.
• Einfache Bug-Fixes: Agenten identifizieren und beheben einfache, von Nutzern gemeldete Probleme.

Gemeinsam ist all diesen Ansätzen, dass sie einen diskreten Teil des Software-Lebenszyklus automatisieren. Der Start mit einfachen Automatisierungen ist ein risikoarmer, kostengünstiger Ansatz und hilft dabei, ein Gespür dafür zu entwickeln, wie man Agenten effektiv für komplexere, mehrstufige Aufgaben einsetzt.

Beispielautomatisierung für das Alert-Monitoring

Diese Automatisierungen können auf selbstgebauter Infrastruktur basieren (z. B. durch Integration des Claude Code SDK in einen Docker-Container und Verdrahtung eines Servers zum Auslösen), oder sie nutzen eine generische Cloud-Agent-Automatisierungsplattform, die speziell für das Ausführen von Agenten auf Trigger hin konzipiert ist. Alternativ könnte auch eine gesamte Plattform verwendet werden, die sich auf eine bestimmte Phase des Zyklus konzentriert (z. B. ein dedizierter agentischer Code-Reviewer oder AI SRE).

Ein Flickenteppich aus Punkt-Automatisierungen ist am Anfang völlig in Ordnung, aber die meisten Teams stoßen irgendwann an die Grenzen dieses Ansatzes.

Konkret bedeutet das:

• Je nach Setup teilen diese Automatisierungen möglicherweise keinen Kontext. Das heißt, wenn du Verbesserungen an einem Aspekt vornimmst (z. B. Code Review), übertragen sich diese nicht auf andere Phasen wie Triage und QA.
• Es gibt keine globale Übersicht darüber, ob diese einmaligen Automatisierungen tatsächlich die Gesamtproduktivität steigern, und keinen systematischen Weg, hochrangige Metriken wie Kosten pro PR, Durchlaufzeit, Automatisierungsgrad usw. zu testen und zu verbessern. Um dies zu verfolgen, benötigst du ein System, das über alle Entwicklungsphasen hinweg funktioniert.
• Jede Punktlösung erzeugt ihren eigenen Aufwand für Einrichtung und Wartung. Sie vergrößern die Angriffsfläche für Sicherheitsrisiken. Zudem fehlt eine einheitliche Schnittstelle für Observability. Teams wünschen sich langfristig zentrale Konfiguration, Auditing und Governance.

Laufen

All diese Probleme deuten auf die Notwendigkeit eines ganzheitlicheren Ansatzes hin. Organisationen, die im „Krabbel“-Modus gestartet sind, fragen sich: „Welches System brauchen wir, um die agentische Entwicklung wirklich skalierbar zu machen?“

Genauer gesagt stellen sie folgende Fragen:

• Wo sollte die Entwicklung stattfinden? Lokal oder in der Cloud? Über welche Schnittstellen?
• Wie sieht ein erfolgreicher automatisierter Entwicklungsprozess aus? Was sind die wichtigsten Kennzahlen?
• Wie steht es um unsere KI-Souveränität? Wie wichtig ist es, die Daten unserer Coding-Agenten zu besitzen? Wie abhängig sollten wir von Modell-Anbietern sein?
• Wie planen wir, unseren Entwicklungsprozess kontinuierlich zu verbessern? Wie kontrollieren wir Kosten, während wir gleichzeitig die Geschwindigkeit der Auslieferung erhöhen? Woran erkennen wir, dass wir uns verbessern?
• Wie sichern wir uns für die Zukunft ab, während Modelle und Agenten besser werden? Berücksichtigen wir regulatorische Risiken, die den Zugang zu Modellen beeinträchtigen könnten?
• Wie genau sollen Ingenieure am Entwicklungsprozess teilnehmen? Gilt dasselbe für Designer, PMs und andere Builder?
• Wie sichern wir die Entwicklung ab? Was ist unser Plan, falls unser Software-Produktionsprozess kompromittiert wird?

Die meisten Engineering-Leader und Plattform-Teams, die intensiv über diese Fragen nachdenken, landen bei einem Ansatz ähnlich einer Cloud-Software-Factory. Sie wollen:

• Entwicklung standardmäßig in der Cloud, da es sicherer ist, Agenten Sandboxes bereitzustellen, als sie lokal frei laufen zu lassen.
• Zentralisierte Governance für Coding-Agenten sowie die Tools und Systeme, auf die sie zugreifen.
• Vollständige Nachverfolgbarkeit dessen, was Agenten getan haben, für Audits und zur Bewertung der Produktivität.
• Flexibilität bei Modellen und Harnesses, um Risiken zu minimieren und die Leistung zu optimieren.
• Integration der Entwicklung in alle Tools, die dein Team bereits nutzt (z. B. Slack/Teams, Jira, GitHub usw.).
• Fluchtwege für Menschen, um die Kontrolle zu übernehmen, entweder durch Steuerung live laufender Agenten oder durch Einbringen der Arbeit in den inneren Entwicklungskreislauf.
• Eine gemeinsame Kontextschicht, die über Agenten hinweg in allen Phasen der Entwicklung funktioniert.
• Einen Ansatz, der Tests, Evals und Benchmarks ermöglicht, damit dein Team Vertrauen darin hat, dass sich das System mit der Zeit verbessert.

Sobald sich ein Unternehmen für den Factory-Ansatz entschieden hat, stellt sich die Frage: Wie kommst du von deinen bestehenden Punkt-Automatisierungen dorthin? Dies läuft meist darauf hinaus, ob du (1) mehr Infrastruktur um diese Automatisierungen herum aufbaust oder (2) zu einer Plattform wie Warp Factories wechselst, die Factory-Infrastruktur bereitstellt.

Beachte, dass ich dies nicht als klassische Build-vs.-Buy-Entscheidung betrachten würde. Egal welchen Weg du wählst, solltest du davon ausgehen, dass dein internes Team etwas bauen muss, denn damit der Factory-Ansatz funktioniert, muss die Factory tief in den Kontext und die Workflows deines Teams integriert sein. Es ist eher die Frage, ob du deine Automatisierungsinfrastruktur komplett von Grund auf baust oder dich mit Partnern zusammenschließt, die dir einen Vorsprung verschaffen.

Zum Beispiel solltest du unabhängig vom gewählten Weg damit rechnen, organisationspezifische Skills zu entwickeln und sie auf deine Codebasis abzustimmen. Du solltest damit rechnen, organisationsspezifische MCPs und interne Kontextquellen freizugeben und zu konfigurieren. Aber vielleicht möchtest du keine Cloud-Infrastruktur für das Ausführen und Verwalten von Agenten, deren Steuerung, die Übergabe ihrer Arbeit, die Messung ihrer Wirksamkeit, Computer-Use-Funktionen usw. selbst bauen. Die Faustregel lautet: Konzentriere dich darauf, die Teile zu bauen, die spezifisch für deine Organisation sind, nicht die, die jede Organisation benötigt.

Unabhängig vom Ansatz schlage ich vor, dass der wichtigste Meilenstein in der Lauf-Phase die Bereitstellung einer ersten Factory End-to-End auf einer einfachen Produktoberfläche ist. Dies könnte deine Marketing-Website oder eine interne App sein.

Der Start mit einem einzigen einfachen Projekt hat den Vorteil, dass der gesamte Kreislauf mit geringem Risiko und minimaler Komplexität in Gang gesetzt wird. Das Hinzufügen weiterer Repositories, Zeilen Code, Service-Abhängigkeiten, menschlicher Stakeholder usw. erhöht die Komplexität und kann dazu führen, dass man sich für die Automatisierung noch nicht bereit fühlt. Besser erst einmal einen einfachen Kreislauf perfektionieren.

Das Ziel ist ein Multi-Agenten-System, das von Triage → Spec → Implementierung → Review → Verifizierung → Monitoring reicht. Im Detail:

1. Ein neues Issue geht im System ein, entweder durch einen Menschen oder einen Monitoring-Agenten.
2. Der Triage-Agent führt aus und versucht, das Issue zu verstehen und zu reproduzieren. Wenn er feststellt, dass die Aufgabe automatisierbar ist → übergibt er sie an den Implementierungs-Agenten. Wenn aufgrund des Umfangs Spezifikationen nötig sind → lässt er den Spec-Agenten mit einem Menschen iterieren, um eine Spezifikation zu erstellen. Wenn es mehrdeutig ist → holt er menschliches Feedback ein und startet erneut, oder legt das Issue vorerst auf Eis.
3. [Falls erforderlich] Der Spec-Agent führt aus, ein Mensch überprüft die Spezifikationen und leitet sie dann an den Implementierungs-Agenten weiter.
4. Der Implementierungs-Agent schreibt Code.
5. Der Code-Review-Agent überprüft den Code.
6. Der Verifizierungs-Agent führt Computer-Use oder andere Verifizierungen durch.
7. Ein Mensch überprüft den Code und die Ausgabe der Verifizierung. Falls nötig, geht es zurück zu Schritt 2, 3, 4 oder 5.
8. CI / CD
9. Ship it (Ausliefern)
10. Der Monitoring-Agent führt aus und erstellt bei Bedarf neue Issues, wodurch der Kreislauf geschlossen wird.

Intern bei Warp automatisiert unsere Lauf-Factory etwa 75 % der Änderungen an warp.dev, unserer Marketing-Website. Im Gegensatz zum Warp Terminal (65k GitHub-Stars, fast eine Million aktive Entwickler, 1 Mio. Zeilen nativer Rust-Code) ist unsere Marketing-Website eine ziemlich einfache App. Beachte, dass ich mit „automatisieren“ meine, den gesamten Prozess von der menschlichen Eingabe bis zum ausgelieferten Feature vollständig durch die Factory laufen zu lassen, mit minimalen menschlichen Berührungspunkten neben der Beschreibung der gewünschten Änderung, entweder in Slack oder unserem Task-Tracker.

Rennen

Erst wenn der grundlegende Kreislauf in einem einfachen Projekt etabliert ist, solltest du auf komplexere Projekte skalieren. Das Skalieren von Factories erfordert robustere Infrastruktur.

Konkret treten beim Skalieren bestimmte Engpässe auf:

• Das Einrichten von Remote-Dev-Umgebungen für große Projekte ist schwierig. Mehr Repositories, Zeilen Code und Service-Abhängigkeiten erschweren die Automatisierung.
• Mit zunehmender Anzahl an Skills, Code usw. wird es schwieriger zu beurteilen, ob die Änderungen an deinen Factories positive Auswirkungen auf die Entwicklung haben oder nur unnötiges Hin und Her verursachen.
• Du gehst naturgemäß höhere Kostenrisiken ein, wenn Agenten an komplexeren Codebasen arbeiten, da leistungsstärkere Modelle benötigt werden und die Agenten länger laufen müssen. Modell-Routing und die Wahl des Harnesses werden wichtiger.
• Sicherheit und Auditing gewinnen an Bedeutung, je mehr du den Factory-Ansatz auf geschäftskritische, nutzerseitige Apps ausweitest.
• Mehr App-Stakeholder bedeuten mehr menschliche Koordination und Freigaben. Du wirst eine Factory-Lösung benötigen, die Multi-Player-Eingaben und Audit-Trails ermöglicht.
• Unweigerlich werden sich PRs ansammeln, daher brauchst du eine definierte Strategie dafür, was code-reviewed wird und wie du agentische Verifizierung und QA einsetzt.
• Du wirst robustere Tools benötigen, um den Kreislauf zu schließen und sicherzustellen, dass Änderungen, die in Produktion gehen, von hoher Qualität sind, nicht abstürzen usw.

Skalierte Factories zum Laufen zu bringen wird meiner Meinung nach eine der interessantesten Herausforderungen im Software-Engineering der nächsten Jahre sein; Software-Engineering entwickelt sich zu Factory-Engineering. Organisationen, die ihre Factories robust, zuverlässig und selbstverbessernd gestalten können, werden mehr liefern, bessere Kostenstrukturen haben und einen Wettbewerbsvorteil erzielen.

Damit Factories wirklich rundlaufen, sind erhebliche Investitionen nötig. Bei Warp verstehen wir darunter den vollständigen Aufbau deines Factory-Stacks:

Ich behandle jede dieser Schichten detailliert in diesem Post:

https://x.com/zachlloydtweets/status/2097739116720910619

Einige wichtige Punkte, die vielleicht nicht offensichtlich sind:

• Factories-as-code: Eine der wichtigsten Entscheidungen, die du treffen kannst, ist die Definition deiner Factories als Code. Dies ermöglicht das Testen verschiedener Factory-Konfigurationen, um herauszufinden, welche am effizientesten sind, die höchste Qualität liefern usw.
• Multi-Model & Multi-Harness: Stelle sicher, dass deine Factories in der Lage sind, die neuesten Modelle zu nutzen, sowohl Frontier- als auch Open-Weight-Modelle, und verschiedene Coding-Agent-Harnesses wie Claude Code und Codex einzusetzen.
• Datenhoheit: Stelle sicher, dass du alle Daten, die aus deiner Factory kommen, speicherst und besitzt – dies ist der Rohstoff für die Verbesserung ihres Betriebs.

In einer voll funktionsfähigen Factory ist das Schlüsselmerkmal, dass es sich um ein geschlossenes Kreislaufsystem handelt, das messbar und verbesserbar ist. Dies sollte das Ziel sein. In einem solchen System arbeiten alle vom selben Kontext aus, öffentlich, in einer vollständig auditierten und beobachteten Weise. Die Agenten selbst beobachten die Skills und Konfigurationen, die das System antreiben, und schlagen Verbesserungen vor. Plattform-Ingenieure können das System erweitern, um es in alle internen Systeme zu integrieren. Engineering-Leader können Produktivitätsmetriken sehen und verstehen, welche Änderungen vorgenommen werden, um sie zu verbessern. Das Ganze läuft empirisch, nicht nach Bauchgefühl.

Bei Warp kommen wir dieser Vision näher. Jeden Tag arbeiten wir alle öffentlich, stimmen unsere Factory ab, senken die Kosten und verbessern Durchsatz und Qualität.

Unsere Mission ist es, den besten Engineering-Teams der Welt die Werkzeuge an die Hand zu geben, um ihre eigenen Workflows mit jedem zugrunde liegenden Modell und Harness auf offener Infrastruktur zu bauen, zu messen und zu optimieren. Diese Fähigkeiten helfen Teams, bessere Software schneller und effizienter auszuliefern.

Warp Factories befindet sich derzeit in der Early Access-Phase. Qualifizierte Unternehmen erhalten $10k Factory-Nutzung.