Programming Tutorials Are Dead

Sep 17, 2026

Rob

I sell programming education.

So this is not a particularly convenient opinion for me to have.

Programming tutorials are dead.

Not literally. Somebody will read a Rails tutorial today. Somebody will buy a programming book this week. I will probably write more tutorials myself. What is dying is the old contract around them: I build a clean example application, show you how I implemented something, and then you do the work of translating that example into the application you actually care about.

That used to be the best interface we had. It is not anymore.

The revenue is already trying to tell us something

I have sold developer books and other educational products for years. I know what launches used to look like, what warm-list sales looked like, and what happened when an article started ranking and pulled somebody into the rest of the catalog. My own gross revenue from traditional developer education has been moving in the wrong direction.

That is one person’s business, not an industry report, and there are plenty of ways I could explain it away. Maybe the audience changed. Maybe the market is saturated. Maybe I should write better emails.

Then Chris Oliver published a pretty blunt update about GoRails and Hatchbox. Chris has been teaching Rails developers for more than a decade, and GoRails grew from tutorials into a business that helped fund Hatchbox development. This is not a creator who posted three screencasts, had a bad launch, and decided education was broken.

In September 2026, while explaining a Hatchbox price increase, Chris wrote that AI had been brutal to education businesses. He said GoRails had historically subsidized Hatchbox development, that this was no longer sustainable, and that GoRails would have fewer new customers in 2026 than it had in its first year.

That got my attention because it lined up with what I had already been seeing. More importantly, it lined up with my own behavior as a developer.

I am part of the problem.

I do not want to build your sample app anymore

The traditional programming tutorial has a hidden translation step. The author starts with their application, reduces the problem into something teachable, and builds a sample app, article, screencast, or course around it. Then the reader has to move all of that knowledge back into their application.

The flow looks something like this:

expert's experience
      ↓
tutorial application
      ↓
your eyeballs
      ↓
your brain
      ↓
your keyboard
      ↓
your application

For a long time, that was just how technical learning worked. The sample app has User; yours has Account and Membership. The tutorial uses Devise; you are using the Rails authentication generator. The author starts from rails new; you are adding the feature to a six-year-old application that has already accumulated several generations of perfectly reasonable decisions.

The tutorial tells you what worked in its environment, and you figure out which parts survive contact with yours. You were always the integration layer.

Coding agents changed that.

The agent already lives on the other side of the tutorial

A capable coding agent can inspect the application where the work is actually going to happen. It can see your models, tests, authentication setup, jobs, naming conventions, existing abstractions, and the weird compatibility code nobody remembers adding. It can search the repository before deciding where something belongs, implement a change, run the tests, inspect the failure, and try again.

That changes what I want from somebody teaching me.

Say I want to add reliable webhook processing to an existing Rails application. I can watch somebody build it from scratch in a clean app, pause the video, copy the relevant pieces, rename everything, adapt their assumptions, notice that my queue setup is different, search for the part where they discussed retries, and eventually get the implementation into my codebase.

Or I can give my coding agent good material about the architecture, failure modes, boundaries, tests, and decisions that matter, then let it inspect the application that already exists. I still need to understand the material, review the implementation, and have enough experience to notice when the result is wrong. I just do not need to manually reconstruct somebody else’s sample app first.

That part of the workflow is disappearing quickly.

Hello World is fine

This is where the title needs a little qualification. Short tutorials and documentation are not going away. Sometimes I want to know how a method works, see one small example, or remind myself how a Rails API works after not touching it for six months.

If I want to know how broadcast_replace_to works, a concise example is great. If I want to understand an N+1 query, I do not need an agentic implementation framework and a 40-page architecture document.

Hello World is fine.

Everything after it is where the format starts to break down. The closer a problem gets to a real production application, the less useful a pristine sample application becomes as the final destination of the teaching.

