「チュートリアル地獄」に代わって現れた「バイブコーディング地獄」

 (blog.boot.dev)
28 ポイント 投稿者 GN⁺ 2025-10-12 | 3件のコメント | WhatsAppで共有
  • 最近のコーディング教育環境では、「チュートリアル地獄」に代わって**「バイブコーディング地獄」**が新たな問題として浮上している
  • チュートリアル地獄が「チュートリアルなしでは何も作れない」状態だとすれば、バイブコーディング地獄は**「AIなしではコーディングできず、AIが生成したコードがどう動くのか理解していない」**状態を意味する
  • AIツールの過度な使用が学習意欲を低下させ、AIリテラシーが低い人ほどAIをより多く使うという逆説的な状況が生じている
  • AIツールは適切に活用すれば学習補助に大いに役立つが、やみくもに「答えだけを得る」使い方は建設的な理解形成の妨げになる
  • 学習過程で自分で考え、自力で解決しようとする努力が核心であり、チュートリアルやAI補助なしに問題解決経験を積む姿勢が重要だ

問題の背景: チュートリアル地獄からバイブコーディング地獄へ

  • 2019年当時、コーディング教育の主要な問題は**「チュートリアル地獄」**だった
    • チュートリアルをなぞることには成功しても、一人では何も作れない
    • 実際のプログラミングよりもプログラミング関連の動画視聴に多くの時間を費やし、核心概念を理解できていない
    • 結果として表面的な知識だけが積み上がり、内部の動作原理を理解していないため、実務では自力でコードを書けない状態
  • Boot.devはこれを解決するため、3つの点に注力した
    • 深いカリキュラム: 伝統的な大学の外でもCSの基礎を学ぶ必要性を強調
    • 実習中心の方式: すべての概念学習と並行して実際にコードを書く
    • 動画よりリッチテキストを強化: 動画は受動的な消費に終わる危険がある
  • 2019年には数百万回再生を記録していた長尺のYouTube講義は、今では5万回再生に届くのも難しい
    • FreeCodeCamp、Traversy Media、Web Dev Simplifiedなどのチャンネルにその傾向が見られる
  • しかし「learn to code」に対するGoogle Trendsのデータは依然として高い関心を維持している
  • Boot.devには毎日約1,300人の新規ユーザーが登録しており、この18か月でチュートリアル地獄への不満は減った一方、新しい形の困難が現れている

バイブコーディング地獄の定義

  • チュートリアル地獄の特徴
    • 「チュートリアルなしでは何も作れない」
    • 「ドキュメントが理解できないから動画が必要だ」
    • 「簡単な作業にも複雑なフレームワークが必要だ」
  • バイブコーディング地獄の特徴
    • 「Cursorの助けなしでは何もできない」
    • 「すごいタワーディフェンスゲームを作りました。リンクはこちらです http://localhost:3000」
    • 「画像のlazy-loadのためにClaudeが6,379行も追加した理由が分かりません」
  • 現在の独学学習者は多くのものを作ってはいるが、ソフトウェアの仕組みに関するメンタルモデルを発達させないままプロジェクトを構築している
  • AIの幻覚(hallucination)と戦い、テスト通過だけに集中するボットと格闘しながら、実際の問題解決よりもAIが生成したコードを盲目的に信頼している

AIコーディングの未来と現実

  • 筆者は短期的にはAIが開発者を完全に置き換えることはないという立場に前向きだ
    • 「AIが仕事を奪うまで6か月」と言われ始めてから3年が経ったが、それでもなお開発者は採用されている
  • GPT-5はリリースされたものの、GPT-4に対して漸進的な改善にとどまり、AGIがまもなく到来するわけではないことを示す証拠だと解釈される
  • 毎日AIツールを使っているが、実際に生産性がどれほど向上しているのか確信が持てない
    • AIがより生産的にしているのか、それともより怠惰にしているのかは不明だ
  • 2025年の研究結果: 開発者たちはAIが生産性を20〜25%高めると想定していたが、実際には19%遅くなった
    • 7兆ドルの投資に見合わない残念な結果だ

