認知的降伏に抵抗する

認知的降伏に抵抗する

Working Notes: アイデアを記録・探求するためのコモンプレイスノートブック。
ホーム。 サイトマップ。 購読。詳細は expLog で。 — Kunal

このノートは、認知的降伏、すなわちエージェントが出力したものを、実際に思考したり、探求したり、代替案を検討したりすることなく無批判に受け入れてしまうことについて探求しています。このやり方は非常に速く、特に負担も少なく、驚くほど魅力的なものです。

しかし、私はエージェントをこのように使うことが本当に良い方法なのか、繰り返し疑問に感じています。しばしば、最適ではない決定を下し、技術的負債を蓄積し、作業しているシステムへの習熟度を低下させてしまうのです。

私たちが集合的に働き方を見直す中で、他人のワークフローを読んだり共有したりすること、そして自分のワークフローについて意識的に書き、検討することが役立つと感じています。この投稿は、エージェントと作業する際の信頼の適切なバランスを見つけることに焦点を当てています。

［画像: managing complexity］

認知的降伏は魅力的である

優秀なプログラマーであることの美徳の一つは怠惰であることです。最短・最簡の道を探すように10年以上自分を鍛えてきた私にとって、問題を単純に委ねられるというのは非常に魅力的です。ソフトウェア工場を立ち上げられるなら、なぜそうしないのでしょうか？

そこには、同僚からのプレッシャー（あるいはゲーム理論）も働いています。もし同僚の誰かが降伏しているように見えるなら、私が理解するために時間をかけすぎようとすると、さらに悪く見えてしまうだけです。そして、もちろん、他の皆が読めるよりも速くコードを生成するスロップキャノンである一方で、私は完璧な設計を製造する、細心の注意を払って設計されたソフトウェア工場を構築できます。その量の多さも驚くほど生産的に見えます。私たちは皆、毎日どれだけ多くのPRをリリースしているかについて話してきました。

これは、エージェントの表明する自信と確信によってさらに増幅される傾向があります。おそらくRLHFの意図しない結果ですが、モデルは推奨することに驚くほど自信を持っている（そして、間違いを認める際にはさらに平然としているかもしれません）。これにより、私が進化させてきたソーシャルプログラミングのようなものと組み合わせて、その回答を額面通りに受け取りやすくなります。

OSSプロジェクト、特に時間的プレッシャーに直面しているものは、急速に巨大な複雑さを蓄積する傾向があり、まともな時間枠でプロジェクトとやり取りする唯一の方法は、コードのナビゲーション、変更、テストのためにエージェントに大きく依存することのように感じられます。これも自己強化的なフィードバックループです。エージェントが野放しになると、壊れた窓は急速に増殖します。[1]

技術的負債と付随的複雑さには、かなり遅延したフィードバックループがあります。スロップによって導入された複雑さはすぐに影響しません。それははるかに微妙で、私が注意を払っていないときに時間とともに複利で増加します。

それらのすべてを超えて、ハイプサイクルに言及しなければなりません。私たちは皆、Anthropicのエンジニアがループ（または今日のエージェントワークフロー）を作る方法についての講演を見るためにNetflixをスキップすべきです。[2]

なぜ降伏しないのか？

降伏することが悪い考えであるとは全く明らかではありません。もしそれがより簡単でより良いなら、なぜその道を選ばないのでしょうか？今のところ、私の個人的な答えは、その道は意識的に、意図的に、そして十分な努力を伴って、ダウンサイドを軽減する必要があるということです。

私が深く不快に感じる理由の一部は、エージェントと作業する際にGell-Mann amnesia（ゲールマン健忘症）の一種を経験することです。私に専門知識と全体的な設計方向があれば、複雑さを制御しながら、一般的に出力を大幅に簡略化できます。そうでない場合、彼らは存在しうる中で最も賢いエンジニアのように思え、私はただ畏敬の念を抱いて従うしかありません。そして、エージェントがディレクトリを作成するのに詰まり、私はすべての仮定をリセットしなければならなくなります。

現在の最先端技術（2026年10月）では、一般的にエージェントの最大利用は複雑さの爆発につながります。それは、驚くべきエッジケースやバグを伴い、ほとんどの場合機能するものです。これらは通常、急速にリリースされる何十万行ものコードを持つプロジェクトであり、ほとんどのソフトウェア開発ツールのサポートを超える規模になります。そのため、それらも再検討する必要があり、これは急速に複利で増加します。