Authentication is not hard because nobody knows how to store a password digest. Billing is not hard because nobody knows how to make a Stripe API request, and webhooks are not hard because nobody knows how to accept a POST request. The difficult part is making those things fit the rest of the application without creating three new definitions of account ownership, two billing truths, and a retry path that only works when nothing actually fails.

That is repo-specific work, and the coding agent is already in the repo.

This is not really about vibe coding

The easy version of this argument is about beginners: somebody who barely knows how to code opens an AI tool, asks for a feature, and lets the model build the whole thing. Sure, that exists. I think the more interesting change is what happens to experienced developers.

I have been building software for a long time. I usually do not need another person to explain what a background job is, and I do not need to watch them type every controller action just to understand the architecture they settled on. What I want is the expensive part of their experience.

Why did you put the boundary there, and what failed before you ended up with this shape? Which assumptions actually matter? Where does concurrency become a problem? What looks like a harmless shortcut until production traffic shows up, what should the tests prove, and what should I absolutely not let the agent “clean up” because it will quietly change the behavior?

That is the useful material. I do not want your sample app nearly as much as I want your decisions. Once I have those decisions, a coding agent can do a lot of the mechanical adaptation inside the application I am already working on.

That is a much better use of both the expert and the reader’s time.

Beginners need the expert context even more

There is a weird assumption in some AI discussions that if models can generate code, beginner-focused education becomes less important. I think the opposite problem shows up pretty quickly.

An experienced developer can look at an AI-generated implementation and feel that something is off before they can always explain why. A beginner often cannot, because they do not have enough bad deployments, race conditions, security mistakes, and regrettable abstractions behind them yet.

The agent gives them far more execution ability than they would have had a few years ago. It does not automatically give them judgment.

There is another problem hiding inside that. Agentic coding lets somebody get surprisingly far while learning only enough to keep the agent moving. The old way was slower and often tedious, but manually connecting authentication, authorization, billing, jobs, tenancy, and everything else forced you to build at least some mental model of how those pieces fit together.

Now the agent can connect a lot of those pieces before the developer really understands why the boundaries are where they are. That does not make the resulting architecture wrong, but it makes architectural judgment easier to skip. Teaching the implementation is not enough if the developer never learns how to tell whether a locally reasonable change still makes sense for the system as a whole.

That is a bigger problem than this article can solve, but it points in the same direction. Good educational material needs to help the human understand the decisions while giving the agent enough constraints that it does not invent the important parts from scratch.

The experienced developer uses that context to save time. The newer developer uses it to borrow judgment they have not built yet. Same source material, different reason for needing it.

Developer education needs an execution layer

This is the part I think traditional developer education needs to react to. Adding a chapter called “Prompts,” putting a chatbot beside a video course, or generating an AI summary of a book keeps the old product intact and bolts an AI feature onto the side.

I think implementation-oriented education increasingly needs an execution layer.

There is still material for the human:

• the mental model
• the tradeoffs
• the architecture
• the reasoning
• the failure modes
• the vocabulary needed to review the result

Then there is material for the coding agent:

• repository inspection instructions
• implementation constraints
• architectural contracts
• recipes that can be adapted instead of copied blindly
• invariants and verification steps
• review questions
• known failure modes
• explicit boundaries around what should not change

The educational product should not stop at the point where the reader understands what should be built. It should be able to make the next jump into the environment where the thing is actually being built.

That is the execution layer.

I backed into this while trying to make my own products less stale

I did not start with a grand theory about replacing technical education. I was trying to make the things I already sell fit the way I actually build software now.

Webhooks in Rails has a human-readable implementation guide, but it also includes an Agent Companion. The guide explains why the boundaries exist, while the companion gives a coding agent contracts, recipes, examples, and review questions it can use while working inside an existing application.

Rails Baseline goes further. The application itself establishes patterns for authentication, authorization, tenancy, entitlements, jobs, and the other boring-but-important pieces. Its agentic material helps a coding agent discover and continue those decisions instead of re-deciding them every time a new feature is added.

