ボトルネックはタイピングだったことは一度もない

AIはタイピングを速くしただけではなかった——ボトルネックそのものを完全に移動させた。エージェントを並列に実行する方法を学んだチームは、一度に一つの差分を待っているチームからは見分けがつかないほど変わって見えるだろう。

AIを使った私の開発ループの最初のバージョンは単純だった。アシスタントにAという物事をやらせる。待つ。差分をレビューする。Bという物事に移る。アシスタントはより速いペアプログラミング・パートナーだった。それでもペアだ。それでも一度に一つの物事。

そのモデルはおよそ三か月続いた。今の私の働き方はそうではない。

今私がやっているのは、複数のAIコーディング・アシスタントを同じコードベースに対して並列に実行することだ。それぞれが独自のgit worktreeで、それぞれが独自のブランチで、それぞれが同時に異なる問題に取り組んでいる。どの瞬間を取っても、リポジトリ全体で五から十のアクティブなブランチがある。異なるエージェントたちがエンジンの異なる部分を同時に押し進めている。私は書いて待つ代わりに、レビューしてマージする。

私の仕事におけるこの変化が、この投稿のテーマだ。

実際の週末はどう見えるか

三月半ばのある週末。五つのリポジトリにまたがって、土曜の朝食から日曜の夕食までの間に112件のコミットが着地した。66件はAIが記録上の著者だった。47件は私だった。残りはマージとレビュー駆動のクリーンアップだった。

作業は一つのプロジェクトではなかった。五つだった。九つのジャンル向けのWASM移植。iOS Metalレンダラーの統合。七段階のパイプラインを通る二十一のアセットを持つコンテンツパック・ランナー。カードバトル・ジャンルのステージ五から七。Webビルドのパフォーマンス最適化。そのすべてが、同じ二日間、それぞれの午後と夜を通じて着地する並列ブランチの中で起きた。

キッチンテーブルの机で一人の人間が週末に112件のコミットを書くことはない。一人の人間が、五つの並列ワークストリームを一つの頭の中に保持し、それぞれのコードを書くことはできない。三か月前の私が持っていたモデルは、この週末を生み出せなかっただろう。

今の私が持っているモデルは、それを生み出す。

ボトルネックが移動する

作業が逐次的なとき、ボトルネックはタイピングだ。誰かがそれを書くまで、次の行のコードは存在しない。AIはその行を速くした。どのステップが遅いかは変えなかった。

作業が並列なとき、ボトルネックは選定だ。四体のエージェントが四つの差分を持って戻ってくる。うち二つは良い。一つは正しい方向だが手直しが必要だ。一つは書かれるべきではなかった。遅いステップは、どれがどれかを判断し、生き残った二つをマージすることだ。

それは、私が訓練を受けた仕事とはまったく異なる仕事だ。タイピングは減る。トリアージは増える。合成は減る。選定は増える。

週末の形はこうだ。

• 土曜の朝:枠組み作り。どの四つの問題が四つの並列試行に値するか。それぞれの成功基準は何か。許容できる答えのおおよその形は何か。
• 両日を通じて:抜き打ちチェック。エージェントたちは順調か。最初の三十分で誰かが自信満々に間違ったものを作らなかったか。誰かが行き詰まっていないか。
• 両日の夕方遅く:レビューとマージ。差分が入ってくる。成功基準を念頭に置いて一つずつ読む。当たったものをマージする。当たらなかったものをやり直すか閉じる。失敗した試みが問題について何を教えてくれたかを記録する。
• 日曜の終わり:週末が何を出荷したか、次の四つの問題は何かを書き留める。

これは、コパイロットを持つシニアICであることよりも、四人のチームを持つテックリードであることに似ている。異なる筋肉を使う。使う筋肉は、領域を超えて驚くほど汎用的だ。

これが.rakuファイルと組み合わさる場所

私たちのエンジンが実行する体験ファイルは.rakuファイルだ:JSON、スキーマバージョン管理され、検証可能で、コードとしてレビュー可能だ。このフォーマットは、この並列エージェント・ワークフローを念頭に設計された。

