技術的負債、認知的分担、意図的な債務。

LLM が大量のコードを生成する様子を目にしながら、人々は「認知的負債（Cognitive Debt）」というメタファーを用いて、「チームがシステムが何をするのかを理解しなくなるプロセス」を捉えようとしています。マーガレット・アンヌ・ストアリーによれば、これらの問題を考えるには、システムの健全性を以下の 3 つの層から捉えるのが有効であると提言しています。

• **技術的負債（Technical Debt）**はコード内に存在します。実装段階での判断が将来の変更可能性を損なうと蓄積し、システムがどのように変化できるかを制限します。
• **認知的負債（Cognitive Debt）**は人々の間に存在します。システムに対する共有理解の減少速度が、それを補完する速度を上回ると蓄積し、チームが変革についてどのように論理を構成できるかを制限します。
• **意図的負債（Intent Debt）**は文書などのアーティファクト内に存在します。システムを導くべき目標や制約事項が適切に記述・維持されていない場合に蓄積し、システムが私たちが建設しようとした意図を反映し続けられるかを制限すると同時に、人間と AI エージェントが効果的にシステムを進化させていくことを制限します。

私は「負債」というメタファーの多用には多少困惑しつつありますが、この考え方は十分に意味があると思います。記事には、それぞれの種類の負債を診断し緩和するための有用なセクションが含まれています。これら 3 つは互いに影響し合っており、記事ではそれを統制するためにチームが実施すべき一般的な活動も概説されています。

なお、同記事ではショアとネイブ（Wharton スクール）による最近の論文にも言及しており、そこでは LLM をカルナーマンの「2 つの系」を持つ思考モデルに加え込んでいます。 私が最も好きな本の 1 つであるカルナーマン著『ファスト＆スロー・ thinking』の中核にある考え方は、人間には直感（System 1）と deliberation（System 2）という 2 つの認知系を備えているというものです。System 1 はほぼ無意識のうちに迅速な判断を行います。一方、System 2 は問題を解決するために自覚的な思考を適用する段階です。彼は、エネルギー節約のために直感への依存がデフォルトとなり、問題に対し deliberation を適用していたら発見できたかもしれないものを見過ごしてトラブルに陥ることもあると指摘しました。 ショアとネイブは、人工知能（AI）を System 3 と位置づけています。

System 3 の導入に伴う帰結として、「認知的投降（Cognitive Surrender）」が生じるとされます。これは、外部的に生成された人工的な推論に対する批判的検討の欠如、すなわち System 2 を迂回する依存関係を特徴とします。重要な点として、外的情報への受動的な信頼や批判的検討を欠く「認知的投降」は、 deliberation 段階での認知を戦略的に委任する「認知的オフローディング（Cognitive Offloading）」とは区別されるべきです。

この論文は内容が多くて長ですが、「認知のトリシステム理論（Tri-System Theory of Cognition）」の詳細な説明や、同理論が少なくとも実験室内における行動をいかによく予測できるかを示す複数の実験結果の報告を含んでいます。

最近では、コードを表すアイコンの一部として"< >"という記号を使うイラストを目にすることがありますが、私にはそれが少し奇妙に感じられます。プログラム要素を"< >"で囲む言語を思い当たることができません。なぜ"{ }"ではないのでしょうか？ その理由は明白で、彼らはおそらく HTML（あるいは XML）を考えているからです。アイコンに"</>"も使えばさらにそれは明らかになります。しかし、エンジニアたちは実際には HTML を書いているわけではありません。

