理解が新たなボトルネックである
(geoffreylitt.com)- エージェントが書いたコードが人の周囲に積み上がり続ける状況で、開発速度を制限する要因はコード生成能力ではなく、システムに追随しながら次の変更を構想できる人間の理解速度へ移りつつある
- コードを理解する目的は、結果を承認または拒否する検証にとどまらず、何度も続くエージェント作業ループの中で次のアイデアを提案し、創作プロセスに参加することにある
- 生のコード差分ではなく、背景知識／変更目標／インタラクティブな図表／叙述的なコード差分をまとめたコード説明ドキュメントを先に読むと、変更の構造と意図をより速く把握できる
- 説明ドキュメント内のクイズや、実行過程を直接操作するマイクロワールドは、エージェントに判断を代行させるのではなく、人がシステムの状態変化と内部動作を体験できるようにする
- AIを人間をループから外す自動化手段としてだけ使うのではなく、理解のためのツールやシミュレーションを作るために活用すれば、人やチームはむしろより深くループに参加できる
コード生成の速度についていけない人間
- エージェントが書いたコードの山が一人の周囲にどんどん高く積み上がるように、生成されるコード量は増える一方で、人がそれを理解する速度は同じ割合では増えない
- すべてのコード差分を1行ずつ読む方法だけでは、エージェントの作業速度についていくのは難しい
- コード理解には、生のコード差分以外にも次のようなさまざまな方法がある
- システムと変更点を教えるコード説明ドキュメント
- 実際に理解しているかを確認するクイズ
- 内部動作を直接操作しながら学ぶマイクロワールド
- チーム全体が同じメンタルモデルを形成する共有空間
理解は検証ではなく参加のためにある
- 人がコードを理解しなければならない理由としてよく挙がる答えは、エージェントの作業を検証するためだというもの
- 仕様に合っているか確認する
- 構造が適切か判断する
- 最終的に承認／拒否を決める
- 発表資料では、これを親指を上げるか下げるかという二分法的な判断として表現している
- 検証だけを人間の役割と見なすと、理解は結果の合否を判断するプロセスへと縮小される
- しかしエージェントは、自分が作った結果を実行・検査し、エラーを見つける自己検証能力も継続的に改善している
- 検証をエージェントがよりうまく行えるようになるほど、人間はどこに残るのかという問題が生じる
- 代案は、理解を通じて参加することである
- エージェントが何をしているのかを把握していてこそ、人は創造的プロセスの能動的な一員であり続けられる
- システムを理解すれば、現在の結果を評価して終わるのではなく、次の段階で何を変えるべきかを考えられる
プロジェクトは1つのループではなく無数のループである
- 実際のプロジェクトは、エージェントに一度指示して結果を受け取る単一のループではない
- 目標設定／実装／確認／修正／拡張へと続く無数の反復ループが互いにつながっている
- 各反復で人が持つシステム理解度が、次のアイデアの質と範囲を決める
- 頭の中に十分な概念と構造があってこそ、次のような問いを流暢に扱える
- 何を追加または削除すべきか
- どの構造を変更すべきか
- 現在の実装からどのような新しい可能性が生まれたか
- 理解が不足していると、エージェントが作ってくれた結果に「だいたい合っていそうだ」と反応することはできても、プロジェクトがどこへ向かうべきかを主導するのは難しい
理解を先送りして積み上がる認知負債
- システムを理解しないままエージェントの結果を受け入れ続けると、短期的には素早く進められる
- しかし技術的負債が後の変更コストを高めるように、理解を省略した作業は**認知負債（cognitive debt）**を残す
- 認知負債が積み上がると、プロジェクトに参加した人が全体の流れを見失う
- コードがなぜ現在の構造になったのかを把握しにくい
- 新しい要件をどこにつなげるべきか判断しにくい
- エージェントが提案した次の変更の妥当性を議論しにくい
- AI時代の問題はコードが生成されないことではなく、生成されたシステムについて人が十分な概念を持てないことである
教育の手法をコード理解に適用する
- 急速に変化するAI作業環境で人間の理解を築く問題は、教育が長く扱ってきた問題に似ている
- 新しい事実を単に伝えるよりも、背景知識／直感／練習／フィードバックを一緒に提供してこそ、実際の理解が形成される
- コード理解にも、教育で発展してきた手法を適用できる
- 詳細な実装の前に背景と直感を提供する
- 内容を読んだあとで思い出して答えさせる
- 抽象的なルールを直接操作できる環境を提供する
- 他の人と同じ概念と語彙を共有させる
変更点を教える /explain-diff
- /explain-diff は、エージェントが行った変更を構造化された説明ドキュメントにするスキルである
- HTML／Markdown／Notionページの形式で出力でき、Notionドキュメントはチームメンバーがコメントし、一緒に議論する協業成果物として使える
- 単なるコード変更一覧ではなく、人が変更点を学べるよう設計された説明資料を生成する
- ゲーム画面の遠近感を変更する事例では、すぐにコードを見せるのではなく、次の順序で進める
- 既存のゲームエンジンのレンダリング方式を先に説明する
- 「2D描画技法で庭を立体的に見せる」という変更目標を提示する
- 等角投影とは何かを説明し、変更の視覚的原理を理解させる
- その後、実際の実装コードへ進む
背景知識から教える
- よい説明は「何が変わったのか」ではなく、**「変わる前には何があったのか」**から始まる
- 既存ゲームエンジンの座標系とレンダリング構造を知らなければ、新しい遠近法のコードだけを読んでも変更の理由を理解しにくい
- 説明ドキュメントは、エージェントと同じ背景を持たない人が対話に参加できるよう、既存システムの構造を先に補う
- これは単なる要約ではなく、人を現在のプロジェクト文脈へ連れ戻すプロセスである
詳細実装より先に直感を作る
- コードに先立って変更の本質を一文で説明すると、詳細実装がどの目標に向かっているのかが分かる
- 庭を立体的に見せる事例では、等角投影の数式から説明するのではなく、平面の絵を3次元のように見せるという視覚的目標を先に伝える
- 背景と目標を理解したうえでコード片を見ると、各計算や変換が全体の結果の中で担う役割を結び付けやすい
- 人を詳細コードの受動的な読者ではなく、変更意図を理解する対等な参加者にすることが目的である
インタラクティブな図表で座標変換を体験する
- 静的な図だけを見せる代わりに、庭の上の岩を直接ドラッグして動かすインタラクティブな図表を使う
- 岩を移動すると、画面上の位置と内部座標が一緒に変わり、等角投影の座標変換を確認できる
- 数式やコードだけを読むよりも、入力と出力の関係を直接操作しながら直感を形成できる
- Notionページ内にインタラクティブなHTMLを埋め込み、コード説明ドキュメント自体を小さな実行環境にできる
- AIは説明文を書くにとどまらず、理解に必要な可視化や操作ツールまで生成できる
生のコード差分を叙述的コード差分に変える
- 一般的なコード差分は、変更されたファイルをファイル名順に並べる
- ファイル間の関係を説明しない
- 変更の目的を教えない
- どの順序で読むべきかを案内しない
- **叙述的コード差分（literate diff）**は、変更点を文章の流れのように再構成する
- 変更の目的を先に示す
- 理解に適した順序でファイルと関数を説明する
- 説明の間に必要なコード片だけを挿入する
- 周辺文脈と実装上の選択の関係も示す
- 生のコード差分が材料をそのまま積み上げたものだとすれば、叙述的コード差分は変更プロセスを1つの物語として編集したものに近い
- 説明を先に読んでから生のコード差分をレビューすれば、各コード片がなぜ存在するのかを理解したうえで読めるため、レビュー速度が上がる
AIが作った説明書を紙で読む
- 完成した説明ドキュメントは、1つのコード説明パケットのように使える
- 生のコード差分も引き続き読むが、必ず説明ドキュメントを先に読む
- 集中が必要なときは、文書を印刷してカフェで紙で読むこともある
- AIとのプログラミングというインタラクティブな活動が、むしろ深く集中できる静的な紙のレポートに変わるという逆説が生まれる
- 核心は、最先端のインターフェースを使うことではなく、人が実際に理解しやすい形へ情報を変換することである
読んだ感覚と実際の理解の違い
- 説明ドキュメントをうまく構成しても、読む行為そのものが理解を保証するわけではない
- 人は文章を目で追っただけで、内容を覚えた、または理解したと錯覚しやすい
- Andy Matuschakの「books don't work」と、Andy Matuschak／Michael Nielsenの Quantum Country からアイデアを得ている
- Quantum Countryは文章の中に間隔反復クイズを埋め込み、読者に内容を自分で想起させる
- 同じ方式をコード説明ドキュメントに適用し、最後に変更点に関する5つの対話型質問を配置する
クイズはAIループの速度調整装置である
- コードを他の人に送る前に、説明ドキュメントのクイズに合格しなければならないというルールを使う
- 他の人が書いたコードをレビューするときも同じ基準を適用する
- クイズは知識を評価するためのおまけ機能ではなく、速度調整装置である
- AIと作業すると、実装／修正／再生成のループが人間の理解より速く進みがちである
- クイズは各ループで機械的に次の問いを投げかける
- 実際に何が変わったのかを説明できるか
- なぜこの構造を使ったのかを理解しているか
- 次の変更に影響する制約を知っているか
- 合格できなければ作業速度を落とし、理解を補う必要があるため、人は創造的な参加者であり続けられる
Seymour PapertのMathlandから得たマイクロワールド
- 2つ目の方法であるマイクロワールドは、教育者Seymour Papertのアイデアから出発している
- Papertは、フランス語を学ぶためにフランスで生活するように、数学を学ぶには数学が自然に機能するMathlandで暮らす必要があると考えた
- 子どもが説明を受動的に聞くのではなく、好奇心に従って環境を探索しながら数学的概念を自然に身につける方法である
- これをコードに適用すると、システムを説明する文書を提供するだけでなく、人がその中に入り、動作の仕組みを直接体験できる環境を作れる
- マイクロワールドは実際の本番システム全体をそのまま露出するのではなく、特定の原理と状態変化を観察しやすく構成した小さな世界である
Prologインタープリタを時間軸で探索する
- Prologインタープリタを開発しているとき、内部で何が起きているのかを直感的に把握するのが難しかった
- エージェントと一緒に実行過程を段階的に探索する専用デバッガを作成した
- このデバッガでは次のことを直接確認できる
- 実行時間を前後に移動する
- 現在のスタックにどの値があるかを調べる
- 各段階でどの規則が評価されているかを確認する
- 特定の規則が正しく適用された瞬間にメモを残す
- 完成した結果だけを見るのではなく、論理言語の実行が時間に沿ってどのように展開されるかを直接たどれる
- エージェントにデバッグを任せれば問題は解決できるかもしれないが、人がデバッガを直接操作してこそ、実行構造に関する理解が生まれる
エージェントが代わりにデバッグすることと、理解ツールを作ることの違い
- 「エージェントが問題を見つけて修正する」と「エージェントが人間が問題を探索するためのツールを作る」は、異なる結果を生む
- 前者は作業結果を素早く得られるが、内部プロセスに対する人間の理解はほとんど増えない可能性がある
- 後者は、人が実行状態を調べ、仮説を立て、結果を確認する探索プロセスを提供する
- コード作成の一部をエージェントに任せつつも、核心となる思考と探索は人が直接行える
- エージェントの役割を、正解の提供者から理解環境の制作者へ拡張するアプローチである
Webサイトの移行をゲームのように行う
- 個人Webサイトをあるフレームワークから別のフレームワークへ移行するとき、Claudeが自動化スクリプトを書いた
- 新しいフレームワークに慣れていなかったため、スクリプトを読んでも**「だいたい合っていそうだ」以上に評価するのは難しかった**
- これを解決するため、Claudeに移行作業を直接実行するビデオゲーム形式のコマンドセンターを作るよう依頼した
- コマンドセンターでは次の過程を視覚的に確認できる
- ボタンを押して移行ステップを1つずつ実行する
- 既存サイトと新サイトを画面の左右に並べて表示する
- 各ステップで新サイトの見た目がどう変わるかを確認する
- ファイルツリーがどの順序で変わるかを観察する
- 全体の変換を一度に実行するのではなく、新しいサイトが段階的に立ち上がっていく過程を直接体験する
- すべてのファイルを手作業で移したときに近い理解を得ながらも、必要な作業と観察環境があらかじめ用意されているため、はるかに速く進められる
コードを理解するためのコードを生成する
- エージェントが書けるコードは、製品機能や自動化スクリプトに限られない
- 人が別のコードを理解できるように、次のような一時的なツールも作れる
- 実行可視化ツール
- ステップ実行デバッガ
- 左右比較画面
- ファイルツリー変化表示器
- インタラクティブな概念説明
- 作業を小さなステップに分けたコマンドセンター
- こうしたツールは、長期的に保守される製品コードでなくても十分な価値がある
- AIでコードを作るコストが下がるにつれ、特定の人と特定の作業のための使い捨ての学習環境も現実的に作れるようになる
チームでは共に理解しなければならない
- 個人がシステムを理解するだけでは、チーム作業には十分ではない
- チームメンバーが同じメンタルモデルを持っていてこそ、短い表現だけでも同じ構造や動作を思い浮かべられる
- 共有された語彙とイメージがあれば、アイデアを即興的にやり取りし、新しい方向を一緒に発展させやすい
- 逆に、各自が別々のエージェントと孤立した状態で作業すると、次の問題が起きる
- 同じ用語を異なる意味で使う
- 技術計画の前提を共有できない
- 成果物は統合できても、理解は統合されない
- チームのAI活用は、各個人の生産性を高める問題だけでなく、チーム全体の共有理解を築く問題でもある
エージェントと人間の作業を同じ共有空間に残す
- NotionではClaudeとCursorエージェントをページ内で実行できる
- エージェントが書いた技術計画は、基本的に共同編集可能なページに作成される
- チームメンバーは、エージェントが作った計画を別のチャネルへコピーせず、同じ場所で直接レビューできる
- 特定の文にコメントを残す
- 実装上の選択について質問する
- 計画を一緒に修正する
- チームの議論とエージェントの結果を1つの文脈に残す
- エージェントが個人ごとのサイロ内で作業するのではなく、人とエージェントが共同文書を中心に思考するようになる
- 共有空間は結果を保存する文書箱ではなく、チームが一緒にメンタルモデルを作る場所である
コンピュータの目的は最初から拡張だった
- コード理解のための説明／クイズ／マイクロワールドの問題は、プログラミングに限られない
- 人は結果を検証するためだけでなく、世界がどのように動くかを理解し、変化に参加するために知識を必要とする
- Alan Kayは約50年前、コンピュータを本より優れた新しい教育メディアとして構想した
- 当時の絵には、子どもたちがタブレットのような装置を見つめる姿が描かれているが、動画を受動的に視聴しているわけではない
- インタラクティブな物理シミュレーションを操作する
- ゲームをプレイしながらコードを直接修正する
- 修正したコードが物理的な動きをどう変えるかを確認する
- コンピュータは静的な情報を伝える機械ではなく、複雑な概念を動かし、変えながら理解させる動的なメディアになり得る
自動化だけでなく、より深い参加へ
- 宇宙飛行士が地球を見ながら「コンピュータの目的は、複雑な概念を理解するための動的シミュレーションを作ることだったのか」と尋ね、背後の宇宙飛行士が「ずっとそうだった」と答えるミームで核心を表現している
- コンピュータとAIの目的を人間の作業を取り除くことだけに置くと、人はシステムの外側へ押し出される可能性がある
- 逆に、AIを説明／シミュレーション／マイクロワールド／共有空間を作るために使えば、人はより多くの概念をより深く理解できる
- AIがシミュレーション制作のコストを下げることで、特定の概念を学ぶためのカスタム環境を必要なときに生成できるようになる
- 目標は人をループから外すことだけではなく、人が以前よりさらに深くループの中に入れるようにすることである
関連記事
- Enough AI copilots! We need AI HUDs - コパイロットを超えて、人間の精神をより直接的に拡張するAIインターフェース
- AI-generated tools can make programming more fun - AIでカスタムデバッガUIを作り、人が直接プログラミングするプロセスを改善した事例
- Code like a surgeon - 付随的な反復作業は委任し、人が核心的な作業に集中する方法
2件のコメント
ボトルネックを完全に取り除くには
人間の認知や記憶の構造は短期記憶と長期記憶に分かれているので、どれだけそうしてAIのコーディング速度を上げようとしても、人が途中途中で確認しながら短期記憶を積み重ねることが、認知的負債に対して最も効率的だと言いたいですね。