Stitch 2.0 ist da: führe dein CI lokal aus, behebe Fehler mit KI

Stitch 2.0 ist draußen. Wenn du die Serie verfolgt hast, die Kurzversion: alles, was du in den Rückschauen gelesen hast, ist jetzt gelandet.

Wenn nicht, ist dieser Beitrag die eigenständige Zusammenfassung. Was Stitch jetzt ist, was sich gegenüber v1 unterscheidet und wie du es in den nächsten dreißig Sekunden ausprobierst.

Was Stitch 2.0 ist

Ein Kommandozeilen-Tool, das auf deinem Laptop läuft. Es liest die CI-Konfiguration, die schon in deinem Repository liegt, parst die definierten Jobs und führt die Verify-Jobs (Lint, Typecheck, Test, Build) lokal in Sekunden aus. Wenn ein Job fehlschlägt, übergibt Stitch den Fehler an einen KI-Agenten (Claude Code oder Codex), den du bereits installiert hast. Der Agent behebt das Problem. Stitch führt den Job erneut aus. Wenn er besteht, bist du fertig.

Ein Befehl zum Installieren und Ausführen:

npx stitch-agent run claude

Keine API-Keys. Kein Docker-Image. Keine neuen Pipeline-Jobs. Keine Konfigurationsdatei erforderlich. Das CI, das du schon hast, laufend auf der Maschine, auf der du schon arbeitest, mit dem Agenten, der schon auf deinem Bildschirm offen ist.

Was sich gegenüber v1 geändert hat

Die Kurzliste, für die Leute, die Stitch v1 benutzt haben und sich fragen, was gebrochen ist:

• Sprache. v1 war Python, verteilt über PyPI. v2 ist TypeScript, verteilt über npm. Der Paketname ist weiterhin stitch-agent.
• Ausführungsmodell. v1 lief als CI-Job, ausgelöst durch Pipeline-Fehler. v2 läuft lokal aus deinem Terminal. Die Pipeline bleibt unberührt.
• Agent-Integration. v1 sprach mit Modellen über eine API, mit Keys, die du bereitgestellt hast. v2 delegiert an dein bereits installiertes Claude Code oder Codex und nutzt dein bestehendes Abo.
• Konfigurationsumfang. v1 verlangte, dass du zwei Jobs (stitch-monitor, stitch-heal) zu deiner CI-YAML hinzufügst. v2 verlangt keinerlei Änderungen an deinem CI.
• Fehlerklassifikation. v1 hatte eine Regex-Engine mit 150 Mustern, die Fehler in neun Kategorien sortierte. v2 hat davon nichts. Der Agent übernimmt die Diagnose direkt.
• Auto-Merge. v1 hatte ein Flag dafür. v2 macht Auto-Commit und Push nur auf sauberen Branches und nur, wenn du --auto-commit übergibst. Standardmäßig aus.
• Interaktive TUI. v1-Ausgabe war ein CI-Log. v2 hat ein Live-Terminal-UI mit Pipeline-Stepper, Job-Status-Tabelle und Driver-Panel.
• Watch-Modus. Neu in v2. Verifiziert betroffene Jobs beim Speichern von Dateien neu.

Warum ein komplettes Rewrite und keine Migration? Weil die meisten dieser Änderungen keine Features sind, sondern Form. Eine Bibliothek, die in einer CI-Umgebung laufen soll, ist anders strukturiert als eine CLI, die neben deinem Editor laufen soll. v1 in v2 umzuformen wäre langsamer gewesen als v2 von null zu schreiben. Wir haben zuerst den langsamen Weg probiert. Die vorherigen Beiträge der Serie erklären, wie wir zu dieser Entscheidung kamen.

Für wen das ist

Das Profil, das wir beim Rewrite im Kopf hatten:

• Du arbeitest an einem oder mehreren Repositories mit CI-Pipeline.
• CI bricht so oft aus trivialen Gründen, dass es dir auffällt.
• Du nutzt Claude Code, Codex oder einen anderen KI-CLI-Agenten schon täglich.
• Du würdest lieber nicht auf einen Remote-Pipeline-Umlauf warten, um zu erfahren, dass du ein Semikolon vergessen hast.

Wenn das auf dich zutrifft, ist Stitch 2.0 einen einzigen Befehl entfernt.

Was als Nächstes kommt

Stitch 2.0 ist das erste Release der local-first-Form. Die Roadmap von hier ist kürzer und einfacher als die von v1, und das ist Absicht. Was wir als Nächstes hinzufügen wollen:

• Mehr CI-Plattformen. GitLab CI und GitHub Actions werden heute unterstützt. CircleCI, Drone und self-hosted Runner sind als Nächstes dran.
• Mehr Agenten. Claude Code und Codex sind die aktuellen Driver. Weitere CLI-basierte Agenten hinzuzufügen ist ein kleiner Pattern-Match.
• Bessere Job-Erkennung. Die Heuristik zur Klassifizierung von Verify- gegenüber Infra-Jobs ist gut, aber nicht perfekt. Randfälle in exotischen Pipelines brauchen mehr Arbeit.
• Team-Sharing. Kein Dashboard, kein Service. Nur eine Möglichkeit, eine .stitch.yml-Policy über ein Repo zu teilen, ohne dass jeder Entwickler sie neu entdeckt.

Die Dinge, die wir bewusst nicht hinzufügen, sind auch erwähnenswert. Kein gehosteter Service. Kein Account. Keine Telemetrie. Kein Training auf deinem Code. Wenn sich das ändert, wird es ein separates Produkt mit separatem Namen.

Probier es aus

npx stitch-agent run claude

Wenn du zehn Minuten und eine fehlschlagende Pipeline hast, reicht das. Das Repository liegt auf github.com/x24labs/stitch-agent. Issues sind offen. Beiträge sind willkommen.

Danke fürs Lesen der Serie. Die ehrliche Antwort auf “warum brauchte das ein Rewrite” ist, dass die richtige Form für uns nicht verfügbar war, bis wir die falsche Form ausliefern sahen. v2 ist die Version, die wir die ganze Zeit bauen wollten. Wir mussten nur v1 zuerst bauen, um das zu wissen.