歴史的な記事です。 v1 のアーキテクチャ、重み付き正規表現分類器、CI トリガーの単一ブランチモデルを説明しています。この記事で述べている内容のほとんどは v2 で意図的に削除されました。何が置き換えられたのか、その理由は Deleting our regex classifier と Local-first CI: the shift をご覧ください。
CI パイプラインが失敗すると、チームの誰かが手を止め、ログを読み、何が壊れたかを突き止め、直し、push して、パイプラインが通るまで待たなければなりません。このサイクルは、ほとんどのエンジニアリングチームで1日に何度も繰り返されます。
AI エージェントはこのループ全体を自動化できます。Stitch がどうアプローチするか、以下で説明します。
ステップ1: 失敗を検知する
Stitch は CI パイプラインの下流ジョブとして動きます。上流のジョブが失敗すると、Stitch が起動します。ポーリングも webhook もしません。CI システム自体からトリガーされるため、レイテンシはゼロで、外部依存もありません。
ステップ2: ログを読み、解析する
CI ログは雑然としています。ANSI カラーコード、タイムスタンプ、プログレスバー、数千行の出力が含まれます。Stitch はノイズを取り除き、関連するエラー署名を抽出します。
エラーをタイプごとにグループ化します: lint の失敗、型チェックエラー、テストの失敗、依存関係の問題、ビルドエラー。カテゴリごとに異なる診断戦略があります。
ステップ3: 根本原因を診断する
ここで AI モデルが価値を発揮します。Stitch はクリーンアップされたエラーコンテキストを、関連するソースファイルとともに言語モデルに送ります。モデルはリポジトリ全体を見るわけではありません。エラートレースで参照されたファイルと、その直接の依存関係だけを見ます。
このスコープ付きコンテキストは意図的なものです。関係ないコードによるハルシネーションを防ぎ、トークン使用量を予測可能に保ちます。
ステップ4: 修正を生成し、検証する
モデルがパッチを生成します。Stitch はそれをローカルに適用し、失敗したチェックを再実行します。チェックが通れば、修正は commit され push されます。失敗すれば、Stitch は診断と試みた修正を報告し、人間が完全なコンテキストで引き継げるようにします。
この検証ステップは重要です。テストされていない AI 生成の修正は、単なる提案にすぎません。Stitch はすべての修正を、検証すべき仮説として扱います。
ステップ5: グループ化と重複排除
複数のジョブが同じ根本原因で失敗したとき、Stitch はそれらをグループ化します。import 漏れで5つのテストファイルが失敗した場合、Stitch は1回 import を直し、5つすべてのジョブに対する修正として報告します。重複 commit も冗長な作業もありません。
ガードレール
Stitch は厳格な境界の中で動作します:
- パイプラインごとに単一ブランチ。 特定のパイプライン実行のすべての修正は、1つのブランチ、1つの merge request に入ります。
- force push は一切しません。
- スコープ付きのファイルアクセス。 エージェントはエラートレースで参照されたファイルしか読みません。
- 設定可能な auto-merge。 デフォルトは無効。着地前に MR をレビューします。
結果
Stitch を使うチームは、些細な CI 失敗でのコンテキストスイッチが減ったと報告しています。lint エラー、import 漏れ、型の不一致のような一般的な問題での「修正-push-待つ」サイクルが、15分から2分未満に短縮されます。より重要なのは、開発者が本当に重要な仕事に集中できることです。
CI パイプラインは常に壊れます。問題は、失敗のたびに人間がループに入る必要があるかどうかです。