Jedes CI-nahe Tool, das in den letzten achtzehn Monaten gestartet ist, kommt mit dem gleichen Pitch: Verbinde dein Repo, übergib uns deine Pipeline, lass unseren Agent die Fehler beheben. Die Form der Forderung ist identisch, auch wenn die Produkte es nicht sind. Gitar will dein Repo in seiner Cloud. Nx Cloud will, dass du deinen Build-Graph in seinem Monorepo umstrukturierst. Dagger will, dass du dein YAML in sein SDK umschreibst. Jeder hat einen vertretbaren Grund. Keiner dieser Gründe nimmt deinem Team die Migrationssteuer ab.
Stitch wurde um eine andere Beobachtung gebaut. Der Entwickler hat bereits die Pipeline, besitzt bereits die Maschine und hat zunehmend bereits einen authentifizierten KI-Agent in seinem Terminal sitzen. Die Aufgabe ist nicht, eine neue Steuerungsebene einzuführen. Die Aufgabe ist, die drei Dinge zu verbinden, die bereits existieren.
Dieser Beitrag handelt von den Teilen des Vergleichs, die in keine Feature-Matrix passen.
Der Markt teilt sich in drei
Wenn man die Produkte wirklich anschaut, ist die KI-CI-Kategorie nicht ein Markt. Es sind drei.
- Cloud-Refactor-Plattformen wie Gitar. Code in ihre Umgebung pushen, ihren Agent großflächige Änderungen ausführen lassen, Ergebnis zurückholen. Optimiert für punktuelle Modernisierung im großen Stil.
- Build-Graph-SaaS wie Nx Cloud. Repo in einen Workspace umstrukturieren, Graph in deren Cache pushen, verteilte Task-Ausführung und Remote-Caching zurückbekommen. Optimiert für große Monorepos mit teuren Builds.
- Programmierbare Pipeline-Engines wie Dagger. YAML durch Code ersetzen, Pipeline durch deren Engine in Containern laufen lassen, Reproduzierbarkeit und Portabilität bekommen. Optimiert für Teams, deren CI-YAML unwartbar geworden ist.
Stitch ist keines davon. Es ist eine vierte Kategorie: ein Local-First-Verify-Loop, der deine bestehende CI-Konfiguration liest und sie auf deiner Maschine mit dem KI-Agent ausführt, den du bereits nutzt.
Capability-Matrix
| Fähigkeit | Stitch | Gitar | Nx Cloud | Dagger + KI |
|---|---|---|---|---|
| Nutzt deine bestehende CI-Konfig | Ja | Nein | Nein | Nein |
| Führt Jobs lokal aus | Ja | Nur Cloud | Cloud + lokal | Container |
| Pluggable KI-Agent | Beliebiger CLI-Agent | Nur Built-in | Nur Built-in | Nur Built-in |
| Erfordert neue Infra | Keine | SaaS-Konto | Nx-Workspace | Dagger-SDK |
| Native Claude-Code-Integration | Liefert eine Skill | Nein | Nein | Nein |
| Preis | Kostenlos, MIT | Bezahlpläne | OSS gratis + Cloud kostenpflichtig | OSS-Engine gratis + Cloud kostenpflichtig |
Die Matrix unterschätzt, was tatsächlich passiert. Der interessante Teil ist, was jede Zeile für ein Engineering-Team drei Monate später bedeutet.
Was “nutzt deine bestehende CI-Konfig” wirklich heißt
Wenn ein Tool .github/workflows/*.yml oder .gitlab-ci.yml direkt liest, bleibt deine CI die einzige Wahrheitsquelle. Die Pipeline, die du in Produktion ausspielst, ist die Pipeline, die der Verify-Loop ausführt. Drift ist konstruktiv unmöglich.
Wenn ein Tool verlangt, dass du deine Pipeline in ein neues Format übersetzt (Dagger-SDK, Nx-Project-Graph, SaaS-YAML eines Anbieters), besitzt du jetzt zwei Pipelines. Eine pushst du in CI. Eine versteht das lokale Tool. Jede Änderung an einer muss in der anderen gespiegelt werden. In der Praxis veraltet der Spiegel. In der Praxis driftet das lokale Tool langsam von der Produktion ab. In der Praxis hört “läuft lokal” auf, “läuft in CI” zu bedeuten.
Die Migration ist nicht der Preis. Die laufende Pflege zweier Konfigs ist der Preis. Stitch umgeht das, indem es sich weigert, die Konfig zu besitzen.
Lokale Ausführung ist nicht nur eine Latenzgeschichte
Cloud-only-Tools werben mit Skalierung. Die ehrliche Lesart ist: Sie werben mit Skalierung, weil Cloud der einzige Modus ist, den sie bieten. Es gibt keinen lokalen CLI, den du auf einem Laptop ohne Netzwerk-Round-Trip laufen lassen kannst. Das hat drei Konsequenzen, die niemand auf eine Vertriebsseite schreibt.
- Dein Code verlässt die Maschine. Jede Iteration schickt Diffs an ein SaaS-Backend. In regulierten Umgebungen ist das ein Compliance-Review.
- Du zahlst pro Compute-Minute. Ein schneller Feedback-Workflow auf einem langsamen Runner wird schnell teuer.
- Du erbst deren Verfügbarkeit. Wenn das SaaS einen Vorfall hat, stoppt dein Verify-Loop.
Local-First dreht alle drei um. Stitch-Jobs laufen auf der Maschine, auf der der Editor lebt. Nichts verlässt sie, außer du konfigurierst einen Notification-Channel, der es verschickt. Es gibt kein Stitch-Backend, das ausfallen kann.
”Pluggable KI-Agent” ist die einzige ehrliche Antwort
Gitar, Nx Cloud und die KI-Features, die an Dagger Cloud geschraubt sind, liefern alle einen einzigen proprietären Agent. Die Wahl gehört dem Anbieter, der Preis ist die Rechnung des Anbieters, die Modell-Update-Kadenz ist die Roadmap des Anbieters.
Stitch hat keinen Agent. Es ruft den Agent auf, den du bereits nutzt: Claude Code, Codex, alles CLI-Kompatible. Die Credentials gehören dir. Die Modellwahl gehört dir. Wenn Anthropic einen schnelleren Claude oder OpenAI einen günstigeren Codex liefert, übernimmst du es am gleichen Tag, ohne Stitch-Release.
Das zählt, weil sich der KI-Agent-Markt schneller bewegt als jeder CI-Anbieter ausliefern kann. Den Agent ins CI-Tool einzusperren ist eine Wette darauf, dass der CI-Anbieter mit Frontier-Modellen Schritt hält. Bisher tut es keiner.
Infrastrukturkosten sind die echte Preisfrage
Die Preiszeile verbirgt die wichtigere Zahl. “Kostenlos, MIT” bei Stitch heißt: Die einzige Ausgabe ist dein bestehendes KI-Agent-Abonnement. Eine SaaS-Position ab 20 Dollar pro Nutzer und Monat, ein Nx-Cloud-Plan oder ein Dagger-Cloud-Plan sind alles Pro-Sitz-Rechnungen, die mit dem Team wachsen, oben drauf auf das KI-Agent-Abo.
Für ein fünfköpfiges Team, das bereits Claude Code nutzt, kostet Stitch null. Die konkurrierenden Tools fügen eine vierstellige Jahresposition hinzu, bevor der Verify-Loop ein einziges Mal läuft.
Wo Stitch verliert
Ehrliche Vergleiche brauchen diesen Abschnitt.
- Wenn du einen verwalteten Fix-on-Merge-Service mit org-weiten Dashboards brauchst, ist Stitch nicht die Form. Es läuft pro Entwickler.
- Wenn dein CI exotische Build-Images braucht, die nicht auf einem Laptop laufen, wird die lokale Ausführung diese Jobs nicht verifizieren. Stitch erkennt sie und überspringt sie; den Rest deckt weiter dein CI ab.
- Wenn dein Problem “modernisiere diesen Java-8-Code auf Java 21” lautet, ist eine Refactor-Plattform wie Gitar dafür gebaut. Stitch nicht.
- Wenn dein Problem “unser YAML ist unleserlich” lautet, könnte der Wechsel zu Dagger-Code richtig sein. Stitch löst das nicht.
Die Matrix ist nicht “Stitch gewinnt überall”. Die Matrix ist “Stitch gewinnt dort, wo das Problem Pre-Push-Verifikation mit einem KI-Fix-Loop auf der Pipeline ist, die du bereits hast”.
Die Wette
Die Wette unter Stitch lautet: Die Maschine des Entwicklers ist der richtige Ort für den Verify-Loop, und der bereits vorhandene KI-Agent des Entwicklers ist der richtige Ort für die Fixes. Jedes andere Tool der Kategorie wettet gegenteilig: Der richtige Ort ist die Cloud des Anbieters, mit dem Agent des Anbieters, zum Preis des Anbieters.
Wenn die Wette stimmt, gewinnen Local-First-Tools bei Latenz, Kosten, Datenschutz und Agent-Freiheit. Wenn die Wette falsch ist, gewinnen Cloud-Tools bei Skalierung und zentraler Kontrolle. Wir glauben, die Wette stimmt, weil die Agents bereits auf der Maschine des Entwicklers sind. Der schwere Teil ist nicht mehr “Wo lassen wir die KI laufen?”. Der schwere Teil ist “Hört auf, sie woandershin zu zwingen”.