Lobstersにおいて、vibecoding タグが付けられたひとつの投稿が 114 個の賛成票と 71 件のコメントを集めて話題となった。タイトルはシンプルに「On AI」。リンク先は jcs.org（現在は接続不可）だが、投稿のコメント欄自体が技術コミュニティの議論の焦点となった。
コメント欄の最上位で、ユーザー tmcb は次のような比喩を投稿した：
「シジフォスが岩を押し上げている横で、クレーンを使って雑な精度で岩を頂上に吊り上げている奴らがいて、時々観客に岩が当たったりしているのを周りが見物して楽しんでいるようなものだ。シジフォスが怒り狂うのも無理はない」
この比喩が 93 個の賛成票を獲得した理由は、多くのエンジニアが密かに感じている不安を突いていたからだ。AIプログラミングツールが「便利すぎる」がゆえに、自分は本当に何かを「学べている」のか疑わしくなってくるのだ。
本記事では、コード作成をAIに委ねたとき、かつて日常の中にあった「ついでに学ぶ」プロセスがどこへ消えてしまうのかを考察する。
画像：現代の開発環境において、AIコード生成は標準的なインフラとなった。しかし生産性向上の裏で、学習への影響が軽視されつつある。
魔法によって消し去られた「学習」のステップ
Lobsters ユーザーの duck_tape は、この議論の本質を突くコメントを残し、38 個の賛成票を集めた：
「私たちがまだ向き合えていない現実がある。私たちの学びの多くは、日常業務の『ついでに起こっていた』ということだ。ランダムな機能を実装しているときや、新しいビルドターゲットのためにCI設定を調整しているとき——嫌でも学ばざるを得なかった。だが今や、そうしたプロセスを魔法のように消し去ることができる。頭の中にあるアイデアを直接『生成』できるのだ。しかし、私たちはもはや『ついでに学ぶ』ことができない。 LLMがバグと格闘している間、集中力を維持するのは非常に難しい」
「ついでに学ぶ（incidental learning / 付随的学習）」は、教育学の難解な専門用語ではない。何か別の目的を達成する過程で偶発的に別の知識を習得するという、人間にとって最も自然な学習形態だ。プログラミングという営みは、長年このメカニズムに強く依存してきた。
例えば、新人エンジニアが実際のバグ修正タスクに取り組むとする。彼の目的は単にバグを治すことだが、その過程でコードベースの構造を理解させられ、デバッガの使い方を覚え、なぜ特定の条件下でしか問題が発生しないのかを悟り、関連するAPIの仕様を記憶する。彼はこれらを「意図的に勉強」したわけではない。目的はバグ修正であり、学びは副産物として「ついでに」発生したのだ。
GitHub Copilot は 2022 年に正式リリースされ、2025 年には 2000 万人以上のユーザーを抱えるに至った。Microsoft のデータによれば、ユーザーが記述するコードの 46% が AI によって生成されている（Java プロジェクトでは最大 61% に達する）。この割合は今も上昇し続けている。
AIは、この学習ループを断ち切ってしまう。その仕組みは、「実践を通じて学ぶ」ループを的確に回避するように設計されている。プロンプトを入力すれば、コードが出力されるからだ。
「学ぶ機会」の喪失が積み重なった結果こそが、魔法のように消し去られた学習プロセスなのだ。
画像：AIコード補全は、開発者の役割を「創作者」から「査読者」へとシフトさせる。検証は記述より早いが、理解の深さは浅くなる。
なぜこれが「Stack Overflow 2.0」にとどまらないのか
よくある反論として次のようなものがある。「かつて Stack Overflow が登場した際も、エンジニアがドキュメントを読まなくなると言われた。IDE の自動補全が登場した際も、API を覚えなくなると言われた。しかし業界は崩壊しなかったではないか」と。
だが、この比喩は完全には当てはまらない。ユーザー bendmorris はその重要な違いを指摘する：
「確かに Stack Overflow をコピペして自分が何をやっているかも理解せずにやり過ごしてきたプログラマーは存在した。ゼロ金利時代の雇用バブル期ならそれで通用したかもしれないし、今はLLMを使えば彼らの平均アウトプットの質は上がるだろう。だが良い結果になるとは思えない。人間として彼らが付加している価値は極めて少ないからだ」
Stack Overflow や IDE の自動補全は、すでに存在する知識構造の上で効率を高めるツールだった. 検索結果を理解し、どのコードブロックが適合するかを判断する必要があったし、自動補全は呼び出すべき関数名を既に知っているときにのみ機能した。それらは実行段階を加速させたが、理解のプロセスをスキップさせたわけではない。
一方、AIによるコード生成は「理解」そのものをスキップする。提示された出力を眺めるだけで、そのロジックを自動的に習得できるわけではない——特にそれが今まで見たこともない30行の抽象化パターンである場合はなおさらだ。
認知心理学には、「流暢性の錯覚（fluency illusion）」と「望ましい困難（desirable difficulties）」という概念がある。カリフォルニア大学ロサンゼルス校（UCLA）の認知心理学者エリザベス＆ロバート・ビョーク夫妻は1990年代の実証研究で、学習が「楽に」感じられる方法ほど、長期記憶への定着率が最も低いことを証明した。逆に、思い出すのに苦労したり自力で課題を解決したりするような「摩擦のある学習」こそが、長期的なスキル定着をもたらす。
AIプログラミングツールが提供するのは、極限まで高められた「流暢さ」と、最小化された「負担」である。それはプロダクトデザイン上の優れた選択だが、学習効果は引き換えに削ぎ落とされている。
2025 年に行われた無作為化対照実験はこの仮説を直接検証した。研究チームは学習者を2グループに分け、一方には ChatGPT を使わせ、もう一方には従来の方法で課題を行わせた。結果、AI補助を受けたグループは目前のタスクの成績が良かったものの、その後の独立したテストでは対照組よりも明らかに低いスコアとなった。 これは「認知のオフローディング（cognitive offloading）」理論と一致する——答えが容易に手に入る環境では、脳は情報を記憶しない選択をするのだ。
「学ぶ意欲はあるが、単なる査読者にはなりたくない」
Lobsters コミュニティで 29 票を集めた zetashift のコメントは、コミュニティ全体に漂う倦怠感を端的に表現している：
「リポジトリの中に
CLAUDE.mdやAGENTS.mdといったファイルを見かけると、条件反射でタブを閉じるようになってしまった。……LLMでコーディングした後は、自分が作ったものに対して何の愛着も湧かない。 その出力が自分のものだとは思えず、理解しようという意欲も失われてしまう」
これは特別な事例ではない。ユーザー gered も、vibe coding を試した後の感覚を「どこか汚れたような気分（dirty）」と表現した。また、ユーザー lake は自身の体験を次のように語った：
「オープンソースプロジェクトに1年半かけて取り組んできた。だがAIを使った他人が、私が目指していた場所にわずか数ヶ月で到達するのを目にした。ツールが存在すること自体は喜ばしいが、もし自分が始める前に存在していたら、私はそのプロジェクトを立ち上げなかったかもしれない。自分に言い聞かせている。『手書きのコードを評価してくれる人はいる』『オープンソースは競争ではない』と。しかし、他人がアクセルを踏んで自分を追い抜いていくのを見るのは、やはり心が折れるものだ」
これらの感情の裏には、軽視されがちな構造的問題が存在する。10年、20年の経験を持つシニアエンジニアが AI を使う場合、彼らには出力の質を判断し、AI の奇妙なエラーを見抜き、生成された 50 行の冗長なコードを 10 行の明快なロジックにリファクタリングする知識の土台がある。しかし、初心者にはその判断力がない。
bendmorris の要約は辛辣だ：
「Andreas Kling のような人物なら容易に LLM へ移行できる。積み上げたスキルによって品質を担保し正しい問題を解決できるからであり、その能力はすぐには衰退しない。だが最初から LLM を使う次の世代のプログラマーは、どうやってそのレベルに到達するのか？ スキルを育む基礎的な作業こそが、最も自動化されやすい作業なのだ。 業界全体が自らの足を引っ張っている」
悪者は AI ではなく、「理解を必要としない」ワークフロー
ここで注意深く区別する必要がある。筆者は「AI は悪である」と主張したいわけではない——そのような立場は無意味であり事実にも反する。AIプログラミング助手は生産性を劇的に向上させ、かつて10倍の人員を必要とした開発を少人数チームで可能にする。非エンジニアが自然言語で簡易アプリを構築できるようにもなった。それらの価値は本物だ。
問題は、ツールの設計が学習回路を回避しているとき、誰が『学びの継続』を保証するのかという点にある。
現在のほぼすべての AI コーディングツールの対話モデルは「要求 → コード生成 → 採択」である。ツールのゴールは「タスクの完了」であり、「ユーザーの理解促進」ではない。
論文『Agents That Teach: Towards Designing Incidental Learning Back into AI-Assisted Software Development』（arXiv:2607.06101）はこの問題を体系的に分析し、**「知識の負債（Knowledge Debt）」**という概念を提示した：
AIエージェントが開発者の十分に理解していないコード変更を実行したとき、その理解のギャップは時間と共に蓄積していく。今日AIが理解できないバグを直し、明日理解できない最適化を生成する。1年後、システムは問題なく稼働しているが、あなた自身はもはやそれを保守できない——内部で何が起きているのか分からないからだ。
これは技術的負債（Technical Debt）よりも察知が難しい。技術的負債はコード品質の指標や静的解析に現れる。だが知識の負債には指標がない——それは開発者の頭の中に潜み、一人で問題解決を迫られた瞬間になって初めて露呈するのだ。
思考を委ねる代償
ユーザー pyj の問いかけは極めて現実的だ：
「個人的な悩みは、AIを使うようになってから記憶に定着する量が著しく減ったことだ。タスクは完了するが、学んだことや覚えていることが以前より遥かに少ない。AIツールを活用しつつ、学習効果を維持するための良い戦略はあるだろうか？」
この問いに対する明確な答えはまだ見つかっていない。経験豊富な一部のエンジニアは、「まず Claude にプロトタイプを作らせ、それを自分でより美しいアーキテクチャにリファクタリングする」といった運用を共有している。しかしそれには、「美しいアーキテクチャとは何か」を既に知っている必要がある。
Lobsters での議論は最終的に2つの方向性に分かれた。一方は「手動でのコーディングは、木工やピアノ演奏のような『職人芸』になりつつある」と主張する——電動工具を使うか手鉋（カンナ）を使うかは個人の選択であり、正解・不正解はないという見方だ。もう一方は、業界全体のインセンティブが AI による速度向上へと傾く中、手動コーディングを選択するコストは高まり続け、極めて裕福な者か強いこだわりを持つ者しか負担できなくなるという懸念だ。
いずれの主張も一理あるが、核心的な問いを回避している：「ついでに学ぶ」ルートが遮断されたとき、新しい世代のプログラマーは、前世代が「ついでに」到達したレベルへ至るために、どれほど遠回りをしなければならないのだろうか？
議論の中で答えを出した者はいなかった。しかし、この問いが提示されたこと自体が、大半の AI プロダクトの PR 宣伝文句よりも遥かに価値のあることだ。
参考リンク：
- Lobsters: On AI (114△, 71 comments) (item?id=zljfgp/on_ai)
- Joshua Stein: On AI (jcs.org)
- Hacker News: On AI discussion
- Bjork & Bjork (2011): Desirable Difficulties in Theory and Practice
- Anthropic: ChatGPT as a Cognitive Crutch
- arXiv 2607.06101: Agents That Teach
- Bjork (1994): Memory and Metamemory Considerations in the Training of Human Beings
- GitHub Research: Quantifying GitHub Copilot’s Impact on Developer Productivity and Happiness
