■ 1. 理解を手放さないとは
- AIエージェントによる開発の速度感:
- AIコーディングエージェントに実装を任せると成果物が高速に出来上がる
- 人間の理解を待たずに進めるのが合理的という考え方も一面では真である
- 理解を手放さないという方針:
- 説明できないものは出さない、という姿勢を指す
- 自分が出すpull requestの内容は説明でき、なぜその変更かを掘り下げて聞かれても答えられる状態を保つ
- 理解しないまま出力をリリースまで進めないことをリリースの条件としている
- 説明できるレベルの目安:
- 変更の目的（なぜ必要か）
- 実現方法の骨子（何をどう変えたか）
- 影響範囲と検証方法（何に影響し、何で確認したか）
- 上記三点を自分の言葉で説明できることを目安とする
- コード全行を諳んじる必要も、利用ライブラリの内部まで説明できる必要もない
- その場で答えられなくても、どこを見れば答えられるか分かっていれば「説明できる」に含める
■ 2. 理解を持ち続けるか、手放すか
- 迷いどころとしてのトレードオフ:
- 人間の理解や判断を挟まなければエージェントは最速で成果物を生成し続けられる
- 待たせればすぐ次ができるため「どんどん進めないと」という焦りが生まれる
- 理解を手放して得られるもの:
- 速度である
- 仕様を伝えて生成させ、動けばそのまま次へ進める
- 人間の確認という待ち時間がなくなり、成果物のペースはエージェントの生成速度そのものになる
- 理解を手放して失うもの:
- 検証の能力:
- 理解がなければ成果物を想像できず、違和感に気付けず、品質はAIの出来次第になる
- 変更のしやすさ:
- 理解していないコードは触ることへの恐怖が膨らみ、運用や変更がやりづらくなる
- システムを良くしていくための元手:
- システムを理解しているからこそ改善点に気付き、障害対応を組み立てられ、ビジネス側の提案に応えられる
- 理解を持ち続けて失うもの:
- 速度である
- 理解のために作業が止まり、エージェントを待たせることになる
- 二つの選択の性質の違い:
- 理解のために失う速度はその場限りのコストである
- 理解を手放して失うものは後から複利で効いてくる負債である
- 焦りに流されて理解を落とすより、止まってでも理解を確保する方が重要だと考えている
■ 3. 理解は0か1かではない
- 理解の粒度:
- 理解には粒度や抽象度があり、理解している・していないの二択ではない
- 何かを作らせようとしている時点でその目的や仕様は理解しており、完全に理解ゼロということはあり得ない
- すべてのコードを自分で書いていた頃も、利用ライブラリやコンパイラの中身まで理解していたわけではない
- 実際の問いは、理解を手放すか否かではなく、どの粒度・どの抽象度で理解を握るかである
- 理解に働く自己強化型ループ:
- 理解していれば成果物を想像でき、実物との答え合わせができる
- ズレていれば違和感として質問が生まれ、一致していれば想像が確信に変わる
- どちらに転んでも理解は深まり、次に似た成果物を見た時の理解も速くなる
- 理解を手放すと成果物を想像できず答え合わせ自体ができず、判断の根拠がないまま成果物が通る
- 理解しないままの成果物が積み上がるほど次の成果物はさらに想像できなくなる
- 理解すればするほど理解は速くなり、手放すほど取り戻しにくくなる構造がある
- 理解の抽象度をどこに置くかは、その場の速度だけでなくこのループの向きで考える
■ 4. 理解不足は負債として蓄積する
- 理解不足の遅効性:
- 理解の不足はその場では問題にならず、成果物は出てリリースも進められる
- 効いてくるのは後からである
- 理解していないコードが増えるほど次の変更のたびに調査からやり直すことになる
- レビューの判断は遅くなり、障害が起きても対応を組み立てられなくなる
- 理解の不足は時間とともに複利で膨らむ負債である
- 外部の議論との一致:
- Geoffrey Litt氏はUnderstanding is the new bottleneckというエントリで、AIがコードを書く速度が上がるほど人間の理解速度が新しいボトルネックになり、理解不足はcognitive debt（認知的負債）として蓄積すると指摘している
- Margaret-Anne Storey氏はHow Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debtというエントリで、生成AIやエージェントの普及によって懸念が技術的負債から認知的負債へシフトすると論じている
- Storey氏が緩和策として挙げる「AIが生成した変更はリリース前に少なくとも一人の人間が完全に理解していることを必須にする」は、「説明できないものは出さない」というリリース条件と重なる
- Storey氏の記事で引かれるPeter Naurの、プログラムとはソースコードそのものではなく開発者の頭の中に生きる理論であるという言葉を借りれば、理解を手放さないとはこの理論を持ち続けることである
■ 5. 理解不足は恐怖を生む
- 未知への恐怖という感覚:
- 人間は知らないもの、分からないものに対峙すると必要以上に恐怖を抱き、扱うリスクを大きく見積もってしまう
- これは経験からくる感覚だが、心理学やリスク認知、行動経済学の研究にも似た主張がある
- ソフトウェア開発への当てはめ:
- 理解しないまま進むというのは、恐怖を抱く領域を自ら増やしていくことである
- システムが分からないものになるほど触ることへの恐怖が膨らみ、運用や変更がやりづらくなる
- テストのないレガシーコードに変更を恐れるようになるのと同じことが、理解していないコードでも起こる
- 変更をためらうようになったら、それは理解が失われつつあるシグナルかもしれない
■ 6. 理解はどうやって作るか
- 事前に想像しておくこと:
- 成果物を見る前に、生成されるコードの姿や挙動、影響範囲を自分なりに想像しておくことがポイントである
- 事前の想像があるからこそ、想定と違うコードや想定外の変更に違和感として気付ける
- 違和感があれば質問や指摘を行う
- セルフレビューでdiffに目を通したり挙動や影響を自ら確認することでこの違和感に気付ける
- 自分の想像が間違っていた場合も、そのズレが質問や確認のトリガーとなり理解が深まる
- こうした質問や指摘を重ねた結果として、リリースの条件を満たすだけの理解が作られていく
- エージェントに聞いて理解を補うこと:
- わからないことをエージェントに聞いて理解を補うのも日常的に行っている
- 説明には必ず出典を出してもらい、自分でも出典にあたって確認する
- 挙動を確かめられるサンプルコードや検証用コマンドを出してもらい、自分の手で動かして確認するのも効果的である
- AIの説明を鵜呑みにせず、一次情報や実際の挙動で裏を取ることではじめて理解と呼べる
- 何を聞くべきかをエージェントに出してもらうこと:
- 「この変更に対して建設的批判の視点で質問を出して」と頼めば、自分では思いつかなかった観点の質問が出てくる
- あとはそれらに答えられるかを確かめていけばよい
■ 7. エージェントに任せると理解は薄れていくのか
- 想定される反論:
- エージェントに任せる範囲が増えるほどコードベースへの理解が薄れ、違和感に気付く力も鈍っていくのではという指摘はもっともである
- それに対する考え:
- 理解を補う手段はAIによってむしろ増えている
- わからないことは聞け、出典や動くコードで裏も取れ、聞くべきことすら出してもらえる
- エージェントは理解を侵食する存在ではなく、聞き方次第で理解の維持装置にもなる
- 任せることと理解の維持は両立できるのではないか
- 前提条件:
- 本エントリの内容は、成果物をある程度想像できるだけの経験があることが前提になっている
- 経験が浅いうちは並列で回すことを考えず、一つのタスクをAIと一緒に進めながら出典にあたって理解を作っていくところから始めるとよい
- 違和感に気付く力は、そうして積み上げた理解によって育っていく
■ 8. どの抽象度で握るかは、チームでも揃える
- 個人だけでは決められない話:
- どの程度の理解でよいかは個人の中だけで決められる話ではなく、チームでの共通認識も必要である
- 個々人が理解の抽象度を上げても、チームが従来の進め方を前提にしているとレビューの期待値や品質の見方で齟齬が起こりうる
- 判断の目安:
- 人がコードを書いていた頃と同等以上の品質を、自分とAIとで出せているかどうかが一つの目安になる
- それが保てているなら理解の抽象度を上げること自体は問題にならないはずである
- その品質を人間の手間をかけずに担保できるよう、検証を仕組みに落としていく模索は続けていく
■ 9. 理解はAI以前から変わらない
- AI以前から続く営み:
- この理解はAI以前と比べて特別に新しいものではない
- 以前からライブラリやフレームワーク、コンパイラなど自分の書いていないコードを、中身ではなくインターフェースや仕様という抽象のレベルで理解して開発してきた
- チームメンバーが書いたコードをレビューしてapproveするのも、自分が書いていないコードを理解して責任を持つという昔からある営みである
- AIによって理解の対象がもう一段抽象側に寄っただけで、理解を持って成果物を出すという営み自体は大きく変わっていない
■ 10. さいごに
- まとめ:
- 理解を手放さないとは、説明できないものは出さない、ということである
- AIがコードを書く速度は上がっていくが、その分だけ人間の理解が律速になる
- 焦りに流されて理解を落とすより、止まってでも理解を確保するという心持ちでいる
- 本エントリの位置づけ:
- 本エントリの内容は2026年7月時点の考えである
- AIの進化や検証の仕組み・制度の成熟によって、どの抽象度で理解を握るのがよいかは変わっていくと考えられる
- 理解に対する考え方そのものも変わっていくと思われ、その時点での考えを改めてまとめたいとしている