ボトルネックは、手を動かす速度からGitHubへ移った

Isamu氏は、Claude Codeのエージェントを最大6セッション並列で走らせるために、ブラウザベースのターミナル「MulmoTerminal」を自作した。結果、1日のコミット数は500を超えるようになった(出典)。

数字の意味は、並列度と判断速度の掛け算だという。6本のエージェントがそれぞれ小さな変更を積み重ねれば、総量は自然に膨れ上がる。

状態が見えないという問題を、表示で解いた

従来の6分割ターミナルの課題は、各セッションが今どういう状態にあるかわからないことだった。MulmoTerminalは、セッションごとの進捗サマリー表示、idle・running・入力待ちの色分け、待ちタスクをスマートウォッチへ通知するiOSのWeb Push、リポジトリごとの色分けといった機能で、この「状態が見えない」問題を解決した。

エージェントが何をしているかが一目でわかれば、人間は次にどこへ判断を返せばいいかで迷わなくなる。

三段階で移り変わったボトルネック

氏はボトルネックの移り変わりを三段階で振り返っている。最初は、手を動かす速度が律速だった。人間が一行ずつコードを書いている限り、そこが生産量の上限になる。MulmoTerminal導入後、律速は判断を返す速度に移った。エージェントが並列に動く分、人間が「これでいい」「これは違う」と返す判断のほうが追いつかなくなる。

そして現在は、GitHubへの取り込み速度がボトルネックになっているという。

手を動かす速度のボトルネックは、並列化で解ける。判断を返す速度のボトルネックも、通知やサマリー表示である程度は緩和できる。だが、GitHubへの取り込み速度というボトルネックは、性質が違う。取り込みにはレビューという工程が挟まり、レビューは判断を返す速度とは別に、その判断が正しいかどうかを確かめる工程だ。確かめる側の人数や時間は、エージェントの並列数がいくつ増えても増えない。

PR量産側を解いた先に、受け取る側の問題が残る

PR量産側の問題を解いた先に、PRを受け取る側の質保証という別の問題が姿を現す。この構図は、PRレビューツールParryの立ち位置とそのまま重なる。Parryが解こうとしているのは、まさにこのGitHubへの取り込み速度、つまりレビューが詰まる場所である。

PRの本数が増えるほど、なぜこの変更が必要かという判断を、レビュアーが都度復元するコストも増える。Why・Risk・Confidence・Contextという四軸をあらかじめ埋めさせておくのは、取り込み側の確認コストを、PRが生まれた時点で先払いさせる設計だと言える。

氏自身、この記事の続きとしてコードレビューの自動化に取り組んでいるという。取り込み側のボトルネックをどう解くかという答えは、まだ出ていない。長年使ってきたemacsの出番がなくなった、という氏の一言は、書く作業そのものが人間の主戦場ではなくなりつつあることを、思いがけず言い当てている。