私は付随的複雑さに対して強い嫌悪感を持っており、それを構築、維持、拡張することを一般的に拒否します。概念実証には構いませんが、そこで終わらなければなりません。継続して動作する必要があるシステムについては、私が実際に運用できるもの（エージェントの有無にかかわらず）を構築できるように、設計をシンプルさとモジュール性に積極的に向かわせることが重要です。

モデルが急速に進歩し続けるにつれて、モデルが学習し、エンジニアリングのセンス、良い設計、品質の広範な感覚を表現できるようになるにつれて、以前の議論はなくなるだろうと予想しています。もう一つの理由、残念ながら続くであろう理由は、私が維持しているシステムに対する個人的な理解と機械的共感（mechanical sympathy）が非常に急速に失われるか、開発の機会さえ得られないことです。

初期の頃、自分で物事を構築していた頃は、コードの構築と維持に関する知識のおかげで、どんなバグや誤動作でも迅速に診断できました。エージェントに依存するほど、私の唯一の選択肢は、さらにセッションを立ち上げて希望することになります。そして、自動化された修正は、自己強化的なループで私の理解をさらに低下させます。コンテキストなしでは、私はもはや意味のある判断を下せず、関与することも、コンテキスト内で処理することもできません。

自動化の皮肉（1983年）は、この種の記事でしばしば参照されます。まだ読んでいない場合は、直接論文を読むことをお勧めします。それは、エージェントが失敗したタスクに対処することがさらに困難になるだろうと警告しています。なぜなら、私たちは簡単なタスクで練習する機会を得られず、標準的な運用状況下でのシステムの感覚を内面化する機会も得られないからです。

［画像: The Ironies of Automation］

結局のところ、私が構築するものに対して責任を負い、説明責任を果たすのは私であり、エージェントではありません。エージェンシーを放棄し、思考しないことは、実質的に意味のある所有権なしに私を責任ある立場に置きます。また、私の仕事の品質に対するささやかな誇りもあります。[3]

ソリューション

陰鬱な導入部分から、AIが解き放つ計り知れない可能性と、それなしでは決して構築できなかったであろうものを作る機会に私が興奮していないと誤解しないでください。それはむしろ、期待値をリセットし、関わるトレードオフを明確に検討し、許容できるものを選ぶことです。そして、私が大切にしている品質と職人技を維持する方法を見つけることです。

トレードオフは依然として存在する

私にとって最初のステップは、ケーキを保持しつつ食べることはできないということを内面化することでした。物事を恐ろしく、人間離れした速さで構築することはできますが、努力なしにはかつて持っていた機械的共感、深さ、自信を維持する方法がないことを受け入れる必要があります。かつてシステムを構築する時間としてのみカウントされていた時間には、理解も含まれていました。エージェントは構築時間をゼロにすることができますが、次のボトルネックである理解は、今のところあまり移動していません。

ハイプサイクルは、これを明示的に伝えることを時々困難にします。エージェントループに関する多くのコミュニケーションは、全くダウンサイドがないと仮定する傾向があります。

バイブレーションリミットを選択し、トリアージする

数ヶ月前、私はバイブレーションリミットを、エージェントを使用して十分な自信を持って行える変更の複雑さと定義しました。リスク/複雑さのカーブが気に入ったので、もう一度掲載します。

［画像: Vibe Limits］

次のステップは、どこに位置するかを見つけることです。十分なもので良いプロジェクトもあれば、問題が十分にサンドボックス化されており、エージェントが生成したものを受け入れられるプロジェクトもあります。一方で、システムが重要で、壊れやすく、簡単に健全性チェックができず、あるいは特にうまく分離されていない場合は、私の時間を直接費やす必要があります。

積極的な優先順位付け、トリアージ、そして絶え間ない自己再調整は、このエコシステムで非常に重要になります。エージェンシーをどこで手放し、どこで時間を費やすかを明確に選択する必要があります（チームを率いるのと似ていますが、ペースははるかに速いです）。自分の予測と結果を絶えずレビューすることは、特に新しいモデルがリリースされたときに、再調整に大いに役立ちます。