AIと学習意欲低下のリスク

  • AI活用文化は学習者の動機づけに否定的に働く可能性がある
  • AIブーム（バブル？）で最も懸念される点は、「なぜ学ぶ必要があるのか。AIが全部知っているじゃないか」という態度を持つ世代が現れることだ
  • AIが実際にはすべてのホワイトカラー職を代替できないなら、株式市場のバブルだけでなく、教育を受けた人材の枯渇にも直面することになる
  • 技術的背景のない投資家は**「AIがすでにコーディングのすべてを代替した」と誤解し、シニア開発者たちは依然としてAIツールを日常業務に統合する有用な方法を見つけられていない**
  • AIリテラシーが低い人ほどAIを多用する傾向があり、懸念される
    • 究極の「Dunning-Kruger（ダニング＝クルーガー）」の罠として機能する。知識が乏しい人ほど、かえって自分はよく分かっていると錯覚する現象だ
    • 学習者は「AIがすでに知っているのだから」と自己研鑽は無意味だと結論づけてしまう

AIは学習に有益か?

  • コーディング学習に対する社会的関心は依然として高い
  • AIが学習に有益である可能性はあるが、2つの構造的問題が存在する

  • 1つ目: おべっか(sycophant)問題

    • AIチャットボットは質問者の意見に過度に同調する傾向がある
    • 「ROAS（広告費用対効果）について」会話してみると、同じデータを前にしても質問の方向次第で正反対の結論を出し、どちらも専門家的な口調で自信満々に答える
    • これは学習者から、検証、批判的思考、誤りを指摘される経験の機会を奪う
      • 専門家に尋ねる理由は、私たちが間違っているときにそれを教えてもらうためだ
      • IRCチャットやStack Overflowはこれをうまくやっていた（おそらくうまくやりすぎるほどに）
      • LLM（大規模言語モデル）チャットボットは、従来の学習者が持つ根本的な誤解を正せない傾向が強い
      • 現在の学生たちはLLMと気楽な会話をしながら、必要なことではなく聞きたいことを聞いてしまう

  • 2つ目の問題: 学習者は実質的な「意見」を求めている

    • AIはあまりにもバランスを取りすぎた立場を提示する
      • 「Xだと考える人もいれば、Yだと考える人もいる」
      • 学習者にとって、どちらに同意すべきか判断するのがより難しくなる
    • 「資本主義者役」や「マルクス主義革命家役」をするようプロンプトしたが、満足のいく結果は得られなかった
    • 学習者は実体験から出た意見や論評を聞きたがっている
      • DHHがTurboからTypeScriptを削除した理由
      • Anders Hejlsbergが語る、TypeScriptがJavaScript開発者のために解決すること
      • 各著者のバイアスや文脈が明確に表れる生の意見を通じて、微妙なメンタルモデルが形成される
    • LLM特有の中立的で慎重な回答は、実際の知識の内面化を妨げる

AIが学習に本当に役立つ場合

  • AIは正しく使えば学習のための驚くべきツールだ
  • コーディングを学ぶのに、今ほど簡単な時代はなかった
  • Boot.devのBoots（AI教育補助ツール）の事例
    • 学生はインストラクターの解答（理想的な正答）を見るよりも、AIチューター（Boots）とチャットすることをほぼ4倍多く利用している
    • Bootsは一般的なチャットボットとは異なり、次の方法で学習を助ける
      • 答えを直接教えないよう事前にプロンプト設定されている
      • ソクラテス式の方法を用いて、学生が問題についてより深く考えるよう促す
      • 講師の解答にアクセスできるため、正答に関する幻覚の可能性がはるかに低い
      • 楽しいキャラクター性を付与している（魔法使いのクマ）

バイブコーディング地獄から抜け出す方法

  • 結論として、**チュートリアル地獄であれバイブ地獄であれ、「他人任せにせず自分でやってみる経験」**が非常に重要だ
    • チュートリアル地獄: 動画を閉じて自分でコードを書く経験を積む
    • バイブ地獄: CopilotなどのAI自動補完を切り、自力で問題を解決する経験を積む
  • 避けるべきもの:
    • エディタ内のAI自動補完
    • エージェントモードやAI自動化ツールによるプロジェクト処理
  • 活用できるもの:
    • 質問に答え、概念を説明し、例を示すチャットボット
    • ソクラテス式に質問するよう促すシステムプロンプトを通じた深い思考の促進
    • 主張をするときに出典を引用し、文書にリンクするよう求めるシステムプロンプトによる情報信頼性の確保

