プログラミングチュートリアルは死んだ

プログラミングチュートリアルは死んだ

2026年9月17日

Rob

私はプログラミング教育を販売しています。

ですから、これは私にとってあまり都合の良い意見ではありません。

プログラミングチュートリアルは死んだ。

文字通りではありません。今日誰かがRailsチュートリアルを読むでしょう。今週誰かがプログラミングの本を買うでしょう。私自身もおそらくチュートリアルをさらに書くでしょう。死にかけているのは、それらを取り巻く古い契約です。つまり、私はクリーンなサンプルアプリケーションを構築し、それをどのように実装したかを示し、あなたはそれをあなたが本当に気にかけているアプリケーションに翻訳する作業を行う、というものです。

収益がすでに何かを語ろうとしている

「収益がすでに何かを語ろうとしている」というタイトルのセクション

私は長年、開発者向けの書籍やその他の教育製品を販売してきました。かつてのローンチがどのようなものだったか、ウォームリストのセールスがどのようなものだったか、そして記事がランクインして誰かをカタログの他の部分に引き込んだときに何が起こったかを知っています。私自身の従来の開発者教育からの総収益は、間違った方向に向かっています。

それは一人のビジネスであり、業界レポートではありません。そして、それを説明する方法はいくらでもあります。おそらく、オーディエンスが変わったのかもしれません。市場が飽和しているのかもしれません。もっと良いメールを書くべきだったのかもしれません。

次に、Chris OliverがGoRailsとHatchboxについてかなり率直なアップデートを公開しました。Chrisは10年以上Rails開発者を教えており、GoRailsはチュートリアルからHatchbox開発を支援するビジネスへと成長しました。これは、3つのスクリーンキャストを投稿して、悪いローンチをして、教育は壊れていると判断したクリエイターではありません。

2026年9月、Hatchboxの価格引き上げを説明する際に、ChrisはAIが教育ビジネスに壊滅的な影響を与えたと書いています。彼は、GoRailsは歴史的にHatchbox開発を補助してきたが、それはもはや持続不可能であり、GoRailsは2026年に最初の年よりも新しい顧客が少なくなるだろうと述べました。

それは私の注意を引きました。なぜなら、それは私がすでに見ていたものと、開発者としての私の行動と非常によく似ていたからです。

私は問題の一部です。

あなたのサンプルアプリをもう作りたくない

「あなたのサンプルアプリをもう作りたくない」というタイトルのセクション

従来のプログラミングチュートリアルには、隠された翻訳ステップがあります。著者は自分のアプリケーションから始め、問題を教えられるものにまで減らし、それを取り巻くサンプルアプリ、記事、スクリーンキャスト、またはコースを構築します。次に、読者はその知識のすべてを自分のアプリケーションに移動させる必要があります。

フローは次のようになります。

専門家の経験      ↓チュートリアルアプリケーション      ↓あなたの目      ↓あなたの脳      ↓あなたのキーボード      ↓あなたのアプリケーション

長い間、それは技術学習のやり方でした。サンプルアプリにはUserがありますが、あなたのアプリにはAccountとMembershipがあります。チュートリアルはDeviseを使用しますが、あなたはRailsの認証ジェネレーターを使用しています。著者はrails newから始めますが、あなたは6年もののアプリケーションに機能を追加しており、それはすでに何世代にもわたる完全に合理的な決定を蓄積しています。

チュートリアルはその環境で何が機能したかを教えてくれますが、あなたはどの部分があなたの環境との接触に耐えられるかを自分で見つけます。あなたは常に統合レイヤーでした。

コーディングエージェントがそれを変えました。

エージェントはすでにチュートリアルの向こう側に住んでいる

「エージェントはすでにチュートリアルの向こう側に住んでいる」というタイトルのセクション

有能なコーディングエージェントは、実際に作業が行われるアプリケーションを検査できます。それはあなたのモデル、テスト、認証設定、ジョブ、命名規則、既存の抽象化、そして誰も追加したことを覚えていない奇妙な互換性コードを見ることができます。変更をどこに配置するかを決定する前にリポジトリを検索し、変更を実装し、テストを実行し、失敗を検査し、再度試すことができます。

