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.
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 looked a lot like what I was already seeing, and like how I was already behaving as a developer.
I am part of the problem.
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:
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.
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.
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.
The title needs an asterisk. 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.
The format starts to break down once the problem looks like a real production application. The less pristine the real app is, the less useful a pristine sample app becomes.
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.
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.
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.
Agentic coding also 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.
The experienced developer uses that context to save time. The newer developer uses it to borrow judgment they have not built yet.
This is where I think the product itself has to change. 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.
The human still needs:
- the mental model
- the tradeoffs
- the architecture
- the reasoning
- the failure modes
- the vocabulary needed to review the result
The coding agent needs:
- 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
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.
The business part is uglier. 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 thing to compete with. 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, tradeoffs, constraints, and context from somebody who has actually dealt with the problem.
The economics around free educational content get awkward too. 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.
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.
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.
So do I. I still read articles to understand concepts, look up APIs, and buy books from people whose thinking I want more of.
What I am much less willing to do is spend hours manually reproducing an implementation in a disposable sample app before I can apply the idea to my own code.
That is what I mean by dead here: the tutorial is not gone, but it is not the whole workflow anymore.
Traditional implementation tutorials bundled two jobs together:
- Teach me what good looks like.
- 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:
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.
The title is supposed to be annoying. There will still be tutorials tomorrow.
What I am calling dead is the assumption that a static walkthrough of somebody else’s implementation is enough for a lot of real application work. Agents can inspect the destination codebase, carry context into the implementation, run the tests, and keep working after the tutorial would traditionally have ended.
The expertise still matters. I just do not want it to stop at a sample app anymore.