AIコーディングがCIのボトルネックを引き起こしたため、私たちはそれに対応するために再構築しました

数年前に、5つ以上のプログラミング言語で書かれたかなり複雑なソフトウェアのBazel移行をリードしたんだけど、完了するまでに数年かかったよ。もっとシンプルなプロジェクト（1つのプログラミング言語で、3つの主要なOSに配信するもの）では、私の知識とエージェントを使って2週間でBazel移行を終えた。Bazelのセットアップコストはかなり下がったし、業界全体がそれに気づいていないと思う。

Bazelについて具体的にはコメントできないけど、nxとturboの両方で作業した経験から言うと、ボトルネックは通常ネットワークとディスクのIOPSで、計算ではあまりないんだ。完全にキャッシュされた出力でも、リモートサーバーから取得して読み込む必要があるし[1]。ステップn-1の出力をリモートキャッシュサーバーから取得してディスクに書き込んで、またステップnで読み込む必要がある[3] - これらはすべてディスクI/Oとネットワークに依存する操作だよ。10秒は、Bazelがよく使われるJava/C++の世界では達成可能かもしれないけど、TSエコシステムでは、多くの人が大きなモノレポで1〜2分の範囲に入るだけでも大喜びすると思う。ここで「ビルド」をもっと明確に定義する必要があるね。トランスパイル/コンパイルのステップだけを実行するのか、それともテストを含む一連のステップ全体を指すのか（ここでLinearの投稿が話しているのはそのこと）。仮想DOMや実際のブラウザが必要な大規模なテストスイートの小さなサブセットでも、10秒以内で実行できるのは難しいと思うよ。[1] 管理されたCIセットアップでは典型的。[3] 異なる言語の一般的なフロントエンド＋バックエンドスタックなど。

Bazelには多くのトレードオフがあるみたいだね。各タスクのサンドボックスのセットアップ時間から、並行して「普通の」ツールを維持するための使い勝手まで。さらに、「温かいキャッシュ」を使うと重い作業ができるけど、1週間の開発での実際のキャッシュヒット率はどれくらいなんだろう？コールドビルドや頻繁なアクションの改善に投資することは、Bazelや他のインクリメンタルビルダーでも重要だと思う。Bazelについて広く話すのが有用かどうかはわからないけど、実際のパフォーマンスや動作は使うルールに依存するからね。Bazelをturbo/nxのように設定して、各package.jsonモジュールでtsc/vitest/eslintをキャッシュすることもできるし、変更のたびに追い出されるキャッシュユニットを得ることもできる。あるいは、Gazelleを使ってファイルごとのアクションをターゲットにすることもできるけど、依存関係が変わらない限り無効にならないんだ。でも、ワーカーを使わない限り、バッチ処理のトレードオフがあるね。

AI時代にこれって本当に簡単なの？エージェントが得意とするはずの、繰り返し可能で検証可能な作業のように見えるけど。

Linearの進化については複雑な気持ちだな。いくつかの機能はあまり好きじゃないけど、全体的には使いやすさを保ってると思う。Jiraみたいになってきてる感じはしないけど、慎重に考えられたプロダクトデザインが失われつつある気がする。コードが簡単に生成できるようになったからかな。Jiraみたいになることは心配してないけど、魂を失ってしまった感じがする。それでも素晴らしい製品だよ。

すべてのソフトウェアは、古い巨大企業ではなく、新しくて速くてシンプルだから人気になる。そしてすべてのソフトウェアは成長し続けて、新しい巨大企業になり、命のサイクルが再び始まる。

これは層のある問題だと思ってる。もし一番下の層（CI）がエージェントの出力に追いつけないと、上の層での問題解決、例えばユーザーエクスペリエンスのチェックなんかは、指数的に遅くて信頼性が低くなる。内側のループを最適化することで、プログラム全体が速くなるのと似てるね。

明らかに、古い人間のテスターをエージェントAIテスターに置き換えなきゃダメだよね。速度が上がるにつれて、人間のユーザーがボトルネックになって、すべての変更や新機能についていけなくなる。幸いなことに、簡単な解決策がある：人間のユーザーをエージェントAIユーザーに置き換えればいいんだ。

LLMのおかげで、コーディングやソフトウェアが「できるだけ多くを壁に投げつけて、何がくっつくか見る」状態になってる気がする。かなり短絡的で無駄だと思う、特に人類がエネルギーの生産と消費についてもっと良くならなきゃいけないことを考えると。ちょっと暗い気持ちになるね。