Die Dark Factory — Televism

Die teuerste Zeit ist die, in der ich zusehe

Meine Arbeitsweise mit dem Coding-Assistenten hat sich eingespielt: Ich komme mit einer Idee, wir diskutieren sie, bis sie umsetzungsreif ist, dann pflegen wir die Doku und danach wird umgesetzt. Committen, pushen, Pipeline, eine zweite Session macht das Review — fertig.

Der Haken sitzt in der Mitte. Die Umsetzung dauert. Manchmal sitze ich zwanzig, dreißig Minuten da und schaue dem Assistenten zu, wie er Datei um Datei abarbeitet. Und das ist genau die Zeit, in der ich eigentlich nichts beitrage. Die spannenden Schritte — die Idee, das Aushandeln des Ansatzes, das saubere Schneiden — die will ich behalten. Das stumpfe Durchziehen ist, wie ich an anderer Stelle schon gestanden habe, ohnehin nie mein Teil gewesen.

Also die naheliegende Frage: Kann das „Machen” nicht einfach woanders laufen, während ich mich um die nächste Idee kümmere? Ich habe für diese fabrikartige Vorstellung intern einen Namen: die Dark Factory — die Halle, in der die Maschinen auch dann weiterlaufen, wenn niemand das Licht anmacht.

Der erste Reflex: „ab in die Cloud”

Der erste Gedanke war: Es gibt doch Claude Code in der Cloud. Man wirft eine Aufgabe rein, sie läuft auf fremder Infrastruktur, man klappt den Laptop zu und bekommt am Ende einen fertigen Branch. Genau das, was ich suche. Und die schöne Nachricht vorweg: Mein Max-Abo reicht dafür aus — man braucht keinen separaten API-Key. Ein einziger Befehl erzeugt einen langlebigen Token, mit dem sich der Assistent auch in einer automatisierten Umgebung mit dem Abo anmeldet.

Ich war also schon halb im Aufsetzen, als ich — bevor ich irgendetwas konfiguriere — den Assistenten die Details habe verifizieren lassen. Gut, dass ich das getan habe.

Die Sackgasse: Cloud-Sessions sprechen nur GitHub

Televism liegt auf GitLab. Und die gemanagten Cloud-Sessions von Claude Code können, so steht es unmissverständlich in der Doku, ihr Repository nur von GitHub klonen und dorthin zurückpushen. Nicht-GitHub-Repos kann man als Bündel hochladen — aber die Session darf das Ergebnis nicht zurückschieben und keinen Merge Request anlegen. Damit ist auch der Rückweg dicht: Man käme mit fertiger Arbeit in der Cloud an und hätte keinen sauberen Weg, sie nach GitLab zu bekommen.

Für meinen Fall heißt das schlicht: Der elegante Ein-Klick-Cloud-Weg fällt aus. Kurz geärgert, dann weitergedacht — denn die Anforderung („losgelöst, ohne mich, auf mein Abo”) ist ja nicht plötzlich weg.

Der GitLab-Weg — und ein Fundament, das alles verändert

GitLab hat seine eigene, offizielle Art, Claude in der Pipeline laufen zu lassen: als CI-Job. Und da wird es interessant, denn hier passt plötzlich alles zusammen:

Die Git-Zugangsdaten sind ohnehin schon da — die Pipeline arbeitet ja im Repo.
Mein Abo funktioniert auch hier, über denselben Token als maskierte Variable.
Und die Pipeline ist zugleich das CI-Feedback, das ich sowieso will.

Beim Durchrechnen kam dann der Punkt, der das ganze Kostenbild umgeworfen hat. GitLab Free schenkt einem 400 CI-Minuten im Monat — und ein einziger halbstündiger Umsetzungslauf frisst davon rund ein Zehntel. Für eine Fabrik, die dauerhaft laufen soll, ist das nichts.

Aber: Diese Minuten zählen nur auf GitLabs eigenen Runnern. Ein eigener Runner — auf meinem Rechner, einem kleinen Server, egal — verbraucht null davon. Unbegrenzt. Und im selben Atemzug lösen sich zwei weitere Probleme in Luft auf: Docker für die Integrationstests läuft dann nativ auf meiner eigenen Maschine, und das Build-Image habe ich vollständig in der Hand. Der eigene Runner ist nicht nur die günstige, sondern die saubere Antwort. Er passt exakt zu dem, was ich für Televism ohnehin will: günstige, privat finanzierbare Infrastruktur statt Enterprise-Cloud.

Wie die Fabrik aussehen soll

Das Bild, das sich daraus ergibt, ist erstaunlich ruhig:

Die kreative Arbeit — Idee, Diskussion, Ansatz — bleibt bei mir, lokal. Ihr Ergebnis ist ein GitLab-Ticket mit einem Umsetzungsplan. Das ist der Übergabepunkt. Ab da übernimmt die Halle:

