I mentor at 42 Warsaw, and the question students and founders ask has updated itself, from “what stack should I learn” to “does the stack even matter now that agents write the code?” It matters more, and the reasoning points somewhere unfashionable.
Twenty years ago Rails made a specific bet: that the scarce resource is people, so the framework should maximize what one person can ship. Convention over configuration, batteries included, one way to do most things, the majestic monolith. The industry spent a decade calling that quaint while assembling teams of specialists around JavaScript build pipelines. Then agents arrived, and the economics flipped back with interest, because AI coding multiplies precisely the quantity Rails was designed to maximize: leverage per person.
Agents are convention-followers, and Rails is conventions all the way down
Here’s the mechanism rather than the vibe. An agent writes good code in your repo when two things hold: its training distribution contains many consistent examples of the patterns you want, and your repo tells it unambiguously which patterns those are. Rails is unusually strong on both.
Two decades of “the Rails way” left the training data with mountains of applications structured the same way (models in app/models, the same callbacks, the same REST shapes) instead of a thousand competing approaches. When the codebase is effectively the prompt, a convention-dense ecosystem is a clean prompt by default. Compare an ecosystem whose blessed patterns changed three times in five years: the training data holds every era’s idioms side by side, and agents demonstrably mix them, conjuring last year’s pattern into this year’s framework version.
And where the conventions need to be yours, Rails culture made writing them down normal long before AI gave the practice teeth. Making conventions enforceable was the single thing that turned agents reliable for me, and we keep ours public. The harness that lets two part-time people ship a production app daily (our count, one product) is built around a Rails codebase, and not by accident. A framework with one blessed way to do things is a framework an agent can be held to.
Fewer seams, fewer places to get lost
The startup version of the argument is about surface area. A Rails monolith with Hotwire gives you one codebase, one deploy, one mental model, web and mobile included. FastTravel’s driver app is a Rails app via Hotwire Native, shipping from the same codebase that runs the kiosks, and that’s a production system at every major airport in Norway, not a demo. Every seam you don’t have (the separate frontend app, the API layer between your own two halves, the second deploy pipeline) is a seam where agents and humans alike get lost, and a seam you don’t pay for in coordination.
For a founder, count what that buys before the first hire: you need one product engineer rather than a department, and the whole product still fits in one head. DHH called Rails the one-person framework. Agents took that from slogan to operating reality, and the one person now mostly reviews.
The boring-stack dividend nobody prices in
Startups die of complexity they chose voluntarily. Every fashionable architecture decision (the microservices, the bespoke frontend constellation, the database that was a conference talk) spends from the same complexity budget that your actual growth will need later. Rails is the maximally boring choice, in the sense where boring means your surprises come from your customers instead of your stack. In the AI era the dividend doubles: a boring stack is also the one your agents misunderstand least.
Where the answer honestly isn’t Rails
If your core product is a model or heavy ML pipeline, the gravity of Python will win and should. If you’re chasing latency floors or throughput ceilings most products never meet, you already know who you are. If your product genuinely is its frontend (a design tool, a game, an editor), a JavaScript-native stack puts the complexity where your product lives, which is where it belongs. If your technical co-founder already lives in TypeScript and ships fast there, momentum beats theory; a stack argument that costs you your best person’s velocity has missed the point. Hotwire Native has limits too: it covers most products honestly, but an animation-heavy consumer app or an offline-first tool belongs in native or React Native hands. And hiring gravity is real: in some cities the TypeScript pool is ten times deeper. Agents are quietly shrinking how much that matters, though, since the constraint moves from hands available to judgment available.
For everything else, which is most startups (a product, users, money moving, a deadline), the calculation in 2026 favors Rails more than it did in 2016, not less. The framework was always optimized for the smallest possible team shipping the most possible product. That used to mean a team of three punching like ten. With agents on a convention-dense stack, the same bet pays out at a different scale, and we’re living the proof daily. Boring, it turns out, was the moat.