Historischer Beitrag. Beschreibt die v1-Architektur, einschließlich des gewichteten Regex-Klassifizierers und des CI-getriggerten Single-Branch-Modells. Das meiste, was dieser Beitrag beschreibt, wurde in v2 bewusst entfernt. Siehe Unseren Regex-Klassifizierer löschen und Local-First CI: der Wandel für das, was es ersetzt hat und warum.
Wenn eine CI-Pipeline fehlschlägt, muss jemand im Team aufhören, was er gerade tut, die Logs lesen, herausfinden was gebrochen ist, es fixen, pushen und warten, bis die Pipeline besteht. Dieser Zyklus wiederholt sich in den meisten Engineering-Teams mehrmals pro Tag.
KI-Agenten können diese komplette Schleife automatisieren. Hier ist, wie Stitch es angeht.
Schritt 1: Den Fehler erkennen
Stitch läuft als nachgelagerter Job in deiner CI-Pipeline. Wenn ein vorgelagerter Job fehlschlägt, aktiviert sich Stitch. Es pollt nicht und nutzt keine Webhooks. Es wird vom CI-System selbst getriggert, was null Latenz und keine externen Abhängigkeiten bedeutet.
Schritt 2: Die Logs lesen und parsen
CI-Logs sind chaotisch. Sie enthalten ANSI-Farbcodes, Timestamps, Progressbars und Tausende Zeilen Output. Stitch entfernt das Rauschen und extrahiert die relevanten Fehlersignaturen.
Es gruppiert Fehler nach Typ: Lint-Fehler, Typcheck-Fehler, Testfehler, Abhängigkeitsprobleme, Build-Fehler. Jede Kategorie hat eine andere Diagnose-Strategie.
Schritt 3: Die Ursache diagnostizieren
Hier verdient das KI-Modell sein Geld. Stitch sendet den bereinigten Fehlerkontext an ein Sprachmodell zusammen mit den relevanten Quelldateien. Das Modell sieht nicht das ganze Repository. Es sieht nur die Dateien, die im Fehler-Trace referenziert werden, plus deren direkte Abhängigkeiten.
Dieser eingeschränkte Kontext ist beabsichtigt. Er verhindert Halluzinationen durch irrelevanten Code und hält den Token-Verbrauch vorhersehbar.
Schritt 4: Den Fix erzeugen und validieren
Das Modell produziert einen Patch. Stitch wendet ihn lokal an und führt die fehlgeschlagenen Checks erneut aus. Wenn die Checks bestehen, wird der Fix committet und gepusht. Wenn sie fehlschlagen, meldet Stitch die Diagnose und den Fix-Versuch, damit ein Mensch mit vollem Kontext übernehmen kann.
Dieser Validierungsschritt ist kritisch. Ein KI-generierter Fix, der nicht getestet ist, ist nur ein Vorschlag. Stitch behandelt jeden Fix als Hypothese, die verifiziert werden muss.
Schritt 5: Gruppieren und deduplizieren
Wenn mehrere Jobs aus derselben Ursache fehlschlagen, gruppiert Stitch sie. Wenn fünf Testdateien wegen eines fehlenden Imports fehlschlagen, behebt Stitch den Import einmal und meldet den Fix für alle fünf Jobs. Keine doppelten Commits, keine redundante Arbeit.
Leitplanken
Stitch operiert innerhalb strikter Grenzen:
- Ein Branch pro Pipeline. Alle Fixes eines bestimmten Pipeline-Laufs gehen in einen Branch, einen Merge Request.
- Keine Force-Pushes. Niemals.
- Eingeschränkter Dateizugriff. Der Agent liest nur Dateien, die in Fehler-Traces referenziert sind.
- Konfigurierbares Auto-Merge. Standardmäßig aus. Du reviewst den MR, bevor er landet.
Das Ergebnis
Teams, die Stitch nutzen, berichten von weniger Kontextwechseln bei trivialen CI-Fehlern. Der Fix-Push-Wait-Zyklus für häufige Probleme wie Lint-Fehler, fehlende Imports und Typ-Mismatches fällt von 15 Minuten auf unter 2 Minuten. Wichtiger noch, Entwickler bleiben auf die Arbeit fokussiert, die zählt.
CI-Pipelines werden immer brechen. Die Frage ist, ob ein Mensch für jeden einzelnen Fehler in der Schleife sein muss.