Der größte Teil des Rewrites von v1 zu v2 betraf die äußere Form. Lokal statt remote, TypeScript statt Python, CLI statt CI-Job. Der Teil, über den es sich lohnt separat zu schreiben, ist intern. v2 wurde mit deutlich weniger Code ausgeliefert als v1, und das meiste, was fehlt, wurde bewusst gelöscht.
Die größte einzelne Löschung war unser Fehlerklassifizierer.
Was er gemacht hat
v1s Klassifizierer war eine gewichtete Regex-Engine. Er las CI-Logs, schickte sie durch rund einhundertfünfzig Muster und sortierte Fehler in neun Körbe: Lint, Formatierung, Typen, Build, CI-Konfig, Test-Verträge, komplexe Typen, Logik und einen Sammelbehälter namens unknown. Jede Klassifikation kam mit einem Konfidenz-Score. Jeder Korb war auf eine Fix-Strategie abgebildet.
Die Landingpage für Stitch v1 listete stolz alle neun Kategorien. Wir hielten das für ein Feature.
Warum wir ihn gebaut haben
Der Klassifizierer war eine Antwort auf ein echtes Problem. Aufrufe an Sprachmodelle kosten Tokens. CI-Logs sind riesig. Wenn du das ganze Log sendest, verschwendest du Kontext und bekommst schlechtere Ergebnisse, weil das Modell das Signal selbst finden muss. Wenn du das Log vorverarbeitest, das Rauschen entfernst, den relevanten Fehler isolierst und seinen Typ etikettierst, sparst du Tokens und gibst dem Modell einen Vorsprung.
Also bauten wir einen Preprozessor. Er lief vor dem Modell. Er produzierte eine kompakte Payload, die sagte “das ist ein Typfehler in Datei X Zeile Y, hier ist der Traceback, hier sind die fünf Zeilen um die Aufrufstelle”. Dann produzierte das Modell den Fix. Das funktionierte.
Warum er weg musste
Zwei Dinge änderten sich.
Modelle wurden besser darin, rohe Logs zu lesen. Claude und GPT wurden pro Token günstiger und schärfer beim Parsen unstrukturierter Ausgabe. Die Lücke zwischen “sende dem Modell einen chirurgisch extrahierten Fehler” und “sende dem Modell das Log und lass es herausfinden” schloss sich. Der Extraktionsschritt verdiente seine Kosten nicht mehr.
Unser Klassifizierer wurde im Vergleich schlechter. Wir hatten Muster für TypeScript und Python und Go. Wir hatten keine Muster für Elixir oder Rust oder irgendein Framework, das ein Nutzer diese Woche laufen ließ. Wenn ein Log kam, das unser Regex nicht traf, leiteten wir es in den unknown-Korb und ließen das Modell es trotzdem behandeln. Das war der Hinweis. Wenn der Fallback funktionierte, war der spezialisierte Pfad optional. Wenn der spezialisierte Pfad optional war, war er auch eine Quelle für Bugs, die wir grundlos pflegten.
Die bahnbrechende Erkenntnis kam im lokalen Kontext von v2. Auf der Maschine eines Entwicklers bedeutete stitch run claude auszuführen, dass wir in Claude Code hineinriefen, einen steckbaren Agenten, der bereits Werkzeuge zum Lesen von Dateien, Ausführen von Befehlen und Durchdenken von Fehlern hat. Ihm eine vorklassifizierte Payload zu schicken war, wie einem Senior-Ingenieur einen vorausgefüllten Bug-Report zu schicken und dann darauf zu bestehen, dass er unser Template nutzt. Er brauchte das nicht. Das Template fügte Reibung hinzu.
Womit wir ihn ersetzt haben
Zwei Dinge. Eines viel einfacher als vorher, eines nicht einmal in derselben Schicht.
Stitch v2 macht weiterhin ein bisschen Vorverarbeitung, aber sie ist grob und sie ist ehrlich. Es schaut sich Job-Namen an und entscheidet, ob sie laufen sollen. Ein Job namens deploy-prod ist Infra, lokal überspringen. Ein Job namens lint ist Verify, lokal ausführen. Das ist eine Ein-Zeilen-Entscheidung pro Job. Es tut nicht so, als wüsste es, was die Fehler sein werden.
Die echte Diagnose wanderte in den Agenten. Wenn ein Job fehlschlägt, übergibt Stitch das Log dem Agenten mit einem kurzen, absichtlich langweiligen Prompt: hier ist der Job, hier ist das Log, hier ist das Repo, bitte repariere es. Der Agent tut, was er in einer interaktiven Session tun würde. Er liest Dateien, er führt Befehle aus, er probiert Dinge aus. Stitch validiert das Ergebnis durch erneutes Ausführen des Jobs.
Der gesamte entfernte Code war in den Tausenden Zeilen. Die gesamte verlorene Fähigkeit war null. Die Diagnosen wurden besser, weil der Agent Zugriff auf das ganze Repo hatte statt auf einen Fünf-Zeilen-Auszug.
Die Lektion
Die Lektion ist unangenehm, aber sie zeigt sich immer wieder in Tools, die um KI-Agenten gebaut sind: die Abstraktionen, die du baust, um dem Modell zu helfen, hören oft auf zu helfen, sobald das Modell gut genug wird. Wenn du sowohl den Preprozessor als auch den Prompt besitzt, erreichst du einen Punkt, an dem der Preprozessor den Prompt schlechter macht. Du wirst es nicht merken, weil du ihn gebaut hast.
Der einzige Weg, wie wir es merkten, war, uns zu erlauben, ihn zu löschen und zu sehen, was passiert. Nichts passierte. Das war der Punkt.
Nächster Beitrag in der Serie: Stitch 2.0 wird ausgeliefert. Was du tatsächlich installierst und was es macht.