AIコーディングの爆速化でCIがボトルネックに?開発効率を最大化するパイプライン刷新術
AI coding has made CI a bottleneck, so we reworked ours to keep up
AI coding has made CI a bottleneck, so we reworked ours to keep up
AIによるコーディング支援の普及により、コード生成のスピードが劇的に向上しました。しかしその結果、CI(継続的インテグレーション)プロセスが開発の足かせとなり、ボトルネック化するケースが急増しています。本記事では、AI時代の開発スピードに追いつくために、私たちがどのようにCI環境を再設計し、オーバーヘッドを最小化したのか、その具体的な取り組みを解説します。
初期設定のコストを払えるなら、Bazelを使えばキャッシュが効いている状態で巨大なプロジェクトでもビルド時間を10秒程度に短縮できるよ。
Agentic Coding(AIエージェントによるコーディング)のせいでCIにめちゃくちゃ負荷がかかってるんだよね。うちはビルド時間を改善するためにBazelを導入して、最終的にはカスタムランナーを構築してCIを最適化してるよ。とにかく、Linearチームのブログ記事は学ぶことが多くて素晴らしいね。
Linearはもうずっと前に完成していて新機能もいらないから、AIコーディングがゆっくりでも問題ないのは幸いだね。あーあ、次のJiraになろうと必死みたいだね。
俺の場合、ボトルネックはCIじゃないんだ。人間によるテストの面だね。動くかどうかは確かに重要。でも、俺たちが求めていることをちゃんと実現できているか、さらに言えば、顧客が理解しやすく、実際に気に入ってくれるやり方で実現できているか、そこが大事なんだ。
GitHub Actionsから、より高速なCPUや高性能なストレージ、優れたキャッシュインフラを備えたサードパーティ製ランナーへワークロードを移行したことで、同じパイプラインをより速いマシンで実行できた
まあ、これを読んで驚きはしなかったね。GitHubを既に使っているならActionsは便利だけど、かなり遅くなることもあるし。最近は信頼性もGitHubの大きな問題点になってるから、他のパイプラインに移行する組織はもっと増えると思うよ。
俺の意見としては、システムはもっと小さく、隔離されていて、コントラクト指向であるべきだと思う。モノリスの支持者として長くやってきたけど、AIエージェントにはもっと小さくて隔離されたサービスの方が向いてそうだね。隔離されていればされているほどいい。サービス間の通信はコントラクトだけにしておく。そうすれば、コントラクトさえ満たしていれば内部でどんどんイテレーションを回せるし、必要ならコントラクトをバージョン管理して進化させ続けられる。
この状況を「2026年の大CIボトルネック」と呼ぶことにしたよ。これについての考えをここにまとめた: https://dagger.io/blog/the-great-ci-bottleneck-of-2026/
ずっと気になってることがあるんだ。
みんな猛スピードで突っ走って、結局あちこちで壁にぶつかってる。レビューとか、CIとか、プロダクトの要望とかね。
それなのに、なぜプロダクト自体には改善が見られないんだろう?
どの投稿やスレッドを見ても90年代のウォール街のオフィスみたいな殺伐とした雰囲気なのに、新しいAndroidやiPhoneは以前より機能が削られて出荷されてる。Linux並みの代替OSを作る個人開発者もいないし、Switch 2はいまだにハックされてない。Windowsの右クリックメニューが出るのには3秒もかかる。
みんなただ全速力でその場で足踏みしてるだけなのかな?
俺たちは pushgate.dev というものを開発中だよ。これはエージェントにテストの実行を強制するものだね。Jevを使ったバンドルファイルの静的解析のサポートも追加しようとしてる。オンボーディングは正直まだ少しごちゃついてるけど、興味があれば cole@testifysec.com までメールしてよ。
俺の一番の教訓(Gitlabの無料プランを工夫してセルフホストのランナーをいじり回している一人のエンジニアとして)は、彼ら(Linear)が1億ドルのARRと10億ドル以上の評価額に達するまで、この手のことは一切気にかけていなかったってことだね[0]。