Ein Implement-Job nimmt den Plan aus dem Ticket, setzt ihn um, committet, pusht einen Branch und öffnet den Merge Request.
Der Push startet die normale Pipeline. Ist sie grün, läuft ein Review-Job, der mir alles ins MR schreibt, was mein finales Review erleichtert — Findings, später vielleicht Screenshots.
Ist sie rot, springt ein Fix-Job an — im Grunde derselbe Assistent, nur mit dem Auftrag „mach die Pipeline wieder grün”. Genau einmal, damit sich die Fabrik nicht in einer Endlosschleife selbst beschäftigt.

Am Ende steht ein MR, den ein Mensch abnimmt. Ich. Das Zusehen beim Tippen ist weg; das Urteil bleibt.

Zwei Ebenen im Ticket: Spec und Plan

Beim ersten größeren Durchlauf ist mir klar geworden, dass „ein Ticket mit einem Plan” zu grob gedacht war. Denn zwei verschiedene Dinge entstehen in der kreativen Phase, und sie haben unterschiedliche Lebensdauer: das Was und Warum — die abgestimmte Spec mit ihren Leitentscheidungen — und das Wie — der konkrete Umsetzungsplan mit Schritten, Dateien und Tests. Beides in eine Ticketbeschreibung zu quetschen vermischt Dauerhaftes mit Wegwerfbarem.

Also habe ich die Übergabe zweistufig gemacht, ganz im Bild klassischer Ticketsysteme: Die Spec wird eine Story, der Umsetzungsplan ein Sub-Task darunter. Ein großes Vorhaben zerfällt in mehrere Sub-Tasks — jeder ist genau eine Umsetzungseinheit, also ein Branch, ein Merge Request. Die Fabrik arbeitet sie nacheinander ab; die richtige Reihenfolge gebe ich vor, weil jeder Lauf frisch von main startet und einen abhängigen Schritt erst nach dem Merge des vorigen sieht.

Zwei Dinge fielen dabei angenehm heraus. Erstens: Der Implement-Job holt sich beim Umsetzen beides — den Plan des Sub-Tasks und die Spec der Eltern-Story. Der Umsetzer sieht das Warum, nicht nur die Schritte. (Ein kleiner technischer Haken steckte im Detail: GitLabs REST-Schnittstelle liefert Sub-Tasks gar nicht aus; sie leben an der GraphQL-API. Ein Zweizeiler mehr im Job — aber ohne die Verifikation vorab hätte ich das erst im roten Lauf gemerkt.)

Und zweitens die Grundsatzentscheidung, die mir am wichtigsten ist: Diese Transitionsdokumente gehören nicht ins Repo. Im Repository will ich immer nur den Endzustand des Projekts sehen — den Code und die Konzepte, die ihn erklären —, nicht tonnenweise Spec- und Plan-Dateien, die beschreiben, wie er einmal entstanden ist. Das Ticketsystem ist der richtige Ort für Übergänge; das Repo ist das Ergebnis. So bleibt beides sauber: die Historie der Entscheidungen im Tracker, die Historie des Codes in Git.

Btw. das passt gut mit dem superpowers skill zusammen.

Der ehrliche Rest

Ganz von selbst läuft noch nichts. Der unangenehmste Teil ist der Funke, der die Fabrik zündet: GitLab macht aus einem Ticket nicht von allein einen Job. Es gibt kein Standard-Mittel dafür. Die erste Ausbaustufe wird deshalb unspektakulär sein — ich starte die Pipeline von Hand und gebe ihr die Ticketnummer mit; den Plan holt sich der Job dann selbst. Ein Klick statt Magie. Der echte, ereignisgetriebene Auslöser kommt obendrauf, wenn sich die Version mit einem Klick bewährt hat.

Und auch das gehört zur Ehrlichkeit: Dass mein Abo im GitLab-Runner wirklich zieht, will ich mit einem trivialen „sag hallo”-Job beweisen, bevor ich in Runner und Image investiere. Erst die billige Gewissheit, dann das Fundament.

Aber die Richtung steht. Und sie fügt sich in ein Muster, das sich durch dieses ganze Projekt zieht: Ich mache eine Sache einmal richtig vor — und der Rest soll skalieren, ohne dass ich dabei sein muss. Bei den Spielfunktionen ist das der Assistent, der ein Muster fortführt. Bei meiner eigenen Arbeitsweise ist es jetzt eine Fabrik, die weiterläuft, wenn ich das Licht ausmache.

Ein Puzzlestück fehlt noch: Momentan reviewed claude claude. Immerhin in einer frischen Session, nicht dem Implementierer, aber die blinden Flecken bleiben. Der nächste sinnvolle Schritt wäre ein anderes Modell reviewen zu lassen. Die naheliegenste Wahl wäre codex als mein zweitliebster Assistent. Leider sind sie Möglichkeiten codex headless über meinen Pro-Account in Jobs laufen zu lassen begrezt (pay per token geht naürlich ;). Daher suche ich hier noch ein besser passendes Stück…