Ich habe eine Software-Fabrik gebaut, die wirklich funktioniert. Das habe ich dabei gelernt.

Softwarefabriken sind in den letzten Wochen in aller Munde. Also habe ich eine gebaut.

Hier ist, was ich gelernt habe, wie sie funktioniert und wie man an einem Nachmittag eine baut.

Meine Ziele

Es musste wirklich einfach sein, etwas, das einfach funktioniert und nicht viel Beaufsichtigung erfordert. Idealerweise würde es vollständig mit meinem bestehenden Claude-Abonnement laufen.

Es klingt naiv, aber im Grunde genommen wird es sich nicht durchsetzen, wenn es nicht einfach in meinen bestehenden Workflow integriert werden kann. Ich möchte das nicht bauen und dann alle meine bestehenden Gewohnheiten ändern müssen, nur um dieses neue System zu nutzen. Ich weiß aus Erfahrung, dass es für mich nicht lange funktionieren wird, wenn das passiert, und in der Bedeutungslosigkeit verschwinden wird.

Also habe ich es nicht als eine große Aufgabe angegangen, sondern in zwei klar getrennte Phasen aufgeteilt:

1. Pre-Triage – Herausfinden, was „zu tun" ist
2. Implementierung – das „Erledigen" der Aufgaben

Im Zentrum steht Linear, die einzige Quelle der Wahrheit für die anstehenden Arbeiten.

Jede Softwarefabrik braucht ein solches zentrales Repository für die zu erledigenden Arbeiten, sei es GitHub Issues, Linear oder etwas anderes. Es sollte das sein, was Sie bereits verwenden, damit es für jedes System leicht erweiterbar ist, um Arbeiten hinzuzufügen, die entweder von Agenten oder Menschen später aufgenommen und abgeschlossen werden können.

Linear mit einem automatisch generierten Issue über die System Health Check-Schleife

Die Pipeline hat bewusst definierte Schnittstellen, die den Prozess des Bauens einer Softwarefabrik tatsächlich handhabbar machen:

1. Arbeit erstellen (Schleifen mit MCPs)
2. Arbeit speichern (Linear)
3. Arbeit abschließen (SDLC-Agent)

Durch die Aufteilung müssen Sie nicht beide Seiten – Pre-Triage und Implementierung – gleichzeitig bauen (und ich rate sogar davon ab, um Over-Engineering zu vermeiden). Linear macht die Schnittstelle zwischen dem, was „zu tun" ist, und dem, was wir gerade „tun", gut definiert und leicht erweiterbar.

Pre-Triage-Schritt

Im obigen Diagramm schreitet die Arbeit von links nach rechts fort. Die linke Seite ist der Ort, an dem Arbeit erstellt wird, und enthält eine beliebige Anzahl von Systemen (entweder Menschen, Agenten oder APIs), die zu dem, was getan werden muss, beitragen. Alle in diesem Pre-Triage-Schritt erstellten Ausgaben werden in unser Linear eingetragen.

Einige Schleifen, die in einer Claude-Cloud-Umgebung laufen

In diesem Schritt haben wir drei Hauptschleifen:

1. System Health Check Loop (d.h. ein Fehlerfinder) – diese Schleife läuft täglich um 5 Uhr morgens und ist mit einigen MCP-Servern verbunden: Posthog für die Fehlerverfolgung; Vercel für Systemdiagnosen; und Linear zum Erstellen von Issues.
2. UX-Verbesserungen und Kundenfeedback-Schleife – diese Schleife läuft wöchentlich am Montag um 9 Uhr und scannt jedes neue Feedback, jeden Kundensupport-Chat von Intercom/Fin und alle Posthog-Sitzungswiederholungen. Sitzungswiederholungen sind eine Goldgrube. Sie können sehen, wo Wutklicks auftreten oder wo Benutzer kämpfen und verwirrt sind.
3. Churn-Analyse-Schleife – diese läuft täglich um 6 Uhr morgens und untersucht jeden Kunden, der in den letzten 24 Stunden auf „Abbrechen" geklickt hat. Sie zieht Zahlungs- und Benutzerdaten von Stripe (einschließlich E-Mail/Standort) und sieht sich dann die Sitzungswiederholung dieses Kunden in Posthog an, um zu sehen, was sie vor der Kündigung getan haben. Wir ziehen ihre Nutzungsdaten von Supabase, um zu sehen, ob es sich um einen falschen ICP handelte, sie nie den „Wow"-Moment erlebt haben oder auf Fehler gestoßen sind. Der Bericht wird an Slack gesendet und der Agent erstellt (oder kommentiert) Issues, wenn sie mit abwandernden Kunden zusammenhängen, um die Priorität zu erhöhen.

