技術的負債、認知的負債、意図の負債
(martinfowler.com)- LLMがコードを大量生産する環境では、コード自体の問題だけでなく、チームの共有理解やシステム目標の記録まで同時に弱くなり、これを 技術的負債・認知的負債・意図の負債 の3層に分けて扱う必要性が高まっている
- Technical debt は将来の変更可能性を制限し、Cognitive debt はチームがシステム変更を推論する能力を弱め、Intent debt は目標と制約の記録を曖昧にして、人間とAIエージェントの継続的な進化を妨げる
- AIをSystem 3に置くTri-System理論は、外部の人工的推論を無批判に信頼して熟考を飛ばしてしまう cognitive surrender を区別し、戦略的に認知を委任する cognitive offloading とは別物として捉える
- コーディングのコストが下がるほど高価になるのは verification であり、正確性や成功の基準は交通ETA、配車、数百のマイクロサービス運用のように文脈ごとに異なるため、人間の判断と検証体系の設計がさらに重要になる
- エンジニアリングの中心軸は実装量より検証へと移り、今後も人間は有用な抽象化や命名、acceptance criteria や test harness の設計のように、システムの意味を捉え続ける役割を担う
3つの負債とシステム健全性
- LLMが大量のコードを生成する環境では、チームがシステムが何をしているのかという理解を失いやすく、それを Cognitive Debt とみなす見方が広がっている
- 3つのシステム健全性レイヤー は、負債をコード・人・アーティファクトの次元に分ける
- Technical debt はコードに存在し、実装上の意思決定が将来の変更可能性を損なうときに蓄積し、システムをどう変えられるかを制限する
- Cognitive debt は人に存在し、システムに関する共有理解が補われる速度よりも速く弱まるときに蓄積し、チームが変更を推論する能力を制限する
- Intent debt はアーティファクトに存在し、システムを導くべき目標や制約が適切に記録・維持されないときに蓄積し、当初作ろうとしていたものを継続的に反映できるか、また人間とAIエージェントがシステムを効果的に進化させ続けられるかを制限する
- この見方には、各負債を 診断し緩和するセクション まで含まれており、3つの負債が相互作用する点も扱っている
- チームはこれら3つの負債を制御するための 一般的な活動 を並行して行う必要がある
Tri-System理論と認知的降伏
- LLMをKahnemanの二重過程思考モデルに追加する論文 は、AIを System 3 に位置づけ、思考体系を拡張している
- System 1 は直感で素早く意思決定し、System 2 は問題を意図的に考える段階として区別される
- エネルギーを節約するため、人間は基本的に直感に頼る傾向があり、その結果、熟考していれば見つけられた要素を見落とすことがある
- System 3の結果として cognitive surrender が登場し、これは外部で生成された人工的推論を無批判に信頼して System 2 を迂回する状態と定義される
- 論文はこれを cognitive offloading と区別している
- cognitive offloading は、熟考の過程で認知を戦略的に委任する行為として扱われる
- この論文は Tri-System theory of cognition を詳しく展開し、少なくとも実験室環境では、この理論が行動予測にどれほど有効かを複数の実験で検証している
コードアイコンとしての <> 表記
- 最近のいくつかのイラストでは、コードアイコンとして「<>」記号が使われているが、この表記はプログラミング言語の要素を囲む記法としては見慣れない
- 「{ }」のような別の記号ではなく「<>」が使われるのは、HTMLやXMLを連想させるためだと読める
- 「</>」の形まで使う場合はHTMLをさらに直接的に想起させるが、HTMLはプログラマがプログラムを書く言語としては扱われない
コーディングが安くなると高くなるのは検証
- if coding agents make coding free, what becomes the expensive thing は、コーディングエージェントがコーディングコストを下げるほど、高価になる要素は verification だと見る
- 正確性の基準 は文脈ごとに変わり続ける
- ジャカルタの交通におけるETAアルゴリズムとホーチミン市の交通におけるETAアルゴリズムでは、「correct」の意味が異なる可能性がある
- 配車では収益の公平性、顧客待ち時間、車両稼働率を同時に満たさなければならないため、「successful」の定義は1つではなく複数になる
- 数百人のエンジニアが約900のマイクロサービスに継続的にデプロイする環境では、「correct」は単一の定義ではなく数千の定義へと分化し、そのすべてが絶えず変化し文脈依存になる
- こうした判断は エージェントが代替できない作業 とされる
- エージェントは、作業結果に対して 良質で、可能なら自動化された検証 があるときに特にうまく機能する流れが強まっている
- こうした流れは Test Driven Development を促進する
- それでも必要な検証量は多いため、人間がより広いテスト範囲を容易に理解できるよう支援する方法に、さらに多くの努力が必要である
- レガシーのモダナイゼーション については、一部で異論も示されている
- agentic coding がレガシーのモダナイゼーションを最終的に解決するという期待は過大評価されている
- ただし understanding what legacy code is doing という側面では、LLMが大きな助けになるという強い根拠がある
検証中心の組織への再編
- エージェントが実行を担うようになると、人間の仕事は verification system の設計、quality の定義、そしてエージェントが解決できない曖昧なケースへの対処へと移る
- 組織構造もこの変化に合わせて変わる必要がある
- 月曜朝のスタンドアップでの問いは、「何をデプロイしたか」より「何を検証したか」が中心になる
- 出力量の追跡よりも、結果が 正しかったか を追跡するようになる
- 機能を作っていた10人のエンジニアチームは、3人のエンジニアと、acceptance criteria の定義、test harness の設計、outcome monitoring を担う7人に再編される可能性がある
- この再編は、作る行為の地位を下げ、判断する行為の地位を上げるため、不快に感じられる可能性がある
- こうした変化を拒まないエンジニアリング文化のほうが、よりうまく適応できる可能性が高い
ソースコードの未来とLLMフレンドリーな言語
- LLMをプログラマのように扱う流れの中で、ソースコードの未来 自体が問いとして浮上している
- several views of the future of code は、コードの未来をめぐる複数の視点をまとめて扱っている
- 一部では、LLMを念頭に設計したまったく新しい言語 を実験している
- 別の立場では、既存言語、特に TypeScript や Rust のような厳格な型付き言語がLLMにより適していると見る
- この記事は引用が多く独自分析は多くないが、議論全体を俯瞰する 概観資料 として読む価値がある
人間が担う抽象化と命名
- LLMとともにソフトウェアを作る過程でも、人間はコードが何をするのかを語れる 有用な抽象化 を作る役割を引き続き担う
- これはDDDの Ubiquitous Language につながる
- growing a language は、LLMとともに言語を育てていく方法を扱っている
- プログラミングは、コンピュータが理解して実行できるコーディング文法を入力することだけでなく、解決策に形を与える作業 でもある
- 問題を焦点の定まった断片に分け、関連するデータと振る舞いをまとめ、意図を表す名前を選ぶことになる
- 良い名前は複雑さを切り分け、誰もが追える図式へとコードを変え、問題構造と解決構造を鮮明に結びつける
3件のコメント
「意図的負債」という用語は、以前に自分なりに定義していた言葉なのですが、こうしてまた見ると嬉しいですね。人の考えることはみんな似ているものなのだと思います。
ブログ記事: https://brunch.co.kr/@limjk/2
変化に合わせて組織改編を素早く進めるのも、やや保守的な印象で反感を覚えますね。
Hacker Newsのコメント
自分がデプロイするものをすべて深く理解していないと落ち着かないタイプなら、こうした変化はかなり不安に感じられる
今では2か月かかるようなmodernizationプロジェクトでも、ビジネスロジックを全部掘り下げてそのまま複製しようとするより、境界とインターフェースをうまく設計することに集中すれば1週間前後で終えられる
そして記事で言うように、テストハーネスをしっかり作って、可能な限り等価性を検証すればいい
私も最初はかなり葛藤したが、よく考えてみると、日々保守している他のシステムについても内部実装やビジネスロジックをそこまで深く理解していたわけではなかった
数年前に自分で書いてほとんど触っていないコードですら、何か変える必要があれば結局はテストスイートを信じるか、コード構造をたどって特定の挙動を把握していた
人員削減やコストカットの局面でも、そうした知識を多く持つ人が、そうでない人より長く生き残るのを何度も見てきた
自分が何を見落としているのか気になる
LLMに怠惰の美徳がないわけではない
意図に合ったベースプロンプトさえ与えれば、Claudeベースのエージェントにコード変更を最小限に抑えさせたり、重複除去パスを走らせたり、まるで非常にシニアな開発者の本能のような振る舞いをかなりうまく引き出せた
モデルがその知識をまったく学んでいないのではなく、デフォルト設定ではそれが前面に出ていないだけだと思う
コードベース全体をむやみにいじり回し、他人の変更や知識喪失のリスクをまったく気にしない過剰修正スタイルのモデルは、誰でも見たことがあるはずだ
ドキュメント生成と検証の話も、結局は伝統的なロッキング問題に近く、従来の解法がある
エージェントはgitを読んで、何が先に行われたのか、慣例上ほかの変更を待っている状態なのかも十分に把握できる
私もかなりシニアで、この記事に出てくる何人かとは実際に同じチームで働いたこともある
その人たちが私のエンジニアリング基準を疑うことはないと思う
それでも私のLLMワークフローではそういう種類の負債はほとんど見えず、むしろ昔と同じ基準で見ても5年前、10年前よりプロジェクトの品質は良くなったと感じる
魔法のような話ではなく、そうした品質上の優先順位を共有するエージェントをうまく回せばいい
そして私はカンファレンスで注目を集めるより、実際の仕事をより多くこなしている
ただ、従来のソフトウェア品質指標で見ても5年前、10年前より良いという部分は、少し曖昧すぎるように聞こえる
どんな指標を使っているのか、10年前・5年前・今のコードがそれぞれどう比較されるのか、もう少し具体的に知りたい
そうした説明がないと、メッセージがかえってぼやけて核心から外れてしまう感じがする
もっと共有できることがあればかなり興味がある
Practical LLM Codingみたいなタイトルで本を書けそうだ
ここで最も過小評価されているのはintent debtというフレーミングだと思う
認知的負債や技術的負債は少なくともコードに痕跡が見えるが、intent debtは見えない
だから、ローカルにはもっともらしいがグローバルには間違った変更が入ったときに、初めて表面化する
元の制約がどの成果物にも残っていないからだ
最も厄介なのは、エンタープライズシステムでその制約が規制要件だったのに、3年前にひっそり変わっていて、誰もコードを更新していないケースだ
テストは通り続けるので、なおさら見落としやすい
テストスイートだけでは意図を復元できない
Martinの言っていることが完全に間違っているとは思わないが、この理屈は抽象化レイヤーが上がるたびに常に言えてしまう主張にも見える
彼の定義に従えば、AssemblyからPythonに移ることもintent debtとcognitive debtを大量に生むことになる
ビットをどう操作するかを自分で考えず、インタプリタに任せたからだ
私の反論は、彼の言う技術的意図というものは結局、人間の意図を機械語に翻訳しなければならなかったことから生じている、という点だ
問題を深く考えること自体は、コードの中でドメイン主導の抽象化を必ず築かなければできないわけではない
マインドマップを描いたり、ジャーナルを書いたり、壁にポストイットを貼ったりしても深く考えられる
オブジェクト指向の抽象化そのものが魔法ではない
その過程で曖昧さや見落としていた細部、さらにはアプローチ自体を見直す必要まで明らかになることがある
自然言語で書くことも思考の道具にはなりうるが、曖昧さを許さない形式言語に思考を合わせることには本質的に異なる要素がある
数学記号なしに自然言語だけで数学をやると煩雑で誤りが増えるのと似ている
ただし、人間にとって理解しやすい言語でやっているだけだ
意図と実装の間には直接的なマッピングが存在する
マッピングがよく定義されていて決定的だからだ
抽象化の目的は、その下を再びのぞき込まなくても、今やったことが依然として正しいと信じられるようにすることにある
私か、あるいは私が信頼する誰かが一度そのコストを払ったからこそ可能になる
ところがLLMは生成のたびに出力を検証しなければならず、そのたびにその負債を払い直す必要がある
だからこれは抽象化とは言いにくい
本当にうまく書かれた文章だった
私も昨日、個人的なノートに、コードを有機的に継続して進化させていなければ、それを本当に所有しているとは言いがたいと書いた
自動運転車のように、以前は通る道の景色くらいは覚えていたのに、今はただ別の場所へ瞬間移動させられて録画だけ見せられている感じだ
こういうやり方のレビューは効果が薄い
小さなツールならこうしたghosted codeでも構わないかもしれないが、データベースのようなシステムでは本当に不安だ
だから今ではエージェントに書き込み権限をほとんど与えず、2年前のような手動QA中心に戻っている
トークン使用量や結果の面でも、むしろその方が効率的だった
もちろん、あくまで私の経験ではある
残念ながら、彼がリンクしていたWharton論文のかなりの部分はAI生成のように見え、しかもまだpeer reviewもされていない
最近の研究者が執筆にAIの助けを借りるのは知っているが、論文のテーマがよりによってcognitive surrenderなら、その内容を真剣に受け止めるのは難しくなる
not merelyを実に7回も使っていたLLMがそこまで同じ表現を繰り返すだろうかとも思うし、むしろ著者がLLMのように書く癖を身につけたのかもしれないとも感じる
Martinの言うことがまったくの的外れというわけではないが、私はAIが怠惰なコードを作った事例を実際に見たことがあり、そのときの正解はむしろコードが増える方向だった
具体的には、ある論理概念セットのためのデータベーススキーマを定義するPythonモデル群があった
そこに既存の論理セットと非常によく似た新しい概念を追加したところ、Claudeは既存モデル群をそのまま再利用すればよいと判断した
理論上は動いたが、実際の利用側では実行時の型推論のせいであれこれ回避策を講じる必要があった
動いてはいたものの、抽象化レイヤーを完全に見誤った例だった
人間の立場では抽象化を望むが、ときにはむしろ重複の方が適切な場合もある
機械がコードを書いて保守するのであれば、以前の追加的な抽象化レイヤーはもう必須ではないのかもしれない
昔はDuff's deviceを使い、ループを手動でアンロールして重複コードを自分で作っていた
今ではコンパイラが意図を理解して重複したアセンブリを生成してくれるので、私たちはその重複を気にしない
最近、LLMでかなり非自明な計算幾何学コードをいくつか必要としたのだが、以前ならライブラリを探し、コンプライアンス承認を取り、自分のドメインデータ構造をそのライブラリ形式に変換するコストがかかっていただろう
それが自前実装より安いとしても、決して些細ではなかった
今ではLLMが必要な部分だけ書いてくれ、私が保存しているデータ形式をそのまま使わせることができる
大きなライブラリを導入する必要もなく、データ構造変換も不要だ
定石としてはgeometry libraryを使って重複を避けるのが正しいのだろうが、ここでは自己完結した関数ひとつがそのままうまく動く
本当に久しぶりにHacker Newsで読んだ中でも最高の内容だった
とても共感する
Simon Willisonの言うcognitive debtと、「証明して動作を確認したコードだけをデプロイするのが君の仕事だ」という観点から、私はIntent-Driven Development寄りのプロジェクトに取り組むようになった
以前の意図は変更が積み重なるほど常に薄れていくように見えた
これを実際のプロトコルとして整理し、後でHacker Newsに投稿するかもしれない
まだ私の投稿を見ていなければ、一度探してみることを勧める
要約するとこうだ
今の自分の問題の可視化はこの図に近い: https://excalidraw.com/#json=y1fSSx2z8-0nFs7CDnqhp,d9Di8JdGU...
ソフトウェアエンジニアリングの認知ボトルネックはコードの内部というより、成果物同士の間にあると思う
コードはそのひとつにすぎない
outcome → requirements → spec → acceptance criteria → executable proof → review
私はこれらの遷移の間にある退屈な部分を自動化し、各段階で意図が生き残っているかを検証することに人間が集中できるような実験的ツーリングを作っている
ここにもうひとつ加えたいレイヤーはproxies/metricsだ
分析の比重が大きいシステムでは、本当の損失はspec → codeではなくquestion → proxyで生じることが多い
proxyがacceptance criteriaやダッシュボード、evalに埋め込まれると、人はそれを最適化し始め、それが単なる代理指標にすぎなかったことをだんだん忘れてしまう
スマホでパン・ズーム・スクロールしようとすると、キャンバス要素を何度も動かしてしまう