I did not add those pieces because “AI-powered” looks good on a landing page. I added them because handing somebody a static implementation and saying “now go adapt this to your app” started feeling incomplete.

That was the clue: the old product ended too early.

Static implementation steps are becoming a commodity

This is the uncomfortable business part. A tutorial whose primary value is:

Here are the steps required to implement X.

is now competing with a machine that can generate those steps on demand while looking at the actual application.

That is a rough competitor. It can answer follow-up questions, explain the same thing differently, change the answer after inspecting the repository, and then start doing the work. Recording the same CRUD flow with a better microphone is not going to fix that.

The valuable part moves toward the things that are harder to regenerate from a generic prompt: judgment, coherent architecture, tested constraints, strong opinions, known tradeoffs, and context that has been maintained by somebody who has actually dealt with the problem.

This is also why the economics around free educational content get awkward. For years, the basic trade was understandable: publish useful material, build an audience, and some percentage of that audience buys the deeper product.

Now a developer can get a useful AI-assisted answer without necessarily visiting the source, joining the list, or buying anything. The knowledge can remain useful while the distribution model around the knowledge gets worse.

Chris’s GoRails numbers are a particularly loud example, but I do not need his business to make the point. I can see the same pressure in my own sales and in my own development habits. I am consuming more technical information than ever while becoming less interested in consuming it in the old format.

That is the problem.

The educator’s job gets better, not smaller

There is a pessimistic version of this where AI replaces the teacher because the model can generate endless explanations and code. I do not buy that version, because the parts of technical education I value most were never the typing. They were the decisions behind the typing.

A good educator has already made the mistake I am about to make. They have already tried the abstraction that looked clean and became annoying six months later, figured out which framework convention is worth following and which one stops helping in this particular case, and seen which production failure should change the design instead of becoming one more rescue block.

That is useful context for a human, and it is also extremely useful context for an agent. The job starts looking less like “record every keystroke” and more like encoding judgment well enough that both the developer and the coding agent can use it.

That seems like a better product to me.

“But I still read tutorials”

So do I. Again, dead does not mean zero; it means demoted. The static tutorial used to be the whole workflow, and now it is increasingly one input into a larger loop.

I will still read an article to understand a concept, look at documentation for an API, and buy a book from somebody whose thinking I want more of. What I am less willing to do is spend hours manually reproducing an implementation in a disposable sample application before I am allowed to apply the idea to my own code.

That step made sense when there was no other option. Now there is.

The tutorial is being split into two things

Traditional implementation tutorials bundled two jobs together:

1. Teach me what good looks like.
2. Show me enough code that I can reproduce it myself.

Coding agents pull those jobs apart. The human still needs understanding, while the agent can handle much more of the translation and execution.

The useful loop starts looking like this:

expert knowledge
      ↓
developer + coding agent
      ↓
actual codebase

That is a much shorter trip, and it changes what is worth packaging and selling.

The future technical book may still have chapters. The future course may still have video. The future tutorial may still have a code sample. But for implementation-heavy material, I think the complete product increasingly includes something designed to travel with the developer into their coding environment.

Not a magic prompt or “build this for me,” but actual context: decisions, constraints, examples, checks, and a process for applying them to a codebase the author has never seen. That is the part I think we are only starting to figure out.

Programming tutorials are dead

The title is supposed to be annoying. There will still be tutorials tomorrow.

The thing I am calling dead is the assumption that a static walkthrough of somebody else’s implementation is enough. For simple questions, it still is. For real application work, the coding environment changed underneath the medium.

Developers now have agents that can inspect the destination codebase, carry context into the implementation, run the tests, and keep working after the educational material would traditionally have ended. Developer education should probably meet them there.

AI did not make technical expertise worthless. It removed a lot of the manual translation work that used to sit between expertise and implementation. The knowledge still matters; the format has to catch up.

Tags:

• Coding Agents

Your Webhook Endpoint Is a Tiny Distributed System