長らく、コーディングエージェントについての問いは「本当に仕事をこなせるのか」だった。その問いは静かに解消されつつある。スコープが明確なタスクであれば、リポジトリを目の前にし、テストを実行できる環境さえあれば、優れたエージェントはレビューを通過する本物の変更を送り出す。そしてそれを信頼できるようになった瞬間、誰も警告してくれなかった問題にぶつかる。エージェントを忙しくさせ続けるだけの仕事を、十分な速さで思いつけないのだ。
実行はもはやボトルネックではない
ソフトウェア製品には、常にやるべき仕事が無限にある。バックログが空になることはなく、改善できる点のリストは尽きることがない。だから、エージェント向けの仕事が尽きるなどという話は奇妙に聞こえる。しかし「無限の仕事が存在する」ことと「エージェントが受け取って完了できる形の仕事が存在する」ことはまったく別の話であり、チームが行き詰まるのはこの両者のギャップにおいてだ。
エージェントは、明確なタスクを数分で実行できる。しかし、その明確なタスク——十分なコンテキストと適切なスコープ、完了の定義を備えたタスク——を書くのは、依然として人が同じ二十分をかけて行う作業だ。実行が遅い部分だった頃は、それで問題なかった。仕様策定は労力の五パーセントに過ぎず、残り九十五パーセントは実行だったからだ。実行コストがゼロに近づくと、この比率は逆転する。今や仕様策定こそが高くつく半分であり、エージェントを一体養えていたチームは、三体は養えないことに気づく。
ボトルネックは上流の、あなた自身へと移った
これがタスク供給の問題だ。エージェント主導の開発における制約は、もはやエージェントが物事をこなす能力ではなく、組織が整った形の仕事を生み出す能力にある。そしてその制約は、あなたが持つ最も希少な人材——次に何をすべきか、なぜそうすべきかを語るだけのコンテキストを持つ人材——にのしかかる。
これは奇妙な種類のプレッシャーとして感じられる。エージェントは速く信頼できるので、キューはあなたが補充できる速度以上に消化されていき、その補充こそが判断力や製品感覚、システムの向かう先についての知識を必要とする部分だ。ボトルネックは消えていない。キーボードから、キーボードが何をすべきかを知っている人の頭の中へと移動しただけだ。
エージェントは仕事の供給を手伝わなければならない
供給問題を乗り越える唯一の方法は供給を増やすことであり、タスクを定義する人はスケールしない。だから、仕事を実行するエージェント自身が、その仕事を生み出す手助けを始めなければならない——無意味な作業をでっち上げるのではなく、あなたのシステムをすでに流れている信号を、具体的ですぐに実行できるタスクへと変換することによって。
TaskGoblinは今日すでに、その一種を実践している。「タスク生成」だとは思っていなかったかもしれない、二つの場所で。
- レビューでの指摘が仕事になる。 エージェントがレビューするすべてのマージリクエストは、具体的で場所の特定された指摘を生み出す——この関数には正確性のバグがある、このパスはテストされていない、これはセキュリティ上の懸念がある、といった具合に。それぞれが事実上、完了の定義を備えた事前に書かれたタスクだ。
@taskgoblin fixと返信すれば、その指摘は変更へと変わる。誰かが座ってそのチケットを書く必要はなかった。レビューがそれを供給したのだ。 - 常設ループが仕事になる。 定期タスクは、時計に従って動くタスク生成器だ。「平日ごとに、マージ済みだが対応するissueがまだ開いている作業を見つけて閉じる」「CIが長時間赤のままになっていないか監視する」。指示は一度書けば、あとは具体的な仕事を生み出し続ける——あるいは、やるべきことが何もないときは正しく何も生み出さない——キューを手動で補充する人を必要とせずに。
どちらの場合も、エージェントは何をすべきか指示されるのを待っていない。システムの状態を読み取り、具体的で完了可能な次の一手を自ら提案しているのだ。
なぜコンテキストがすべてを決めるのか
エージェントが提案する仕事がたいてい価値が低い理由は、モデルが十分に賢くないからではない。エージェントがあなたにとって何が重要かを知らないからだ。プロダクトの意図に対して盲目なままだと、エージェントは目に見える二十個のリファクタリングを喜んで提案するが、実際にビジネスを動かすたった一つの変更は提案しない——コードが教えてくれるのは何が可能かであって、何が重要かではないからだ。
だからこそ、有用なタスク生成の場は、実際の意図に結び付いたものになる。レビューの指摘が重要なのは、それが誰かが選んで行った変更の上に成り立っているからだ。定期ループが重要なのは、issueとマージを日々同期させておく価値があると人間が判断したからだ。提案されたタスクを実行する価値があるものにするコンテキストは、コードだけには存在しない。issue、議論、そしてコードを取り巻く数々の決定の中にこそ存在する——そして私たちのエージェントのように、そうしたシステムの中で生きるエージェントは、推測するのではなく、その意図を読み取ることができる。
価値は今どこにあるのか
この流れが優位性をどこに残すのかは、はっきりさせておく価値がある。モデルがほぼあらゆることを実行できる方向へと収束するにつれ、不釣り合いな価値はもはや最も賢いエージェントを持つ者には蓄積されず、優れたエージェントに意味のある仕事を供給し続けられる者に蓄積されるようになる。勝つための一手は、より賢いモデルではない。あなたのツール群に散らばる意図と、それに基づいて行動できるエージェントとの間のループを閉じることであり、それによって「次に何をすべきか」が、あなた自身が背負うボトルネックであることをやめるのだ。
これこそが、私たちが実際に取り組んでいる問題だ。エージェントがコードを書けるようにすることは前半戦だった。何をすべきか常に把握し——あなたを待つことなく、あなたのコンテキストを次の具体的なタスクへと変換できるようにすること——それが、前半戦の価値をどれだけのものにするかを決める後半戦だ。