Um diese Agenten tatsächlich konsistent auszuführen, habe ich es einfach gehalten und Claude Code Cloud Routines verwendet.

Kein Over-Engineering mit einem Hetzner VPS, einem koffeinhaltigen Mac Mini usw. Es ist bei weitem der einfachste Weg, den ich gefunden habe, um Ihr bestehendes Claude Code-Abonnement zu nutzen und ständig aktive Agenten zu erstellen, die nach Zeitplan oder über ein Webhook-Ereignis ausgelöst werden können. Und an alle, die sagen: „Aber was ist mit Vendor-Lock-in!!" – es ist buchstäblich nur Text. Fühlen Sie sich frei, den Prompt zu kopieren, wohin Sie wollen. Ich wollte nur die einfachste und billigste Lösung, die zuverlässig funktioniert.

Ein weiterer Grund für die Verwendung von Claude Code Cloud Routines ist, dass die Cloud-Umgebungen von Anthropic eine enge Parität mit lokal laufendem Claude aufweisen.

Cloud Claude Routines

Offensichtlich haben sie nicht Ihre Umgebungsvariablen (die bei Bedarf zur Cloud-Umgebungseinrichtung hinzugefügt werden können), aber wenn Sie eine MCP-Verbindung über die Connectors der Desktop-App einrichten, können sowohl Ihre lokale Claude CLI als auch das entfernte Claude sie verwenden, im Gegensatz zu Codex. Das war für mich das Killer-Feature und macht diese Pre-Triage-Agentenschleifen so gut funktionieren. Es macht es auch einfach, eine Reihe von Sitzungen parallel auszuführen, ohne sich um den Arbeitsspeicher Ihres Laptops sorgen zu müssen.

Wenn Sie nur diesen Pre-Triage-Schritt implementieren, werden Sie trotzdem viel Hebelwirkung erzielen, selbst wenn Sie den nächsten Schritt, in dem die Arbeit abgeschlossen wird, nicht bauen.

Fangen Sie klein an mit einer einzigen Schleife, probieren Sie sie aus, verfeinern Sie sie, fügen Sie dann weitere hinzu. Finden Sie heraus, welche Routinen Sie heute erstellen können, die neue, qualitativ hochwertige Arbeit in Ihren bestehenden Issue-Tracker einbringen, und machen Sie dann das, was Sie heute für die Implementierung tun.

Implementierungsschritt

Die grundlegendste Version von Schritt zwei ist, Ihrem Agenten eine Issue-ID zu geben und zu sagen, er solle es erledigen. Das machen die meisten Menschen bereits heute, wenn sie mit Agenten arbeiten. Aber das ist wahrscheinlich nicht das, was Sie wollen, wenn Sie das lesen, denn Sie sind jetzt der Engpass in der Schleife, indem Sie einen Agenten direkt in einer Sitzung starten.

Stattdessen habe ich einen Weg gebaut, um entfernte Claude Code-Sitzungen direkt von Linear aus auszulösen.

Vom Linear-Issue zu Claude

Es funktioniert so:

1. Zuerst identifizieren Sie, wie Sie eine neue Claude-Sitzung auslösen möchten. Bei uns fügen wir ein „auto"-Label zu einem Linear-Issue hinzu, das diese neue Aufgabe startet.
2. Dann sendet Linear ein Webhook-Ereignis an unseren internen Webhook-API-Dienst (eine neu erstellte interne Hono-App), der das Ereignis parst und dann die richtigen Informationen an die Claude Routine weiterleitet.
3. Schließlich sendet dieser leichte API-Dienst eine POST-Anfrage an Anthropic, die die Claude Routine mit einem initialen Prompt auslöst.

