LLMのコードをそのままコピペしてない？「認知負債」を回避するためにあえて手打ちすべき理由

LLM（大規模言語モデル）が生成したコードをそのままコピー＆ペーストしていませんか？もちろん効率的ですが、実は「認知負債」を蓄積させるリスクがあります。コードを理解せずに使うことは、後に大きな技術的負債となって返ってきます。あえてLLMの生成物を参考にしながら自分で書き直す（手打ちする）ことで、コードの構造を脳に定着させ、将来のデバッグや保守のスピードが圧倒的に変わります。真のエンジニアスキルを維持するために、あえて手打ちするプロセスを取り入れてみませんか？

自分も似たようなやり方をしてる。20ドルのプランにダウングレードして、質問はするけどコードを書かせるのはほとんどやめた。可能な限り昔ながらのWeb UIを使って、CLIのトークンを消費しないようにしてるよ。

昨日も今日も、そして明日も変わらない良いアドバイスだね。これが誰かの助言だったか、それとも（苦い経験を経て）自分で直感したものかは覚えてないけど、90年代にコーディングを始めてからずっと守っているプログラミング習慣なんだ。もし誰かに後ろから見られていて焦っていたり、コピペで済ませたりすると、いつも嫌な感じが残る。それは、一見単純なスニペットであっても、記憶と理解に穴を開けてしまうんだよね。ステップ実行して慎重に追わない限り、それが本当に単純だと断言するのは難しいし、「単純」というのは往々にして欺瞞的だから。周囲のコードとの相互作用や前提条件が予期せぬトラブルを招くことはよくある。手でコードを打つことで、全体像を考える時間と余白が持てるようになるんだ。

余談だけど、昔Stack Exchangeを使っていた頃は、見つけた回答を必ず手打ちして、自分がシステムに何を追加しようとしているのかを完全に理解するようにしていたよ。

あんまり楽しそうじゃないな。個人のプロジェクトなら手書きでコードを書いたほうがいいよ。そっちの方がずっと学べる。書き写すのは学習効率が悪すぎる。微積分の解答を書き写すようなものだよね。それじゃ何も身につかない。なぜそのコードがそう書かれているかの説明があったとしても、自分で導き出したわけじゃないし、他の解決策も知らないままになる。それは暗記の練習であって、直感を養う方法じゃない。それよりは、まず自分で書いてみて、そのあとLLMに「もっと良い方法はないか」と聞くのがベスト。LLMはそういうのが得意だし、特にホットループの最適化が必要な時なんかはかなり役立つよ。

一時期、人の宿題を写したり、オンラインの読書感想文をコピーしたり、解答集を使って課題を終わらせていた自分から言わせてもらうと、この戦略は学習の蓄積を妨げ、認知的な借金を積み上げるだけだってことは昔から知られてるよ。

結局、これは認知的な借金にしかならないよ。https://arxiv.org/pdf/2509.21972v1 でも触れられている通り、「学生がこうした出力を自分の推論や批判的思考の代わりとして依存すると、学習プロセスが根本から損なわれる。真の学習とは、意味の積極的な構築、知識の統合、そしてコンテンツに対する内省的な関与を必要とする。これらのプロセスは、文法的に正しくても意味的に中身のない回答を受動的に消費するだけでは起こり得ない。こうした深い認知的作業なしでは、学習者は言語的な流暢さを理解力と勘違いし、教育そのものの目的を損なう危険がある」。個人的には、LLMの利用と認知的な借金を両立できる日が来るとは思わないな。LLM以前からその兆候はあって、管理職やPMになった人が最終的にコーディングスキルを錆びつかせていくのを知っていたはず。まあ、今や私たちはみんな管理職のような立ち位置にいるわけだけど…

LLMが生成したコードを手書きで写すのは絶対に反対。でも、LLMに丸投げせず、自分の手でコードを打つこと自体は大賛成。もちろん、自分の脳で考えたコードである必要があるけどね。それが新しいニューロンやコネクションを作り、認知機能の低下を防ぐことになる。LLMを使わないという制約は、創造性を高めてくれるはずだ。実は、LLMがコードに持ち込む制約の方がよっぽど多い。LLMは学習データの中にある特定の書き方しかしないから、他のアプローチに出会うチャンスを失ってしまうんだ。ふと思いついたけど、10年以上前にRubyを学んでいた頃に出会ったRubyQuiz.com [0] がある。ユーザーから投稿された多数の解決策（zipファイルをダウンロードする必要がある！）を見ると、同じ問題に対して全く異なる解決策があることがわかる。もちろん、今のLLMやrubocopのチェックでは効率的でも標準的でもないとされるものも多いけど、彼らのコードを読んで、それを打ち込んで動かしてみることは、Rubyでどう思考し、問題を解決するかを学ぶ上で非常に重要だった。Goでも「learn go with tests」ガイド [1] を使って同じことをやったよ。

いろんな意見があるね。でも、それが自分に合っているなら素晴らしいことだよ。個人的には、LLMのおかげで認知能力が（良い意味で）爆発的に向上したと感じてる。今は兵士の役割を演じるのではなく、軍を率いる将軍になった気分だ。もちろん、孤独な兵士としての経験は失われるわけだけど、自分にとっては迷う必要もないトレードオフだね。とりあえず、歩き方を忘れないように車を押してスーパーまで行ってくるから、また数時間後に戻るよ。大きなふくらはぎと一緒にね。全部冗談半分で言ってることだから気にしないで。そのまま続けていけばいいと思うし、共有してくれてありがとう。みんなが優しく、良い感じに茶化してくれるといいね。

「バイブコーディング（vibecoding）」に対して愛憎入り混じる感情を抱いている自分も、このアプローチを試してみた。しばらくは上手くいったけど、その「しばらく」は、OOPがこの波に乗ってきた「数ヶ月」ほど長くは続かなかった。ただ、なんとなく波長が合わない時もあって、株主価値にはほとんど貢献しないようなコードであっても、自分で「考えて」かつ「書く」というスタイルを維持できればよかったなと思う。こう思うのは、ソーシャルメディア中毒と同じように、自分の思考の一部が乗っ取られているような感覚があるからかもしれない。時々、深刻な介入が必要なんじゃないかと感じるよ。

「理論上は、理論と実践は同じ。だが、実践においてはそうではない」。昔、これを試したことがある。Haskellがどうも理解できなくて、記憶と再構成を頼りにプログラムを打ち直していたんだ。音楽なら当たり前だけど、コードでやっちゃダメな理由は？…この根拠のない意見の数々は、まるでBMWの良し悪しを議論してるみたいだね。