Die erste Version von Stitch tat, was auf der Packung stand. Du fügtest zwei Jobs zu deiner CI-Konfig hinzu, stitch-monitor und stitch-heal, zeigtest auf ein öffentliches Docker-Image, und das nächste Mal, wenn eine Lint-Regel oder ein Test brach, tauchte ein Merge Request mit einem Patch auf. Für die Teilmenge der Fehler, die es gut behandelte, war das Erlebnis fast magisch.
Wir lieferten es aus. Wir nutzten es in unseren eigenen Repositories. Und über ein paar Monate stellten wir eine ehrliche Liste der Dinge zusammen, die schief gingen. Dieser Beitrag ist diese Liste.
Es lebte am falschen Ort
Stitch v1 war Bürger deines CI-Systems. Es lief als nachgelagerter Job, aktiviert bei vorgelagertem Fehler, und erledigte seine ganze Arbeit innerhalb der Pipeline-Umgebung. Das klingt sauber. Es hatte Konsequenzen, die wir unterschätzten.
Jeder Fix verlangte einen vollen Pipeline-Umlauf. Dein CI lief, schlug fehl, Stitch lief, committete, pushte, dein CI lief erneut. Selbst auf einem schnellen Runner war die Feedback-Schleife Minuten, manchmal zehn Minuten. Für die Art von Fehler, die Stitch behandeln sollte, einen fehlenden Import, eine Formatierer-Meinungsverschiedenheit, eine Typ-Annotation, die der Test-Runner nicht mochte, dauerte der Fix selbst eine Sekunde und die Verifikation eine Ewigkeit. Der Mensch wartete weiterhin auf die Maschine, nur in einem anderen Raum.
Es nahm an, der Agent lebe woanders
v1 sprach über eine API mit einem Sprachmodell. Wir lieferten eine OpenRouter-Integration, einen GitHubAdapter und eine StitchAgent-Klasse. Die Onboarding-Story war “bring your own API key”. Das las sich wie eine kleine Bitte. In der Praxis hieß das, jedes Team, das Stitch probieren wollte, musste bei einem Anbieter einen Account anlegen, einen Key generieren, ihn in CI-Secrets speichern und Tokens budgetieren.
Gleichzeitig hatten immer mehr Entwickler Claude Code oder Codex schon auf ihrem Laptop, schon authentifiziert, schon über ihr persönliches oder Team-Abo bezahlt. Stitch v1 wusste nicht, wie es mit einem dieser sprechen sollte. Es bat die Nutzer, zweimal zu zahlen.
Es überkonstruierte die sichtbaren Teile
v1 lieferte einen Regex-Klassifizierer aus. Eine gewichtete Engine, die CI-Logs las, sie durch einhundertfünfzig Muster schickte und Fehler in neun Kategorien sortierte: Lint, Formatierung, Typen, Build, CI-Konfig, Test, komplexe Typen, Logik, unbekannt. Jede Kategorie hatte einen Konfidenz-Score. Jede Kategorie hatte eine Fix-Strategie.
Es war befriedigend zu bauen. Es war auch größtenteils Theater. Der Agent am anderen Ende der API war fähig, ein rohes Log zu lesen und herauszufinden, was schiefgelaufen war. Unser Klassifizierer war bestenfalls ein Weg, den Prompt kurz zu halten. Schlimmstenfalls war er eine Übersetzungsschicht, die eigene Bugs einführte. Als der Agent besser wurde, behielten wir den Klassifizierer. Wir hatten ihn schon gebaut.
Es pushte, bevor es wusste
Auto-Merge war ein Flag. Standardmäßig aus, aber beworben. Ein Fix landet, der Re-Run besteht, der Merge Request kann sich selbst schließen. In der Praxis ist dieses Flag ein Selbstschuss. Bestehendes CI ist Evidenz, dass die Test-Suite zufrieden ist, nicht dass der Patch der richtige war. Wir sahen Fälle, in denen der Agent einen fehlschlagenden Test stummschaltete, indem er die Assertion änderte, Grün bekam, und das Team das Signal komplett verlor. v1s Antwort war “reviewt jeden MR”. v2s Antwort musste anders sein.
Es skalierte schlecht für den kleinen Fall
v1 nahm an, dass das Team eine CI-Plattform irgendwo laufen hatte, die sein Docker-Image hosten konnte, dass es das Budget für zusätzliche Compute bei jedem Fehler hatte und dass es jemanden gab, der Jobs zur Pipeline-Konfig hinzufügen durfte. Für ein Startup mit drei Ingenieuren waren das drei Hürden vor dem ersten Fix. Für einen Solo-Entwickler an einem Nebenprojekt war es eine Mauer.
Die Fehlerfälle, in denen Stitch am besten war, die fünf-Minuten-Aufräum-Fixes, waren die Fälle, in denen das kleinere Team am meisten Hilfe brauchte. Und das waren genau die Teams, die v1 nicht erreichen konnte.
Was wir behalten haben
Nicht alles. Aber viel.
Die Kernidee, dass KI-Agenten fehlschlagende Logs lesen, das Problem verstehen und einen gezielten Patch produzieren können, war richtig. Das Beharren auf Validierung, dass ein Patch, der nicht sauber neu läuft, kein Fix ist, war richtig. Der Gedanke, nach begrenzten Versuchen zu eskalieren, war richtig. Diese wurden unverändert in v2 übernommen.
Die Form drumherum nicht. Der nächste Beitrag in dieser Serie handelt davon, wohin wir es gebracht haben.