Die Verwendung eines „auto"-Labels als Auslöser ermöglicht es uns, die automatische Ausführung neuer Claude-Sitzungen zu steuern.

Standardmäßig enthalten unsere Pre-Triage-Schritte diese „auto"-Labels nicht und erfordern, dass ein Mensch das Label hinzufügt, das den Agenten dazu bringt, mit der Arbeit zu beginnen (Human-in-the-Loop). Deshalb nennen wir Schritt 1 den Pre-Triage-Schritt, weil immer noch etwas herausfindet, woran tatsächlich gearbeitet werden soll, entweder durch menschliche Beteiligung oder durch einen Agenten, der in einer Schleife neue Issues beobachtet und neue Implementierungssitzungen startet.

Da das Hinzufügen eines Labels aber auch einfach von einem Agenten erledigt werden kann, könnten Pre-Triage-Schleifen standardmäßig neue Issues mit dem „auto"-Label erstellen, was eine neue Claude-Sitzung startet. Die Verwendung eines Labels wird zu einer sehr flexiblen Methode, um neue Implementierungsarbeiten entweder automatisch durch einen Agenten oder durch uns Menschen zu starten.

Ein leichter Routing-Dienst zum Starten von Claude-Sitzungen

Da Linear Webhooks unterstützt, funktioniert das ganze „Push bei Hinzufügen eines Labels". Der einzige Nachteil ist, dass wir eine öffentliche API benötigen, die diese Webhooks annimmt und die Ereignisse und Nutzdaten formatiert, um Claude Code auszulösen. Dieser neue Dienst fügt auch die richtigen Authentifizierungsheader hinzu, weshalb Linear die Routine nicht direkt auslösen kann.

Alternativ könnten Sie eine geplante Routine haben, die in regelmäßigen Abständen startet und versucht, alle neuen Issues, die nicht in Bearbeitung sind, mit dem auto-Label zu implementieren.

Für den eigentlichen Routine-Prompt empfehle ich, eine wiederverwendbare Fähigkeit zu erstellen, die den gesamten SDLC durchläuft, etwa mit dem Namen /implement oder /do, die es einfach macht, einfach „/do ISSUE-NNN" zu sagen, was dokumentiert, wie man die Schritte zum Abrufen des Issue-Kontexts, Implementieren der Arbeit, Verifizieren im Browser, Erstellen des PRs und Beobachten von Kommentaren korrekt durchläuft.

Dann kann der Claude-Routine-Prompt, der durch das Linear-Ereignis ausgelöst wird, einen sehr einfachen Prompt haben. Hier ist meiner:

Rufe das bereitgestellte Issue ab und verwende die /do-Fähigkeit, um die angeforderte Änderung zu implementieren und einen Pull-Request zu erstellen. Rufe nur das genau angegebene Issue ab. Wenn es bereits abgeschlossen oder in Bearbeitung ist, stoppe.

Die Issue-Referenz erscheint nicht in dieser Nachricht – sie kommt als separate Folgenachricht, die in ein \<routine-fire-payload>\-Tag eingewickelt ist, und wird unmittelbar nach dieser in derselben Sitzung gesendet. Warte auf diese Nachricht, bevor du entscheidest, ob ein Issue bereitgestellt wurde. Schließe nur dann darauf, dass das Issue nicht existiert oder keines angegeben wurde, nachdem du es in der \<routine-fire-payload>\-Nachricht überprüft hast und bestätigt hast, dass das referenzierte Issue tatsächlich nicht existiert.

Wenn du mit der Arbeit beginnst, kommentiere das Issue, setze es auf "In Progress" und aktualisiere das Issue mit allem Sinnvollen, während du voranschreitest. Stelle immer [Claude] voran bei Kommentaren zu Linear-Issues.

An diesem Punkt haben Sie also parallele Claude Remotion-Sitzungen, die über die API ausgelöst werden, Issues implementieren, PRs erstellen (und hoffentlich ihre Arbeit über Playwright oder Agent Browser verifizieren).

Es ist im Wesentlichen eine vollständige Softwarefabrik, die vollständig beobachtbar ist, während Sie schlafen läuft und vollständig auf Ihrem Claude Code-Abonnement basiert.