エージェントが.rakuファイルを編集するとき、その差分はコードの差分と同じように現れる。二番目のエージェントが最初のエージェントの作業をレビューできる。三番目のエージェントを実行して両方を抜き打ちチェックできる。マージの判断は私のものだ。全体が、ランタイムに使うのと同じプルリクエストの規律の中に収まる。

もし.rakuがバイナリのアセットだったら、これのどれも機能しなかっただろう。フォーマットの選択とワークフローの選択は、同じアーキテクチャ上の決定の下流にある:体験はコードであり、開発作業はコードレビューであり、エージェントはループがコードを受け入れるからこそそのループに参加する。

ファイルフォーマットは荷重を支えている。それが、チームが人員ではなくエージェントを通じてスケールすることを可能にしているものだ。

実際にうまくいっていること

私が落ち着いた三つのパターン。

一つ:問題にエージェントをペアにする。 何かが自明でないとき、異なる学習を持つ二体のアシスタントは生産的に意見を異にする傾向がある。私はそれらを同じプロンプトで別々のブランチで実行し、それから答えを差分する。意見の相違が、本当のレビューの注意が向かう場所だ。

二つ:一体のエージェントをレビュー専任にする。 私は、その日の四体のアシスタントのうち一体を常にレビュー専任の役割に置いておく。それは決して最初の草稿を書かない。他のものが生み出す差分を批評するだけだ。専任レビュアーを実行するコストは小さい。バグ捕捉率は大きい。

三つ:エージェントのコンテキストを狭く保つ。 一つの問題に対する一つのブランチに対する一体のエージェントは速い。五時間分のコンテキストを持つ広範な問題に対する一体のエージェントはドリフトし、質の低い作業を生み出す。修正は、問題をより小さな断片に分解し、頻繁にコンテキストを回転させることだ。

何が壊れるか

うまくいかないことについても正直に。

協調のオーバーヘッドは本物だ。 同じファイルに同時に取り組む二体のエージェントは、私が解決しなければならないマージ競合を生む。競合ごとのコストは小さいが積み重なる。緩和策:可能なときはエージェントを異なるファイルに置き、収束のステップがワークフローの一部であることを受け入れる。

レビュー疲労は本物だ。 各日の終わりに四つの差分をレビューするのは、四日にわたって四つの逐次的な差分をレビューするよりも大変だ。判断が密になる。並列エージェントの日は、作業が逐次的だったときよりも早めに仕事を切り上げる。

すべてを残しておきたい誘惑は本物だ。 二体のエージェントが両方とも妥当なものを生み出したとき、怠惰な動きは両方をマージすることだ。規律ある動きは一つを選ぶことだ。両方をマージすると、同じことをする二つの方法でコードベースが汚染され、負けたほうをやり直すだけよりもコストがかかる。

長時間実行される並列セッション全体でのコンテキストのドリフトは本物だ。 一日開いたままのブランチは、エージェントが開始した瞬間にコードベースについて行った前提を蓄積する。夕方までに、それらの前提は古くなっているかもしれない。修正は、容赦なく短命なブランチだ。

すべてが並列化するわけではない。 微妙な不変条件を持つ横断的なリファクタリングは、四つの並列試行ではなく単一の慎重なパスを望む。技術は、どの問題がきれいに分割でき、どれがそうでないかを知ることだ。今も逐次的な日はある。

これがエンジニアリング・リーダーにとって何を意味するか

あなたのチームがAIを取り付けた逐次モデルを実行しているなら、次のステップは「より良いモデルを使う」ではない。「一度に複数のエージェントを使う」だ。能力の天井はより高い。スキルの天井もより高くなり、シニアの役割を制作から、枠組み作り・検証・選定へと移す。それは、AIをうまく実行しているあらゆる他の分野で私が見ている方向性と同じだ。

今後二年間で並列エージェント・ワークフローを見出すチームは、いまだ逐次モデルを実行しているチームからは見分けがつかないほど変わって見えるだろう。変わるのは作業の形だ。ツールではない。

二日間で112件のコミット。日曜日にほとんどがグリーンの状態でラップトップを閉じる。