核心原則

  • 学習は必ず不快であるべきだ
    • チュートリアル地獄は、他人がコーディングするのを見ることで不快さを避けられるようにする
    • バイブコーディング地獄は、AIにコードを書かせることで不快さを避けられるようにする
  • 本当の学習は、行き詰まり、挫折し、そして何より問題解決を強いられるときに起こる
    • それが人間の神経回路が再配線される方法だ
  • 「学習は難しくあるべきだ」という概念を過度に拡大すると、ひどい教育設計の言い訳になり得る
    • 筆者はそれを擁護していない
    • 概念が最善の方法で説明されたとしても、学生は依然としてそれと格闘し、新しい文脈で自分で使ってこそ本当に理解できる
  • 本当の学習は、自分で行き詰まり、挫折し、自力で突破する過程で完成する

関連記事

3件のコメント

 
aer0700 2025-10-12

少し文脈は違いますが、チュートリアル地獄が起こるのは、フレームワークのチュートリアルが基本的なCS教育資料として使われたものではないからでもあります。
Djangoチュートリアルを見て poll app を作ってみた初心者が一人でブログを作れないのは、Djangoチュートリアルが HTTP とは何か、テンプレートとは何か、WS とは何か、DB とは何か、といったことをすでに全部知っている人に対して Django を説明するための文章であって、Web を説明する文章ではないからです。Djangoチュートリアルでは非常に多くの文脈が省略されていて、これがチュートリアル地獄を生む原因なのではないかと思います。
今日初めてプログラミングをする人向けに Django チュートリアルを書き直してみるのも、なかなか良い課題かもしれません。まず HTTP の構造を説明し、そのうえで Django が各要素をどのように扱っているのかを説明する、という形です。
 
gudrb963 2025-10-15

とても良い意見ですね！
 
