I love Rails, but after working for a few places with huge Rails codebases and then several other places with .NET and other frameworks with actual typing, I just can't go back to Rails for anything that isn't a personal project.
Working with a large codebase with an untyped codebase is just a nightmare, even with powerful IDEs like RubyMine that are able to cover some of the paint points. I wonder how good Sorbet is these days, though, especially the RoR experience
Thanks for such public confirming there is a lot of more us.
I’m just tired hearing how great ideas will save our overblown pseudo-microservice architecture and I’m also running into some projects during evening that just solve problems without use STOA, unnecessary solutions and architectures.
I’m not into RoR, because I was mainly PHP rescuer in the beginning of my career, but they both are just problem solvers. Sit down, write minimal (in case of PHP not so cool looking) code and proceed to next task.
I've just started using RoR for a live greenfield project since New Year.
Honestly, breath of fresh air.
It's the closest I've come to that old school "in the box" desktop development experience you used to get from building desktop software with Visual Studio or IntelliJ IDEA or NetBeans or Eclipse or any of the other IDEs of the 90s/00s (I never used Delphi or VB but I imagine in some sense they were even moreso than the ones I've listed, which are the ones I used), only it's web development.
For me web development has always felt like a frustrating ordeal of keeping track of 10,000 moving parts that add noise and cognitive load and distract you from fixing the actual problems you're interested in solving. This means the baseline ancillary workload is always frustratingly high. I.e., there's too much yak-shaving.
Whereas Rails seems to drag that all the way down to a level where it feels more similar to the minimal yak-shaving needed to (at least superficially) build, run, and distribute desktop software. Not that this is without its challenges, because every deployment environment is a little different in the desktop world, but the day to day developer experience is much lower friction that modern web development in general.
Also, no sodding TypeScript to deal with. I hate TypeScript: an ugly, verbose, boilerplatey abomination that takes one of the nicest and most fun features of JavaScript (duck typing) and simply bins it off. Awful.
TS doesn't "bin off" duck typing, it's a fundamentally structural type system. It's statically analyzed ducks, all the way down - when nominal behavior is preferred, people have to bend over backwards. Either you are using the wrong vocabulary or I don't think you've bothered to actually learn Typescript. In any case, it's the programming language that successfully brought high-level type system concepts like type algebra, conditional types, etc. to their widest audiences, and it deserves a ton of credit for that. The idea that JS and Ruby and Python and PHP developers would be having fairly deep conversations about how best to model data in a type system was laughable not that long ago.
I love the batteries that RoR or Django gives you, but then I also remember how much time it takes to maintain old projects. Updating a project that was started 5-6 years ago takes a lot of time. Part of that is managing dependencies. For Django, they can easily go above 100. Some of them have to be compiled with specific versions of system libraries. Even Docker does not save you from a lot of problems.
Right now, I would rather use Go with a simple framework, or even without one. With Go, it's so easy just to copy the binary over.
I'm working on a large (at least 300k+ loc) Django code base right now and we have 32 direct dependencies. Mostly stuff like lxml, pillow and pandas. It's very easy to use all the nice Django libs out there but you don't have to.
I was talking about total deps, not direct. By installing something like Celery, you get 8-10 extra dependencies that, in turn, can also have extra deps. And yeah, extra deps can conflict with each other as well.
Sometimes I think the issue here is churn. Security fixes aside, what is it that updated dependencies really give? Can't some of these projects just... stop?
The issue with that is, that the longer you wait to upgrade dependencies, the more pronounced the problems upgrading it will become generally speaking, because more incompatibilities accumulate. If those 5-6 year old projects were updated every now and then, then the pain to get them updated would be far less. As you point out, security is an aspect too, so you can leave the project inactive, but then you might hit that problem.
Dependency hell. Usually how it goes is you have to develop a new feature, you find a library or a newer version of the framework that solves the problem but it depends on a version of another library that is incompatible with the one in your project. You update the conflicting dependency and get 3 new conflicts, and when you fix those conflicts you get 5 new conflicts, and repeat.
"Security fixes aside" is too dismissive. Transitive dependencies with real CVEs can feel like the tail wagging the dog, but ignore them at your peril.
I agree, but let's say you are looking for a library to solve your problem - you see one repo updated 2 weeks ago and the other one updated 5 years ago - which one do you choose?
Do I need a library to sort an array? The 5 years ago option is going to be the more likely choice. A library updated 2 weeks ago is highly suspicious.
Do I need a library to provide timezone information? The 2 weeks ago option, unquestionably. The 5 years ago option will now be woefully out of date.
I think you could only get around this by forcing your whole dependency chain to only add non-breaking security fixes (or backport them for all versions in existence). Otherwise small changes will propagate upwards and snowball into major updates.
I have not had this experience as badly with Laravel. Their libraries seem much more stable to me. We've gone up 5 major versions of Laravel over the last year and a half and it was pretty simple for each major version.
It used to take at least a day of work. In a post-2025/11 world, it is under an hour. Maybe even 15 minutes if you've landed on a high quality LLM session.
My experience has been the opposite, especially since Rails has included more batteries over the years. You need fewer non-Rails-default dependencies than ever, and the upgrade process has gotten easier every major version.
Rails is way more stable and mature these days. Keeping up to date is definitely easier. Probably 10x easier than a Node/JS project which will have far more churn.
I also think it's the opposite, since the dependencies are almost guaranteed to be compatible with each other. And I think Ruby libraries in particular are usually quite stable and maintained for a long time.
My medium-sized Django projects had close to 100 dependencies, and when you want to update to a new Django version, the majority of them must be updated too.
Thankfully, updating to a new Django version is usually simple. It does not require many code changes.
But finding small bugs after an update is hard, unless you have very good test coverage. New versions of middleware/Django plugins often behave slightly differently, and it's hard to keep track of all the changes when you have so many dependencies.
We've been running Rails apps in production continuously since 2007. If you treat software as anything other than completely disposable, it's been a no-brainer for the entire 19+ years I've been paying attention (not despite its age, but because of it).
The premise that you get meaningful efficiencies from JavaScript on the back-end just because you have to use it on the front-end has been pretty thoroughly debunked at this point. Instead you mostly get a larger blast radius when the front-end ecosystem has its monthly identity crisis. OP's "stacks-du-jour" and programming language "flavour of the month" framing is exactly right. A shocking amount of web software architecture is just following fashion trends dressed up as technical decision-making.
Most of the churn in tech stack isn't driven by engineering requirements, it's driven by résumé optimization and Hacker News anxiety. Rails has quietly been powering serious businesses the whole time. Does anyone think NPM's 3.1 million packages enable more functionality than RubyGems' 190,000 packages?
We've also been running Rails in production for 15+ years (since 2011) in two companies and it has been serving us greatly. Hiring is tough, but I definitely believe the stack makes up for it due to the productivity gains.
In late 2025 we decided to migrate one of them to Inertia. Public facing pages is already done, and we're 80% through migrating the logged in area (it's a huge app). We choose Vue.js.
It's amazing how powerful this stack is and how little you have to change in the backend.
The "one-person framework" thing is a big draw. I'm amazed at how productive I was in it, and it's not just at the code level. Even though I've been doing sysadmin/devops/architect work for over 25 years now, it's just so damn nice now not to have to think about e.g. standing up a HA PostgreSQL cluster or Redis and deployment is largely a solved problem.
There are two types of devs: those that ship and those that fill out surveys (and not because their stacks are so much more efficient that they have time to fill out the surveys)
The upgrade story is underrated. I've maintained Next.js projects where major version upgrades broke fundamental patterns (pages router → app router, completely different data fetching). Rails' deprecation-then-removal cycle is slower but way less disruptive. When you're shipping product, stability of the interface you build against matters more than having the latest paradigm.
Switching from Next's pages router to app router (RSCs by default) is a major shift in architecture, practically replatforming. Not to be taken lightly (and an opportune time to consider less-opinionated modern alternatives, like TanStack Start).
I've never used Rails, but I agree upon "the state of the modern landscape". Instead of looking backwards, I tried to look forward, and what I found was Elixir and the Phoenix framework.
You're about the 5th person now in as many days who has recommended Elixir when I mentioned I was building a project in Ruby. I'll definitely have to check it out for my next project (whatever that may be!)
Can you expand on why you found it so appealing or "holy crap, this is awesome" things I should look at first ?
Not the guy, but I used rails at my old job for one and a half year, and used it in some personal projects. I looked into Elixir(and Phoenix) during this time, and Phoenix felt like it was designed for more modern websites, where RoR is built for older and tries to adapt to handle modern ones. It just feels that when you want to do something more responsive in Elixir, it's designed for it, but in Rails, it feels like you're doing something unorthodox or something that is added as an afterthought. Obviously this isn't quite accurate, but it is the vibe I got.
Elixir is also a very cool language in a lot of ways. I wouldn't go all in on Elixir/Phoenix, but that's because there's not a huge demand for it, at least where I reside. I would 100% consider it for some smaller projects though, if I stood between that and Rails, and I wouldn't mind having to get more comfortable with Elixir.
Edit: I haven't used Rails 8, and haven't followed the ecosystem since a bit before, so not sure how this feels nowadays. I *really* enjoy Rails backend though, but the frontend stuff never quite clicked.
Counterpoint on the "going all-in": we have a 7 year old Elixir/Phoenix project that currently sits at ~100K LOC and I couldn't be happier.
It has been absolutely wonderful building this with Elixir/Phoenix. Obviously any codebase in any language can become a tangled mess, but in 7 years we have never felt the language or framework were in our way.
On the contrary: I think Elixir (and Phoenix) have enabled us to build things in a simple and elegant way that would have taken more code, more infrastructure, and more maintenance in other languages/frameworks.
Not OP, but I made the move from Ruby/Rails to Elixir years ago, so I'll try to answer from my perspective.
Elixir is a functional programming language based on the "BEAM", the Erlang VM. We'll get back to the BEAM in a moment, but first: the functional programming aspect. That definitely took getting used to. I remember being _very_ confused in the first few weeks. Not because of the syntax (Elixir is quite Ruby-esque) but because of the "flow" of code.
However, when it clicked, it was immediately clear how easy it becomes to write elegant and maintainable code. There is no global state in Elixir, and using macros for meta-programming are generally not encouraged. That means it becomes very easy to reason about a module/function: some data comes in, a function does something with that data, and some data comes out. If you need to do more things to the data, then you chain multiple functions in a "pipe", just like how you chain multiple bash tools on the command line.
The Phoenix framework applies this concept to the web, and it works very well, because if you think about it: a browser opening a web page is just some data coming in (an HTTP GET request), you do something with that data (render a HTML page, fetch something from your database, ...) and you return the result (in this case as an HTTP response). So the flow of a web request, and your controllers in general, becomes very easy to reason about and understand.
Coming back to the BEAM, the Erlang VM was originally written for large scale (as in, country size) telephony systems by Ericsson. The general idea is that everything in the BEAM is a "process", and the BEAM manages processes and their dependencies/relationships for you. So your database connection pool is actually a bunch of BEAM processes. Multi-threading is built-in and doesn't need any setup or configuration. You don't need Redis for caching, you just have a BEAM process that holds some cache in-memory. A websocket connection between a user and your application gets a separate process. Clustering multiple web servers together is built into the BEAM, so you don't need a complex clustering layer.
The nice thing is that Elixir and Phoenix abstract most of this away from you (although it's very easy to work with that lower layer if you want to), but you still get all the benefits of the BEAM.
Something I never quite understood: differentiate between BEAM process and operating system process. The OS has launched one (in theory) BEAM Erlang VM runtime process with N threads; are we saying “process” here to try to emulate the OS process model internally within the BEAM OS process, when really we’re talking about threads? Or a mix of threads and other processes? I’m imagining the latter even cross network, but am I at least on the right track here?
A BEAM process is not an OS thread. The way I understand it, a BEAM process is just a very small memory space with its own heap/stack, and a message system for communication between BEAM processes.
The BEAM itself runs multiple OS threads (it can use all cores of the CPU if so desired), and the BEAM scheduler gives chunks of processing time to each BEAM process.
This gives you parallel processing out of the box, and because of the networking capabilities of the BEAM, also allows you to scale out over multiple machines in a way that's transparent to BEAM processes.
Rails for straight up CRUD is top, autogenerated things etc
however if your app doesn't fit the standard crud pattern you end just fiddling with a lot of things that you shouldn't and in that case I recommend Django which provides enough flexibility while providing a good base. There's less magic in Django
Serious question, as someone who started his professional developer career as a RoR developer in 2012: Isn't vibe-coding top for straight up CRUD?
I'm not trying to be glib. The thing that seemed magic to me at that time was all the scaffolding that Rails provided with a few simple commands, making it possible to quickly build something that let the user authenticate and enter and display data. Sure, Ruby itself and the culture around it back then was also great and will always have a place in my heart. But the whole convention-over-configuration and scaffolding thing, that was what I liked so much about it, and I never found that in any other language/framework combo in a way that felt as smooth.
But now, I use AI for scaffolding, and for my side-projects often never have to touch code.
So why would I choose something for a CRUD application that might give me headaches down the road, when there's a possibility that the app might morph into something less conventional, when I could use *any* language/framework that's not as rigid and have the scaffold be built by AI?
I get it if you enjoy actually writing code. But I don't quite get the benefits if the goal is to have something working quickly and be able to potentially build it out to something that is not served that well by RoR.
If you're building a pure SaaS app then Rails is perfect. If you need SaaS + more complex backend services like coordinating tons of webhooks I'd choose Elixir. Documentation sites and light server apps I'd use Node.
Go and Rust fill in lots of gaps for more serious performance stuff.
FWIW modern Rails is fairly magic-free also. They learned. With ActiveJob now part of the framework you get event queues/async processing and whatnot as part of the batteries.
I'm a fanboi, so I am biased, but Rails is still pretty great in 2026 for general business purposes.
I had a project I already tried out in Symfony and then full typescript, both a normal REST setup and ORPC. They all felt like - at scale - they became messy and I was unsure where goes what.
I gave RoR a try last year, and so far I'm at the same level I was with the other projects but I actually enjoy programming the project after the PoC phase. Maybe because third time's a charm? Maybe because I know what I need to do? Who knows! But RoR fits in that idiom.
Just to note, its a really boring app thats been done before (odeva.app)
I usually go full Symfony with my projects until I need to spread it out. But even for interactivity, I first go for htmx and Alpine.js instead of full React or so, where I then need to setup API on backend and frontend.
I think once you're deep into a project, you of course know the features needed and the constraints and you'll be more efficient the next time around.
I think the challenge is to keep working on your old legacy projects.
Plus Symfony is quite flexible on how you want to organize your code. Modular monolith, monolith, DDD, microservices, "junior developer just setting up controllers and entities".
Going off topic, but the article made me look into "2025 Stack Overflow Developer Survey" and as usual there is the big difference between what the "Professional Developers" with and without AI claim to be using, and the usual HN discussions "X is taking over the world, no one uses Y anymore".
As for Rails, I guess now that Ruby is serious about having a JIT in the box, a few actually, it is kind of atractive.
Due to my experience with Tcl, and continuous rewriting into C modules, if a JTI isn't in the box, I kind of don't bother unless it is due to external factors.
I love rails and the recent improvements are great.
I have the impression, though, that these days it only appeals to those who picked it up before version 3 or 4, when it was smaller, maybe more understandable, and incredibly better than all the competing frameworks (except Django maybe).
If your first contact with rails is version 7+ and you’re only comfortable with JS/TS, then you’re not going to get it and might actually strongly dislike it
If have a different opinion on this, as I think it's 100x better to learn sql and just write it directly instead of using the dozens of leaky abstraction of some framework.
I mean, I've seen enough "django specialists" to end up with queries doing a dozen of join bombs and producing 10 million rows from dataset of maybe 1000 items. So pretty safe to add "ORM" to your last statement.
> If your first contact with rails is version 7+ and you’re only comfortable with JS/TS, then you’re not going to get it and might actually strongly dislike it
This is the primary issue with Rails in my experience. It takes intentional effort to internalize the idioms before it clicks and you unlock the magic that makes it so insanely productive. JS devs will keep trying to force backend business logic into Franken-React Stimulus components and complaining it's not very good.
we run next.js on the frontend and the page router to app router migration was really painful. rails having stable conventions sounds very good when you go through something like that. I keep thinking about this trade off - move fast with the latest thing or just pick boring tech that works for 5 years.
One thing that is not stressed enough, is Rails enforces good code patterns early on. If you follow the docs, you will know where model code should be, helpers should be, controllers should be. After all, it is an MVC framework.
However, modern day JS frameworks don't care about this at all. Most of them love flaunting about their raw performance numbers. Security? Fuck that. Not even basic form CSRF protection. A lot of times, there is not even SQL injection prevention in them.
Compound this with someone who just vibe codes their app on top of these frameworks - that's how you end up getting hacked. Every week there is an incident. That's why good frameworks like Rails are very important. People who actually care about writing secure, good quality software are on the decline, but thank God rails still exists as an option in 2026 despite the fact.
The difference between JS frameworks and RoR/Laravel is the ecosystem cohesion. RoR and Laravel ecosystems employ the RoR or Laravel way of doing things and everything works together very smoothly.
JS solutions are loosely coupled, lots of good reasons to do so, but comes at a major complexity cost.
Eh, there's NestJs and AdonisJs if you want opinionated MVC with lots of built-ins like CSRF and ORMs.
But you can also pick tight packages that do one thing well. Something like oRPC + Drizzle that lets you pipe data from your database to frontend with full typing and cross-boundary go-to-definition while covering most of what Nest and Adonis do with better focused APIs.
And in terms of security, I'll take Typescript with a strong compiler config anyday. For example, I disable: `any`, non-null asserts (no `!`), floating promises without `void` for explicitness, no unnecessary conditions, and a bunch of other strict rules. I also use Branded Types liberally. All of that makes logical errors that can become app-specific security issues (and are thus less readily detected) much less likely to happen. And as a bonus you get really reliable code too.
Javascript frameworks just do SSR + Express-style api routes. They don't handle SQL injection prevention because they don't deal with databases at all. CSRF prevention is less important in todays world tho.
it's like you're saying SQL injection happens if you're running sql on the client so if it's on the server you're fine.
that's not how it works. and i'm fairly sure most all apps deal with databases, unless they're explicitly static pages.
edit: sql injection is about hacking the parameters used in a query. they almost always in some way come from external sources, user input. so they have to be sanitized. it sounds straightforward but bounties are paid all the time on hackerone with documented cases of injection. people are very clever.
i've had to patch some verified cases where the hacker used the name field to pass code in and alter links in emails to make it look like they came from our (household name) company.
i returned to rails in 2025 after 12 years pause and my experience has been frustration and annoyance
rails lost it's convention over configuration ways, the generated app is dozens of files, lack of explanations and guidance on how to setup various things like environments, kamal being the worst offender and the changes between recent major releases aren't making it any easier to read the (often ai slop) articles and docs
Remember only one programming language delivers developer joy - Ruby.
No other programming language brings developer joy because……. errrr because ……. Well because we are just super certain and confident, that’s why! Oh and DHH said so.
> Accelerate your agents with convention over configuration.
Ruby on Rails scales from PROMPT to IPO. Token-efficient code that's easy for agents to write and beautiful for humans to review
And I fucking hate it. If I read this the first time I would think this is some kind of tool to optimize your LLM agents.
I have been using Rails for over a decade now and always liked the focus on writing beautiful and simple code. On making it easy to reason about with colleagues. Now it seems like DHH is throwing all what made Rails special overboard.
If we are all supposed to be talking to agents now, what's the difference if my agent uses fucking Next, Nuxt, Rails or Django?
Author of the article here (hi! Anxiously watching my Grafana stack right now...)
I've only just noticed that on the Rails homepage, and while I acknowledge everyone's chasing that sweet sweet AI hype, I gotta say that's... disappointing[1]. The reason I fell in love with Ruby (and by extension, Rails) is because it enabled me as a human to express myself through code. Not to become a glorified janitor for a LLM.
[1]=Well, I had a stronger response initially but I toned it down a bit for here...
> Accelerate your agents with convention over configuration. Ruby on Rails scales from PROMPT to IPO. Token-efficient code that's easy for agents to write and beautiful for humans to review
This is so painful... I can't help but wonder who they're trying to target with such inane slogans.
Rails is amazing, but "token-efficiency" is not on the list of reasons why.
There was a post last week about the best programming language for LLMs, and in the comments people loved Go, with the claim being it's very opinionated and there's really only one way of doing things. I'd say the same is mostly true for Rails apps as well.
However having worked with Typescript for 8 years now... I'm not sure I could go back to Ruby without types. For LLMs thats important as well, the more guard rails you can give them the better. What's the state of type checkers today?
TS is very AI native to the point i'd agree it's near magical in terms of contract.
However, the fact its still the js ecosystem with react, thing is even though it's super productive in churning out the code, there's too many possible ways to do something. it's unwieldy.
For example Claude is obsessed with making react context providers. it'll make tons of them to power every feature. and your app will happily hold 20 layers of russian doll'd state in memory with no way to link to anything.
you have to tell it, no don't do that. i need you to power this thing through the router, through the url. and that has to be designed cohesively. and that's very different from the context free-for-all.
Ruby has types with RBS and Steep now. It's a lot like using .d.ts sidecar files alongside JavaScript, via jsconfig.json configuring tsc. I like it a lot!
>The claim seems quite clear to me: "convention over configuration allows coding agents to be more effective".
The agents pick up conventions from the extensive code in their corpus and aggressively follow them. I don't think Rails being explicit about it adds a lot unless someone is prone to prompting towards absurdity.
doesn’t forcing your agent to think in ruby put it at huge disadvantage though? since the language isn’t that popular it can’t have learned it as well as say python or Java?
Python does have a bigger pool of examples, but agents usually get tripped up by missing context about specific frameworks more than by language syntax. The real obstacle for LLMs is understanding Rails' implicit conventions and magic, not the Ruby language itself.
>If we are all supposed to be talking to agents now, what's the difference[...]?
it's a little cringe, but arguably the benefit of having agents use rails would be tht when you review and audit the agent produced code, you review something that is, as you put it: "beautiful and simple code" and "making it easy to reason about..."
I loved rails back in 2017. I may be an outlier but the line tempts me to try it again despite having adopted the who cares attitude to langs. Would be nice to hear from someone first hand if they felt it helped.
Don't worry, it's just the hype phase and it will pass. (By 'pass' I mean agent-coding will be so ubiquitous that it's a given and not worth mentioning.)
both statements are true though. rails excels in the AI world because it's extremely cared for and intentional with language. and there's a ton of built up knowledge.
fwiw that headline is cringey for sure. but DHH has proven himself a great marketer. it very likely is riding the wave.
I love Rails, but after working for a few places with huge Rails codebases and then several other places with .NET and other frameworks with actual typing, I just can't go back to Rails for anything that isn't a personal project.
Working with a large codebase with an untyped codebase is just a nightmare, even with powerful IDEs like RubyMine that are able to cover some of the paint points. I wonder how good Sorbet is these days, though, especially the RoR experience
Are you hand coding?
I used to think ruby/rails was the best way to solve most problems, I still do, but I used to too.
Thanks for such public confirming there is a lot of more us. I’m just tired hearing how great ideas will save our overblown pseudo-microservice architecture and I’m also running into some projects during evening that just solve problems without use STOA, unnecessary solutions and architectures.
I’m not into RoR, because I was mainly PHP rescuer in the beginning of my career, but they both are just problem solvers. Sit down, write minimal (in case of PHP not so cool looking) code and proceed to next task.
I've just started using RoR for a live greenfield project since New Year.
Honestly, breath of fresh air.
It's the closest I've come to that old school "in the box" desktop development experience you used to get from building desktop software with Visual Studio or IntelliJ IDEA or NetBeans or Eclipse or any of the other IDEs of the 90s/00s (I never used Delphi or VB but I imagine in some sense they were even moreso than the ones I've listed, which are the ones I used), only it's web development.
For me web development has always felt like a frustrating ordeal of keeping track of 10,000 moving parts that add noise and cognitive load and distract you from fixing the actual problems you're interested in solving. This means the baseline ancillary workload is always frustratingly high. I.e., there's too much yak-shaving.
Whereas Rails seems to drag that all the way down to a level where it feels more similar to the minimal yak-shaving needed to (at least superficially) build, run, and distribute desktop software. Not that this is without its challenges, because every deployment environment is a little different in the desktop world, but the day to day developer experience is much lower friction that modern web development in general.
Also, no sodding TypeScript to deal with. I hate TypeScript: an ugly, verbose, boilerplatey abomination that takes one of the nicest and most fun features of JavaScript (duck typing) and simply bins it off. Awful.
TS doesn't "bin off" duck typing, it's a fundamentally structural type system. It's statically analyzed ducks, all the way down - when nominal behavior is preferred, people have to bend over backwards. Either you are using the wrong vocabulary or I don't think you've bothered to actually learn Typescript. In any case, it's the programming language that successfully brought high-level type system concepts like type algebra, conditional types, etc. to their widest audiences, and it deserves a ton of credit for that. The idea that JS and Ruby and Python and PHP developers would be having fairly deep conversations about how best to model data in a type system was laughable not that long ago.
What is STOA standing for here, please?
Likely a typo of State Of The Art.
I love the batteries that RoR or Django gives you, but then I also remember how much time it takes to maintain old projects. Updating a project that was started 5-6 years ago takes a lot of time. Part of that is managing dependencies. For Django, they can easily go above 100. Some of them have to be compiled with specific versions of system libraries. Even Docker does not save you from a lot of problems.
Right now, I would rather use Go with a simple framework, or even without one. With Go, it's so easy just to copy the binary over.
I'm working on a large (at least 300k+ loc) Django code base right now and we have 32 direct dependencies. Mostly stuff like lxml, pillow and pandas. It's very easy to use all the nice Django libs out there but you don't have to.
I was talking about total deps, not direct. By installing something like Celery, you get 8-10 extra dependencies that, in turn, can also have extra deps. And yeah, extra deps can conflict with each other as well.
I find the thought daunting but the reality surprisingly easy.
You just keep up as you go, as long as you keep things close to the framework it's fine.
> You just keep up as you go
He said "Updating a project that was started 5-6 years ago takes a lot of time."
Yes but GP said "In reality it's not that much".
Sometimes I think the issue here is churn. Security fixes aside, what is it that updated dependencies really give? Can't some of these projects just... stop?
The issue with that is, that the longer you wait to upgrade dependencies, the more pronounced the problems upgrading it will become generally speaking, because more incompatibilities accumulate. If those 5-6 year old projects were updated every now and then, then the pain to get them updated would be far less. As you point out, security is an aspect too, so you can leave the project inactive, but then you might hit that problem.
Dependency hell. Usually how it goes is you have to develop a new feature, you find a library or a newer version of the framework that solves the problem but it depends on a version of another library that is incompatible with the one in your project. You update the conflicting dependency and get 3 new conflicts, and when you fix those conflicts you get 5 new conflicts, and repeat.
So churn causes more churn.
Also breaking APIs should be regarded very poorly. It isn’t. But it should be.
"Security fixes aside" is too dismissive. Transitive dependencies with real CVEs can feel like the tail wagging the dog, but ignore them at your peril.
I agree, but let's say you are looking for a library to solve your problem - you see one repo updated 2 weeks ago and the other one updated 5 years ago - which one do you choose?
Perhaps some kind of ‘this code is still alive’ flag is key. Even just updating the project. Watching issues. Anything showing ‘active but done’.
That depends. What problem do I have, exactly?
Do I need a library to sort an array? The 5 years ago option is going to be the more likely choice. A library updated 2 weeks ago is highly suspicious.
Do I need a library to provide timezone information? The 2 weeks ago option, unquestionably. The 5 years ago option will now be woefully out of date.
I think you could only get around this by forcing your whole dependency chain to only add non-breaking security fixes (or backport them for all versions in existence). Otherwise small changes will propagate upwards and snowball into major updates.
Indeed that’s what a lot of Elixir and Erlang packages do, if it’s done then it’s done.
I have not had this experience as badly with Laravel. Their libraries seem much more stable to me. We've gone up 5 major versions of Laravel over the last year and a half and it was pretty simple for each major version.
Laravel is extremely stable and consistent.
It used to take at least a day of work. In a post-2025/11 world, it is under an hour. Maybe even 15 minutes if you've landed on a high quality LLM session.
Does batteries included somehow result in upgrading years old projects being a larger lift? I would think the opposite.
My experience has been the opposite, especially since Rails has included more batteries over the years. You need fewer non-Rails-default dependencies than ever, and the upgrade process has gotten easier every major version.
Rails is way more stable and mature these days. Keeping up to date is definitely easier. Probably 10x easier than a Node/JS project which will have far more churn.
I also think it's the opposite, since the dependencies are almost guaranteed to be compatible with each other. And I think Ruby libraries in particular are usually quite stable and maintained for a long time.
My medium-sized Django projects had close to 100 dependencies, and when you want to update to a new Django version, the majority of them must be updated too.
Thankfully, updating to a new Django version is usually simple. It does not require many code changes.
But finding small bugs after an update is hard, unless you have very good test coverage. New versions of middleware/Django plugins often behave slightly differently, and it's hard to keep track of all the changes when you have so many dependencies.
In my experience, the magic makes the easy parts easier and the hard parts harder
We've been running Rails apps in production continuously since 2007. If you treat software as anything other than completely disposable, it's been a no-brainer for the entire 19+ years I've been paying attention (not despite its age, but because of it).
The premise that you get meaningful efficiencies from JavaScript on the back-end just because you have to use it on the front-end has been pretty thoroughly debunked at this point. Instead you mostly get a larger blast radius when the front-end ecosystem has its monthly identity crisis. OP's "stacks-du-jour" and programming language "flavour of the month" framing is exactly right. A shocking amount of web software architecture is just following fashion trends dressed up as technical decision-making.
Most of the churn in tech stack isn't driven by engineering requirements, it's driven by résumé optimization and Hacker News anxiety. Rails has quietly been powering serious businesses the whole time. Does anyone think NPM's 3.1 million packages enable more functionality than RubyGems' 190,000 packages?
We've also been running Rails in production for 15+ years (since 2011) in two companies and it has been serving us greatly. Hiring is tough, but I definitely believe the stack makes up for it due to the productivity gains.
In late 2025 we decided to migrate one of them to Inertia. Public facing pages is already done, and we're 80% through migrating the logged in area (it's a huge app). We choose Vue.js.
It's amazing how powerful this stack is and how little you have to change in the backend.
I've been a Rails DevOps and nowadays a web one-man-show with it for over 10 years and I'd do it again.
Not many frameworks have been thriving that long, and there's good reason.
It packs everything, is tidy and productive, with a pleasant language to read and write.
In the latest Stackoverflow survey, it's back at the "top 5 of desired stacks to use for next project" over a decade after its inception !
Give it a try.
The "one-person framework" thing is a big draw. I'm amazed at how productive I was in it, and it's not just at the code level. Even though I've been doing sysadmin/devops/architect work for over 25 years now, it's just so damn nice now not to have to think about e.g. standing up a HA PostgreSQL cluster or Redis and deployment is largely a solved problem.
And most folks getting stuff done with Rails ain't be filling out surveys to boost their stack - or maybe that's just me.
So everyone just stop worrying what everyone else thinks or seems to think and just use the right tools for you and get on with it
There are two types of devs: those that ship and those that fill out surveys (and not because their stacks are so much more efficient that they have time to fill out the surveys)
Over TWO decades! Rails has been around since 2004, making it just slightly younger than Django.
Rails is definitely older than Django. Django wasn’t released publicly until 2005.
Django had private use before then, but rails was also in private use before it was released.
Rails's public release was July 2004: https://rubytalk.org/t/ann-rails-0-5-0-the-end-of-vaporware/...
Django's was July 2005: https://www.djangoproject.com/weblog/2005/jul/15/chipy/
rails = ruby = oo/mutable && slow && resource hungry
And for a lot of folks that just doesn’t matter. Paying 50 or 100 USD for a server per month won’t be the thing that breaks you.
Before you get to a scale where Rails become a problem you need to have a product that drives a pretty significant engagement, that’s where most fail.
The upgrade story is underrated. I've maintained Next.js projects where major version upgrades broke fundamental patterns (pages router → app router, completely different data fetching). Rails' deprecation-then-removal cycle is slower but way less disruptive. When you're shipping product, stability of the interface you build against matters more than having the latest paradigm.
Switching from Next's pages router to app router (RSCs by default) is a major shift in architecture, practically replatforming. Not to be taken lightly (and an opportune time to consider less-opinionated modern alternatives, like TanStack Start).
I've never used Rails, but I agree upon "the state of the modern landscape". Instead of looking backwards, I tried to look forward, and what I found was Elixir and the Phoenix framework.
You're about the 5th person now in as many days who has recommended Elixir when I mentioned I was building a project in Ruby. I'll definitely have to check it out for my next project (whatever that may be!)
Can you expand on why you found it so appealing or "holy crap, this is awesome" things I should look at first ?
Not the guy, but I used rails at my old job for one and a half year, and used it in some personal projects. I looked into Elixir(and Phoenix) during this time, and Phoenix felt like it was designed for more modern websites, where RoR is built for older and tries to adapt to handle modern ones. It just feels that when you want to do something more responsive in Elixir, it's designed for it, but in Rails, it feels like you're doing something unorthodox or something that is added as an afterthought. Obviously this isn't quite accurate, but it is the vibe I got.
Elixir is also a very cool language in a lot of ways. I wouldn't go all in on Elixir/Phoenix, but that's because there's not a huge demand for it, at least where I reside. I would 100% consider it for some smaller projects though, if I stood between that and Rails, and I wouldn't mind having to get more comfortable with Elixir.
Edit: I haven't used Rails 8, and haven't followed the ecosystem since a bit before, so not sure how this feels nowadays. I *really* enjoy Rails backend though, but the frontend stuff never quite clicked.
Counterpoint on the "going all-in": we have a 7 year old Elixir/Phoenix project that currently sits at ~100K LOC and I couldn't be happier.
It has been absolutely wonderful building this with Elixir/Phoenix. Obviously any codebase in any language can become a tangled mess, but in 7 years we have never felt the language or framework were in our way.
On the contrary: I think Elixir (and Phoenix) have enabled us to build things in a simple and elegant way that would have taken more code, more infrastructure, and more maintenance in other languages/frameworks.
Not OP, but I made the move from Ruby/Rails to Elixir years ago, so I'll try to answer from my perspective.
Elixir is a functional programming language based on the "BEAM", the Erlang VM. We'll get back to the BEAM in a moment, but first: the functional programming aspect. That definitely took getting used to. I remember being _very_ confused in the first few weeks. Not because of the syntax (Elixir is quite Ruby-esque) but because of the "flow" of code.
However, when it clicked, it was immediately clear how easy it becomes to write elegant and maintainable code. There is no global state in Elixir, and using macros for meta-programming are generally not encouraged. That means it becomes very easy to reason about a module/function: some data comes in, a function does something with that data, and some data comes out. If you need to do more things to the data, then you chain multiple functions in a "pipe", just like how you chain multiple bash tools on the command line.
The Phoenix framework applies this concept to the web, and it works very well, because if you think about it: a browser opening a web page is just some data coming in (an HTTP GET request), you do something with that data (render a HTML page, fetch something from your database, ...) and you return the result (in this case as an HTTP response). So the flow of a web request, and your controllers in general, becomes very easy to reason about and understand.
Coming back to the BEAM, the Erlang VM was originally written for large scale (as in, country size) telephony systems by Ericsson. The general idea is that everything in the BEAM is a "process", and the BEAM manages processes and their dependencies/relationships for you. So your database connection pool is actually a bunch of BEAM processes. Multi-threading is built-in and doesn't need any setup or configuration. You don't need Redis for caching, you just have a BEAM process that holds some cache in-memory. A websocket connection between a user and your application gets a separate process. Clustering multiple web servers together is built into the BEAM, so you don't need a complex clustering layer.
The nice thing is that Elixir and Phoenix abstract most of this away from you (although it's very easy to work with that lower layer if you want to), but you still get all the benefits of the BEAM.
Something I never quite understood: differentiate between BEAM process and operating system process. The OS has launched one (in theory) BEAM Erlang VM runtime process with N threads; are we saying “process” here to try to emulate the OS process model internally within the BEAM OS process, when really we’re talking about threads? Or a mix of threads and other processes? I’m imagining the latter even cross network, but am I at least on the right track here?
A BEAM process is not an OS thread. The way I understand it, a BEAM process is just a very small memory space with its own heap/stack, and a message system for communication between BEAM processes.
The BEAM itself runs multiple OS threads (it can use all cores of the CPU if so desired), and the BEAM scheduler gives chunks of processing time to each BEAM process.
This gives you parallel processing out of the box, and because of the networking capabilities of the BEAM, also allows you to scale out over multiple machines in a way that's transparent to BEAM processes.
Rails for straight up CRUD is top, autogenerated things etc
however if your app doesn't fit the standard crud pattern you end just fiddling with a lot of things that you shouldn't and in that case I recommend Django which provides enough flexibility while providing a good base. There's less magic in Django
Serious question, as someone who started his professional developer career as a RoR developer in 2012: Isn't vibe-coding top for straight up CRUD?
I'm not trying to be glib. The thing that seemed magic to me at that time was all the scaffolding that Rails provided with a few simple commands, making it possible to quickly build something that let the user authenticate and enter and display data. Sure, Ruby itself and the culture around it back then was also great and will always have a place in my heart. But the whole convention-over-configuration and scaffolding thing, that was what I liked so much about it, and I never found that in any other language/framework combo in a way that felt as smooth.
But now, I use AI for scaffolding, and for my side-projects often never have to touch code.
So why would I choose something for a CRUD application that might give me headaches down the road, when there's a possibility that the app might morph into something less conventional, when I could use *any* language/framework that's not as rigid and have the scaffold be built by AI?
I get it if you enjoy actually writing code. But I don't quite get the benefits if the goal is to have something working quickly and be able to potentially build it out to something that is not served that well by RoR.
If you're building a pure SaaS app then Rails is perfect. If you need SaaS + more complex backend services like coordinating tons of webhooks I'd choose Elixir. Documentation sites and light server apps I'd use Node.
Go and Rust fill in lots of gaps for more serious performance stuff.
FWIW modern Rails is fairly magic-free also. They learned. With ActiveJob now part of the framework you get event queues/async processing and whatnot as part of the batteries.
I'm a fanboi, so I am biased, but Rails is still pretty great in 2026 for general business purposes.
Ruby on Rails and Laravel all the way. Solid, proven, stable and scalable.
I had a project I already tried out in Symfony and then full typescript, both a normal REST setup and ORPC. They all felt like - at scale - they became messy and I was unsure where goes what.
I gave RoR a try last year, and so far I'm at the same level I was with the other projects but I actually enjoy programming the project after the PoC phase. Maybe because third time's a charm? Maybe because I know what I need to do? Who knows! But RoR fits in that idiom.
Just to note, its a really boring app thats been done before (odeva.app)
I usually go full Symfony with my projects until I need to spread it out. But even for interactivity, I first go for htmx and Alpine.js instead of full React or so, where I then need to setup API on backend and frontend.
I think once you're deep into a project, you of course know the features needed and the constraints and you'll be more efficient the next time around.
I think the challenge is to keep working on your old legacy projects.
Plus Symfony is quite flexible on how you want to organize your code. Modular monolith, monolith, DDD, microservices, "junior developer just setting up controllers and entities".
Article nicely written, great overview of Rails current state. Kudos to the author.
Going off topic, but the article made me look into "2025 Stack Overflow Developer Survey" and as usual there is the big difference between what the "Professional Developers" with and without AI claim to be using, and the usual HN discussions "X is taking over the world, no one uses Y anymore".
As for Rails, I guess now that Ruby is serious about having a JIT in the box, a few actually, it is kind of atractive.
Due to my experience with Tcl, and continuous rewriting into C modules, if a JTI isn't in the box, I kind of don't bother unless it is due to external factors.
> As for Rails, I guess now that Ruby is serious about having a JIT in the box, a few actually, it is kind of atractive.
Not until they get their gradual typing story straight.
Depends on how much one likes the Smalltalk, SELF or Lisp development experience, regarding types.
Great post, this has also been my experience in the past 2 years. Rails is just a lot of fun, and that’s especially important for side projects.
I’m usually a Go person and love it, but building simple crud routes is not the fun part of it.
it is also very token efficient in nowadays modern AI driven development[^1]. I wish more people would renown ruby/rails
[^1]: https://github.com/mame/ai-coding-lang-bench?tab=readme-ov-f...
I love rails and the recent improvements are great.
I have the impression, though, that these days it only appeals to those who picked it up before version 3 or 4, when it was smaller, maybe more understandable, and incredibly better than all the competing frameworks (except Django maybe).
If your first contact with rails is version 7+ and you’re only comfortable with JS/TS, then you’re not going to get it and might actually strongly dislike it
I'd say that if you're first encounter with rails is version 8+ -- it's a lot easier to use than previous versions.
Partly because the handling of JavaScript is much less bespoke and complex.
I now also believe that at least Active Record is much easier to use than Django's ORM
Doesn't matter when devs just slop out 400 lines of SQL and bypass the ORM.
Frameworks and structure will save you from neither stupidity nor ignorance.
If have a different opinion on this, as I think it's 100x better to learn sql and just write it directly instead of using the dozens of leaky abstraction of some framework.
That has always been the case, why would it be different now? Easy to flag and spot in code review.
Boy, I sure wish I had the opportunity to review codebases before inheriting them for maintenance...
I get your point but this is neither a Rails, nor an AI problem and as old as time.
I mean, I've seen enough "django specialists" to end up with queries doing a dozen of join bombs and producing 10 million rows from dataset of maybe 1000 items. So pretty safe to add "ORM" to your last statement.
> If your first contact with rails is version 7+ and you’re only comfortable with JS/TS, then you’re not going to get it and might actually strongly dislike it
This is the primary issue with Rails in my experience. It takes intentional effort to internalize the idioms before it clicks and you unlock the magic that makes it so insanely productive. JS devs will keep trying to force backend business logic into Franken-React Stimulus components and complaining it's not very good.
we run next.js on the frontend and the page router to app router migration was really painful. rails having stable conventions sounds very good when you go through something like that. I keep thinking about this trade off - move fast with the latest thing or just pick boring tech that works for 5 years.
nextjs pages -> app router is a massive change: new paradigm, practically replatforming.
One thing that is not stressed enough, is Rails enforces good code patterns early on. If you follow the docs, you will know where model code should be, helpers should be, controllers should be. After all, it is an MVC framework.
However, modern day JS frameworks don't care about this at all. Most of them love flaunting about their raw performance numbers. Security? Fuck that. Not even basic form CSRF protection. A lot of times, there is not even SQL injection prevention in them.
Compound this with someone who just vibe codes their app on top of these frameworks - that's how you end up getting hacked. Every week there is an incident. That's why good frameworks like Rails are very important. People who actually care about writing secure, good quality software are on the decline, but thank God rails still exists as an option in 2026 despite the fact.
The difference between JS frameworks and RoR/Laravel is the ecosystem cohesion. RoR and Laravel ecosystems employ the RoR or Laravel way of doing things and everything works together very smoothly.
JS solutions are loosely coupled, lots of good reasons to do so, but comes at a major complexity cost.
I agree. Opinionated frameworks are better in this regard.
Give AdonisJS a try, it's pretty much the JS sibling of Laravel and RoR.
Adonis is nice, but still young and lacking features. And in my experience very verbose compared to rails.
That said, absolutely worth a look.
Thanks! Never heard of it, definitely will check it out.
Eh, there's NestJs and AdonisJs if you want opinionated MVC with lots of built-ins like CSRF and ORMs.
But you can also pick tight packages that do one thing well. Something like oRPC + Drizzle that lets you pipe data from your database to frontend with full typing and cross-boundary go-to-definition while covering most of what Nest and Adonis do with better focused APIs.
And in terms of security, I'll take Typescript with a strong compiler config anyday. For example, I disable: `any`, non-null asserts (no `!`), floating promises without `void` for explicitness, no unnecessary conditions, and a bunch of other strict rules. I also use Branded Types liberally. All of that makes logical errors that can become app-specific security issues (and are thus less readily detected) much less likely to happen. And as a bonus you get really reliable code too.
Javascript frameworks just do SSR + Express-style api routes. They don't handle SQL injection prevention because they don't deal with databases at all. CSRF prevention is less important in todays world tho.
it's like you're saying SQL injection happens if you're running sql on the client so if it's on the server you're fine.
that's not how it works. and i'm fairly sure most all apps deal with databases, unless they're explicitly static pages.
edit: sql injection is about hacking the parameters used in a query. they almost always in some way come from external sources, user input. so they have to be sanitized. it sounds straightforward but bounties are paid all the time on hackerone with documented cases of injection. people are very clever.
i've had to patch some verified cases where the hacker used the name field to pass code in and alter links in emails to make it look like they came from our (household name) company.
i returned to rails in 2025 after 12 years pause and my experience has been frustration and annoyance
rails lost it's convention over configuration ways, the generated app is dozens of files, lack of explanations and guidance on how to setup various things like environments, kamal being the worst offender and the changes between recent major releases aren't making it any easier to read the (often ai slop) articles and docs
Remember only one programming language delivers developer joy - Ruby.
No other programming language brings developer joy because……. errrr because ……. Well because we are just super certain and confident, that’s why! Oh and DHH said so.
The main line on the Rails website now reads:
> Accelerate your agents with convention over configuration. Ruby on Rails scales from PROMPT to IPO. Token-efficient code that's easy for agents to write and beautiful for humans to review
And I fucking hate it. If I read this the first time I would think this is some kind of tool to optimize your LLM agents.
I have been using Rails for over a decade now and always liked the focus on writing beautiful and simple code. On making it easy to reason about with colleagues. Now it seems like DHH is throwing all what made Rails special overboard.
If we are all supposed to be talking to agents now, what's the difference if my agent uses fucking Next, Nuxt, Rails or Django?
Author of the article here (hi! Anxiously watching my Grafana stack right now...)
I've only just noticed that on the Rails homepage, and while I acknowledge everyone's chasing that sweet sweet AI hype, I gotta say that's... disappointing[1]. The reason I fell in love with Ruby (and by extension, Rails) is because it enabled me as a human to express myself through code. Not to become a glorified janitor for a LLM.
[1]=Well, I had a stronger response initially but I toned it down a bit for here...
> Accelerate your agents with convention over configuration. Ruby on Rails scales from PROMPT to IPO. Token-efficient code that's easy for agents to write and beautiful for humans to review
This is so painful... I can't help but wonder who they're trying to target with such inane slogans.
Rails is amazing, but "token-efficiency" is not on the list of reasons why.
> This is so painful... I can't help but wonder who they're trying to target with such inane slogans.
Typical DHH insanity.
> This is so painful... I can't help but wonder who they're trying to target with such inane slogans.
The people who think that spicy autocomplete actually has an understanding of the slop it's churning out for them.
Those people don't choose frameworks. It'll be chosen for them by some LLM and given the prevalence of JS, it'll likely be some flavor of React.
> what's the difference if my agent uses fucking Next, Nuxt, Rails or Django?
The claim seems quite clear to me: "convention over configuration allows coding agents to be more effective".
But yes, I do agree that the main line should say what Ruby on Rails actually is, not why it's good for your agent.
There was a post last week about the best programming language for LLMs, and in the comments people loved Go, with the claim being it's very opinionated and there's really only one way of doing things. I'd say the same is mostly true for Rails apps as well.
However having worked with Typescript for 8 years now... I'm not sure I could go back to Ruby without types. For LLMs thats important as well, the more guard rails you can give them the better. What's the state of type checkers today?
TS is very AI native to the point i'd agree it's near magical in terms of contract.
However, the fact its still the js ecosystem with react, thing is even though it's super productive in churning out the code, there's too many possible ways to do something. it's unwieldy.
For example Claude is obsessed with making react context providers. it'll make tons of them to power every feature. and your app will happily hold 20 layers of russian doll'd state in memory with no way to link to anything.
you have to tell it, no don't do that. i need you to power this thing through the router, through the url. and that has to be designed cohesively. and that's very different from the context free-for-all.
Ruby has types with RBS and Steep now. It's a lot like using .d.ts sidecar files alongside JavaScript, via jsconfig.json configuring tsc. I like it a lot!
Personally I love rust for agents because of types. In the ruby world there's sorbet and rbs so would be interesting to try that.
>The claim seems quite clear to me: "convention over configuration allows coding agents to be more effective".
The agents pick up conventions from the extensive code in their corpus and aggressively follow them. I don't think Rails being explicit about it adds a lot unless someone is prone to prompting towards absurdity.
doesn’t forcing your agent to think in ruby put it at huge disadvantage though? since the language isn’t that popular it can’t have learned it as well as say python or Java?
Python does have a bigger pool of examples, but agents usually get tripped up by missing context about specific frameworks more than by language syntax. The real obstacle for LLMs is understanding Rails' implicit conventions and magic, not the Ruby language itself.
Claude munches through Ruby just fine, all day long.
The frontier models all handle Ruby just fine. So does th cheap Chinese models like Mini, Qwen, Deepseek.
>If we are all supposed to be talking to agents now, what's the difference[...]?
it's a little cringe, but arguably the benefit of having agents use rails would be tht when you review and audit the agent produced code, you review something that is, as you put it: "beautiful and simple code" and "making it easy to reason about..."
I loved rails back in 2017. I may be an outlier but the line tempts me to try it again despite having adopted the who cares attitude to langs. Would be nice to hear from someone first hand if they felt it helped.
I thought you were joking so I went to check it myself and... unfortunately you were not. That is insane.
Don't worry, it's just the hype phase and it will pass. (By 'pass' I mean agent-coding will be so ubiquitous that it's a given and not worth mentioning.)
Oh boy. I can't even imagine what sort of hell an AI could unleash on a language as dynamic and magical as Ruby...
both statements are true though. rails excels in the AI world because it's extremely cared for and intentional with language. and there's a ton of built up knowledge.
fwiw that headline is cringey for sure. but DHH has proven himself a great marketer. it very likely is riding the wave.
That is just DHH (/37signals) being expert(s) at positioning.
Trying to answer the question of, why is language and framework still relevant in a world where almost everyone uses an agent for coding?