世界を動かす技術を、日本語で。

LLM生成コードを手動で再入力して認知的負債を防ぐ

2026年8月3日原文(ankursethi.com)

概要

  • 個人プロジェクト でコーディングアシスタントを活用しつつも、 理解を重視 した独自の使い方を模索。
  • AI生成コードの丸投げ による認知的負債の増加を懸念。
  • 自分でコードを手入力 することで、コードベースの全体像を把握。
  • 効率よりも 理解と楽しさ を優先したワークフローの構築。
  • 業界全体の 認知的負債 への危機感と、プロフェッショナルとしての責任意識。

コーディングアシスタントとの付き合い方

  • 個人プロジェクト では、AIアシスタントを活用しつつも、全てを任せることに抵抗感。
  • AIによる機能の一括生成 は、満足感やプロジェクトの把握を損なう要因。
  • 退屈な部分の効率化には役立つが、 仕組みを理解したい という根本的な欲求。
  • 問題が退屈でも、 解決策の理解を機械任せにしたくない という姿勢。

AI生成コードのレビュー問題

  • AI生成のPR(プルリクエスト) のレビューは苦痛であり、個人プロジェクトでは絶対にやりたくない作業。
  • 大量の冗長・誤り混じりコード の精査は、雇われ仕事ならやむを得ないが、趣味では避けるべき。
  • 個人開発の 最大の魅力はプロセス自体の楽しさ

独自ワークフローの構築

  • AIにコード生成を依頼し、編集は全て自分で手作業 という非効率だが満足度の高い方法を採用。
  • 個人プロジェクトのエージェントファイルに 「全ての編集は提案だけ、実際の操作は自分で」 という指示を明記。
    • ファイル操作やコマンド実行も提案のみ、実行は必ず手動。
    • 説明不要、必要な場合のみ詳細をリクエスト。

理解を深めるメリット

  • LLM未使用よりは効率的 だが、全自動よりは遅い(体感2倍速程度)。
  • 手入力によるコードの咀嚼 で、全体構造やAPIの理解が深まる。
  • 理解できない箇所は その場で調べたり、AIに質問 したりして補完。
  • 手入力により誤りや設計ミスの早期発見 が可能。
  • コードの 整理・リファクタリング・コメント追加 も随時実施。

コードベースの把握と継続的な成長

  • 全機能の配置や構成を把握 でき、将来の変更やAIへの指示も容易。
  • 十代で学んだ「コピペ禁止」の教え と同じく、手入力による学習効果を実感。
  • 効率より理解重視 の姿勢で、今後もこのワークフローを継続予定。

ソフトウェア業界の認知的負債への懸念

  • 業界全体が認知的負債を抱えつつある 現状への危機感。
  • 近い将来、 インフラの仕組みを誰も説明できない事態 への警鐘。
  • 自分のアウトプットだけは完全に理解する ことがプロとしての責任。
  • 理解なき開発はプロフェッショナルの倫理違反 という信念。

Hackerたちの意見

私がやったのは似たような感じで、$20プランにダウングレードして、質問をするだけで、ほとんどコードを書かせないようにしてるんだ。できるだけ昔みたいにウェブUIを使って、CLIトークンを使わないようにしてるよ。

昨日のアドバイスも良かったし、今日のアドバイスも明日のアドバイスもいいね。これを読んだか、自分で直感的に気づいたかは覚えてないけど(多分、いくつかの厳しい教訓の後で)、プログラミングの習慣はずっと続けてるよ(90年代からコーディング始めた)。急かされると、例えば誰かが肩越しに見てるときに、何かをコピー&ペーストすると、いつも不安な気持ちになるんだ。簡単そうなスニペットでも、記憶と理解の穴ができちゃう。慎重に進めないと、本当に簡単かどうかはわからないし、簡単だと思っても、周りのコードとの相互作用や仮定が驚きをもたらすことがある。手動でコードを書くことで、全体像を考える時間と余裕ができるんだ。

それは楽しそうじゃないね。手動でコーディングしながらサイドプロジェクトに取り組む方がいいよ。もっと学べるし。何かを再入力するのは学習には非効率的だよ。微積分の解答を再入力するようなもので、そこからは学べない。コードがなぜそのように書かれているのかの説明があっても、自分で考えたわけじゃないし、別の解法も知らない。これは記憶のための練習であって、直感を育てるためのものじゃない。まず自分で書いてみてから、LLMにより良い選択肢を聞く方がいいよ。特にホットループの最適化が必要なときには、彼らはかなり得意だから。

微積分の解答を再入力することには同意できないな。証明や導出を書き出すことで、以前は十分に理解していなかった細かい部分に気づかされることが多いんだ。それが生産的な質問を生むことが多いよ。

昔、雑誌からプログラムを再入力してたときは、楽しかったし、たくさん学んだよ。今に適しているかはわからないけど、そのアイデアには確かに価値があると思う。

書くことは強化につながるよ。盲目的に理解せずに書き直しても学べないけど、すでにその分野を知っていると、書くことで理解し消化する余裕ができるんだ。コピー&ペーストや生成されたコードを盲目的に受け入れるよりも、確実に多くのことを学べるよ。楽しむ必要はないけど、より良い結果が得られるんだ。

書き直している人が他に何もしないという暗黙の前提があるね。ほとんどの人にとって、意図や解決策を理解することも含まれているよ。微積分の多くは、解答のブロックを再構築して問題に適用することなんだ。微積分と実解析の教え方には大きなギャップがある。君の論理だと、微積分は非常に価値が低いはずだよ。でも、なぜかそれを基に他のことを学ぶための扉をたくさん開いてくれるんだ。

それからは学べない Except that you do. そうじゃなければ、学校や大学に座ってただ聞いているだけで何もしないことになるけど、そうすると授業を受けるよりもずっと少ないことしか学べないよ。

大学でビジネスの学位を取ってたとき、一人でコーディングを学んでたんだけど、iOS開発の本を買ったんだ。この本は、例を一行ずつタイプすることを求めてたんだよね。最初は「なんでこんなことしなきゃいけないんだ?」って思ったけど、何もわからなかったから、学びたくて続けたんだ。14年後、ソフトウェアエンジニアとして、その本のことを今でも思い出すし、初期の成長の多くがその一行ずつ書くっていう要求に起因してることに気づいた。今でも新しいツールやコマンドを覚えるために、文書の例をそのままエディタにコピペするっていう習慣を続けてるし、誰かが「> 微分積分の解を再入力するようなもんだ — それからは学べない」って言ったときも、ああ、そういう考え方もあるんだなって思った。でも、私にはこの方法が合ってたんだよね!

それからは学べない。私は強く反対だね。この戦略を使って、C++でゲームのリバースエンジニアリングや関数フックを学んだんだけど、めっちゃ学びがあったよ。それに、Imguiを学ぶときもこの戦略を使ったけど、すごく良かった。LLMが出る前も、書籍から学ぶときにこれをやってたよ。

これ、メモしておくね。再入力が言語やアーキテクチャについて何かを学ぶのに役立つって思ってたけど、しばらくすると忘れちゃうことが多かったんだ…最初に試すのは遅いように思えるけど、確実に認知トレーニングには良さそうだね :)

今の時代に言語を学ぼうとしているなら、Cursorスタイルのオートコンプリートを使う方がいいんじゃない?CodexやClaudeに全部書かせても、あんまり得にはならないと思うよ。

Hacker Newsで議論の続きを見る