Nobody sat down and planned Ruby on Rails. DHH was frustrated. He was building Basecamp, saw how much boilerplate and ceremony contemporary web frameworks required, and thought: this is stupid. There has to be a better way. So he built one.

That frustration gave us a framework that changed how an entire generation thought about building for the web. Convention over configuration. Developer happiness as a design principle. A single opinionated answer where the industry had offered a hundred agonizing choices. I’ve been building web applications since the late nineties, and I remember what it felt like when Rails appeared. It wasn’t about speed, it was about a different philosophy.

Here’s what worries me: I’m not sure that framework gets built today.

Not because the people aren’t talented enough. But because AI-assisted development is making the current way of building things feel just comfortable enough that nobody bothers to get properly frustrated anymore.

Frustration Is a Feature

Think about where the tools we rely on actually come from. React didn’t emerge from a conference room brainstorm at Facebook: it came from engineers hitting a wall. DOM manipulation at scale was a nightmare, and the existing answers weren’t working. Somebody got fed up and rethought the model from scratch.

Vite exists because Evan You got tired of waiting for Webpack to compile. Bun exists because Jarred Sumner wanted a faster JavaScript runtime. Next.js, Tailwind, Hotwire: every one of these started with someone staring at their screen, annoyed, thinking: why does this have to be so painful?

That annoyance is the engine of progress in web development. Not academic research or product roadmaps, but frustration. The lived experience of building something, running into the same wall over and over, and finally deciding to tear it down instead of working around it.

AI doesn’t experience frustration. It doesn’t wait 45 seconds for a hot reload and think: I’ve had enough of this. It doesn’t feel the drag of configuring the same authentication flow for the twentieth time. It just does what you ask, as fast as it can, within whatever paradigm you’re already using.

Optimizing the Status Quo

Let me be clear: I’m not anti-AI. I use it daily, and it’s spectacular at making me more productive within the tools and frameworks I already know. For execution within a known paradigm, it’s the best assistant I’ve ever had.

But that’s exactly the problem. AI makes the current paradigm so comfortable that the motivation to question it evaporates. Why rethink your stack when your AI pair programmer just made your existing stack feel effortless? Why endure the pain of building something new from the ground up when the pain has been anaesthetized?

Right now, somewhere, there’s a developer building a web application who’s running into a fundamental limitation of how we currently handle state management, or routing, or server-client communication. Ten years ago, that developer would have hit that wall hard enough to start sketching an alternative on a napkin. Today, they prompt an LLM, get a clever workaround within the existing framework, and move on.

The Depth Problem

There’s a second, quieter risk. The breakthroughs I described above didn’t just require frustration. They required deep understanding of what was happening under the hood. DHH understood the Java ecosystem well enough to know exactly what was wrong with it. Evan You understood Webpack’s internals well enough to see where the architecture itself was the bottleneck, not just the configuration.

When developers increasingly generate code through AI, they spend less time in the internals. The abstraction layer gets thicker, and the number of people who truly understand what’s underneath gets smaller.

I’ve seen this pattern before. When I wrote about the Ruby community over thirteen years ago, I worried about an influx of developers who used Rails without understanding Ruby, treating the framework as a black box. AI accelerates that tendency by orders of magnitude. It’s not just one framework becoming a black box, but the entire stack.

Fewer people with deep understanding means fewer people equipped to see where the paradigm is broken. And if nobody sees it, nobody fixes it.

Will AI Innovate for Us?

This is where I keep landing when I think it through: will LLMs eventually figure this out themselves? I don’t think so. At least not in the way that matters. Current AI models are exceptional at recombining existing patterns. They can produce novel-looking solutions by mixing and matching what they’ve been trained on. But sometimes, we don’t need a recombination, but a paradigm rejection. Someone who looks at the existing approach and says: the premise itself is wrong, let’s start over.

LLMs are trained on what exists. They’re a reflection of our current thinking, compressed and accelerated. If nobody writes the next Rails, there’s nothing for the next generation of models to learn from. The training data doesn’t update itself; we do.

Stop Medicating the Pain Away

I’m not predicting doom. AI-assisted development is here to stay, and it’s making all of us more productive. That’s real and valuable.

But I think we’re sleepwalking into a subtle trap. We’re building an ecosystem where execution is effortless and invention is no one’s job. The web development world won’t stop, but it could plateau. And the strange thing about a plateau is that it feels like a peak when you’re standing on it.

I don’t have a neat solution, but I think it starts with noticing and paying attention to your frustrations. When something feels fundamentally wrong about how you’re building, don’t just ask the AI to work around it. Sit with it. Dig into why. That discomfort might be the most valuable thing you have.

The next Rails won’t come from a prompt. It’ll come from someone who’s annoyed enough to ignore the easy answer.