GN⁺ 2025-10-12
Hacker News の意見

  • 「Tutorial Hell」という言葉にはとても共感する。6時間の講義を見てその通りにコーディングはできても、いざ最初から何か作れと言われると手が止まってしまう。これこそ典型的なチュートリアル地獄だ。だから歴史的には徒弟制度(apprenticeship)が最も効果的な学習方法だった。ジュニアがシニアについて回り、親方が上から全体を引っ張る構図で、職人がプロジェクトの管理と指導を並行して行う形だ。開発者コミュニティが長いあいだギルドのように運営されてこなかったのは残念だし、1980年代末の時点でもうそうあるべきではなかったと思う。もしギルドが存在していたなら、開発者の数そのものがはるかに少なくなり、業界の発展自体も違う流れになっていたかもしれない

    • 新人だけでなく経験のある開発者でも、完全なゼロからプロジェクトを始めろと言われれば難しさを感じる。たいていは既存のコードベースで作業するし、新しいアプリが必要でもテンプレートやコピペから始める。本当に何もないところからまったく新しいものを作るケースはまれだ。電気技師が新築建物に配線するように、会社の開発者が本当に何かを完全に一からセットアップすることは少ない。徒弟制度も根本的にはこの構造を大きく変えるものではない

    • 私の経験では、良い大学は段階的で実践的な課題を通じて学生を鍛える。最初は簡単なデータ構造やアルゴリズム、パズルから始まり、やがてOS、データベース、永続データ構造、コンパイラ、CPU、シミュレーション、機械学習モデルまで作るようになる。関数ひとつから始めて、徐々により大きなものを自分で構築するようになるので、この訓練には本当に感謝している。関連リンク を参照

    • 私はLLMを、徒弟関係のような形でコーディング学習に活用している。LLMは私が指示したときだけ先へ進み、説明と指導だけを行い、実際に書くのは自分でやる。新しい講義やチュートリアルを探すよりずっと良い。そもそもチュートリアル地獄は、自分を教師だと思っている人たちが作り出した現象だと思う。無数の本や講義も結局、実質的には何かを教えられていない。今のコーディング教育モデルは完全に間違っていると感じる。最近はLLMに新しい言語やライブラリの最新ドキュメントを要約させたり、自分で計画を立てる方式を好んでいる。ただ、LLMが幻覚(hallucinate)していないか確信が持てず、その点は少し不満だ

    • 私は学校をかなり早く辞めた。理由は退屈さと時代遅れの教育方法だった。ソフトウェアエンジニアの徒弟として現場に入り、学校の課程はまったく役に立たなかった。90年代後半は失敗と試行錯誤の連続で、私も師匠も、そのまた師匠も、みな体当たりで学んでいた。LinuxでISDNルーターを作り、Webサイトのサーバーも構築し、HTML、Perl、PHPを扱いながら、本物のDevOpsとエンジニアリングを経験した。当時はそんな言葉すらなかったが。文書はほとんどなく、創造力とチャレンジ精神だけで境界を押し広げていく時代だった。今のAI時代のvibe codingと通じる部分もあり、プレッシャーははるかに大きいが、本当に楽しい思い出だ

    • テック業界では、職業へのゲートキーピングが否定的に受け取られている。業界内部のうぬぼれのせいでもあるし、資本の力で労働供給を増やして賃金を下げたい意図もある。その結果、まともな職業標準が失われ、leetcodeのような屈辱的な面接が、職業そのものとは無関係なゲートキーパーになってしまった

  • Zed ProとGPTを毎日コーディングに使っている者として、こうしたツールの進歩は現代のプログラミングの非効率さを露呈していると思う。現代のWebは驚異的であると同時にひどい。官僚主義とは複雑な規則でがんじがらめになることだとすれば、現代の開発こそその代表格だ。いちばん単純な作業ですら、確率ベースの自動化ツールの案内が必要だというのは少し悲しい。昔は後輩たちに「特定の言語を知っていることが重要なのではなく、学び続ける能力こそが核心だ」と助言していた。長く続くトレンドもあるだろうが、結局は新しいツールや言語を絶えず学ばなければならない。年のせいかもしれないが、ある時点からその複雑さがあふれ始めたと感じる。昔はプログラミングが電気工学的すぎる、あるいは数学的すぎると思っていたが、今はまた別種の複雑さが積み重なっている

    • 私もこの感覚には共感する。SF映画のように「エネルギーを前方へ回せ！」というノリで、部品やシステムがいつでも簡単に互換・再利用できるコンピューティング環境を望んだことがある。でも現実には、AndroidスマホのカメラをiPhoneに載せ替えることすらほとんど不可能な課題だ

    • 何を言おうとしているのか正確にはつかみにくいが、官僚主義という言葉の使い方は妙に見える。実際には検索力こそが中核的な能力であり、何でも見つけ出せる人なら何でもできる。自動化ツールも結局は本質的に本や教師と変わらない。こうした能力が不足している人が一部にいるのは人間の不変的な性質であって、ツールが良くなったことを責めるべきではない

    • ドキュメントを書くこと、検索すること、読むことが本当に難しいというのが大きな問題だ。だから学習が難しいのだが、AIのおかげで学ぶのはより簡単になった。たとえばUnreal Engineのようなものでも、AIは驚くほどよく理解している

    • 私たちが抱えている多くの問題はすべて、Brooksの『銀の弾などない』で言うところの偶有的複雑性だ。LLMはその複雑性を突き破り、言語やフレームワークごとに積み上がった知識のサイロまで壊す役割を果たしている

    • 今のような投機的な業界の状態がもう少し続けば、いずれプログラミングそのものが消える世界が来るかもしれない

  • 今は誰もがコードを書けるので、組織レベルではコード量が10倍くらいに増えている。だがレビューアーの数はそのままで、とてもさばききれない。LLMによるコード sanity check も使えないなら、いったいどうすればいいのかという気分になる。実際、昨日は非専門家がCodexで最適化アルゴリズムを作り、それを私に改善してくれと依頼してきた。問題は、そのコードが完全にひどかったことだ。数千個の整数の組み合わせを総当たりし、制約もろくに守れていないので、結果として信頼できない出力しか出ない。結局、一日中コードを精査したうえで、これは本質的に使い物にならないという内容を役員の前でプレゼンする羽目になった

    • 「LLMコードの sanity check」への答えは単体テストだ。LLMはテストコードや testable なコードも、頼めば非常にうまく生成できる。テストが実際にコードを呼び出し、エッジケースまでしっかり検証するなら、コードレビューよりずっと速い。パフォーマンステストなども含められる。これからは定義(definitions)とテストを中心に仕事をし、関数内部の実装方式は次第に重要でなくなっていく流れが来るだろう。これは大きな視点の転換だ

    • Excelプログラミング問題を見ればいい。最初はみんな無視するが、いざ爆発すると手遅れになってから何十万円、何百万円と使い、会社が傾く前に後始末しようとするようなものだ

    • 「レビューアーの数は変わらない」という部分については、LLMもコードレビューの助けになりうる。GPT-5でさえ、off-by-oneのような局所的なミスや戻り値の欠落の検出には強い。ただ、より高次の全体構造の理解が必要な問題にはまだ限界がある。将来的には、大規模コードベースを定期的にLLMへファインチューニングし、すべての変更に対する一次レビューアーとして使うような導入も可能だと思う

    • OR(組合せ最適化)の問題は、行き当たりばったりでコーディングする人たちが、自分が本質的に特殊なアルゴリズム領域に踏み込んでいることをよく理解していないところから生じる。指摘しても数学的理論を理解できず、結局は自分のやり方で進めようとする傾向が強い

    • こういう状況では、会社のリーダーたちに技術的なプレゼンテーションを行い、現状を正確に認識させることが、事実上唯一の対応策かもしれない

  • AIがジュニア開発者を駄目にし、その結果としてシニア代替要員の危機が来る、という話がまた出るのかと思った。この記事にも間接的にはそういう内容はあるし、全体的には同意する。だが特に印象的だったのは、おべっか(sycophancy)についての部分だ。以前はChatGPTのようなインターフェースが学習に役立つと思っていたが、YouTube ROASの例は強烈だった。質問の仕方次第で、教師の結論を学生がいくらでも歪められる構造なら、無数の初心者開発者が誤った方向へ導かれるのも避けられない。しかも、AI「Boot」に適用したさまざまなプロンプトの工夫が十分かどうかすら分からない。結局、AI時代でも、私のPRを何度も突き返してくれる「誰か」がいなければ成長できない。その「誰か」は、まだAIにはなれない

    • 私の経験では、辛辣な批評(Scathing critique)を求めても、AIには私を気分よくさせようとする態度が混じる。昔のGPTでも最新のGPTでも同じようなものだ。どこか曖昧な違和感がある。結局このツールは、自分がどう助けられたいかを理解し、LLM特有の問題点を自覚している人だけが最もうまく使える手段にとどまる

    • おべっか現象を避けるため、私はいつも反対バイアスを入れて二度質問する。でも、自分の中にある隠れたバイアスまでAIが強化していないかは分からない

  • 初心者ではないが、新しいフレームワークや言語、アルゴリズムを学び続けているので、AIオートコンプリートが悪いとは思わない。昔のIntelliSenseやReSharperのオートコンプリートも、新しいライブラリや言語機能を学ぶときに大いに役立った。ReSharperは昔ながらの書き方をしていると新機能を提案してくれて、それで新しく学んだことも多い。AIベースのオートコンプリートはそれをさらに発展させたものに感じる。自然な形で何かを提案してくれるし、実際に使っても使わなくてもよいので学習にも役立つ。結局、好奇心を持って提案を読み、理解しようとする姿勢さえあれば、AIのおかげで学びやすくなる。昔はただStack Overflowからコピペしていただけだった

    • 従来のオートコンプリートは、そのスコープにあるすべてのメソッド、変数、定数などを見せ、ドキュメントにもつないでくれる。どんな選択肢があるのかを自分で判断できるので、本当に学習に向いていた。AIオートコンプリートは、実質的にはStack Overflowの回答を文脈説明なしに貼り付けるのに近い。学ぶ側なら、自分でStack Overflowを検索したり、必要ならチャットボットにプロンプトを出して、なぜそのコードになるのかまで説明してもらうほうがよりよいかもしれない

    • 私の考えでは、少し違いがある。ある程度経験があれば、新しい言語でオートコンプリートを使っても自然だ。でも基礎のない初心者が、最初のfor文からそれに頼るのは別の話だ

    • 私はAI Agenticプログラミングが好きだ。作ることそのものが楽しく、アイデア実験の一部でもある。コードを本番環境にデプロイするわけではないので、人の目も気にしない。技術的に優れた仲間と話すには、自分で試して学ぶことが必要だ。10歳の頃からプログラミングが好きだったが、職業プログラマではなかった。AI時代が来て、コーディングと実験への愛がよみがえった。WASMなどの未来のWeb技術やさまざまなシステム、バグ探し、自分なりのやり方で試すことが大きな喜びだ。Cursor AIのようなツールは、私のgit設定まで自動化し、sshでのpushまで簡単にしてくれる。もちろん自分でもできるが、AIに任せている。子どもの頃にCの文法から始めて固まった習慣もあるが、pythonバックエンド、flask Webサーバー、JavaScriptフロントエンドを扱う楽しさは大きい。WASM Pythonはまだかなり未熟だが、実験は続けている。基礎を固め、自分のやり方で学ぶのが私の好みだ。エンジニアは必要以上に複雑にしがちだと感じることも多い

    • AIオートコンプリートは最高のツールだ。ドキュメントなしでも欲しいコード提案が得られ、数行程度なのでレビューもしやすい。大きな塊を自動生成するわけではないから、学習の妨げにもならない

  • 初心者ではないが、CopilotのおかげでRustを学ぶのは確かに楽になった。Intellisenseと組み合わせて使えば文法の負担が減り、言語の重要な部分の学習に集中できる。Rustの本を開いてから1週間で、動くツールまで作れた。もちろんそれでシニアエンジニアになれたわけではないが、「0から1」へのハードルを確実に下げてくれる。私はCopilotにコードを書けとは指示せず、改良版オートコンプリートのように提案だけを受け取り、自分で採用するか決めている

    • ここで繰り返し出てくるテーマは、経験豊富なシニアは新しい言語を知らなくても「コードの書き方」を知っているので、こうしたツールから価値を引き出せるという点だ。言語が変わってもコードスメルは同じだが、初心者は「コードスメル」という概念自体をよく分かっていない

    • 私も以前はCopilotがRust学習に大いに役立つと思っていたが、AIなしで自力で書いてみると本当に難しかった。AIを切って学ばなければ、本当に理解しているという錯覚から抜け出せなかった

  • さまざまな教育の近道にも同じ問題がある。学生が家庭教師に宿題を代わりに解いてもらったり、説明だけ聞いて試験は大丈夫だと錯覚したりする。実際には、説明を聞いているときは簡単に見えても、本当に自分ひとりでやり切るのはまったく別の能力だ

  • AIが本当に数年以内にすべてのホワイトカラー職を置き換えないのだとしたら、株式市場のバブルだけでなく、高学歴労働力の不足にも直面することになりそうだ。私には「自分の世代の最高の人材たちが、こんなふうに散っていくのを見ている」という衝撃に近い

  • 記事タイトルとして使えそうな代表的なフレーズを探そうとしたが、ちょうどよいものが見つからず、できる限りやってみた。もっと正確で中立的なタイトル案があれば差し替えてもよい。関連案内

  • 「理解はしたけれど、最初から書いてみろと言われると完全に詰まる」という部分には強く共感する。最初はチュートリアルを追いかけるだけで、似たものを作ろうとして行き詰まるのがいちばんつらく、難しかった。しかし、そうした苦しい過程こそが、学習効率の密度が最も高い経験でもあった。その後もっと複雑で多様なことを学んだが、あの密度の学習を再び経験したことはない。高校数学で感じた、頭が痛くなりストレスを受ける感覚に少し似ていた。誰にでもよくある経験ではないのかもしれないと思う