> 37signals differentiates their products with opinionated UI/UX, not novel features. They are rewriting Hey as six native apps because the web fidelity isn’t good enough. So UI matters enough to justify complete rewrites, but also everyone just wants CLIs?
I've seen this one a few times lately. People should stop building UIs, nobody wants to interact with a UI. Everyone's app should just be an API that you can use with a chatbot. Except for my app — my app is a handcrafted miracle of artisanal UX and its UI will change the way you see the world.
It's exactly the old argument, just now with LLMs in the place of shell pipelines: in terms of functionality and value to users, software ought to be malleable and composable. We've known it since the eighties. But the model of selling a piece of software as a product as if it were a pair of shoes is incompatible with that. You need a big monolithic application to justify users paying a bunch of money for it, and you need it to have a fancy interface that makes an impression. And the whole software industry is built on top of that model. Where monolithic software is completely unfit for a purpose, like when it needs to be a component of a larger system, we rely on (mostly unpaid) OSS.
Except now LLMs let you, with very little technical know-how, plaster a ‘programmable’ interface on top of unstructured data/interface meant for humans, and because that's what we actually want, of course everybody does that. So the end result is a wildly expensive pipeline from API to UI and back to API again. I wonder how long the legacy ‘human-oriented’ layer in the middle, and the industry that's been built on top of it, will last.
(Separately, chatbots are not great as a UI for most things, and the problem of building the universal UI still also stands. But it turns out for a lot of things people would rather have a bad universal UI than a good special-purpose UI for each task.)
Words are a great UI. They can be easily converted into audio and haptics. We already have many systems in place that do exactly this with words.
Sure, pretty graphics are nice, but their sole intent should be to convey information. A User Interface that does not allow a person to easily have information conveyed to them is a bad interface.
The modern AI world isn’t perfect, but for a large portion of people who have accessibility needs, it’s absolutely a positive impact on their life in a way that no single technology has been until now.
I think LLMs may actually help us get to CLI/API driven development. At least, that has been my experience.
Even though most of my projects have a UI, I build a CLI/API version so that the LLM can interact with it directly. I have been using this "CLI driven development" approach for more than a year now and have had fantastic results. The CLI arguments make it easy for LLM to interact with software it wrote.
I usually ask LLM to build a lib, then expose as a CLI and a RESTful API.
I think chat is a great entry point for many experiences. The approachability and flexibility are unmatched.
A question becomes, how do you evolve a chat experience to task specific actions?
I’m building an app to explore scripture. Chat is an amazing starting point. But it’s terrible once you get into reading the actual scripture.
I think we will see more of this in the future. Here is how I’ve envisioned evolving an experience out of chat. Curious if others have their own ideas.
For me personally, the effort to type on a mobile phone is too much. If I can't complete an interaction with maybe two sentences, I much much prefer typing on a computer, and if required, copy everything over.
>Everyone's app should just be an API that you can use with a chatbot.
I see this sentiment a lot, but UI has a greater purpose than just serving the customer needs, it also be used to shape them.
Imagine if instead of going to the grocery store, you called a number and told them what you needed. Sometimes you don't know everything you need. Sometimes you end up discovering something new and buying it even if you didn't plan on it.
> Except now LLMs let you, with very little technical know-how, plaster a ‘programmable’ interface on top of unstructured data/interface meant for humans, and because that's what we actually want, of course everybody does that.
I don't think that is what everyone wants, or at the very least its not what I want. My ideal software has a well designed and thought through user interface for the primary interactions, allowing me to think about the goal I'm trying to achieve rather than how I'm manipulating the underlying data model.
Additionally to that please also provide access to the underlying data. Ideally in the form of a locally accessible API but I'll accept a remote one if necessary, provide a CLI on top of that as well if you like.
> I've seen this one a few times lately. People should stop building UIs, nobody wants to interact with a UI. Everyone's app should just be an API that you can use with a chatbot.
Same happened when the first smartphones came out, and everything was about "mobile first". Everyone will use their mobile phones for everything, desktop is dead, every app should be primarily designed for smartphones, everything comes after. Turned out smartphones just another interface that are good for some things, and not good for some other. Same for the "cloud native" movement.
1. This is why BDFL culture in open source is bad. Because if the BDFL decides to go all in on some completely bizarre mess, all of a sudden there’s massive fork politics.
2. Hey is the marquee product now?? Does anyone actually use Hey? I tried it for a year, and basically found I was paying for the privilege of having a slower, buggier, less feature-rich gmail that can’t even dent the have-a-paid-email-that-doesn’t-exploit-you market (Fastmail and Proton exist, yo).
The only people I know still using Hey are doing so because there's no way to move your address elsewhere. It's a PITA to change your email everywhere (and some unfortunate place don't let you; e.g. email as the login and primary key)
As an SRE I would be very interested on experienced devs point of view on that stance, "we don’t even necessarily need to read the code the LLMs produce". To me, that is the only way a single dev can manage > 1 agent. Because I feel running the code will always be slower than a single agent generating it. On the other hand, it implies lack of human understanding on what is going on under the hood. Which is fine if you trust the LLM to write great code, and great tests for the code, but fundamentally you have to have 100% trust, 99.9% is not going to be enough in any serious industry, would it ?
Also eventually you'll also have to trust it to write the deployment code or even run the deployment itself, otherwise SRE is going to be the bottleneck. And only then should I feel anxiety about the rest of my career (that, or my employer decide LLM are good enough to get rid of me, even if they are imperfect).
We are many of us now engaged in a big experiment to see just how little you can read the code, and for how long. Considering the consensus is that we have still not yet passed the 1 year anniversary of agents getting good, it feels too early to say how it will play out. But there are a lot of market forces working to make it happen.
> Which is fine if you trust the LLM to write great code, and great tests for the code, but fundamentally you have to have 100% trust, 99.9% is not going to be enough in any serious industry, would it ?
This is lacking a lot of nuance. There are many types of code. There are many situations where I'm analysing something one-off and if I get 33% success ratio, but can easily verify the result, I'm happy - still saved me time and money. They're are situations where I'm generating graphs from some dataset and I don't have to trust anything - I know what the result should look like, I just need the agent to drive matplotlib. There are low stakes dashboards which I'm happy to generate and develop entirely via agents - they'll embed the updated screenshots in PRs that I can yolo-merge - worst case is that someone complains about something not working next time they visit. Then there's lots of experimenting which was never stopped to hit production anyway.
Finally after all of that you get code that's actually part of deployable features. Of course the trust is nowhere near 100%, but if you have a healthy testing process (e2e, validating different browsers, or whatever is appropriate for your environment), then what's your trust in human developer+review? Because mine is nowhere near 100% either.
In practice there are places where I extremely don't care about the code and never wanted it anyway, places where I'll read the code to check the design or just in case, and places which agents are not allowed to touch (medical billing rules for example).
Not trying to be a jerk but at this point SRE is my main use case for heavy LLM stuff. It's pretty awesome at that. Deployments and CI pipelines have become a breeze. I used to have to ask DevOps for that and wait days. I have even let agents run deployments for side projects and they seem to do better work than most humans I've worked with. It's wild they will actually read all the logs and debug problems so fast. Not something we could ever keep up with.
The actual code and architecture is where it still lacking IMHO. Especially in rails... Like it will just build the least scalable features if you let it do it's thing. Ten queries for what could be one. No separation of concerns. Huge files, lots of duplicated code and then tens of thousands of units tests that just grow like a fatberg.
If your app does anything serious, if you have serious traffic... you are going to need to review each session finely (and your DB schema with each deploy). It could be that this is maybe an indictment of rails more than LLMs, I guess maybe time will tell.
Writing deployment manifests and CI pipelines is not really the core part of "SRE" to me: it's more related to how you run software in production, not the build/test process to get it there.
If you don't look at your code and need to debug a production issue, do you just panic chat with your agent to solve the problem?
I guess it all depends on context, where I work ops stuff is clearly the bottleneck for a variety of reasons (technical debt that we are constantly working around, secret management for compliance reasons, etc). We self-host everything from bare metal. Some people would need to rethink the infra from the bottom up before it is "LLM ready".
That doesn't mean my job is not threatened mid/long term, in fact, thanks to LLM it is possible to rebuild that in a reasonnable amount of time I think. It's actually one of my side projects to offer this as a service. But if that doesn't work maybe I should have a plan C.
> Because I feel running the code will always be slower than a single agent generating it.
That is very not true for many cases. Agents generating code are usually painfully slow, finding workflows that replace that reasoning with running code usually speed things up in my experience.
I code and maintain a Rails stack. About 20% of the time an endpoint takes to respond is spent in Ruby. New Relic tells me our Apdex is 99, and it’s very rare for an endpoint to take more than 100ms. Most respond in under 80ms. I could LLM-port it (and probably will one day), but end-user response performance wouldn’t be the motivation.
What does make me consider switching is reading about things like how Shopify’s native apps are moving towards superfast product cores that can be tested incredibly quickly, with the slower UX layer kept separate. I think that model is the future, and in that world Rails starts to look pretty dead.
If your average per request in the application layer is say 20ms. Your p50 is probably 10-15ms and your p99 is probably something like 80ms. p99.9 is probably a good bit higher than that.
If your site is highly interactive, everyone using it is going to regularly run into actions that take long enough that they notice them, and it won’t feel snappy.
Let’s say you went all out and wrote the application layer in C with purely static allocation. You could easily see a p50 around 1-2ms and a p99 of 3-5ms. (This is obviously dependent on the app).
Even with an average time spent waiting in the database of 80ms, you’ve already made a noticeable difference.
That’s not even mentioning the biggest impact, which is that you can likely get by with far fewer application servers.
Now does it make even more sense to optimize your queries? Yes. Definitely. But with faster application stack you can start moving more things into the application layer and out of the database which is generally harder to scale.
And if you have or can build endpoints that don’t hit your database at all, those will actually be 10x faster than before every time.
It is pretty obvious rails is dead as it hangs massively on its founder for good and for bad.
And it is quite telling that he prefers to kill it off like this rather than handing the reigns over to someone else.
A technical note - the big difference is that a design with a number of fat clients don’t need server side rendered html - that lowers the load on the server regardless of the programming language.
You can probably write quite light json apis in Ruby and the performance of them will be dominated by network and db usage anyways compared to a similar implementation done in a compiled language.
He did slow down, but that's not the way to look at dhh contributions. Rails is a whole umbrella of projects, from rails top level package to turbo, solid_cache, sprockets, action-/active-anything, etc. There are lots of relatively recent contributions in that org overall.
Every piece of software has an expiration date. You can extend its lifespan, but technology keeps moving. What was considered standard on the backend five years ago may look completely different today. I think that's a good thing. Rails worked extremely well for its time, especially around 2007–2015, but it started to show its age as newer, more capable languages and runtimes matured.
We should be celebrating the fact that we can now port almost anything with far less effort, or modernize an existing stack to meet today's performance expectations, requirements, and engineering standards.
Whats the expiration date on, say, the windows 95 version of paint? Because it still loads just fine on my current windows computer, does everything I'd expect from a paint program, and gets out of the way when I don't need it anymore
>Whats the expiration date on, say, the windows 95 version of paint? Because it still loads just fine on my current windows computer,
When people say software is "expired", "obsolete", "legacy", "limited shelf life", etc ... they're not talking about whether somebody somewhere in the world has the ability or idiosyncratic desire to continue running that old software.
Instead, it means the software's ability to be practical and usable in relation to the rest of the current computing ecosystem. E.g. In this perspective, Win95 MSPAINT is "expired/obsolete" because it can't open .PNG and .JPEG files. In today's world, .PNG/.JPEG files are much more common than the .BMP files that MSPAINT 95 can open.
I still have an old 16-bit Microsoft C/C++ v 7.0 compiler from 1992. Did it expire?!? Well, not literally. There's no ticking time bomb in it that checks the system clock and refuses to run. Instead, the issue is that it doesn't have the newer C99/C++98/C++11 features and I can't use it to compile today's ffmpeg source code. That's what people mean by "expired/obsolete".
I don't think OPs comment was meant to be taken literally word for word. Breaking down language this way is hardly a productive way to discuss. OP is saying that most software has an expiry date, is this even controversial? All active software companies are constantly rewriting their stuff and would love to move to a more optimized stack, if cost of porting is not a factor.
I don't know the expiration date of all software, I only know all software has some expiration date. Maybe that version you're using will not be usable in the next 5 years, and it will prove my point. That doesn't mean you cannot use it anymore, it means better options took over.
DHH's keynote was like listening to David Brent give a motivational speech.
"Some of you will loose your jobs. I know, I know. Gutting. Gutting. On a more positive note, I'm getting a promotion. So every cloud. Oh, you're still think about the bad stuff aren't you?"
You have to laugh about it because he's kind of making himself irrelevant too. We listened to him because of Rails not Hey or Basecamp. They were just application of Rails as a technology.
If he no longer has a vision for Rails' niche, what do we need him for? What's his pitch?
He might as well just be a Danish Barry Gibb impersonator that can't sing but instead drones on and on about politics. :P
The summary is exactly why a lot of people is upset.
>That’s what bothers me most. I’m skeptical of his AI claims, but that’s not the real issue here.
>The problem is that he stood up at Rails World and told everyone that he was moving his product off Rails and the best thing he could come up with to say to people still using Rails was that we’re “the best of the best.” Thanks, I guess.
>Maybe Rails is done, in the way the Mosscap project claims. Maybe it’s time to focus on stability and maintenance. If that’s the plan, someone needs to say it. If it isn’t, then let’s hear about where we’re headed. DHH did neither.
A lot of people bet their entire careers on Rails. I've worked on Rails shops, and the majority of developers have not touched another language in years. There are people who never shipped anything in anything but Rails, and haven't done anything in other language since college, or ever if they did a bootcamp.
I have even interviewed a significant number of people doing Rails for ten years who did not know it was possible to launch a Ruby application with `ruby script.rb`.
Not to mention that with the emergence of frontend frameworks, most Rails developers were doing API-only stuff, and barely interacted with the frontend.
I recently left a company that was moving to from Rails to Go (might have been partially my fault), and there were was a bit of a mutiny where several teams have refused to change languages.
DHH is pretty much saying AI is gonna eat this people alive.
So it seems this started because of DHH. Let's judge the technology by the technology, else we are just taking a holier-than-thou approach whereby we think we are better than others because we don't commit certain sins, which is a real problem because when we look inwardly and honestly we shall see that we are guilty of many of the same sins. Let's judge the technology for the technology itself and leave personal ideology out of it. My 2 cents (which will inevitably be downvoted)
Interesting article. I understand the fury and disappointment.
But still, let's face reality. Rails with Ruby and Django with python's biggest advantage was readability and accessibility. For many, it is just much nicer reading Ruby code than Rust code. But LLMs have completely changed the equation, and development with a statically typed language plays much better into the agentic feedback loop. Add the memory safety guarantees of the rust compiler and the incredible runtime speed even compared to the Java Stack you will see many benefits.
I am biased since I love Rust, but I think backend technologies are going to move more towards statically typed memory safe languages.
Also if you use an agent to write most of your code, with python it gives me a lot of stomach pain just thinking about error potentials and hallucinations, with Rust, that fades to only security implications
Honestly Rails being finished it's that bad. If you aren't writing the code by hand what benefit is it really bringing to you now?
Rails niche was fast setup/low starting out costs and relatively constrained/medium maintenance costs. To get this you traded performance and type system. The latter usually resulted in increased maintenance costs as test suites ballooned to compensate.
These days fast setup is simply a product of AI, every ecosystem now offers fast setup.
Maintenance costs are now about how token efficient it is to find and fix problems.
Test suites are going to be huge everywhere now but there is some chance languages that require less to accomplish more will win on token efficiency and be favored.
Humans aren't the dominant factor in programming language design or selection anymore, that is a fact at this point it just hasn't sunk in for everyone yet.
We are only ~6mo in to agents being good enough to write code. A year from now our profession will be entirely changed. Agents will get better (how much? don't know) but importantly they will definitely get cheaper and access will be broader. Which is really the point DHH was trying to make.
Access and economics are finally going to do what no-code failed to do, which is democratise software. Maybe not to the point that everyone writes code or even that shit programmers are good, but it will enable shit programmers to write Rust which was literally impossible 6mo ago and they will have better programs as a result.
Which is the other thing he touched on. Good programmers are going to excel here and great programmers are going to dominate. I'm already seeing the 10x programmers hit 100x and 1000x with more access doesn't seem out of sight.
It's also restoring the will to create in a lot of people that lost the passion for the mechanical part of programming, unlocking the experience and skill of these people that were otherwise considering cashing in the bag is huge.
So yes. Rails is done but what is coming next is way more exciting.
I'm with DHH here, be glad it happened but get moving on where things are going to be instead of clinging to the past.
As can be seen from that list, DHH is now protected here like Steinberger. Never mention money and funding. Calling DHH a fascist is allowed and encouraged because it distracts from the end goals. But money, hell no!
The article forgets one thing, how DHH started his talk: he asked the audience how many people still codes by hand, and only 5 people raised their hands.
I was also waiting for some cool talk of some change, as I loved the simplificiation that Rails has done last year, but I also understand his point of view: he could either speed up the development of rails with AI (what Bun has done), or just say that it's mature and it doesn't matter anymore and it's better to not ruin a mature system.
There’s a Louis CK - yes I know, a horrible person, but unfortunately he used to be funny - joke where he asks the audience if they are in their 20s (loud cheer), 30s (less loud, but cheering) and in their 40s (very few cheers, mostly silent). The switcheroo is that he says “See, old people are smart! Why should they cheer? Who knows why I’m asking?”, or something along those lines. Well, it was funnier when he told it.
Anyway, the only logical conclusion clearly is that most Rails developers are over 40.
That was something of a public speaking trick, though. “How many of you are STILL doing X” is never likely to get many people to put up their hands. The speaker is framing it as stupid and backward.
I really like Rails and I don't see the controversy in anything DHH said. The strongest points for Rails always were productivity, developer ergonomics and strong conventions. Two out of three are now neutral in the age of agentic coding.
Strong conventions are my selling point to still choose rails for green-field projects in 2026. But I'm talking about LoB or CRUD-heavy apps. I wouldn't have chosen rails for an SMTP server. The HEY architecture was based on the productivity/performance trade-off. That trade-off is no longer worth it, since productivity is through the roof, let's prioritize performance and first class UX (the one you can only achieve in native apps).
In his shoes, I would have made the same decisions before and now.
Regarding the future of Rails. I feel this applies to a lot of other frameworks. The idea of frameworks was always to give devs a set of tools to solve problems faster and better. Tools that resonate with you. That you can find "synergy" with. Now you're not writing any of the code; you're barely even looking at it. So, what's the point of frameworks then? I don't know. Popular ecosystems already have out of the box solutions for almost everything. Rails, Django, Laravel, .NET, JVM and many more are mature enough. You could turn them all to maintenance mode and everything would be just fine. What future lies ahead? No idea.
Rails, or even more so php have VERY little to bring to the table in 2026 going forward. Rails (ruby) is still a saner language than PHP, but as slow as php is. (granted ruby is not idiotic like PHP and runs rather than start/die).
If you go the LLM route something like Go is probably the goto default for MOST networking/web-first apps. You get static types, and a fast compile cycle (rust is still very slow here), and IF you want more from the language you can use something like Lisette (https://lisette.run/).
Bottom line is dynamic languages are obsolete. There is really no benefits from using them outside very small throw away scripts.
Well that's not something you say in a Rails conference, best language or framework for a project has been debated before I was born and will continue to be
No... no its not. PHP is bound by IO in 99,9% of cases. This means im pretty much fucked the moment i need to do something even a little more complex. Say one request need 5-10 separate sql queries, and some http call and possibly some task like sending a mail. PHP need to run these all sync. I have to hack around and use a shit-tonne of deps like message queues and all sorts of plugins to get something like this working performantly.
Before you go on that apologist route, no, im not installing any random shit just to do simple stuff like this..
I would have been more interested if he'd spoken about improvements actually in the Ruby world.
There fast JITS like YJIT, ZJIT, JRuby and TruffleRuby.
We also have static typing with RBS and an AOT compiler in Spinel and we have embeddable Crystal.
The speed of TruflleRuby or Spinal with RBS isn't that far behind Go.
And here's a Ruby advantage for you, Ruby even with static typing needs fewer tokens from your context window to represent the same solution as verbose Go.
DHH's own pitch for HotWire was that it allowed a native like experience without having to bow to Apple app store review process. Where's that gone?
There's lots of positive things that DHH could have spoken of but didn't.
Citation needed? I love hating PHP, but of the reasons I would chose something other than PHP, speed and resource consumption is pretty far down the list?
PHP is sync. This means every IO operation i do runs sync. This is why PHP will always be the slowest ones out there. Open a file, SQL queries, sending emails etc. Its all sync. Its all slow.
PS. I fully aware of hacks around this like reactphp and the other related async things, but those are all just heavy dependencies and for most sane devs non starters.
Why would I bother with anything but Laravel for small CRUD apps? Not having to think about concurrency is neat, having tons of abstractions built by people with 50x my experience is neat, just being able to get going is neat.
Building the things I've built using Laravel with Golang would probably take 10x the development time as I have to handcraft everything Laravel already natively provides. Or I have to trust 100 packages from 100 different random devs to simulate the Laravel experience in Golang.
With LLMs the language DOES NOT MATTER. The framework DOES NOT MATTER. This is the thing we are talking about here. Laravel is 100% useless for a LLM first project. I can pretty much do anything in vanilla Go i can in Laravel and be 100x more performant, 100x more typesafe, and produce 100x more maintainable systems.
This is why dynamic languages, and even more so BAD ones like PHP are just useless going into 2027 and the future. Its simple, the language gives you what it gives in perf, builtin RUNTIME features, and COMPILETIME features.
From that you pick the best for whatever you are building, be it Go, Rust, Ocaml etc. The language does not matter.
Go has 90% of stuff builtin, you rarely need any dependencies. Look at Laravel ITS A HUGE CODEBASE and a high risk for any real software project. I would stay FAR away from it.
> 37signals differentiates their products with opinionated UI/UX, not novel features. They are rewriting Hey as six native apps because the web fidelity isn’t good enough. So UI matters enough to justify complete rewrites, but also everyone just wants CLIs?
I've seen this one a few times lately. People should stop building UIs, nobody wants to interact with a UI. Everyone's app should just be an API that you can use with a chatbot. Except for my app — my app is a handcrafted miracle of artisanal UX and its UI will change the way you see the world.
It's exactly the old argument, just now with LLMs in the place of shell pipelines: in terms of functionality and value to users, software ought to be malleable and composable. We've known it since the eighties. But the model of selling a piece of software as a product as if it were a pair of shoes is incompatible with that. You need a big monolithic application to justify users paying a bunch of money for it, and you need it to have a fancy interface that makes an impression. And the whole software industry is built on top of that model. Where monolithic software is completely unfit for a purpose, like when it needs to be a component of a larger system, we rely on (mostly unpaid) OSS.
Except now LLMs let you, with very little technical know-how, plaster a ‘programmable’ interface on top of unstructured data/interface meant for humans, and because that's what we actually want, of course everybody does that. So the end result is a wildly expensive pipeline from API to UI and back to API again. I wonder how long the legacy ‘human-oriented’ layer in the middle, and the industry that's been built on top of it, will last.
(Separately, chatbots are not great as a UI for most things, and the problem of building the universal UI still also stands. But it turns out for a lot of things people would rather have a bad universal UI than a good special-purpose UI for each task.)
UIs are great, until you can’t see the UI.
Words are a great UI. They can be easily converted into audio and haptics. We already have many systems in place that do exactly this with words.
Sure, pretty graphics are nice, but their sole intent should be to convey information. A User Interface that does not allow a person to easily have information conveyed to them is a bad interface.
The modern AI world isn’t perfect, but for a large portion of people who have accessibility needs, it’s absolutely a positive impact on their life in a way that no single technology has been until now.
I think LLMs may actually help us get to CLI/API driven development. At least, that has been my experience.
Even though most of my projects have a UI, I build a CLI/API version so that the LLM can interact with it directly. I have been using this "CLI driven development" approach for more than a year now and have had fantastic results. The CLI arguments make it easy for LLM to interact with software it wrote.
I usually ask LLM to build a lib, then expose as a CLI and a RESTful API.
> in terms of functionality and value to users, software ought to be malleable and composable.
For technically competent users, sure. but for everyone else the UI should just follow the principal of least surprise.
> People should stop building UIs, nobody wants to interact with a UI.
If the UI is completely local and the chat is not, then I prefer UI.
I think chat is a great entry point for many experiences. The approachability and flexibility are unmatched.
A question becomes, how do you evolve a chat experience to task specific actions?
I’m building an app to explore scripture. Chat is an amazing starting point. But it’s terrible once you get into reading the actual scripture.
I think we will see more of this in the future. Here is how I’ve envisioned evolving an experience out of chat. Curious if others have their own ideas.
https://trysojourn.app
For me personally, the effort to type on a mobile phone is too much. If I can't complete an interaction with maybe two sentences, I much much prefer typing on a computer, and if required, copy everything over.
I’m in the same boat. Hate typing on a phone. But due to chat interfaces,I’ve learned to mutter discretely into Apple keyboard dictation.
>Everyone's app should just be an API that you can use with a chatbot.
I see this sentiment a lot, but UI has a greater purpose than just serving the customer needs, it also be used to shape them.
Imagine if instead of going to the grocery store, you called a number and told them what you needed. Sometimes you don't know everything you need. Sometimes you end up discovering something new and buying it even if you didn't plan on it.
> Except now LLMs let you, with very little technical know-how, plaster a ‘programmable’ interface on top of unstructured data/interface meant for humans, and because that's what we actually want, of course everybody does that.
I don't think that is what everyone wants, or at the very least its not what I want. My ideal software has a well designed and thought through user interface for the primary interactions, allowing me to think about the goal I'm trying to achieve rather than how I'm manipulating the underlying data model.
Additionally to that please also provide access to the underlying data. Ideally in the form of a locally accessible API but I'll accept a remote one if necessary, provide a CLI on top of that as well if you like.
> I've seen this one a few times lately. People should stop building UIs, nobody wants to interact with a UI. Everyone's app should just be an API that you can use with a chatbot.
Same happened when the first smartphones came out, and everything was about "mobile first". Everyone will use their mobile phones for everything, desktop is dead, every app should be primarily designed for smartphones, everything comes after. Turned out smartphones just another interface that are good for some things, and not good for some other. Same for the "cloud native" movement.
Two slightly disconnected thoughts:
1. This is why BDFL culture in open source is bad. Because if the BDFL decides to go all in on some completely bizarre mess, all of a sudden there’s massive fork politics.
2. Hey is the marquee product now?? Does anyone actually use Hey? I tried it for a year, and basically found I was paying for the privilege of having a slower, buggier, less feature-rich gmail that can’t even dent the have-a-paid-email-that-doesn’t-exploit-you market (Fastmail and Proton exist, yo).
The only people I know still using Hey are doing so because there's no way to move your address elsewhere. It's a PITA to change your email everywhere (and some unfortunate place don't let you; e.g. email as the login and primary key)
As an SRE I would be very interested on experienced devs point of view on that stance, "we don’t even necessarily need to read the code the LLMs produce". To me, that is the only way a single dev can manage > 1 agent. Because I feel running the code will always be slower than a single agent generating it. On the other hand, it implies lack of human understanding on what is going on under the hood. Which is fine if you trust the LLM to write great code, and great tests for the code, but fundamentally you have to have 100% trust, 99.9% is not going to be enough in any serious industry, would it ?
Also eventually you'll also have to trust it to write the deployment code or even run the deployment itself, otherwise SRE is going to be the bottleneck. And only then should I feel anxiety about the rest of my career (that, or my employer decide LLM are good enough to get rid of me, even if they are imperfect).
We are many of us now engaged in a big experiment to see just how little you can read the code, and for how long. Considering the consensus is that we have still not yet passed the 1 year anniversary of agents getting good, it feels too early to say how it will play out. But there are a lot of market forces working to make it happen.
> Which is fine if you trust the LLM to write great code, and great tests for the code, but fundamentally you have to have 100% trust, 99.9% is not going to be enough in any serious industry, would it ?
This is lacking a lot of nuance. There are many types of code. There are many situations where I'm analysing something one-off and if I get 33% success ratio, but can easily verify the result, I'm happy - still saved me time and money. They're are situations where I'm generating graphs from some dataset and I don't have to trust anything - I know what the result should look like, I just need the agent to drive matplotlib. There are low stakes dashboards which I'm happy to generate and develop entirely via agents - they'll embed the updated screenshots in PRs that I can yolo-merge - worst case is that someone complains about something not working next time they visit. Then there's lots of experimenting which was never stopped to hit production anyway.
Finally after all of that you get code that's actually part of deployable features. Of course the trust is nowhere near 100%, but if you have a healthy testing process (e2e, validating different browsers, or whatever is appropriate for your environment), then what's your trust in human developer+review? Because mine is nowhere near 100% either.
In practice there are places where I extremely don't care about the code and never wanted it anyway, places where I'll read the code to check the design or just in case, and places which agents are not allowed to touch (medical billing rules for example).
Not trying to be a jerk but at this point SRE is my main use case for heavy LLM stuff. It's pretty awesome at that. Deployments and CI pipelines have become a breeze. I used to have to ask DevOps for that and wait days. I have even let agents run deployments for side projects and they seem to do better work than most humans I've worked with. It's wild they will actually read all the logs and debug problems so fast. Not something we could ever keep up with.
The actual code and architecture is where it still lacking IMHO. Especially in rails... Like it will just build the least scalable features if you let it do it's thing. Ten queries for what could be one. No separation of concerns. Huge files, lots of duplicated code and then tens of thousands of units tests that just grow like a fatberg.
If your app does anything serious, if you have serious traffic... you are going to need to review each session finely (and your DB schema with each deploy). It could be that this is maybe an indictment of rails more than LLMs, I guess maybe time will tell.
Writing deployment manifests and CI pipelines is not really the core part of "SRE" to me: it's more related to how you run software in production, not the build/test process to get it there.
If you don't look at your code and need to debug a production issue, do you just panic chat with your agent to solve the problem?
Why would any of this make you a jerk ?
I guess it all depends on context, where I work ops stuff is clearly the bottleneck for a variety of reasons (technical debt that we are constantly working around, secret management for compliance reasons, etc). We self-host everything from bare metal. Some people would need to rethink the infra from the bottom up before it is "LLM ready".
That doesn't mean my job is not threatened mid/long term, in fact, thanks to LLM it is possible to rebuild that in a reasonnable amount of time I think. It's actually one of my side projects to offer this as a service. But if that doesn't work maybe I should have a plan C.
> Because I feel running the code will always be slower than a single agent generating it.
That is very not true for many cases. Agents generating code are usually painfully slow, finding workflows that replace that reasoning with running code usually speed things up in my experience.
I code and maintain a Rails stack. About 20% of the time an endpoint takes to respond is spent in Ruby. New Relic tells me our Apdex is 99, and it’s very rare for an endpoint to take more than 100ms. Most respond in under 80ms. I could LLM-port it (and probably will one day), but end-user response performance wouldn’t be the motivation.
What does make me consider switching is reading about things like how Shopify’s native apps are moving towards superfast product cores that can be tested incredibly quickly, with the slower UX layer kept separate. I think that model is the future, and in that world Rails starts to look pretty dead.
Those numbers can be misleading though.
If your average per request in the application layer is say 20ms. Your p50 is probably 10-15ms and your p99 is probably something like 80ms. p99.9 is probably a good bit higher than that.
If your site is highly interactive, everyone using it is going to regularly run into actions that take long enough that they notice them, and it won’t feel snappy.
Let’s say you went all out and wrote the application layer in C with purely static allocation. You could easily see a p50 around 1-2ms and a p99 of 3-5ms. (This is obviously dependent on the app).
Even with an average time spent waiting in the database of 80ms, you’ve already made a noticeable difference.
That’s not even mentioning the biggest impact, which is that you can likely get by with far fewer application servers.
Now does it make even more sense to optimize your queries? Yes. Definitely. But with faster application stack you can start moving more things into the application layer and out of the database which is generally harder to scale.
And if you have or can build endpoints that don’t hit your database at all, those will actually be 10x faster than before every time.
It is pretty obvious rails is dead as it hangs massively on its founder for good and for bad.
And it is quite telling that he prefers to kill it off like this rather than handing the reigns over to someone else.
A technical note - the big difference is that a design with a number of fat clients don’t need server side rendered html - that lowers the load on the server regardless of the programming language.
You can probably write quite light json apis in Ruby and the performance of them will be dominated by network and db usage anyways compared to a similar implementation done in a compiled language.
https://github.com/rails/rails/commits/main/
https://github.com/rails/rails/graphs/contributors?from=6%2F...
Zero commits are from DHH. It seems he already handed reigns over to other people.
He did slow down, but that's not the way to look at dhh contributions. Rails is a whole umbrella of projects, from rails top level package to turbo, solid_cache, sprockets, action-/active-anything, etc. There are lots of relatively recent contributions in that org overall.
If all this is true, why are election apps still popular instead of native?
Why are high level managed languages still being used?
For that matter, why aren’t LLMs generating everything in wasm or native assembly?
Unfortunately, the answer most likely is “because we didn’t shift everything over yet”.
Every piece of software has an expiration date. You can extend its lifespan, but technology keeps moving. What was considered standard on the backend five years ago may look completely different today. I think that's a good thing. Rails worked extremely well for its time, especially around 2007–2015, but it started to show its age as newer, more capable languages and runtimes matured.
We should be celebrating the fact that we can now port almost anything with far less effort, or modernize an existing stack to meet today's performance expectations, requirements, and engineering standards.
Whats the expiration date on, say, the windows 95 version of paint? Because it still loads just fine on my current windows computer, does everything I'd expect from a paint program, and gets out of the way when I don't need it anymore
>Whats the expiration date on, say, the windows 95 version of paint? Because it still loads just fine on my current windows computer,
When people say software is "expired", "obsolete", "legacy", "limited shelf life", etc ... they're not talking about whether somebody somewhere in the world has the ability or idiosyncratic desire to continue running that old software.
Instead, it means the software's ability to be practical and usable in relation to the rest of the current computing ecosystem. E.g. In this perspective, Win95 MSPAINT is "expired/obsolete" because it can't open .PNG and .JPEG files. In today's world, .PNG/.JPEG files are much more common than the .BMP files that MSPAINT 95 can open.
I still have an old 16-bit Microsoft C/C++ v 7.0 compiler from 1992. Did it expire?!? Well, not literally. There's no ticking time bomb in it that checks the system clock and refuses to run. Instead, the issue is that it doesn't have the newer C99/C++98/C++11 features and I can't use it to compile today's ffmpeg source code. That's what people mean by "expired/obsolete".
I don't think OPs comment was meant to be taken literally word for word. Breaking down language this way is hardly a productive way to discuss. OP is saying that most software has an expiry date, is this even controversial? All active software companies are constantly rewriting their stuff and would love to move to a more optimized stack, if cost of porting is not a factor.
I don't know the expiration date of all software, I only know all software has some expiration date. Maybe that version you're using will not be usable in the next 5 years, and it will prove my point. That doesn't mean you cannot use it anymore, it means better options took over.
DHH's keynote was like listening to David Brent give a motivational speech.
"Some of you will loose your jobs. I know, I know. Gutting. Gutting. On a more positive note, I'm getting a promotion. So every cloud. Oh, you're still think about the bad stuff aren't you?"
You have to laugh about it because he's kind of making himself irrelevant too. We listened to him because of Rails not Hey or Basecamp. They were just application of Rails as a technology.
If he no longer has a vision for Rails' niche, what do we need him for? What's his pitch?
He might as well just be a Danish Barry Gibb impersonator that can't sing but instead drones on and on about politics. :P
I laughed when he showed the slide that Hey could run on a single Raspberry Pi.
Not the flex you think it is, Dave!
1 year from now: "don't ask why do all requests resolve to a single IP."
The summary is exactly why a lot of people is upset.
>That’s what bothers me most. I’m skeptical of his AI claims, but that’s not the real issue here.
>The problem is that he stood up at Rails World and told everyone that he was moving his product off Rails and the best thing he could come up with to say to people still using Rails was that we’re “the best of the best.” Thanks, I guess.
>Maybe Rails is done, in the way the Mosscap project claims. Maybe it’s time to focus on stability and maintenance. If that’s the plan, someone needs to say it. If it isn’t, then let’s hear about where we’re headed. DHH did neither.
It's kind of crazy to witness.
Rails is very insular tech.
A lot of people bet their entire careers on Rails. I've worked on Rails shops, and the majority of developers have not touched another language in years. There are people who never shipped anything in anything but Rails, and haven't done anything in other language since college, or ever if they did a bootcamp.
I have even interviewed a significant number of people doing Rails for ten years who did not know it was possible to launch a Ruby application with `ruby script.rb`.
Not to mention that with the emergence of frontend frameworks, most Rails developers were doing API-only stuff, and barely interacted with the frontend.
I recently left a company that was moving to from Rails to Go (might have been partially my fault), and there were was a bit of a mutiny where several teams have refused to change languages.
DHH is pretty much saying AI is gonna eat this people alive.
From the talk it’s clear, Rails needs to be forked.
isn't https://mosscap.dev/ a fork?
So it seems this started because of DHH. Let's judge the technology by the technology, else we are just taking a holier-than-thou approach whereby we think we are better than others because we don't commit certain sins, which is a real problem because when we look inwardly and honestly we shall see that we are guilty of many of the same sins. Let's judge the technology for the technology itself and leave personal ideology out of it. My 2 cents (which will inevitably be downvoted)
speak for yourself, I never compare people to shoot wolves
I think one can just wait till DHH loses interest, can't be long now.
Interesting article. I understand the fury and disappointment.
But still, let's face reality. Rails with Ruby and Django with python's biggest advantage was readability and accessibility. For many, it is just much nicer reading Ruby code than Rust code. But LLMs have completely changed the equation, and development with a statically typed language plays much better into the agentic feedback loop. Add the memory safety guarantees of the rust compiler and the incredible runtime speed even compared to the Java Stack you will see many benefits.
I am biased since I love Rust, but I think backend technologies are going to move more towards statically typed memory safe languages.
Also if you use an agent to write most of your code, with python it gives me a lot of stomach pain just thinking about error potentials and hallucinations, with Rust, that fades to only security implications
While I mostly agree with DHH's take on this particular technological cycle, this is a very well thought out criticism.
Honestly Rails being finished it's that bad. If you aren't writing the code by hand what benefit is it really bringing to you now?
Rails niche was fast setup/low starting out costs and relatively constrained/medium maintenance costs. To get this you traded performance and type system. The latter usually resulted in increased maintenance costs as test suites ballooned to compensate.
These days fast setup is simply a product of AI, every ecosystem now offers fast setup. Maintenance costs are now about how token efficient it is to find and fix problems. Test suites are going to be huge everywhere now but there is some chance languages that require less to accomplish more will win on token efficiency and be favored.
Humans aren't the dominant factor in programming language design or selection anymore, that is a fact at this point it just hasn't sunk in for everyone yet.
We are only ~6mo in to agents being good enough to write code. A year from now our profession will be entirely changed. Agents will get better (how much? don't know) but importantly they will definitely get cheaper and access will be broader. Which is really the point DHH was trying to make.
Access and economics are finally going to do what no-code failed to do, which is democratise software. Maybe not to the point that everyone writes code or even that shit programmers are good, but it will enable shit programmers to write Rust which was literally impossible 6mo ago and they will have better programs as a result.
Which is the other thing he touched on. Good programmers are going to excel here and great programmers are going to dominate. I'm already seeing the 10x programmers hit 100x and 1000x with more access doesn't seem out of sight. It's also restoring the will to create in a lot of people that lost the passion for the mechanical part of programming, unlocking the experience and skill of these people that were otherwise considering cashing in the bag is huge.
So yes. Rails is done but what is coming next is way more exciting. I'm with DHH here, be glad it happened but get moving on where things are going to be instead of clinging to the past.
100% agree
It is quite irrelevant to examine political opinions or if the conference turned into a Jonestown cult etc.
The only thing that matters in AI is to examine the flow of money. DHH is a Shopify board member and surely got Shopify stock.
Additionally, his Omarchy is sponsored by the following AI boosters (https://omarchy.org/patrons/):
His Fridman promotion was sponsored by Shopify:https://lexfridman.com/sponsors/ep501-sb
His future is tied to the AI narrative and he sells out stuff he no longer needs like RoR. Anything he says is an advertisement.
As can be seen from that list, DHH is now protected here like Steinberger. Never mention money and funding. Calling DHH a fascist is allowed and encouraged because it distracts from the end goals. But money, hell no!
>Calling DHH a fascist is allowed and encouraged because
...it's true, based on his own words.
The article forgets one thing, how DHH started his talk: he asked the audience how many people still codes by hand, and only 5 people raised their hands.
I was also waiting for some cool talk of some change, as I loved the simplificiation that Rails has done last year, but I also understand his point of view: he could either speed up the development of rails with AI (what Bun has done), or just say that it's mature and it doesn't matter anymore and it's better to not ruin a mature system.
There’s a Louis CK - yes I know, a horrible person, but unfortunately he used to be funny - joke where he asks the audience if they are in their 20s (loud cheer), 30s (less loud, but cheering) and in their 40s (very few cheers, mostly silent). The switcheroo is that he says “See, old people are smart! Why should they cheer? Who knows why I’m asking?”, or something along those lines. Well, it was funnier when he told it.
Anyway, the only logical conclusion clearly is that most Rails developers are over 40.
That was something of a public speaking trick, though. “How many of you are STILL doing X” is never likely to get many people to put up their hands. The speaker is framing it as stupid and backward.
People were afraid of cameras. You have to wear the AI Swastika in public.
I haven't been coding by hand for the last 15 years. The autocomplete of RubyMine is that good.
I really like Rails and I don't see the controversy in anything DHH said. The strongest points for Rails always were productivity, developer ergonomics and strong conventions. Two out of three are now neutral in the age of agentic coding.
Strong conventions are my selling point to still choose rails for green-field projects in 2026. But I'm talking about LoB or CRUD-heavy apps. I wouldn't have chosen rails for an SMTP server. The HEY architecture was based on the productivity/performance trade-off. That trade-off is no longer worth it, since productivity is through the roof, let's prioritize performance and first class UX (the one you can only achieve in native apps).
In his shoes, I would have made the same decisions before and now.
Regarding the future of Rails. I feel this applies to a lot of other frameworks. The idea of frameworks was always to give devs a set of tools to solve problems faster and better. Tools that resonate with you. That you can find "synergy" with. Now you're not writing any of the code; you're barely even looking at it. So, what's the point of frameworks then? I don't know. Popular ecosystems already have out of the box solutions for almost everything. Rails, Django, Laravel, .NET, JVM and many more are mature enough. You could turn them all to maintenance mode and everything would be just fine. What future lies ahead? No idea.
Rails is dead.
Its founder has converted to AI driven Rust.
He has a point. Anything you could build in Rails you can now build in fast reliable type safe memory safe multithreaded Rust in minutes.
DHH will bring his tribe of true believers to where he has gone, where he has set up a new sideshow tent.
Do you follow the leader.
Is it Rails that you follow or is it DHH?
> Rails is dead.
I forgot how many times Rails has died, maybe it is a cat & this is perhaps the 7th/8th time?
Rails, or even more so php have VERY little to bring to the table in 2026 going forward. Rails (ruby) is still a saner language than PHP, but as slow as php is. (granted ruby is not idiotic like PHP and runs rather than start/die).
If you go the LLM route something like Go is probably the goto default for MOST networking/web-first apps. You get static types, and a fast compile cycle (rust is still very slow here), and IF you want more from the language you can use something like Lisette (https://lisette.run/).
Bottom line is dynamic languages are obsolete. There is really no benefits from using them outside very small throw away scripts.
Dynamic languages without direct support for machine code generation are obsolete.
BASIC and Lisp were invented with machine code generation as part of the REPL workflow, interpreters have always been the exception.
In BASIC's case for a brief moment interpreters were favoured only due to 8 bit home computer's hardware limitations.
If we are going the way of 5 GL (as LLMs being the 4GL revenge), natural language is quite dynamic to start with.
Well that's not something you say in a Rails conference, best language or framework for a project has been debated before I was born and will continue to be
PHP is significantly faster than Ruby.
No... no its not. PHP is bound by IO in 99,9% of cases. This means im pretty much fucked the moment i need to do something even a little more complex. Say one request need 5-10 separate sql queries, and some http call and possibly some task like sending a mail. PHP need to run these all sync. I have to hack around and use a shit-tonne of deps like message queues and all sorts of plugins to get something like this working performantly.
Before you go on that apologist route, no, im not installing any random shit just to do simple stuff like this..
I would have been more interested if he'd spoken about improvements actually in the Ruby world.
There fast JITS like YJIT, ZJIT, JRuby and TruffleRuby.
We also have static typing with RBS and an AOT compiler in Spinel and we have embeddable Crystal.
The speed of TruflleRuby or Spinal with RBS isn't that far behind Go.
And here's a Ruby advantage for you, Ruby even with static typing needs fewer tokens from your context window to represent the same solution as verbose Go.
DHH's own pitch for HotWire was that it allowed a native like experience without having to bow to Apple app store review process. Where's that gone?
There's lots of positive things that DHH could have spoken of but didn't.
> as slow as PHP is.
Citation needed? I love hating PHP, but of the reasons I would chose something other than PHP, speed and resource consumption is pretty far down the list?
PHP is sync. This means every IO operation i do runs sync. This is why PHP will always be the slowest ones out there. Open a file, SQL queries, sending emails etc. Its all sync. Its all slow.
PS. I fully aware of hacks around this like reactphp and the other related async things, but those are all just heavy dependencies and for most sane devs non starters.
Why would I bother with anything but Laravel for small CRUD apps? Not having to think about concurrency is neat, having tons of abstractions built by people with 50x my experience is neat, just being able to get going is neat.
Building the things I've built using Laravel with Golang would probably take 10x the development time as I have to handcraft everything Laravel already natively provides. Or I have to trust 100 packages from 100 different random devs to simulate the Laravel experience in Golang.
With LLMs the language DOES NOT MATTER. The framework DOES NOT MATTER. This is the thing we are talking about here. Laravel is 100% useless for a LLM first project. I can pretty much do anything in vanilla Go i can in Laravel and be 100x more performant, 100x more typesafe, and produce 100x more maintainable systems.
This is why dynamic languages, and even more so BAD ones like PHP are just useless going into 2027 and the future. Its simple, the language gives you what it gives in perf, builtin RUNTIME features, and COMPILETIME features.
From that you pick the best for whatever you are building, be it Go, Rust, Ocaml etc. The language does not matter.
Go has 90% of stuff builtin, you rarely need any dependencies. Look at Laravel ITS A HUGE CODEBASE and a high risk for any real software project. I would stay FAR away from it.