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

プログラミングチュートリアルは死んだ 9月17日、2026年 Rob 私はプログラミング教育を販売しています。ですから、これは私が持つにはあまり都合の良い意見ではありません。プログラミングチュートリアルは死んでいます。文字通りではありません。誰かが今日Railsのチュートリアルを読むでしょう。誰かが今週プログラミングの本を買うでしょう。私自身もおそらくもっとチュートリアルを書くでしょう。死んでいるのは、それらを取り巻く古い契約です。つまり、私はクリーンなサンプルアプリケーションを構築し、何かをどのように実装したかを示し、そしてあなたはそれをあなたが実際に気にかけているアプリケーションに翻訳する作業を行うということです。 収益はすでに何かを語ろうとしている 私は長年、開発者向けの書籍やその他の教育製品を販売してきました。ローンチがかつてどのようなものだったか、ウォームリストのセールがどのようなものだったか、そして記事がランク付けされて誰かをカタログの残りの部分に引き込んだときに何が起こったかを知っています。私の従来の開発者教育からの総収益は、逆方向に動いています。それは1人のビジネスであり、業界レポートではありません。そして、それを説明する方法はたくさんあります。おそらくオーディエンスが変わったのかもしれません。市場が飽和しているのかもしれません。もっと良いメールを書くべきだったのかもしれません。 次に、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処理を追加したいとします。誰かがクリーンなアプリでゼロから構築するのを見て、ビデオを一時停止し、関連する部分をコピーし、すべてをリネームし、彼らの仮定を適応させ、私のキュー設定が異なることに気づき、再試行について議論した部分を検索し、最終的に実装を私のコードベースに組み込むことができます。 または、アプリケーションのアーキテクチャ、障害モード、境界、テスト、および重要な決定に関する優れた資料をコーディングエージェントに提供し、それが既存のアプリケーションを検査できるようにします。それでも、資料を理解し、実装を確認し、結果が間違っていることに気づくのに十分な経験が必要です。誰かのサンプルアプリを最初に手動で再構築する必要はなくなりました。 ハローワールドは大丈夫です。 タイトルにはアスタリスクが必要です。短いチュートリアルとドキュメントがなくなるわけではありません。メソッドがどのように機能するかを知りたいとき、小さな例を見たいとき、または6か月間触っていなかったRails APIの動作を思い出したいときがあります。broadcast_replace_toがどのように機能するかを知りたい場合、簡潔な例は素晴らしいです。N+1クエリを理解したい場合、エージェント型実装フレームワークと40ページのアーキテクチャドキュメントは必要ありません。ハローワールドは大丈夫です。 問題が実際のプロダクションアプリケーションのように見えると、その形式は崩壊し始めます。実際のアプリがきれいであればあるほど、きれいなサンプルアプリは役に立たなくなります。認証が難しいのは、誰もパスワードダイジェストの保存方法を知らないからではありません。請求が難しいのは、誰もStripe APIリクエストの作成方法を知らないからではありません。Webhookが難しいのは、誰もPOSTリクエストの受け入れ方法を知らないからではありません。難しいのは、それらのものをアプリケーションの残りの部分に適合させ、アカウント所有権の3つの新しい定義、2つの請求の真実、そして実際には何も失敗しない場合にのみ機能する再試行パスを作成しないことです。それはリポジトリ固有の作業であり、コーディングエージェントはすでにリポジトリ内にいます。 これは実際にはバイブコーディングに関するものではありません。 この議論の簡単なバージョンは初心者に関するものです。コードの書き方をほとんど知らない人がAIツールを開き、機能を要求し、モデルにすべてを構築させます。確かに、それは存在します。より興味深い変化は、経験豊富な開発者に何が起こるかだと思います。私は長年ソフトウェアを構築してきました。背景ジョブが何であるかを誰かに説明してもらう必要はほとんどありませんし、彼らがアーキテクチャに落ち着いたことを理解するためにすべてのコントローラーアクションを入力するのを見る必要もありません。 私が欲しいのは、彼らの経験の費用のかかる部分です。なぜ境界をそこに置いたのですか？そして、この形状に至る前に何が失敗しましたか？どの仮定が実際に重要ですか？並行処理はどこで問題になりますか？本番トラフィックが表示されるまで無害なショートカットのように見えるものは何ですか？テストは何を証明すべきですか？そして、エージェントに「クリーンアップ」させてはいけないことは何ですか？それは静かに動作を変更する可能性がありますか？それが役立つ資料です。私はあなたのサンプルアプリを、あなたの決定ほど欲しくはありません。それらの決定が得られれば、コーディングエージェントは私がすでに作業しているアプリケーション内で多くの機械的な適応を行うことができます。 初心者はさらに専門家のコンテキストを必要とします。 モデルがコードを生成できる場合、初心者向けの教育が重要でなくなるという奇妙な仮定が一部のAI議論にあります。私は逆の問題がかなり早く現れると思います。経験豊富な開発者は、AIによって生成された実装を見て、理由を常に説明できる前に、何かがおかしいと感じることができます。初心者はしばしばそうできません。なぜなら、彼らはまだ十分な悪いデプロイ、競合状態、セキュリティミス、そして後悔する抽象化を持っていないからです。エージェントは、数年前よりもはるかに多くの実行能力を彼らに与えます。それは自動的に彼らに判断を与えません。エージェント型コーディングはまた、開発者がエージェントを動かし続けるために必要な十分な学習しかせずに、驚くほど遠くまで到達することを可能にします。古い方法は遅くてしばしば退屈でしたが、認証、認可、請求、ジョブ、テナンシー、そして他のすべてを手動で接続することは、それらのピースがどのように組み合わさるかについての少なくともいくつかのメンタルモデルを構築することを強制しました。今では、開発者が実際に理解する前に、エージェントがそれらのピースの多くを接続できます。