例えば、既存のRailsアプリケーションに信頼性の高いWebhook処理を追加したいとします。クリーンなアプリでゼロから構築するのを誰かが見ているのを一時停止し、関連する部分をコピーし、すべてをリネームし、彼らの仮定を適応させ、私のキュー設定が異なることに気づき、再試行について議論した部分を検索し、最終的に実装を私のコードベースに組み込むことができます。

または、アプリケーションのアーキテクチャ、障害モード、境界、テスト、および重要な決定に関する良い資料をコーディングエージェントに提供し、それが既存のアプリケーションを検査できるようにします。私はまだ資料を理解し、実装を確認し、結果が間違っていることに気づくのに十分な経験を持っている必要があります。誰かのサンプルアプリを最初に手動で再構築する必要がなくなっただけです。

Hello Worldは大丈夫

「Hello Worldは大丈夫」というタイトルのセクション

タイトルにはアスタリスクが必要です。短いチュートリアルやドキュメントがなくなるわけではありません。時々、メソッドがどのように機能するかを知りたい、小さな例を見たい、または半年間触っていなかったRails APIの仕組みを思い出したいことがあります。

broadcast_replace_toがどのように機能するかを知りたい場合、簡潔な例は素晴らしいです。N+1クエリを理解したい場合、エージェント的な実装フレームワークと40ページのアーキテクチャドキュメントは必要ありません。

Hello Worldは大丈夫です。

問題が実際のプロダクションアプリケーションのように見えるようになると、フォーマットは壊れ始めます。実際のアプリがきれいであればあるほど、きれいなサンプルアプリの有用性は低下します。

認証が難しいのは、パスワードダイジェストの保存方法を知らない人がいないからです。請求が難しいのは、Stripe APIリクエストの仕方を知らない人がいないからでも、WebhookがPOSTリクエストを受け付ける方法を知らないからでもありません。難しいのは、それらをアプリケーションの残りの部分に適合させる際に、アカウント所有権の3つの新しい定義、2つの請求の真実、および何も失敗しない場合にのみ機能する再試行パスを作成しないことです。

それはリポジトリ固有の作業であり、コーディングエージェントはすでにリポジトリ内にいます。

これは実際にはバイブコーディングに関するものではない

「これは実際にはバイブコーディングに関するものではない」というタイトルのセクション

この議論の簡単なバージョンは初心者に関するものです。コードの書き方をほとんど知らない人がAIツールを開き、機能を要求し、モデルにすべてを構築させます。確かに、それは存在します。より興味深い変化は、経験豊富な開発者に何が起こるかだと思います。

私は長年ソフトウェアを構築してきました。バックグラウンドジョブとは何かを誰かに説明してもらう必要はほとんどありませんし、彼らがアーキテクチャを理解するためにすべてのコントローラーアクションを入力するのを見る必要もありません。私が欲しいのは、彼らの経験における高価な部分です。

なぜあなたは境界線をそこに置いたのですか、そしてそれがその形になった前に何が失敗しましたか？どの仮定が実際に重要ですか？並行処理はどこで問題になりますか？一見無害なショートカットに見えても、プロダクショントラフィックが現れたらどうなるか、テストは何を証明すべきか、そしてエージェントに「クリーンアップ」させてはいけないことは何ですか？それは静かに動作を変える可能性があるからです。

それが有用な資料です。私はあなたのサンプルアプリを、あなたの決定ほどは欲しくありません。それらの決定を得たら、コーディングエージェントは私がすでに作業しているアプリケーション内で多くの機械的な適応を行うことができます。

初心者は専門家の文脈をさらに必要とする

「初心者は専門家の文脈をさらに必要とする」というタイトルのセクション

モデルがコードを生成できる場合、初心者向けの教育の重要性が低下するという奇妙な仮定が一部のAI議論にあります。私は逆の問題がかなり早く現れると思います。

