- AI支援開発によりコード生成速度が人間の理解速度を上回り、「認知負債（cognitive debt）」 が発生する
- コードが正常に動作しテストに通っていても、開発者自身がコードの構造や理由を理解できていない状態が蓄積される
- レビュアーの検討限界、組織の暗黙知の喪失、新人開発者の学習不足などがこの負債を加速させる
- 組織は**速度中心の指標（DORA、ストーリーポイントなど）**だけを測定し、理解不足を捉えられない
- 生産性と理解の乖離が大きくなるほど、長期的には保守失敗・知識断絶・エンジニアの成長停滞につながるリスクが大きい
理解の遅延（The Comprehension Lag）
- 手動コーディングは生産と吸収の2つの過程を同時に行い、タイピングの摩擦が思考を促進する
- コードを書きながら自然にメンタルモデルと直観が形成される
- AI支援開発はこの過程を分離し、出力速度は急増する一方で理解速度は人間の限界に縛られる
- この出力と理解のギャップこそが認知負債であり、技術的負債と違って速度指標には現れない
- 問題は後になってMTTRの増加、変更失敗率の上昇など信頼性指標として表れる
組織が実際に測定しているもの（What Organizations Actually Measure）
- 組織は可視的な成果物（機能数、コミット、レビュー速度など）だけを測定する
- 過去には成果と理解が結びついていたため、機能をデプロイすれば理解もあると仮定していた
- しかしAI時代には表面的な理解だけでも機能のデプロイが可能であり、この仮定はもはや有効ではない
- 組織指標は理解不足を捉えられないため、評価と報酬の体系が歪められる
レビュアーのジレンマ（The Reviewer’s Dilemma）
- AIによってジュニアがシニアより速くコードを生成することが可能になる
- シニアレビュアーは膨大なコード量を深く検討する時間が足りず、レビューの深さを犠牲にすることになる
- その結果、「レビューされたコード = 理解されたコード」という前提が崩れる
- 組織の圧力は速度を優先するため、レビュー品質より処理量中心の文化が強まる
バーンアウトのパターン（The Burnout Pattern）
- AIツールを使うエンジニアは、高いアウトプットと低い確信が同居する疲労を経験する
- コードは動くが、自分が作ったシステムを完全には理解していないという不安が続く
- 速度中心の評価体系が深い理解のための時間投資を不利にし、認知負債を加速させる
組織記憶の崩壊（When Organizational Memory Fails）
- 組織知識は文書化された明示知と開発者の頭の中にある暗黙知で構成される
- AI開発は**暗黙知の形成過程（直接実装する経験）**を短縮し、知識の蓄積が起こらない
- その結果、システムは動いていても、それを理解できる人材が徐々に消えていく
- 問題が起きたとき、誰もシステムの文脈を説明できない状態になる
認知負債の蓄積（How the Debt Compounds）
- 第一に、古いコードほど危険になる — 書かれた当時から不完全にしか理解されていなかったコードが完全に不透明になる
- 第二に、障害対応時の復旧時間が急増する — 「ブラックボックスが作ったブラックボックス」をデバッグする状況が生まれる
- 第三に、将来のシニアエンジニアの不在 — AI依存で学習曲線が消え、長期的なリーダーシップの空白を招く
ディレクターの視点（The Director’s View）
- 経営陣は生産性向上、日程短縮、人員効率化といったポジティブなシグナルだけを認識する
- **「理解の深さ」や「説明可能性」**を測る指標が存在しないため、認知負債は報告されない
- そのためデータに基づく意思決定は合理的ではあっても不完全であり、実際のリスクは隠される
モデルの限界（Where This Model Breaks）
- すべての作業に認知負債の概念が同じように適用されるわけではない
- 単純な反復作業や迅速な実験には適している可能性がある
- 過去にも理解水準は個人ごとに異なっており、新しい現象というより分布の移動である可能性がある
- 今後、ツールや文書化の改善によって理解のギャップが縮まる可能性もある
測定の問題（The Measurement Problem）
- 組織は測定可能なものだけを最適化する
- 理解が評価体系に反映されない限り、速度中心のインセンティブは維持される
- これは個人や管理者の失敗ではなく、過去の時代の測定システムが現在の現実と一致していないことの結果である
- 最終的にこのギャップは、保守コストの増加、障害対応の遅延、システム脆弱性の露出として表れる可能性がある
- 「システムは測定するものに合わせて最適化される。しかし、今測定しているものはもはや重要なものを捉えていない」という結論で締めくくられる
3件のコメント
最近ちょうど似たようなことを考えていて、昨日、認知負債に関するブログ記事を1本書いたのですが、みんな似たような悩みを抱えているみたいですね。
コード理解はどのように進めるべきでしょうか。内部コードベースをもとにクイズでも出して測定すべきなのでしょうか。
Hacker Newsの意見
ここ数か月の経験は記事の内容にとても共感できる
私が取り組んでいるプロジェクトは着実に成長したが、エンジニアの数はむしろ減った
テストへの依存度を高め、シミュレータベースの開発へ移行した。実システムで検証することはまれで、そのたびに最も複雑な部分を扱うことになる
昨年あたりからは、数か月かけて作業した機能ですら細部をすぐ忘れてしまうと感じていた。まだコーディングエージェントが本格導入される前だったのにそうだった
エージェントが入ってからはPRレビューがずっと暗黙的になり、文脈が頭に残らないので意識的に集中しなければならない。チームメンバーも同じ経験を報告している
今はコードと一緒にエージェントの計画をコミットするなど、いろいろ試しているところだ。そのおかげでプロセスはより体系的で明示的なものに変わってきている
ただ、エンジニアリングマネージャーはこうした認知負荷の増加についてほとんど認識していないようだった
文章の前提である「開発者は6か月前に自分が書いたコードを覚えている」という仮定は誤っている
昔から、コードを書くときに理解するほうが、読むときに理解するより簡単だった。Joel Spolskyも「コードを読むのは書くより難しい」と言っていた
「理解できないコード」の問題はAI以前にもあった
たとえば、MicrosoftのPinballコード削除事例のように、古い外注コードが複雑すぎて誰にも理解できず、最終的に機能を諦めたこともある
Oracle RDBMSコードベースの事例も似ている
「正常に動作しているが見慣れないシステム」という言葉が印象的だった
これは開発者がマネージャーに転じるときに感じる感覚と似ている。コードから離れるほど理解が抽象的で断絶した感じになる
「深く理解しようとするエンジニアが速度指標で遅れを取る」という言葉がいちばん痛かった
市場は品質より速度を重視し、結局は慎重なエンジニアが解雇される構造になっている
今は「LGTM, LLM」の時代に進むべきなのかもしれない
産業はいつも過剰に振れたあとでバランスを見つける。問題は、20倍の生産性を求めながら100%の責任も負えという不可能な期待だ
結局、理解を諦めるか、最大20%程度の生産性向上だけを受け入れるしかない
Richard GabrielのWorse Is Betterという哲学を思い出した
AIコードはしばしば正確さより単純さを選ぶが、**「動きさえすれば勝ち」**という現実的なアプローチが勝利するかもしれない
ひとまず動くシステムができれば、段階的に改善していける
私たちのチームもここ6か月、記事で語られている現象をまったく同じように経験した
AI支援開発が暗黙知の蓄積を断ち切るという中心的な一文は正確だ
ただし、この現象は一時的な過渡期なのかもしれない
長期的には、LLMがコード構造をうまく整理し、人間が必要な瞬間にだけ深く理解できるよう支援するメタレベルの価値を提供する可能性もある
文書化が不足すると、製品サポートチームも大きな打撃を受ける
顧客が製品の動作について尋ねたとき、エンジニアですら自分の書いたコードをよく把握していなければ答えるのが難しい
更新速度が速いと、ほかのチームは追随しにくい
高水準言語が登場したときにも似たことはあったが、結果的には問題なかった
ならば、LLMがコード理解を抽象化しても問題ないのだろうか
違いは、**コンパイラは決定的（deterministic）だがLLMは確率的（probabilistic）**だという点だ