8月2日、ソフトウェアエンジニアのAnkur Sethi氏がブログで一見時代に逆行するような提案を行った。「AIでコードを書く際、コピペをやめてAIが生成したコードを手動でエディタに打ち込むべきだ」というものだ。同氏はAIに対して「チャットパネル内でのコード表示のみを許可し、ファイルを直接編集してはならない」という厳しいルールを課した。この短い記事は当日、Hacker Newsで363ポイント、300件以上のコメントを集め、同日第2位の注目投稿となった。
図：議論の現場。タイトル下には熱い議論が交わされるコメント欄が広がる。出典：news.ycombinator.com
コメント欄は即座に賛否両論の二つの陣営に分かれた。「これはAIをやめられない人々が発明した新しい祈りの儀式だ」「体を鍛える一番の方法は、車の後ろを歩いてついていくことだと言うようなもの」「あまりにも愚かな提案だ」といった厳しい批判が上がる一方で、強い共感を示す声も多く寄せられた。なかでも頻繁に引用されたコメントがある。「かつては、マネジメント職に転向したプログラマーの腕が鈍ると言われていた。今や、私たちは全員がマネージャーになってしまったのだ。」
「理解の借金」——認知負債（Cognitive Debt）の罠
なぜ彼はこのようなアプローチをとるのか。Sethi氏には10年以上のプログラミング経験があり、日頃からAIアシスタントを活用している。AIに任せれば、数分で機能が完成する。しかし、同氏は強い違和感を覚えるようになった。コードはリポジトリに入るものの、理解が脳に入ってこないのだ。機能はリリースされても、それがどのように動作しているかを自分自身で説明できない。
同氏はこれを「認知負債（Cognitive Debt）」、すなわち返済されていない理解の借金と呼ぶ。後からそのコードを修正する必要が生じたとき、再びAIに「この部分は一体何をしているのか」と尋ねなければならない。まるで試験前に友人の宿題を丸写しし、後から見返しても一文字も理解できない学生のようだ。
同氏も一般的なアプローチを試さなかったわけではない。現在の開発者における標準的な動作は、AIロボットがコードを提案し、人間がそれを1行ずつレビューするというものだ。しかし、防衛的なコードが何百行も並び、コメントも不十分で、微細なバグが潜んでいるコードを読み進めるのは苦痛でしかない。同氏はブログで「会社での業務なら我慢してこなすが、個人プロジェクトでは絶対に譲れない。個人プロジェクトの醍醐味はプロセスそのものと、自らの手で書き上げたコードにある」と語る。
この問題意識には科学的な裏付けもある。MITの研究チームが54名の大学生を対象に文章作成実験を行った。ChatGPTを使うグループ、検索エンジンを使うグループ、自力で書くグループの3群に分けたところ、脳波測定の結果、AIを使用したグループの脳内神経結合が最も弱かった。執筆直後に自分が書いた内容の要約を求めた際も、AIグループの成績が最も低く、「自分がこの文章を書いた」という感覚すら薄かったという。ツールの代行が増えるほど、脳の関与は低下する。研究チームは「注意すべき警鐘である」と提示している。
図：MIT研究（Kosmynaら）の脳波データ——外部ツールの介入が増えるほど、脳の神経結合は低下する。出典：brainonllm.com
そこでSethi氏がとった対策が、AIに境界線を設けることだった。同氏はプロジェクトの指示ファイルに次のように記している。「このプロジェクトに入るすべての行を理解したい。明示的に指示しない限り、ファイルの作成、編集、移動、削除を行ってはならない。すべての変更提案はチャット枠内に表示し、入力は私自身が行う。依存関係のインストールやコマンド実行も私が行う。」AIをゴーストライターではなく、アドバイザーとして位置づける方法だ。
手打ち（写教）で磨かれるものとは何か
その手法は一見すると非効率に見える。AIがチャット画面に生成したコードを、彼が1行ずつエディタに打ち込み、理解できない部分に直面したら立ち止まってドキュメントを調べるか、AIに説明を求める。生産性は「10倍速」から「2倍速」に低下したというが、その見返りとして、すべてのコードが自分の手と目を通ることになる。
この背景には、古くからのプログラミング学習の原則がある。80年代や90年代にプログラミングを学び始めた世代には馴染み深い光景だ。書籍や雑誌に掲載されたサンプルコードは、コピペが許されず、自分で1行ずつ打ち込んで実行し、改造しながら覚えたものだ。手動での入力は、自然と人を立ち止まらせる。キーを叩く手に合わせて目がコードを追い、脳内で「この行は何をしているのか」という検証が強制的に行われる。
キーボードを叩く筋肉記憶（マッスルメモリー）は、コードの構造を指先に刻み込む。次回似たような機能を実装する際、脳よりも先に手が動き出す。
さらに、手打ちのプロセス自体がコードレビューの役割を果たす。Sethi氏は、手と脳を同時に動かすことで、AIのハルシネーションや不適切な設計に気づきやすくなると述べる。一度手打ちを終えれば、頭の中に「コードの地図」が形成され、どの機能がどこにあり、どこを改修すべきかが明確になる。次にAIへプロンプトを出す際も、より的確な指示が可能になる。コメント欄には、作家ハンター・S・トンプソンが若き日にヘミングウェイの小説を全文タイプライターで手打ちし、名文の文体とリズムを体に染み込ませたエピソードを引き合いに出す者もいた。コードの手打ちもこれと本質的に同じだ。
反対派の主張：記憶の訓練か、直観の育成か
最も激しい反論を寄せたのはユーザーf311a氏だ。コードの手打ちは微積分のお手本を丸写しするようなものであり、鍛えられるのは「記憶」であって「直観」ではないと主張する。写経する者は各ステップの書き方は分かっても、なぜその設計に至ったのか、他にどのような解法が存在するのかという思考のプロセスを学べない。同氏の提案は真逆だ。「まず自分でコードを書き、その後にAIに最適化させる」べきだという。
この見解には多くの支持が集まった。「その論理なら、コンパイラが生成したアセンブリ言語も手打ちすべきだ」という皮肉や、「開発のボトルネックがタイピング速度であることは稀であり、低価値な作業に時間を浪費している」という指摘もあった。また、職場同僚から「作業が遅い」とみなされるリスクを懸念する声もある。一方で賛成派は、「構文的には正しいが意味的に空洞な出力」を受動的に消費するだけでは学習プロセスが破壊されるという認知研究を引用し、見ていることと理解していることは別物だと反論した。
| 手打ち（写教）賛成派 | 手打ち（写教）反対派 |
|---|---|
| 宿題の丸写し＝理解不能、写教＝真の理解 | 解答の丸写しは記憶の訓練であり直観は育たない |
| スローダウンすることでAIのハルシネーションを見抜ける | ボトルネックはタイピングではない、時間の無駄 |
| 筋肉記憶とコードマップにより改修が容易になる | 自力で書いてからAIに最適化させる方が効率的 |
| 伝統的ルール：プログラミングは自分の手で打って学ぶ | ツールは人間を解放し、より重要な仕事に向かわせるべき |
両派の対立は、本質的に同じ問いの裏表である。「AIに作業を委ねた結果、あなたの能力は伸びているのか、それとも錆びついているのか？」賛成派は能力の低下を恐れ、反対派は「手打ち」という防錆手段の効率の悪さを批判する。人間が設計を担い、AIが実行を補佐する形でも、能力の低下を防ぐことは可能だという立場だ。
コードを書かないすべての人にも及ぶ共通の課題
この議論は一見、エンジニアコミュニティ内部の話題に見える。しかし実際には、AIを活用して業務を行うすべての知識労働者が同じ分岐点に立っている。AIに年次報告書を書かせたとき、あなたは自分自身で文章を書く力を保てているだろうか？AIにスライド作成やデータ集計を任せたとき、分析や表現の能力はどれほど残るだろうか？「AIに依存した結果、自身の成長が止まる」という課題は、技術の波がすべての人々にもたらす問いであり、エンジニアはその最初の当事者に過ぎない。
プログラミングを行わない人々も、この議論から3つの実践的なアプローチを学ぶことができる。第一に、AIに下書きを作成させ、それを自分自身の言葉でリライトすること。修正のプロセスこそが理解のプロセスとなる。第二に、AIには骨組み（アウトライン）を作らせ、詳細な内容は自分自身で埋めること。第三に、Hacker Newsのコメントで絶賛された方法を採用することだ。作業完了後、AIに自らが作成した成果物に関するテストを出題させ、答えられなかった部分を「未返済の認知負債」として把握することである。
手打ちが最適な解決策であるかどうかについて、300件以上のコメントの中で明確な合意には至らなかった。Sethi氏自身も、この方法が「お笑いぐさに思えるほど非効率」であることを認めている。しかし、この議論は持ち帰るべき重要な問いを投げかけている。**「ツールによって10倍のスピードを手に入れたとき、あなたは何を犠牲にして理解を買い戻すのか？」**この問いにAIが代わりに答えてくれることはない。技術が加速する時代において、素早く走ることも重要だが、自らの足で歩む感覚を忘れてはならない。
参考リンク：
- Ankur Sethi: Prevent cognitive debt by manually retyping LLM-generated code
- HN 議論 (item?id=49153374)
