Ein Produkt-Pivot startet selten mit einem Slide. Er startet meist mit einer Beschwerde, die nicht weggeht.
Für Stitch war die Beschwerde Latenz. Selbst wenn v1 perfekt funktionierte, war der Feedback-Zyklus immer noch ein Pipeline-Umlauf. Wir schmückten es aus, wir dokumentierten es, wir machten Frieden damit. Die Nutzer nicht. Die Leute, die Stitch ausprobierten und mochten, stellten uns weiter dieselbe Frage: warum warte ich, bis mein CI einen fehlenden Import findet, wenn ich denselben Linter in einer Sekunde auf meiner Maschine hätte laufen lassen können?
Die Antwort, die wir uns immer wieder gaben, war “weil der Agent die CI-Umgebung braucht”. Die ehrliche Antwort, als wir sie aufschrieben, war “weil wir entschieden haben, dass der Agent dort leben soll”. Das ist nicht dasselbe.
Die Beobachtung
Entwickler führen KI-Agenten schon lokal aus. Claude Code sitzt im Terminal. Codex auch. Beide sind authentifiziert, beide sind konfiguriert, beide haben bereits Zugriff auf das Repository, das der Entwickler gerade bearbeitet.
Nichts davon ist in der CI-Umgebung. Um es dorthin zu bekommen, musst du eine Teilmenge davon neu aufbauen, schlecht. API-Keys, Image-Registries, gecachte Abhängigkeiten, gemountete Secrets. Alles, um auf einem Runner eine Sache zu approximieren, die der Entwickler schon vor sich hat.
Der Wandel, als wir ihn endlich laut aussprachen, war peinlich einfach. Hör auf, den Agenten in die Pipeline zu bauen. Führe die Pipeline lokal aus, neben dem Agenten, den der Entwickler schon besitzt. Lass sie direkt miteinander reden.
Was das freischaltet
Sobald du sagst “Stitch läuft lokal”, hören viele Probleme von v1 auf, Probleme zu sein.
Latenz kollabiert. Jobs laufen auf derselben Maschine wie der Editor. Ein Lint-Job, der früher neunzig Sekunden auf einen Queue-Runner wartete, läuft in einer halben Sekunde. Der Fix, der früher drei Pipeline-Zyklen zum Verifizieren brauchte, braucht drei lokale Läufe. Feedback in Sekunden, nicht Minuten.
API-Keys verschwinden. Der Agent ist schon durch das Claude Code oder Codex Abo des Entwicklers authentifiziert. Stitch braucht keinen eigenen Key, speichert keinen, fragt nach keinem. Das Onboarding ist npx stitch-agent run claude und das ist das Ganze.
Deine bestehende CI-Konfig ist die Konfig. Es gibt nichts, was zu .gitlab-ci.yml oder .github/workflows/*.yml hinzugefügt werden muss. Stitch liest die Datei, die du schon geschrieben hast, und führt dieselben Jobs auf deiner Maschine aus. Die Pipeline, die du in deinem Repo hältst, bleibt die Quelle der Wahrheit.
Infrastruktur-Jobs bleiben remote. Deploys, Publishes, Image-Pushes, nichts davon sollte auf einem Laptop laufen. v2 erkennt sie am Job-Namen und überspringt sie. Du bekommst lokale Ausführung für die Verify-Jobs, dein CI behält die Infra-Jobs. Nichts dupliziert, nichts gebrochen.
Privacy hört auf, eine Sales-Folie zu sein. Lokale Ausführung bedeutet, dass deine Logs, dein Source, deine Fixes die Maschine nie verlassen, außer du konfigurierst einen Benachrichtigungskanal, der sie irgendwohin sendet. Es gibt kein Stitch-Backend, durch das etwas leaken könnte, weil es kein Stitch-Backend gibt.
Was das einschränkt
Local-First ist kein freier Gewinn. Es bedeutet, dass Stitch läuft, wo deine Tools laufen. Wenn dein CI ein spezifisches Docker-Image braucht, um ein Binary zu kompilieren, muss deine lokale Maschine dasselbe können, sonst kann der Job nicht lokal verifiziert werden. In der Praxis ist das für typische Sprach-Toolchains okay und für exotische Build-Umgebungen schmerzhaft.
Es bedeutet auch, dass Stitch ein Tool pro Entwickler ist, kein Team-Service. Es gibt kein geteiltes Dashboard, keine organisationsweiten Metriken, keine zentrale Control Plane. Das ist ein bewusster Trade. Der Trade ist “dein CI, deine Maschine, dein Agent, dein Tempo”. Wenn du einen Managed Fix-on-Merge-Service willst, ist Stitch nicht die richtige Form für dich.
Die zweite Erkenntnis
Die kleinere, leisere Erkenntnis aus diesem Pivot war, für wen Stitch da ist.
v1 nahm immer ein Team mit Pipeline-Budget an. v2 funktioniert genauso gut für einen Solo-Entwickler an einem Wochenendprojekt. Dem Code ist es egal. Derselbe npx-Befehl, dieselbe Agent-im-Terminal-Erfahrung, dieselbe Null-Konfiguration. Wir hatten für den Kunden optimiert, den wir uns wünschten, statt für den Entwickler, den wir immer wieder beobachteten, wie er Stitch ausprobierte und abprallte.
Local-First machte das Produkt zugänglich für jeden, der schon ein Repo und einen Agenten hatte. Was zunehmend jeder ist.
Der nächste Beitrag ist ein kleinerer, technischerer: ein Klassifizierer, den wir drei Monate lang bauten und dann an einem Nachmittag löschten.