自動化バイアスに注意する

また、作業中にさらに注意を払う必要があると感じています。最近私が注意している警告サインは、セッション中に繰り返し「はい、続行」をタップしている自分に気づいたときです。その時点で、問題をClaudeに完全に委任するために何が必要かを見つけるか、あるいは思考を停止したことに気づき、行われている決定を確認する必要があるかのどちらかです。

問題を完全に委任することは、一般的に、より良いサンドボックスやフィードバックループを構築すること、あるいは本番環境にリリースする前に、はるかに簡単に健全性チェックを行う方法を見つけることを意味します。あるいは、より深く関与する必要がある場合は、以下に説明する他の戦術のいくつかを使用します。

ループに自分を強制する

強力な思考機械とループ内で作業することによって自分を拡張するという前提は、私が現在の会社に入社した大きな理由の一部でした。これは一般的に、モデルが取るステップのサイズを縮小するための指示を与えるか、受動的に観察する代わりに積極的に運転することを選択することにつながります。

私が深く気にかけているプロジェクトでは、モデルに運転させるのではなく運転を選択することが、すべての決定に介入する一つの方法です。タイプアウトするのははるかに遅いですが、すべての決定に関与することを強制され、それを上書きする機会を与えられます。実際、この投稿ではCodexセッションを編集に使用しています。投稿を絞り込み、小さなタイプミス、句読点の誤り、あるいは公開後に私を恥ずかしくさせる半完成の文章を指摘してもらいますが、すべての変更は手作業で行います。

ノートブックのAGENTS.mdでは：

ファイルを直接編集しないでください。常に作者が変更を要求または確認するのを待つか、作者が直接編集できるようにしてください。

これは、私がStack Overflowと作業していた方法を彷彿とさせます。コードをコピー＆ペーストせず、代わりにドキュメントと照合しながら明示的に書き出します。新しいことを学び内面化するか、Stack Overflowの回答が最適でないか古いことに気づくでしょう。

理解可能性を強制する

もはや既存のインターフェースに限定する必要はありません。エージェントを使用すると、理解をサポートし、消化可能な方法で変更を行うための膨大な量の足場を構築させることも可能です。

多くの場合、より大きく複雑なスタックでは、エージェントにプルリクエスト用のカスタムビューを4つの列で構築させます。標準的な2つの差分表示列、3つ目の列にはエージェントからの特定の変更を行った理由についての実行中のコメント、そして4つ目の列は私がコメントや指示を追加する場所です。

エージェントに、「変更を容易にし、それから容易な変更を行え」という明確な指示で変更のスタックを作成させることは、非常にうまく機能します。私はレビュー担当者の時間を尊重するために、差分をレビューしやすくするために多くの時間を費やしていました。今ではエージェントに同じことを私にしてくれるように頼むことができます。

デバッガを使用した実際の実行に飛び込むこと（またはエージェントに代わってデバッガを操作させること）は、物事がプログラムをどのように流れているかを深く理解するまで非常に価値があります。これは実際の実行パスであるという確信を持って。

別の例として、ハーネスが何をしているかを説明させることです。私はシェルセッションに透過的に適合するコマンドラインヘルパーのいくつかのバリエーションを構築しました（最後の公開バージョンはxです）。私の最新のイテレーションでは、モデルに、使用されている曖昧なフラグやコマンドを説明するように明示的に依頼しており、学習しながら進めることができます。

委任することを決定した場合

場合によっては、問題のエージェントへの引き渡しが理にかなっています。それは大きすぎる、価値が十分でない、時間が短すぎる、あるいは単にエンドツーエンドで問題を探索するために最初のプロトタイプを出したいだけかもしれません。

これはおそらくそれ自体で一つのエッセイになるでしょう。無限に速い確率的知性が上に乗っている場合に、昔ながらのベストプラクティスを適応させることです。このアイデアは、変更を加える際のリスクを軽減し、バイブレーションリミットカーブを平坦化し、より大きな変更を安全に行えるようにすることです。

エージェントに目標に対して自身を検証する手段を与えることに加えて、私は以下を行うことが非常に役立つと感じています。

