Linearは、AI支援コーディングによって、プルリクエストの検証がコードの生産速度に追いつかなくなったと述べています。同社の説明によると、テストスイートの規模はほぼ4倍に拡大した一方、PRの平均待ち時間は6分超から5分強に短縮され、1テストあたりのランナー使用時間も約半分に減少しました。これらはLinear自身が報告した測定値であり、独立したベンチマークではありません。
同社が示す主な教訓は、CIの速度はシステム全体の問題だということです。高速なランナーも役に立ちました。Linearによれば、ワークロードをより高速なCPU、ストレージ、キャッシングを備えたインフラへ移した結果、ジョブは平均34%高速化されました。しかし同社は同時に、チェックアウト工程の短縮、マージパスから不要な作業の削除、共有依存関係の事前インストール、そして各ジョブに必要なパッケージだけをインストールする対応も進めました。シャードごとのセットアップ時間は約44%短縮され、110～140秒から67～73秒になりました。
高速なランナー、短いセットアップ、短縮されたクリティカルパス上の作業について説明したあと、工程ごとの所要時間がパイプラインの高速化による効果を具体的に示しています。
最大の効果は、実行場所ではなく実行方法を変えたことから生まれました。Linearは大規模なテストファイルを分割し、APIシャードを4つから8つに増やし、安全に利用可能なファイル向けには、任意参加型の共有Vitestモジュールレジストリを導入しました。同社によると、最も遅いシャードの実行時間は約300～379秒から約195秒に短縮され、APIシャードのランナー使用時間は1回あたり約32.8分から22分へ減少しました。
この図は、ハードウェアの変更だけでなく、作業と依存関係の再編成も検証の高速化に寄与したという記事の説明を裏付けています。
変更前後の構造は、1つの状態を共有することで冗長な再構築がどのように減ったかを明確にするとともに、安全でないファイルには隔離が必要であることも記事で説明しています。
この最適化には、正しさの面で代償が伴います。共有モジュールの状態は、偽タイマーやその他の状態間の相互作用を表面化させる可能性があるため、Linearは安全でないファイルを隔離し、後処理を追加し、生成されたテストに関する指針を更新しました。実務上の教訓は「高速なランナーを購入する」ことよりも限定されます。AIによって変更量が増えると、CIの高速化は多くの場合、反復されるセットアップの削減、クリティカルパス上のジョブの短縮、そして隔離ルールが安全に保たれる場合に限りテストを並列化することからもたらされます。