技術的負債だけじゃない？「認知の負債」「意図の負債」が開発現場を蝕む理由

エンジニア界隈でよく耳にする「技術的負債（Technical Debt）」。しかし、実際の現場ではそれだけでは説明がつかない問題が山積みです。今回は、コード以外の見えない負債として「認知の負債（Cognitive Debt）」と「意図の負債（Intent Debt）」という概念にスポットを当ててみたいと思います。これらを理解し、マネジメントすることが、持続可能な開発チームを作る鍵になるかもしれません。

マーティンの言いたいことはわかるけど、それならどの段階で抽象化レイヤーを上げるかという議論にも同じことが言えるはず。彼なりの定義でいえば、アセンブリ言語からPythonへ移行するだけで多大な「意図と認知の負債」が生まれることになる。ハードウェアのビットをどう操作するかを深く考えず、インタプリタに任せてしまうからね。僕の反論としては、彼が言うような「技術的意図」というのは、人間が意図したことを機械語に翻訳する必要があったからこそ存在したものだと思う。コード上でドメイン駆動の抽象化を行わなくても、問題について深く考えることはできる。マインドマップを描いたり、日記に書いたり、壁中に付箋を貼ったりしてもいい。オブジェクト指向の抽象化を作るなんて、魔法でもなんでもないよ。

LLMに「怠惰」という美徳が欠けているなんてことはないよ。プロンプトのベースで意図を正しく指定すれば、ちゃんと備わっている。僕はClaudeをバックエンドにしたエージェントに、コード変更を最小限に抑えて重複排除を徹底させるよう指示して成功しているし、優秀なシニアエンジニアが持つような「直感」を再現できている。これはモデルが学習していない知識ではなく、デフォルト設定では前面に出てこないだけの話。みんなも経験があるでしょ、なんでもかんでもオーバーにリファクタリングして、他人の変更なんてお構いなし、過剰な修正で知識が失われるリスクも無視してコードベース全体をいじり回す、あの厄介な中堅エンジニアみたいなモデルのことだよ。それと、ドキュメントの検証と生成に関するジェスのコメントについてだけど……これは昔からあるロックの問題であって、解決策も定石通り。それに、エージェントがGitを読み取れないわけじゃないんだから、習慣的にどちらの作業が先に行われるべきか把握させることだってできるでしょ。僕はかなりのシニアレベルで、実際この記事で言及されている何人かとは同僚だったこともある。彼らも僕のエンジニアリング基準を疑うことはないはずだ。それなのに、LLMを使ったワークフローでそういった負債を感じたことはない。むしろ、伝統的なソフトウェア品質の評価指標で言えば、今のプロジェクトは5年や10年前よりも改善しているくらいだ。魔法なんかじゃない。品質の優先順位を共有するエージェントを動かしているだけだよ。まあ、僕はカンファレンスで注目を集めることより、実務を終わらせることに集中しているだけだけどね。

「よりパワフルな抽象化を開発することで、後々の作業が圧倒的に楽になる」という部分、暗に「怠惰になるには多くの努力が必要」と言っているのが面白いね。これってYAGNIに通じる話だけど、世の中のほとんどの人は逆を信じていて、必要な抽象化を構築しないための言い訳としてYAGNIを使っていることが多すぎる。

マーティンが言っていることは間違っていないと思う。でも、AIが「怠惰」なコードを書こうとして、結果的にコード量が増えてしまった例を実際に見たことがある。具体的な例を挙げると、ある論理的な概念セットのためにデータベーススキーマを定義したPythonモデルがあったんだ。そこに既存の概念セットとよく似た新しい概念を追加した時、Claudeは「既存のモデルセットを再利用すべき」と判断した。理論上は機能するけど、結局呼び出し側が実行時に型推論をするために複雑な処理を強いられることになった。「動いてはいる」けど、明らかに抽象化レイヤーの選択を間違えていたね。

「LLMには本質的に怠惰という美徳が欠けている」だって？いやいや、そんなことは絶対にないよ。

「負債」という枠組み自体は公平だけど、僕らのケースで一番の問題は「怠惰なコード」じゃなくて「熱心すぎるコード」なんだよね。Claudeは「パターンを見つけた」という理由で、関連のない3つのファイルを勝手にリファクタリングしようとしてくる。結局、「聞かれてもいないことは触るな」というリストを記したCLAUDE.mdを作らざるを得なくなったよ。モデルというより僕らの使い方の問題かもしれないけど、本当にそう。

これが僕の現状の問題の可視化図：https://excalidraw.com/#json=y1fSSx2z8-0nFs7CDnqhp,d9Di8JdGUCDE4S3OkEFaDQ ソフトウェア工学における「認知のボトルネック」は、単なるコードだけでなく、アーティファクト同士の間にこそ潜んでいると思っている。成果物→要件→仕様→受け入れ基準→実行可能な証明→レビュー。僕は、これらの移行に伴う退屈な作業を自動化しつつ、人間の力で各ステップごとに「意図が守られているか」を検証することに集中できるツールを実験的に作っているよ。

LLMは人間を模倣するって聞いたことがある。なら「怠惰、短気、傲慢」というプログラマーの美徳をAGENT.mdに追記して、強化していこうじゃないか。

残念なことに、彼がリンクしていたウォートン・スクールの論文の大部分はAIが生成したもので、査読もまだのようだね。ほとんどの研究者がAIを執筆支援に使っているのは理解できるけど、論文のテーマが「認知の降伏」なのに、その内容を真面目に読むのはちょっと苦しいな。

記事の後半はどこへいったの？なんて唐突な終わり方なんだ……。