経験豊富な開発者は、AIによって生成された実装を見て、それがなぜそうなのかを常に説明できる前に、何かがおかしいと感じることができます。初心者は、まだ十分な悪いデプロイ、競合状態、セキュリティミス、そして後悔する抽象化を経験していないため、しばしばできません。

エージェントは、数年前よりもはるかに多くの実行能力を彼らに与えます。それは自動的に判断力を与えるわけではありません。

エージェントによるコーディングは、エージェントを動かし続けるために必要なだけの学習で、驚くほど遠くまで到達することを可能にします。古い方法は遅くてしばしば退屈でしたが、認証、認可、請求、ジョブ、テナンシー、その他すべてを手動で接続することは、少なくともそれらのピースがどのように組み合わさるかの精神的なモデルを構築することを強制しました。

今や開発者が境界がどこにあるのかを本当に理解する前に、エージェントがそれらのピースの多くを接続できます。それは結果のアーキテクチャを間違っているとはしませんが、アーキテクチャの判断をスキップしやすくします。開発者がローカルで合理的な変更がシステム全体にとってまだ意味があるかどうかを判断する方法を学ばない場合、実装を教えるだけでは不十分です。経験豊富な開発者はその文脈を使用して時間を節約します。新しい開発者は、まだ構築していない判断を借りるためにそれを使用します。

開発者教育には実行レイヤーが必要

「開発者教育には実行レイヤーが必要」というタイトルのセクション

ここに製品自体が変わる必要があると考えています。「プロンプト」というタイトルの章を追加したり、ビデオコースの横にチャットボットを置いたり、本のAI要約を生成したりすることは、古い製品をそのままにしてAI機能を側面に付け加えることです。

人間はまだ以下を必要とします。

• 精神的なモデル
• トレードオフ
• アーキテクチャ
• 推論
• 障害モード
• 結果を確認するために必要な語彙

コーディングエージェントは以下を必要とします。

• リポジトリ検査指示
• 実装制約
• アーキテクチャ契約
• 盲目的にコピーするのではなく適応できるレシピ
• 不変条件と検証ステップ
• レビュー質問
• 既知の障害モード
• 変更してはならないことの明確な境界

自分の製品をより新鮮にするために試みている間にこれにたどり着いた

「自分の製品をより新鮮にするために試みている間にこれにたどり着いた」というタイトルのセクション

私は技術教育を置き換えるという壮大な理論から始めたわけではありません。私はすでに販売しているものが、私が現在ソフトウェアを構築する方法に適合するようにしようとしていました。

Webhooks in Railsには人間が読める実装ガイドがありますが、Agent Companionも含まれています。ガイドは境界が存在する理由を説明し、コンパニオンはコーディングエージェントが既存のアプリケーション内で作業する際に使用できる契約、レシピ、例、およびレビュー質問を提供します。

Rails Baselineはさらに進んでいます。アプリケーション自体が、認証、認可、テナンシー、権限、ジョブ、およびその他の退屈だが重要な部分のパターンを確立します。そのエージェント的な資料は、コーディングエージェントが新しい機能が追加されるたびに再決定するのではなく、それらの決定を発見し、継続するのを助けます。

私は「AI搭載」がランディングページで良く見えるからこれらの部分を追加したのではありません。私がそれらを追加したのは、静的な実装を誰かに手渡して「これをあなたのアプリに適合させてください」と言うことが、不完全だと感じ始めたからです。

静的な実装手順はコモディティになりつつある

「静的な実装手順はコモディティになりつつある」というタイトルのセクション

ビジネスの部分はより醜いです。主な価値が次のとおりであるチュートリアル：

Xを実装するために必要な手順はこちらです。

は、実際のアプリケーションを見ながらオンデマンドでそれらの手順を生成できるマシンと競合しています。

それは競合するのが厳しいことです。フォローアップの質問に答えたり、同じことを別の方法で説明したり、リポジトリを検査した後に回答を変更したり、そして作業を開始したりできます。より良いマイクで同じCRUDフローを録音しても、それを修正することはできません。

