2人のビルダー、1つの正典、そして「誰が1ステップ飛ばせるか」をめぐる意見の不一致。
あなたのAIエージェントは、退屈なステップが「やれる」と思った瞬間に、すぐに飛ばします。しかも即座に。金曜の16時にへとへとになった開発者と同じです。ただしエージェントはそれを100倍速く、100倍の確信でやります。そして、他の人をときどき救うことになる自己疑念は一切ありません。
私はこのことを苦い経験から学びました。私は、Claudeに実際のプロダクト作業をさせるためのハーネス「Mycelium」を作りました。つまり、ディスカバリーをデリバリーによって行うのです。エージェントはmacOSアプリで行うディスカバリーを完璧にこなしました。機会のツリーを教科書のようにマッピングしました。ところが、その後はテストもなく、アクセシビリティも欠いたまま「そのまま」出荷しました。間違った半分の仕事に、見事に美しく仕上げてしまったという、完璧な計画です。なぜ？ 私のルールは親切なアドバイスにすぎなかったから。アドバイスは、人間でも機械でも、部屋の中に締切があると最初に窓の外へ飛んでいきます。
そこで私は、同じ問題を直そうとしている他の人を探しました。見つけた中で最良だったのがDean Peters と彼の Product-Manager-Skills です。
ここからが、私が身を乗り出した部分です。Deanは、AIエージェント向けに49のプロダクトマネジメントスキルをパッケージ化しました。Torresがディスカバリー、Caganがエンパワーされたチーム、Jobs-to-be-Done、全ての正典。私はMyceliumも同じ正典で作りました。さらに49のスキル。2人の人間、連携なし。同じ「良いプロダクト作業がどう見えるか」という地図。読書リストにまで至るまで。私たちはどちらも何かに気づいているのか、あるいは同じ5冊を読んでいるのか。たぶん両方です。
私たちの意見が1点だけ分かれるのは、どこが違うのかということ。そしてそれが重要なところです。
人間をコーチするのか、エージェントを止めるのか
Deanはコーチします。彼のキャッチフレーズは "Always Be Coaching"（常にコーチせよ）で、すべてのスキルが「最初よりも人間が多くを知る」状態で終わるように作られています。姿勢について彼は驚くほど率直です。彼のSubstack では、彼はフレームワークを「メインコースのようではなく、調味料のように」使うと言っています。ここ数年でフレームワークについて誰かが言ったこととしては、最も筋が通っていることです。規律はあなたの判断の中に宿る。ツールはそれを研ぎ澄ます。
Myceliumはコーチしません。ゲートします。同じフレームワークを、3つの階層の中で38のガードレールとして配線しています。いくつかは最初から完全にブロックされ、大きな中間の階層では、エビデンスが存在するまで作業を「完了」として通しません。残りは単なる後押しです。テストもなく、doneもない。「脅威モデル」もなく、doneもない。エージェントはこれを非常に不合理だと感じるはずです、もしくは感じていたでしょう（もし気持ちがあれば）。しかし気持ちはありません。だからこそ、これがポイントです。
規律を「どこに置くべきか」について、2つの賭けがある。
Deanは人間に賭けます。軽く保ち、技術を教え、そこから先は本人が運ぶと信じる。キーボードの前にいる人が舵を取っていて、現実のリスクは「まだ良いものがどう見えるかを分かっていない」ことだ、という状況なら、それが正しい賭けです。コーチングはプロダクトマネージャーを育てます。ゲートは誰かに何かを教えたことがありませんし、教えるつもりもありません。
私はループに賭けました。つまり、そのステップを「エージェントが意図的にスキップしなければならないもの」にします。放っておくと、確信した瞬間に必ずスキップするからです。いつでも。いくつかのものは最初から完全にブロックされます。残りは、フレームワークが単に「完了」と呼ぶことを拒否し、「まだ完了ではない」と書き残すだけです。そして、それでほとんどの場合十分だと分かりました。エージェントが速く動いていて、リスクが「無知」ではなく「勢い」であるときに、それが正しい賭けです。退屈な修正を「大事にしよう」とエージェントをコーチすることはできません。ですが、退屈な修正が終わるまでドアの前に立ち続けることはできます。
どちらも、もう一方のアップグレードではありません。両者は積み重なります。まずコーチングスキルで問題を考え抜き、その後ゲートで、未完成のまま半端に出荷できないように出力を制限します。ライブラリは人間を教えます。ゲートはエージェントを制約します。同じ正典、同じループの両端。
では、どちらが必要か
質問は1つだけです。リスクはどこにありますか？
リスクが「人がまだその技能を知らない」ことなら、コーチングが必要です。ゲートは彼らを苛立たせるだけで、何も教えません。つまり、双方の最悪を同時に生むことになります。Deanのフレームワークは、まさにそういう人のために作られています。しかも、それを教えることを明らかに楽しんでいる誰かによって。
リスクが「エージェントは速く、確信していて、たった1回のキー入力で、次の四半期に支払うことになるショートカットへ飛び込んでしまう」ことなら、ゲートが必要です。ここは私に根拠があります。控えめですが、実際のものです。私は先月、Myceliumを3人の初めてのユーザーで動かしました。そのうちの1人、ジュニアの開発者が、エージェントが自分自身のブリーフを書き換えようとしていることを静かに見つけました。改良版で上書きしようとしていたのです。彼女はそれを止め、両方を残すようにしました。フレームワークが強制するために作られた「まさにその規律」を、フレームワークがまだうまく管理しきれていない唯一の瞬間で、彼女がきちんと強制したのです。自分のテスターに規律で負かされる経験は、謙虚にさせられます。おすすめします。これが、たった1つの物語に集約された議論の全てです。規律は誰も見ていないときにこそ維持されなければならない。特にそのとき。
3人のユーザーは3であって、30ではありません。私はまだスケールするとは主張していません。失敗のモードは本物だ、と主張しています。なぜなら私は、それが起きるのを見続けているからです。たいていは、エージェントが「どれも完璧に見えます」と言った直後に。
私たちが合意している部分
メカニズムを剥がしてしまえば、Deanと私が言っていることは同じです。ツールは、こちらが望もうが望むまいが、毎月変わり続けます。残るのは、締切と接触しても規律が生き残るかどうかです。彼はその規律を人間に「コーチする」ツールを作っています。私は、エージェントが欲しがるかどうかに関わらず、それに従わせるものを作りました。
だから、もしあなたが私たちのどちらかを選ぶなら、たぶん間違った質問をしています。私たちは2つの違うことに答えています。あなたが信頼できないのが、人間の知識なのか、エージェントの自制なのかを整理し、その選択が自ずと決まるのです。そしてそれがエージェントだと分かったなら、まあ、そのための「足枷」です。
Myceliumは github.com/haabe/mycelium にあります。Deanの Product-Manager-Skills は、あなたがどちらに賭けるかにかかわらず、あなたの時間を投資する価値があります。
