この記事は、認知的負債（記事ではこれを理解の負債と呼ぶ）を、システムの中に存在するコードの量と、そのうちいずれかの人間が本当に理解している量との間で広がっていくギャップとして定義する。記事の中心的な対比は技術的負債との対比である。技術的負債は増大する摩擦を通じて自らの存在を知らせるが、理解の負債は誤った自信を生む。清算の時が来るまで、コードベースはきれいに見え、テストはグリーンのままだからである。
記事が示すメカニズムは速度の非対称性である。同僚のプルリクエストを人間がレビューすることは常にボトルネックであったが、それは生産的なボトルネックであった。レビューは理解を強い、隠れた前提を浮かび上がらせ、システムの保守に責任を持つ人々の間に知識を行き渡らせた。AI が生成するコードはその量によってこのループを壊し、しかもその出力は、歴史的にマージへの自信を引き起こしてきた表面的なシグナルをまさに備えている。Osmani はこの逆転を鋭く言い表す。コードを生み出すのが高価だった頃、シニアエンジニアはジュニアエンジニアが書くよりも速くレビューできた。AI はそれをひっくり返し、今やジュニアエンジニアはシニアエンジニアが批判的に監査できるよりも速くコードを生成できるため、品質ゲートだったものがスループットの問題に変わってしまった。
記事の大部分は、明白な対策がなぜこのギャップを埋めないのかの説明に費やされている。テストは必要だが十分ではない。仕様は魅力的だが不完全である。そして組織が既に運用している計測システムは、この不足をまったく捉えられない。記事の結論は、コードの生成を安くしても理解を省略してよいことにはならず、理解のための作業こそが仕事なのだというものである。
要点
- 記事は理解の負債を、システムの中に存在するコードの量と、そのうち人間が本当に理解している量との間で広がっていくギャップとして定義し、それが技術的負債よりも油断ならないと論じる。技術的負債はたいてい場所の分かっている意識的なトレードオフであるのに対し、理解の負債は目に見えないまま蓄積するからである。
- 記事が述べるメカニズムは速度の非対称性である。AI は人間が評価できるよりもはるかに速くコードを生成し、かつてレビューを意味あるものに保っていた律速要因、すなわち書くことがレビューすることよりも遅いという事実が取り除かれてしまった。
- Osmani は、表面的な正しさはシステム全体としての正しさではないと論じる。構文的にきれいで整形も整った AI の出力はマージへの自信を引き起こす一方で、その下では理解が空洞化していく。
- テストについての記事の主張は、観測可能なすべての振る舞いをカバーするテストスイートは、それが検証するコードよりも複雑になることが多く、また、規定しようと思いもしなかった振る舞いに対してテストを書くことはできない、というものである。したがってテストは必要だが十分ではない。
- 記事は特定の失敗モードを挙げる。AI が実装の振る舞いを変え、それに合わせて何百ものテストケースを更新したとき、問題はそれらのテストの変更が必要だったのか、そしてレビュアーが考えていないことをカバレッジが捉えているのかになる。記事は、それに答えられるのは理解だけだと述べる。
- 仕様について記事は、仕様を動くコードに翻訳するには、どの仕様も完全には捉えきれない多くの暗黙の判断が伴うこと、同じ仕様を実装した 2 人のエンジニアは観測可能な点で異なるシステムを作ること、そしてプログラムを完全に記述できるほど詳細な仕様は、実行不可能な言語で書かれたプログラムとほぼ同じものであることを論じる。
- 記事は計測のギャップを主張する。ベロシティの指標、DORA 指標、PR の数、カバレッジはいずれも健全に見えうる一方で、理解の不足は目に見えないままである。そのためインセンティブの構造は測っているものに対しては正しく最適化されるが、測っているものはもはや重要なものを捉えていない。
- 記事は、レビューされたコードは理解されたコードであるという組織の前提はもはや成り立たず、誰も気づかないうちに責任が分散されてしまったと論じる。
- Osmani は規制の到来を予測する。AI が生成したコードが医療、金融インフラ、行政サービスで動くようになれば、「AI が書いたもので、私たちは完全にはレビューしなかった」という説明はインシデント後の報告書では通用しなくなる。
- 記事が述べる価値の再配分は、AI による生成量が増えるにつれて、システムを本当に理解しているエンジニアの価値は下がるのではなく上がり、その能力がシステム全体が依存する希少な資源になる、というものである。
背景
この記事は単独で立つのではなく、他のいくつかの説明との関係の中で自らを位置づけている。記事は、新しいライブラリを学ぶ 52 人のソフトウェアエンジニアを対象とした Anthropic のランダム化比較試験を引用する。この試験では、AI の支援を使ったグループは対照群とほぼ同じ時間で作業を終えたが、その後の理解度クイズでは 17 パーセントポイント低いスコア（50% 対 67%）となり、最も大きく低下したのはデバッグであった。記事が強調するのは、受動的な委任（「とにかく動くようにして」）は、能動的で質問主導の使い方よりもはるかに大きくスキルの発達を損なうという研究者らの指摘である。記事はまた、コード生成の委任に AI を使う開発者は理解度テストで 40% を下回る一方、概念的な問いかけに使う開発者は 65% を上回ることを示す研究を報告し、それを、ツールが理解を破壊するのではなく、使い方が破壊するのだとまとめている。Osmani は、7 週目までに何かを壊さずには単純な変更すらできなくなった学生チームの事例を Margaret-Anne Storey によるものとしている。そこでの問題は、コードが乱雑だったことではなく、設計上の判断がなぜ下されたのかを誰も説明できなかったことであった。
記事の締めくくりの議論は技術的なものではなく歴史的なものである。分散したチームにまたがってソフトウェアの品質を管理してきた数十年の経験は、チームメンバーが今やモデルになったからといって消え去るわけではない実践を生み出してきた。記事の説明によれば、AI が変えるのはコスト、速度、そして人間関係の管理にかかるオーバーヘッドであり、変えないのは、システムについての深いコンテキストを持つ誰かが、コードベースが何をしているのか、そしてなぜそうしているのかについての一貫した理解を保つ必要性である。