• オブザーバビリティ: オブザーバビリティ（ブラックボックスとホワイトボックスの両方）に重点的に投資し、エージェントのビューだけに頼るのではなく、メトリクスを直接把握できるようにします。習慣として、複数のメトリクスソースで動作を三角測量することを選びますが、システムが急速に不透明になるにつれて、これはさらに重要になります。
• 非機能要件: リソース利用率やその他の非機能要件を観察することを忘れないでください。これらは予期しない動作のカナリアになる可能性があります。
• 決定論的検証: モデルに機械的な拘束具を構築します。モデルの誤解やグリッチに対する保留として、検証と観測のためにコードの保留された断片や決定論的なツールを用意します。
• シャドウトラフィック: デプロイされた候補を、副作用なしにシャドウトラフィックに対して実行できるようにし、安価にします。本番環境と可能な限り似た状態に保ち、これが驚きを防ぐための最終ゲートになる可能性があります。
• スタイルガイド: 既存のコードと作業に基づいたスタイルガイドをモデルに提供します。過去に私が書いたコードとブログ記事全体に基づいてモデルにスタイルガイドを生成させた後、Claudeの出力が私の好みに far more 近づきました。
• 高速デプロイ: Facebookでしばしば悪く言われたモットーはMove Fast & Break Thingsでした。それもまた、意図的なトレードオフです。品質に確信が持てない場合は、コードをデプロイしやすくすることも重要です。そうすれば、変更を迅速に出荷したり元に戻したりできます。
• 可能性を再考する: 学習するにつれて、システムをゼロから迅速に書き直すことは驚くほど簡単です。投げ捨てるために構築し、評価し、繰り返して、素晴らしい形に整えます。私は複数のイテレーションでプロジェクトを構築し、前のイテレーションとその制限を初期コンテキストとしてエージェントに与え、常に品質を深く向上させることができました。これはコードレビュー担当者を罰する場合にはあまりうまくいかないので、チームと連携するか、最初の数回のイテレーションをレビューしてもらわないようにしてください。

良い設計はフォース・マルチプライヤーである

Notes on the Synthesis of Formの中で、クリストファー・アレグザンダーは、分解、つまり、軽度に結合された、凝集性の高いシステムを構築して迅速に成功するための素晴らしい例を示しています。

複雑な適応システムは、適応がサブシステムごと、各サブシステムが他のサブシステムから相対的に独立して進行できない限り、合理的な時間内に適応に成功することはない。

［画像: Screenshot 2026-11-01 001757］

エージェントであれ人間であれ、良い設計はシステムを理解し、イテレーションし、検証し、拡張することをはるかに容易にします。設計の限界を学ぶにつれて、以前よりもはるかに迅速にそれをやり直す能力も得られます。プロジェクトで維持する深さに関わらず、より広範な構造が理にかなっていることを確認してください。

追加資料

関連する興味深い記事、講演、書籍がいくつかあります。

• Addy Osmani による追加テクニックの数々
• Guy Levi による批判的思考への傾倒の推奨
• Cory Doctorow によるAIの使用を強制された場合の対処法
• Stuart Halloway によるAIは自動化であり、メティスを構築するための摩擦の重要性
• Elizabeth, SigNoz によるスキルの衰退について
• Ricard Solé et al. によるLLMを認知ウイルスとして、認知オフローディングの相互作用と結果のモデリングについて

コンテキストを失うことなくエージェントを効果的に活用することに関する他の推奨事項があれば、ぜひ知りたいです。試すべき追加の実験や採用すべきワークフローがあれば、ぜひ聞かせてください！特に、スロップに崩壊したプロジェクトをうまく回復させた経験があれば、なおさらです。

---

1. 私は、ソフトウェアが自身の複雑さの重みで失敗することを常に予期してきました。私のホットテイクの一つは、これが私が期待する規模と magnitude でまだ起こっていないのは、前の世代が導入した負債に追いつくほどエージェントが速く賢くなったからだということです。↩︎
2. 私の毎週のThe Great British Baking Showへの耽溺は、私の冷たく死んだ手から奪われるでしょう。↩︎
3. これは物事を構築する非常に「個人貢献者」的なアプローチであり、マネージャーは常にこれに対処していると主張するかもしれません。アンドリュー・グローブのマネジメントについて引用します。「フォローアップのない委任は放棄である」 – あなたが必要な結果を得るためには、依然として関与する必要があります。↩︎

---