Ajey Gore 氏は、コーディングエージェントによってコーディングが解放された場合、何が高価なものになるのかと問いかけています。彼の答えは「検証（Verification）」です。 ジャカルタの交通状況における ETA アルゴリズムでの「正しい」という定義とは何でしょうか？ホーチミンシティではどのような違いがあるのでしょうか？収益の公平性、顧客の待機時間、車両運用率を同時にバランスさせる際に、「成功」とされるドライバー配分とはどのようなものなのでしょうか？数百人のエンジニアが昼夜問わず約 900 のマイクロサービスにコードを送っている状況において、「正しい」というのは単一の定義ではありません。それは何千もの定義であり、すべてが変化し文脈依存しています。これらはエッジケースではなく、その職務全体の正体です。 そして、まさにそのような判断能力をエージェントが代わりに行使することはできないのが現実です。

ますます、エージェントが良い、できれば自動化された検証プロセスを持ち込んでいる場合に非常にうまく機能するという見解を目にします。これは Test Driven Development（TDD）などを促すものですが、それでもなお大量の検証作業が必要となります。これは、人間がより広範なテストを容易に理解するための方法を発見する努力を増やすべきだことを示唆しています。 Ajey 氏の記述の大部分には同意しますが、彼のレガシー系モダナイゼーションに関する見解については異議を持っています。「エージェント型コーディング（Agentic Coding）は最終的にレガシー系の近代化を打破する」という考えについて、彼はそれが幻覚であると指摘しています。私はレガシーコンテキストにおいてエージェント型コーディングが過大評価されている点には同意しますが、LLM がレガシーコードの動作を理解する上で多大な助けとなることを示す説得力のある証拠を目にしました。

Ajey 氏の評価による大きな帰結は、我々はコードを書くことから組織を再編し、検証を核へとシフトさせる必要があるということです： もしエージェントが実行を担当するなら、人間の役割は検証システムの設計、品質の定義、そしてエージェントが解決できない曖昧なケースへの対処に移行します。社内の組織図もこれに即して再構築されるべきです。実践的には、月曜日の朝例会議の焦点も変化します。「何を提供したか」ではなく「何を検証したか」と聞かれるようになり、アウトプットの追跡から、そのアウトプットが正しいかどうかの追跡へと移行します。かつて特徴量構築に 10 名のエンジニアが投入されていたチームは、今や 3 名のエンジニアと、7 名の人が受入基準を定義したり、テストハーネスを設計したり、結果を監視したりすることに配分されます。それが再編です。これは快適ではありません。「構築すること」が降格し、「判断すること」が昇格するからです。多くのエンジニアリング文化はこの変化に抵抗します。抵抗しない組織だけが勝ち残るでしょう。

LLM をプログラマーとして考える際に出会う課題の一つには、ソースコードにも未来があるかどうかという問いがあります。The New Stack に掲載された David Cassel 氏の記事は、コードの将来に対する複数の見方を概説しています。一部の人々は LLM を意識した新しい言語の実験を行っており、他方は既存の言語、特に TypeScript や Rust のように厳格な型付けを持つ言語が LLM にとって最も適していると认为しています。これは多数の引用を含みながら分析的には限定的ですが、議論の全体像を把握するには有益な記事です。 これらの潮流がどのように展開するか注目しています。私は、人間が LLM と協力して、コードの動作について語るための有用な抽象化を構築する役割が残っていると考えています。本質的には、DDD（ドメイン駆動設計）における「ユニバーサル言語（Ubiquitous Language）」の概念です。昨年、Unmesh 氏とともに LLM を用いて言語を成長させるという話題に取り組みました。Unmesh 氏は以下のように述べていました：

プログラミングとは、コンピュータが理解し実行できるコーディング記法をタイプするだけではあり得ません。それは解決策を形作る行為です。私たちは問題を焦点を絞った部分に分割し、関連するデータと振る舞いを結び合わせ、—そして何よりも重要なのは—意図を明らかにするような名称を選択します。優れた名称は複雑性を切り裂き、すべての人が追えるスケマティックなコードへと変容させます。最も創造的な行為とは、我々が解決しようとしている問題に明確に対応する解決策の構造を顕在化させるような、名前の連綿たる織り交ぜ続けることにあります。