価値のある部分は、汎用的なプロンプトから再生成するのが難しいもの、つまり判断、トレードオフ、制約、そして実際に問題に対処したことがある人からの文脈へと移行します。

無料の教育コンテンツを取り巻く経済学も厄介です。長年、基本的な取引は理解可能でした。有用な資料を公開し、オーディエンスを構築し、そのオーディエンスの何パーセントかがより深い製品を購入するというものです。

今や開発者は、ソースを必ずしも訪問したり、リストに参加したり、何も購入したりすることなく、有用なAI支援の回答を得ることができます。知識は有用なままであり、知識を取り巻く流通モデルは悪化します。

ChrisのGoRailsの数字は特に大きな例ですが、その点を説明するために彼のビジネスは必要ありません。私自身の販売や開発習慣でも同じ圧力を感じることができます。私はかつてないほど多くの技術情報を消費していますが、古い形式で消費することへの関心は薄れています。

教育者の仕事は小さくなるのではなく、良くなる

「教育者の仕事は小さくなるのではなく、良くなる」というタイトルのセクション

AIがモデルが無限の説明やコードを生成できるため、教師を置き換えるという悲観的なバージョンがあります。私はそのバージョンは買いません。なぜなら、私が技術教育で最も価値を置いている部分は、決してタイピングではなかったからです。それはタイピングの背後にある決定でした。

良い教育者は、私がこれから犯すであろう間違いをすでに犯しています。彼らは、きれいに見えたが6ヶ月後に面倒になった抽象化をすでに試しており、どのフレームワークの慣習に従う価値があり、どの慣習がこの特定のケースで役立たなくなるかを見つけ、どのプロダクション障害が設計を変更すべきか、単なるレスキューブロックになるのではなく、を経験しています。

仕事は「すべてのキーストロークを記録する」というよりも、開発者とコーディングエージェントの両方が使用できるくらいによく判断をエンコードすることのように見え始めます。

「でも、私はまだチュートリアルを読んでいます」

「でも、私はまだチュートリアルを読んでいます」というタイトルのセクション

私もそうです。概念を理解するために記事を読んだり、APIを調べたり、考え方をもっと知りたい人の本を買ったりしています。

私がはるかにやりたくなくなったのは、アイデアを自分のコードに適用できるようになる前に、使い捨てのサンプルアプリで実装を手動で再現するのに何時間も費やすことです。

これが私がここで死んでいると言う意味です。チュートリアルはなくなっていませんが、もはやワークフロー全体ではありません。

チュートリアルは2つのものに分割されている

「チュートリアルは2つのものに分割されている」というタイトルのセクション

従来のインプリメンテーションチュートリアルは、2つのジョブをバンドルしていました。

1. 良いものがどのようなものか教えてください。
2. 自分で再現できるだけのコードを見せてください。

コーディングエージェントはそれらのジョブを分離します。人間はまだ理解を必要としますが、エージェントは翻訳と実行の多くを処理できます。

有用なループは次のようになります。

専門知識      ↓開発者 + コーディングエージェント      ↓実際のコードベース

実装が重い素材の場合、完全な製品はますます開発者をコーディング環境に連れて行くように設計されたものを含んでいくようになると考えられます。

魔法のプロンプトや「私のためにこれを構築してください」ではなく、実際の文脈です。つまり、決定、制約、例、チェック、そして著者が一度も見たことのないコードベースにそれらを適用するプロセスです。

プログラミングチュートリアルは死んだ

「プログラミングチュートリアルは死んだ」というタイトルのセクション

タイトルは腹立たしいことを意図しています。明日もチュートリアルはあるでしょう。

私が死んでいると呼んでいるのは、誰かの実装の静的なウォークスルーが多くの実際のアプリケーション作業に十分であるという仮定です。エージェントは宛先コードベースを検査し、実装にコンテキストを運び、テストを実行し、チュートリアルが伝統的に終了した後に作業を続けることができます。

専門知識は依然として重要です。ただ、それがもはやサンプルアプリで止まってほしくないのです。