TL;DR;
- AIをうまく使うための中核的な能力は、出力物の品質を判断して修正する力であり、この能力はAIに依存するほどむしろ弱まる
- Bjorkの「望ましい困難」理論によれば、容易に処理した情報は長期記憶に残りにくい
- Roediger & Karpicke（2006）の研究では、想起練習グループの1週間後の記憶保持率が反復読解グループより約50%高かった
- AIがコードを代わりに書くと、本質的認知負荷（germane load）まで取り除かれ、スキーマ形成の機会そのものが失われる
- 熟練した開発者ほど神経効率性のため、AIの出力を読むだけでは脳にかかる負荷がほとんどない
- AI以前にも成長が止まる経路は存在したが、AIはその経路の摩擦を劇的に取り除く
詳細要約
AIをうまく使うにはコードを理解している必要があるという逆説
- 「これを作って」と言える人は多いが、AIの成果物を見て「この構造は変更に弱い」「このインターフェースは2つの責務を持っている」と具体的に修正できる人ははるかに少ない
- この能力は、数多くの失敗、デバッグ、リファクタリングの経験から形成された直感に近い
- AIの使い方の学習とコードパターンの学習は二者択一ではなく、後者が前者の土台になっている
- 「AIを最もうまく活用できる開発者は、AIがなくてもコードを判断できる開発者だ」
脳は楽だと記憶しない
- Bjorkの「望ましい困難」: 学習過程に適切な難しさと抵抗があると、短期的な成績は遅くなるが、長期的な記憶保持と転移は向上する
- Roediger & Karpicke（2006）: 反復読解 vs 想起練習の実験
- 5分後のテスト: 反復読解グループの成績が高い
- 1週間後の再テスト: 想起練習グループの記憶保持率が約50%高い
- 能動的想起グループでは海馬―前頭前皮質の結合性が強化され、感覚運動ネットワークの活性も増加する
- 受動学習状態の脳では海馬―紡錘状回の結合だけが活性化する — 「情報を見ているだけで処理していない」状態に近い
- 生成効果（Slamecka & Graf, 1978）: 「熱い-冷___」のように自分で完成させたグループは、完成済みの対を読んだグループより記憶保持率が有意に高い
- 流暢性の錯覚: 情報を簡単に処理できる感覚が、よく記憶できるという錯覚につながる
コーディング力は手続き記憶である
- コーディング能力のかなりの部分は手続き記憶であり、自転車に乗るように一度体得すると意識しなくても自動で実行される
- Andersonの適応的思考制御（ACT）モデル: 手続き記憶形成の3段階
- 認知段階: すべてを意識的に一段階ずつ実行し、作業記憶の大半を消費する
- 連合段階: 個別の手続きが統合され、1つの流れとして実行できる
- 自動化段階: 作業記憶をほとんど使わずに自動実行でき、余った余力を設計判断に使える
- 段階の移行は、反復的な直接実行を通してのみ進む
- チャンキング（Chase & Simonのチェス研究）: 熟達者と初心者の差は、作業記憶スロットの数ではなく、1つのチャンクに入れられる情報量にある
- チェスの名手は駒の個別の位置ではなく、「シシリアン・ディフェンスの典型的な中盤配置」のような意味のあるパターンを1つのチャンクとして認識する
- 無作為配置の実験では名手と初心者の差が消えることで証明された
AIはこの過程を妨げる
- AIに実装を任せると、本質的認知負荷（germane load）までAIが代わりに処理し、スキーマ構築の機会そのものが消える
- 手続き記憶の観点では、認知段階でもがく時間が減ることで連合段階への移行が遅れ、自動化段階への到達が難しくなる
- AI出力コードを読むことは、生成効果の実験でいう「完成した単語ペアを読むこと」に当たり、理解した気になっても深く刻み込まれない
- 熟練した開発者ほど神経効率性により、コードをより少ない資源で処理する → AI出力を読む行為は思った以上に脳へ負荷をかけない
- 自分でコードを書くときは予測―フィードバック・ループによってシナプスが修正されるが、完成済みのAIコードを読む行為は予測過程が省略された事後解釈にすぎない
- ジュニアには特に深刻: 認知段階にあるパターンが多い状態でAIがその段階を飛ばさせると、手続き記憶を形成しないまま経験年数だけが積み上がる
脳に負荷をかける方法
- AIに任せる前に、まず自分の設計案を書く: 生成効果を意図的に活用する — AI出力と比較・評価する過程で、脳の意味処理と実行制御の領域が同時に活性化する
- 真剣なコードレビュー: 「なぜこの構造なのか」「6か月後に修正するとしたらどこが問題になるか」を意識的に問うこと — 面倒くささそのものが望ましい困難である
- 自分でコードを書く時間を確保する: 手続き記憶の形成に代替はなく、詰まったときは完全な答えではなく最小限のヒントだけをAIに求める
- 生産と学習の最適戦略は異なる: AIは生産ツールとしては卓越しているが、学習ツールとしては限界がある
- 結局、脳に残ったものがコードレビューの質、設計判断の正確さ、そして逆説的にAI活用能力を決定する
20件のコメント
個人的には、自分の専門分野ではAIがひどく頼りないということを痛感しています。おそらく他分野の専門家も同じだろうと想像しています。もちろん大きな助けにはなります。とはいえ、一日中こまごまとした文書を書かされることにはなりますが、以前の生産性とは決して比べものになりません。
アテンションは多数決で形成されます。
検証エージェントは評価関数さえ通過すれば十分です。
優れた産業用コードの大半は公開されていません。
オープンソースは見せるためのコードです。
この点を常に念頭に置いて使うべきです。
同感です。航空宇宙、医療、精密制御分野などにおける高度化されたドメインの中核データは、徹底して閉じた内部ネットワークにあり、アクセスするには中核的な内部関係者であるか、外部であればかなりの費用とNDAへの署名を経てようやく公開されます。AIが学習するデータの大半はインターネット上に公開されたものであり、Python、JavaScriptベースのWeb/アプリサービスであれば、ある程度のFull Automationは可能です。
高度化されたドメインで使われる3DグラフィックスやCADベースのアルゴリズムは、インターネット上に断片的に散らばっているか、そもそも存在しないため、AIもまたバイブコーディングでは表面的な結果しか作れません。1つのメインエージェントを置き、ドメイン文脈をマイクロマネジメントのレベルで継続的に注入しながら、Planning → Redirection → Reviewのサイクルで、開発者が直接主導するフル自動化ではなく、継続的増幅の方式で開発することが、安全で現実的なアプローチだと思います。
私もまだ自分の専門分野では力不足を感じているので、自分が助けを受ける分野でもその程度のレベルなのだろうと考えて注意しています。その代わり、進歩のスピードがかなり速いだけに、引き続きその程度のクオリティで十分な業務には使ってみようと思っています。
ここにもAIが付けたようなコメントが多く見えるのは、気のせいでしょうか
ディストピアにたどり着いた気分ですね
結局のところ、人間は楽な選択をするようになります。その結果、ショートフォームコンテンツがよくないと分かっていながらも、今ではほとんどすべての人がショートフォームコンテンツを楽しんでいます。続いて、AIは選択ではなく必須のものになり、実際のところ使うか使わないかで生産性の差が生まれます。これは開発者でも非開発者でも同じです。単に方法とやり方が違うだけです。下の携帯電話の話にたとえて、電話番号を覚えなくてもよくなったとおっしゃっていたように、現代人はナビゲーションがなければ、もはや地図だけを見て運転することができず、いつも通る道ですらあえて覚えようとはしません。
だからといって、運転能力が退化したり、空間認識能力や記憶力が退化したのでしょうか。いいえ、ナビゲーションの発達によって、私たちはナビさえあればどこへでも行けるようになりました。
また、AIを使うことで人間の認知能力が退化するという話もありますが、これは退化ではなく、認知能力が別の形に変わっていくことだと思います。
最近は手書きコーディングの話も出ていますが、自分のレガシーな能力が淘汰されることへの不安を趣味の範囲で解消していくのには同意するものの、これがまるで正解であるかのように、「開発者は自分の基礎能力を高めるために手書きコーディングを必ずやるべきだ！」という方向には進んでほしくありません。
プログラミング言語の発展も、実際には究極的には徐々に人間に親しみやすい自然言語へ近づいていく方向で進化してきました。ですが今は、その究極的な目標へ向かう過渡期なのだと思います。
こうした内容は、過去の作業方式への執着に見える。どうせそうした部分はAIの方がよりうまくやるようになるだろう。今重要なのは、AIを使いながら、うまくいかない部分を改善した経験だ。とはいえ、これもまた一時的なものだと思う。
コーディングに限った話ではないでしょう。望ましい困難は、単なるありきたりなスローガンではなく、さまざまな科学的根拠に基づいています。
計算機があるのに九九を暗記するのは、過去の作業方式への執着に見える。どうせそうした部分は計算機のほうがうまくこなすようになるだろう。今重要なのは、計算機を使いながら、うまくいかない部分を改善した経験だ。とはいえ、これもまた一時的なものだと思う。
いつもこれと似たような論理で反論しているように見えますが……電卓は計算を間違えません。自分の役割はきちんと果たします。
ある日、電卓が壊れて
3 X 3 = 10と表示したのに、誰もそれが間違いだと気づけないのではないかと心配になります……。それが自分の銀行口座を扱うプログラマーのコンピューターで起きたとしたら……。用心するに越したことはないと思います。「コーディング能力のかなりの部分は手続き記憶」という言葉がとても響きますね
数学の問題を解くのも、手順を記憶して同じ結果を出せるように練習する行為ですし、
AIでコーディングするのも構いませんが、同等以上の成果物を繰り返し生み出せるように、脳に負荷をかける必要がある気がします。
短い考えですが、最近私はこんなことを考えるようになりました。昔、アセンブリ言語の専門家たちがC言語の開発者を見て「メモリの大切さが分かっていない」「ハードウェアを分かっていない」などと言っていたそうですが、今見ても同じ文脈で似たような指摘なのではないかと思います。結局、私たちはソフトウェア開発の観点から、従来のプログラミング言語よりもう少し抽象化された言語（AI）で開発するようになるだけなのではないかと思います。そうであれば、その前に使っていた言語については当然ながら専門性が落ちることになります。ただ、少し前まで、今よりもさらにlow-levelな言語を扱って開発する人たちを「怪物」と呼んでいたように、これからはバイブで開発をしつつも、依然として従来の言語の原理を理解している人たちは、一味違う人として見なされるのではないかと思います。
「もしそのスーツがなければ何者でもないのなら、それを持つべきではない。」 - トニー・スターク
意図的にでも、煩わしさを経験する過程を持つ必要がありそうですね
頭を使わずにバイブコーディングしている開発者を見ると腹が立つ。自分の成果物のクオリティがめちゃくちゃなのに、「AIが書きました」と言い訳してみろ。責任は本人が負うべきだ。
AIは、電動ドリルやチェーンソー、掘削機を使っているような感覚です。携帯電話を使うようになってから、自分の電話番号すら覚えられない人も多いです。
……こうしたものを衰退と見ることもできますが、私は効率だと捉えています。開発者やさまざまな職種を経験してきた立場から見ると、AIツールは、開発者だけの世界を離れてより広い視点を持つ機会や助けにもなる道具だと思います。ある部分では衰えるかもしれませんが、その領域は別のもので埋められます。
私もこの意見に同感です。
結局のところ、トレードオフがはっきりしたツールだと見ています。
AIを使うほどコーディング力が落ちるのではと心配にもなりますが、以前はしなかった、あるいはできなかった別の悩み方をしているのは確かです。
少なくともAIに指示するときは、短く二言三言投げるのではなく、できるだけ具体的に自分の考えや論理の展開を解きほぐして伝え、その後、作業を進める前にさらに確認すべきことがあれば必ず質問してから進めるようにするのが役に立つようです。
「デジタル認知症」という言葉が思い浮かぶ文章ですね。