> 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.)
A chatbot is worse than a CLI app: a CLI app does exactly what you ask for, and has a manual documenting exactly what command do what, and the output is consistent, the same command does the same thing period.
A chatbot using an LLM of course not, it suffers from hallucinations, it may do what you want but there is a change it won't and you have to fight it to get the desired result.
Chatbots are far WORSE than traditional UI for everything. If some product has a chatbot functions it's the first thing I disable, if it's not possible to disable it, I avoid the product.
And GUI applications are typically preferred, at least for the normal people and not us nerds, to CLI applications, since you know people like moving a mouse and clicking on buttons (or tapping them on a touchscreen) that learning commands: a chatbot doesn't make the CLI experience less awful for the average user, and for the nerd user, he prefers to use the CLI directly (replace asking the chatbot with man or --help and you don't need to emit tons of CO2 and transmit your personal data to a datacenter on the other side of the world to do stuff you did with MS-DOS)
> a CLI app does exactly what you ask for, and has a manual documenting exactly what command do what, and the output is consistent, the same command does the same thing period
This is a very software-engineery point of view and totally false for the ordinary user. Heck, it is even false for me as a software engineer.
> since you know people like moving a mouse and clicking on buttons
No, they like well-designed user interfaces, and the UI design of a typical CLI is abysmal.
> Heck, it is even false for me as a software engineer.
Amen
Honestly, the gap from knowing which command line tool you probably need, to the command that does what you need... Prior to AI I have replicated probably a thousand command line capabilities in Ruby because I just couldn't be bothered.
The nice thing about a CLI is that even if you don't like the interface you're given, it's trivial to put an interface you do like in front of it. Much harder to do that with a point and click interface.
>> Chatbots are far WORSE than traditional UI for everything. If some product has a chatbot functions it's the first thing I disable, if it's not possible to disable it, I avoid the product.
The chatbot we added to our B2B product is by far the most popular addition we've made this year. Our users are not tech-savvy, they use a lot of apps everyday and don't want to have to learn and keep up with just another UI. So they like being able to type their wants and needs in plain language (or speak it into their phone, if they are in the field) and get a plain language response back with embedded images and charts.
> So they like being able to type their wants and needs in plain language (or speak it into their phone, if they are in the field) and get a plain language response back with embedded images and charts.
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.
As a developer/user I hope for that outcome too — if everybody is using your app through an agent you might as well cut the maintenance cost and drop the GUI, or at least have a nice API alongside it to make it nicer for the agent. But I wonder what it does to the financial incentives to produce software.
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.
For sure! One of the big draws of malleability is that you can adapt it to your particular needs. Natural language is a UI just as much as a WIMP GUI, and for some tasks or some people it's a great one.
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.
"I think chat is a great entry point for many experiences. The approachability and flexibility are unmatched."
Just wait a few months/years and then some smartasses will come with a novel approach nobody ever has thought of before. Let's call it "context menus". They will give rapid access to the most used features without the tedious typing.
Until MacOS 27 the text context menus had items "Writing Tools" and "Proofread". Quick and efficient. MacOS has dropped these items and replaced with "Ask Siri". Now I have to type "proofread" every time and pray Siri agrees that it should proofread the selected text. Once it has done that, do i have to type "replace"? I don't even know.
There is a reason why UIs became popular. Command lines are fine but hard to discover and tedious to use. With AI it's even worse. You can't know for sure the AI interprets your commands in the way you intended.
You gave me an idea :). The original motivation was to explore the Bible like I explore Wikipedia. I think this UX for Wikipedia would be really amazing. Someone should build it. I hope I don't get the itch to do it this weekend!
> 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.
Yes you caught me out in a bit of exaggeration there. For the topmost level of tasks people typically do want a low-latency, high-bandwidth UI for displaying and manipulating the information they care about.
> "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"
Yes, this is the crux of the whole discussion. The paradigm is called "Intent-based UX".
>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.
In case it wasn't clear, that was intended as a somewhat satirical representation of the position I was discussing :) An important part of any ‘universal UI’ — and arguably the hardest part of building it — has to be that it allows feedback from the API about what and how to display, which is always in tension with the malleability/universality aspect. People are trying to solve that for chatbots right now, with limited success so far.
I think the popularity of these chat interfaces disagrees with that to some extent. We do already have malleable software for people who can program — the problem has always been bringing it to everyone else.
> 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.
Exactly this. Each new hype cycle, everything must be shoe horned into the hot new technology. So now there's a push to use chatbots for everything, why even have an interface? Just ask the chatbot to make one for you! Because the user totally knows what they want and what works, we've been wrong all these decades when it comes to UIs and customer preference. /s
> 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.
The last thing people want is interacting with a chatbot for anything that doesn't require a chatbot.
> in terms of functionality and value to users, software ought to be malleable and composable.
No, it shouldn't. The last thing people want is for software to change from under them, or be replaced with the bullshit that is a chatbot.
> plaster a ‘programmable’ interface on top of unstructured data/interface meant for humans
Ah yes. I can imagine everyone "plastering programmable interfaces" on top of daily stuff they want to do. Like buying a ticket to a museum. Ordering Doorsash. Sending a meme to a friend. Renting a car...
Most managers don't read the code of their direct reports. They just trust that the code is "good enough" and that there are enough other processes in place to catch bugs before they cause too much damage. I think I'm a pretty skilled programmer, or I'm at least good enough at interviewing to convince other people of that, but it's pretty obvious from comparing LLM generated code to code I'd write myself that in many domains LLMs are superior to me. They do make mistakes, but so do I, and those mistakes are eventually found and corrected.
We're in the very early stages of LLM driven programming, so it's hard to say how it will all shake out, but my anecdotal experience is that LLM written software is very reliable and easy to extend and develop. I have a side project that is about 90% LLM generated code (about 25k lines of production code and a similar amount of test code). This is a revenue generating product and I've had no issues with reliability, security, or performance.
For what it's worth this app is a rails app and I have no plans to switch to anything else. Rails works nicely, the LLMs extend it easily, and almost everything is I/O bound so I don't need C++/Rust level performance.
> I think I'm a pretty skilled programmer, or I'm at least good enough at interviewing to convince other people of that, but it's pretty obvious from comparing LLM generated code to code I'd write myself that in many domains LLMs are superior to me.
there's an important caveat here - LLMs absolutely can write better code than me, but they can also write far worse code, and often don't seem to be able to tell the difference. I find myself spending a lot of time prompting the bots to refine their code in specific ways that I only know about because I read the generated output.
but my anecdotal experience is that LLM written
software is very reliable and easy to extend and
develop.
Extremely refreshing to read. The whole thing, not just this statement.
Too much discourse creates a false dichotomy of "awesome, wonderful, hand-crafted code" vs "shitty AI slop."
A lot of hand-crafted code is pretty bad. This is true even with talented engineers: there are often edge cases they did not think of... and in many cases, could not have thought of.
And AI code is pretty good if it's steered and vetted by a knowledgeable engineer. It is clear to me, and has been clear for a long time, that "talented engineer plus AI" is the winning combination and will remain that way for at least the near future.
I still review PRs, all of which are written by agents. I almost never have meaningful feedback to offer unless it's feedback on the architectural approach. And even then, a lot of architectural/coding patterns that I've been a stickler for in the past mean less to me now because those patterns served to create maintainable code for human beings, which just isn't a priority anymore.
"If every product is used by an agent driving a CLI, what’s going to differentiate Basecamp or Fizzy from the cheapest alternative?"
At that point, why even bother with "driving a CLI"? I have a hard time seeing how this all doesn't go away soon. At the current trajectory, I am not seeing a future where software like Basecamp or Fizzy or the cheapest alternative are competitive with "Claude, build a basecamp-style project management tool for my team."
I don't mean to say that thoughtfully built, opinionated software doesn't have intrinsic value, I believe it will always be "better" in certain aspects...I just can't fathom that a market for it will exist in very short order.
I would LOVE to be talked out of this perspective.
I’m building a language learning application [1]. It uses spaced repetition, built upon FSRS, an open source algorithm.
I’ve spent the last three years tweaking away at this algorithm. There are so many little details that have had to come together to make it an enjoyable experience. For example, take the one problem of balancing multiple language: What is the best way to balance multiple languages? How should you switch between them, and how often? What happens if you are over performing in one language and underperforming in another? What happens if you have more reviews in one language than another that isn’t in line with your priorities? How do you deal with competing learning speeds and language priorities? Spiky review burdens? What happens when you change your language priorities?
This is probably the most trivial part of the algorithm, and it took years of trial and error and dozens of iterations to get it to feel right. It requires knowing about SRS, the FSRS algorithm, language learning principles, and even then tons of experimentation, trial and error, and hundreds of days of daily usage.
I’ve asked LLMs every step of the way what to do. I’ve probably taken <1% of the advice I was given. Just asking an LLM “build an SRS app that balances multiple languages” would produce a result, but one that would definitely be terrible to use, and probably would end up slowing you down, not speeding you up. Explaining to it any of the issues that you would come across when using it will likely suggest to changes that will only make things worse, based on the thousands of terrible ideas I’ve seen confidently produced.
The hard part of a product is not the idea, but the experience of using it. The valueable work is normally not in the big feature specs, but the hundreds of little paper cuts that have all been smoothed over. The time saved is not because you don’t have to code it, but is from not having to become an expert in several different fields.
Phweww - 100% agree and am seeing that with my app as well! It's been one of the most joyful pieces of building it, is that I am really making something for myself and have been using it and continually adding the things that I want.
Claude can 100% build you your own basecamp quickly, but there is a lot of good thinking that has gone into a product. Edge cases. Integrations. Clarity of thinking and ways to extend it. Agents love standing on the shoulders of good crystalized cognition (grep, curl etc), but I think that extends even beyond base CLI tools.
Which is not to say that "cheapest alternative" won't be much more important than it is now, but the tools that will succeed are the ones that solve clear problems with accessible CLI/tool-call like interfaces and take significant load off the agent running, while doing it efficiently and cost effectively so they are clearly better than building it yourself.
To be fair, there will be a ton of margin collapse and that will be unachievable by a lot of current orgs / structures.
Why waste tokens and ops team time and developer bug chasing time when you can get a signed contract with guaranteed uptime and support, and have those people be building something you can sell instead?
It's all opportunity cost.
Edit: throw in mandated security audits and maintenance for SOC2 compliance or whatever else you're on too, depending on the industry you're in.
People don’t actually want to build software. There will still be a market for hosted software that feels like magic. The next shape and UX is still getting fleshed out.
Also: the coded apps that AIs build are unmaintainable without a tech background. They may work for exactly their proposed happy-path and that may be great. But over time I can’t see how it’s possible these apps get maintained.
In the current/legacy market, people accept bugs in software because software was expensive and the alternatives are often few for that same reason.
Tomorrow's software will need to be _perfect_, or else it won't differentiate from "Claude, build a basecamp-style project management tool for my team".
Why would you build an app at all? Why wouldn't Claude just be the app itself? You ask it to set up your UI in the web app and you just use Claude for your entire workflow.
We're only a few persistent widgets and a better persistent storage story away from this possibility.
This is kind of like Alan Kay's idea in the 70s/80s for the Smalltalk image being the software that users customize to their needs instead of buying the software, except now it's a chatbot/agent interface instead of a customizable, integrated Smalltalk IDE.
I know this is not exactly a nuanced take, but why would anyone take advice about the future of technology whose contributions are now limited to an opinionated email app? I appreciate that tech is and will change even more, but relegating an entire ecosystem to the dustbin because you're feeling bullish about LLMs seems...premature.
DHH is the creator of rails and you are listening to a very cherry picked take, like all of the internet these days.
His whole argument which I agree with is summed up in a section where he shows a clip of himself 21 years ago saying “look at how much code I’m not writing” and that is the core thesis of rails. And agents provide a better solution than rails with less downside and more upside. So now that the core reason for rails has been overturned, instead of holding onto an old inferior solution to a problem, he has moved on because he is a value driven pragmatist at heart.
He literally built rails to write code as close to English as possible. Expressiveness, get code out of your way so you can focus on solving the non technical problems, stop getting stuck in engineering decisions and focus on business and UX, etc. Now whether his values were truly accomplished some people can argue but what those values are is pretty clear.
DHH created rails for himself and he has been unabashedly firm on his own values, it’s Steve Jobs esque, provides great clarity and focus but pisses people off who deviate from that focus.
Lots of people jumped on rails but don’t share DHH exact values. They see rails as a community ownership not a DHH ownership and they believe in the framework beyond just a tool to solve problems. More specifically they rely on it and helped build it up well beyond “just a tool to write code more like English” to a robust, well maintained usable platform you can build and run sophisticated real world applications with.
DHH has left rails because it no longer is the right solution for his set of values, that’s it. Others in the community rely on Rails to run their systems and will continue to do so until the end of time because let’s face it Rails has been pretty mature since rails 5/6 and despite all the exciting “progress” it’s just a solidly good framework that doesn’t really need to keep up with the trends.
The Ruby on Rails community has always been hard to separate from DHH.
The fact that he went on stage at a Ruby on Rails keynote and talked about his current passions instead of Rails is kind of typical for his style of leadership. The Ruby on Rails project and community were always the DHH show, even though there were years where they tried hard to act like it was an independent community run project now.
This late in the game, I think most RoR fans who are committed enough to attend a RoR conference have aligned themselves with DHH more than RoR, which is why you see some positive responses to a RoR keynote that didn't talk about RoR.
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.
Yup - this! A big ol' experiment, we shall see how it goes. I'd be curious (if they exist) on some larger / older orgs with internet scale customer bases that are full in on AI development with limited human reading of it to see how they fare.
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.
>The actual code and architecture is where it still lacking IMHO.
My experience is that the more structure and constraints you can place on what the LLM/Agents actually do, the better they perform. If you just let them run wild a la "make me an app that will make a million dollars MRR, no mistakes", you get a clusterfuck. And it gets more clusterfucky the longer it goes on.
> 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).
vary similar processes. vibe code/vibe create a presentation. he also knew what "shape the graph should look like" but still had errors in his powerpoint. if you can't trust it with a powerpoint i'm not sure why you can trust it for other low stakes things.
Have you got any sources? The only thing I can find is the 2026/2006 mix-up which feels like a classic typo rather than AI mistake. There are other typos there which makes it less likely the presentation was fully generated. And it means that the result wasn't reviewed - looking at code is irrelevant in comparison.
Coding part of the job (as in „typing with my bare hands“) is gone. Now I get to spend more time making product decisions, capturing constraints and executable specs. Resulting code is boring, consistent and gets the job done.
> 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.
oh I meant "reading" is slower not "running", but I guess you may still be right for large context. The article is about that though (a dev giving up on reading code entirely because that would be too slow).
I don't read the code my LLM produces unless I am investigating the code. I actually don't know Kotlin, or React.
My version of "code review" is "test failure investigation" and I have a hard rule in my repos that agents never modify existing tests while they're implementing features. This means that when I run the tests after they do a bunch of stuff, I see all the tests break. Mostly they're stale assertions and we patch them up. Sometimes they're regressions and we patch those up, and sometimes I notice something dumb and dive deep into a facet of the architecture that can be improved, spend some time exploring it then get the agent to implement.
I think it's a better approach than trying to read everything and catch bugs or improve quality because you wind up focusing the things that actually matter in the real world rather than the things you think might matter.
This is how I've always approached working with offshore devs too. Focus on testing for quality control, not "code quality". After all, you're going to look at the code you wrote 5 years ago and think it's shit anyway right? So all your code is shit.
Regarding "lack of understanding", here's a recent anecdote: I had a bug in a production (but relatively new) system. The customer was texting me saying that they couldn't scan a QR code because it kept "skipping and glitching". They sent me a short video. I described the problem to the agent and it figured out WAY faster than I would have been able to that the customer's clock was set incorrectly. They turned on network time and bingo bango, the thing worked straight away.
I don't thing "comprehension debt" matters at all, because if you want to know something about the code you ask the agent. I can't remember how anything works after 12 months anyway, so I would frequently have to spend ages grepping my own code when a customer came back and asked me to change something in a system we hadn't touched since last year. Asking an agent the same thing takes minutes and is way more accurate (and fun!)
>Regarding "lack of understanding", here's a recent anecdote: I had a bug in a production (but relatively new) system. The customer was texting me saying that they couldn't scan a QR code because it kept "skipping and glitching". They sent me a short video. I described the problem to the agent and it figured out WAY faster than I would have been able to that the customer's clock was set incorrectly. They turned on network time and bingo bango, the thing worked straight away.
That only describes a happy path though -- I also had many instances where there's an issue and just describing it to an agent immediately identifies a fix and it all goes faster compared to me having to "load up" the flow of codebase into my brain first. But I also still have instances where it thinks it identifies an issue correctly, spits a fix which doesn't work and looks wrong. You point out that it does not make sense because of X, it agrees and spits out a new fix, which is also wrong and you start out on these back and forth wild goose chases, at this point I usually give up and do it the old fashioned way by understanding what is actually happening. If it is within an agent loop, there may be no back-and-forth to waste your time but then you pay with wasted tokens when it will eventually gives up or you stop it.
>I don't thing "comprehension debt" matters at all, because if you want to know something about the code you ask the agent. I can't remember how anything works after 12 months anyway, so I would frequently have to spend ages grepping my own code when a customer came back and asked me to change something in a system we hadn't touched since last year. Asking an agent the same thing takes minutes and is way more accurate (and fun!)
I would question the last part. In my mind the more you let go of control over your codebase the more likely that it will drift way from a place where it is still comprehensible to you, and also your comprehension skills atrophy, and with that, your ability to ask good questions and to prod your agent in a correct directions weakens, leading to more wild goose chases and burned tokens.
This is all keeping in mind that for throw away or small applications, maintainability is not that of important of a value so this doesn't affect all codebases.
I dunno, I've built a production billing system for my small telecom company, a first version of a Multiplatform app with some novel technical features, and multiple internal tools for a company I work for, which replace a bunch of tools that were strung together using various off the shelf tools. I've been working with agents for about a year. I haven't noticed any cognitive or comprehension decline. I've built things that would have taken a team of offshore devs multiple months on my own in 4 - 6 weeks, including my own coding agent harness which runs an LLM gateway and has mobile, desktop and web apps which is now in use by non-technical colleagues to build and maintain apps on the same platform.
I don't know any more about KMP, Kotlin, Compose, Bash or React than I did a year ago. I'm not that familiar with any of those technologies (well, I am pretty familiar with bash but not to the level at which it's coded by agents), and I have never run into a situation where I felt like it would be better or faster for me to learn them and go hunting through the code to find some problem or other.
Maybe I'm heading towards a cliff somewhere in the future, but based on my experience of building software for 20+ years I'm not feeling anything but optimism so far.
Fair, but based on your experience surely you would agree that 1 year is not really enough time to start seeing codebase design issues from accumulated cruft, misaligned intents and other maintainability issues, this app is still in the honeymoon phase.
Haha I’ve seen apps that never got RELEASED because of code base design issues. As I said maybe there’s a cliff somewhere but I’ve managed enough teams where I wasn’t reading the code to have an understanding of what unsalvagable looks like. I’m not seeing any red flags!
> I described the problem to the agent and it figured out WAY faster than I would have been able to that the customer's clock was set incorrectly.
:blinks: The architecture of your service relied on customer clocks being correct? That is, you built a distributed service without a clock synchronization primitive that relied on the clocks being sychronized?
I don't know man, even AWS gives you cryptic errors if you have a drifting clock and try to perform some operations. Feels like a pretty forgivable mistake.
I’m not sure that deploying a custom clock synchronisation system would be warranted to show a countdown timer on the screen. The fix is to accept that the interface may be potentially inaccurate by a few seconds and send the relative time rather than the expiry time. Also probably to make the expiry UI stable (ie. have a “try again” button rather than flipping back to the start screen when the timer expires).
I also think that expecting that a computer connected to the internet in 2026 has the correct time isn’t too much of a long shot and things like 2fa QR codes rely on correct timing anyway.
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)
I already migrated all of my projects off rails, moving to fastapi, due to a combination of DHH's political bs and Ruby's fumbling of progressive typing/type hints. I actually just completed the migration a couple weeks ago.
I'm now doubly-glad since it seems like, indeed, the bdfl has lost both the plot and the B. The fact that Omarchy is also some weird corporate-sponsored AI-pilled linux reskin is further concerning.
In retrospect, his jamming of things like thruster, hotwire, etc etc into the framework and then now basically abandoning them has me grateful I didn't adopt them, even though I thought they seemed pretty well-intended at the time.
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.
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.
But they fill different niches, there's no way I'm going to choose Rust+Axum as much as I love Rust for an ecommerce/CRUD vs something as batteries-included and expressive like Rails or Django.
And yet people build sophisticated apps with them anyway, because there are plenty of components you can bring in piecemeal in any language ecosystem. You can even do this in Ruby without Rails.
By way of example, "react doesn't have a router" hasn't stopped it from becoming the dominant frontend framework.
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.
Rails has died many deaths over the years. I suppose its ironic that yet another one will be at the hands of its creator, as part of the keynote of a Rails conference he created because the community tried to have one conference where he wasn't the focus of attention.
All this does is justify the people that have been trying to move on from DHH for years. If his politics didn't do it, or his bullying, maybe the fact that he doesn't even use Rails himself will pull the wool from their eyes.
Rails itself will continue. I see no reason to stop using it.
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.
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
Oh man! now I really need to see an AI edit of the presentation were he storms out at the end to the tune of Simply the Best... Shit! I cant get it off my head
I get the whole “we don’t have to read the code anymore” Schtick from most product devs, and DHH I guess is at his core a builder / product dev whatever.
But the development of something like rails pushed forward the state of the art in ways that LLMs now replicate.
The point being like - someone has to keep writing programming languages and frameworks and libraries. Like - someone has to be thinking what the code looks like for LLMs to have patterns to match against, right?
> someone has to be thinking what the code looks like for LLMs to have patterns to match against, right?
Assuming no new paradigms on the hardware side that no longer fit into our current programming models, do they? Rails' claim to fame was eliminating "XML sit-ups" to improve the developer experience, but who cares how many "sit-ups" LLMs need to do?
At large enough scale, I suspect it'll become a problem. At the moment part of the appeal is how effortlessly models absorb menial work, but I do wonder if eventually it'll be too wasteful at large scales to sustain it. Maybe not, though.
Rails didn’t really push forward the state of the art, though. Not compared to something like DirectToWeb in WebObjects, where instead of static code generation, it did dynamic site generation with open-ended rules.
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.
These people who refer to them selves as a "Rails Engineer" (or substitute any other language/framework) and fail to realize that there are other tools in the box are of course first against the wall in the AI-driven future.
A carpenter who only knows how to use a hammer isn't a very good carpenter.
Rails is the most cult-like, anti-learning, anti-choice and even anti-engineering technology I have ever used. It does NOT want you to make your own choices, it does NOT want you to decouple from the framework, it does NOT want you to grow. It’s frightening.
I mean, in an app that uses Rails by-the-book, you won’t even find a class instantiation. No call to new. You won’t find a class that does not inherit from a framework bass class either. The framework handles everything, don’t worry.
People are reading into moving to native apps for each OS for an email app as a move away from Rails or that Rails is dead. The hot-take headline could be "Web applications are dead!" Rails, Django, Laravel, HTMLX, every one of them is in the same spot Rails is in.
We as an industry have been abusing HTTP and HTML for 2+ decades now by building web apps that were traditionally installed client/server applications or standalone client applications. There was a time in the industry that managing all the OS versions, patches, etc. was extremely labor intensive, hence the move to the web. If the cost of building native apps is near zero, in comparison to before AI, then how many web applications are better suited to client/server apps?
Take everyone's favorite app (sarcasm) - ticket tracking for IT or software work. Back in the day (late 90's) this was an installed app, the UI was extremely responsive and restrictive. People building native apps in Visual Basic didn't have to deal with HTML, CSS, and all the trade-offs of a markup language for an application, they had modules/components they could build for UIs. There wasn't weird DOM hierarchies, a data transform to text, send it over HTTP with auth, protect the web server that is open to anyone on the planet to hack, transform from text to data types, save to a database. The native app had a database driver in it or nearby and you did SQL from the app to your database server.
We can containerize application runtimes now. Look at what 37signals did with ONCE as an example, yes they are Rails apps but they could be anything that reduces IT install time compared to the '90s.
My takeaway from that keynote (watched the whole thing) is we need to re-think everything in software: process, tech stacks, architecture, etc. as the industry moves forward. AI has advanced a lot in what it can do in the last 10 months, it might plateau at some point and become another usable tool, but what it opens up is the ability to do things differently because the cost of creating (and throwing away crap output and re-creating) is very cheap.
The web as an application delivery model is very complicated compared to building small native apps. If your average Joe or Jane is going to be creating apps, I would think the thing to reach for is not web.
IMO, something like Basecamp would not be any better as a 'native' app. (probably worse as web tech makes the 'polish' more accessible.)
Not to mention, those VB client/server apps were not as popular with users as HN likes to reminisce. And modern IT departments have often completely banished that stuff.
Well naturally, Basecamp is collaboration software that class of apps probably belongs on the web.
There are probably others that don't need HTML user interfaces. I wasn't suggesting to use VB but there has to be modern UI native/client app frameworks or libraries. The problem IT departments had (speaking from personal experience) was the variation of client machines, DLL "hell" (shared library version conflicts) and patching. If the app is delivered and run as a container on the client's machine, a lot of those issues go away.
RIIR when? On a more serious note frameworks like Rails are getting less interesting because generating the boilerplate got significantly cheaper with LLMs.
If it is all true then, given the talk, we can establish those truths as not yet widely recognized. The point of the talk was, after all, to convince you of these ostensible truths, which would not resonate if it was already the prevailing understanding. Thus we can surmise that the "old way" persists because the masses don't yet understand those truths or are still adjusting.
Yet to be determined if they actually ship or do stuff at a reasonable rate. It only has any notoriety because of the subject matter and jumping on the hate-DHH train.
I guess they've been "laying the groundwork" of a fork that claims to just want to rename things and do little else for over a month?
Heh. It's always funny how people like that don't see their irony of being "inclusive" of "all backgrounds" just after having made a long list of people who they will throw out immediately for vague transgressions that are based on rumors and innuendo.
Where's the irony? They are happy for anyone to be a part of their community, unless you are making other in their community feel unwelcome. It's spelled out in their code of conduct for you. If you're making innuendos that make other people feel unwelcome, you are not welcome
because once you attempt to start to apply any label it becomes more and more vague. If I am a black man from South Africa who hates white people for perpetuating the Apartheid, am I welcome or am I a racist? If I am a man who's own father transitioned to being a woman and I no longer feel comfortable around trans-people because I lost my 'father figure', am I a transphobe or am I welcome? I understand these are deliberately obtuse examples. I bring them up because I never know where on the spectrum the line is drawn for these labels yet people will gladly declare somebody a 'nazi' because their dad watches Fox News. Even asking the question "when does somebody on the right go far enough to be considered a fascist?" often is met with the retort "defending nazis makes you a nazi".
We both know what the 'answer' is because we are normal people who understand nuance - a skill many people have lost as they have come to have their ideals defined by their identity, not the other way around.
> Just because some people calling someone a nazi are wrong doesn't mean everyone calling someone a nazi is wrong.
Sometimes they aren't just wrong, they are the loudest.
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)
Aside from the actual politics, DHH is clearly in "fuck you mode". I certainly don't trust that he's going to make decisions in the interest of the broader rails community.
That post called for deportation and not killing of illegal immigrants. If you people ever interact outside your bubble, those are normal opinions held by normal people (even though I would not consider DHH normal) and you people are snowflakes.
In any case railers are screwed (or railed, if I may). Either use the upstream which DHH is going to slopify and slowly kill, or use these forks by left-fascists who might happily sabotage you for perceived wrongthink in future.
In the absurd post-truth future we find ourselves in a situation where wrong think just means anything right of what Hasan Piker thinks on a given day.
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
Rails needs hard break from DHH. He has been toxic for the rails community for a long time. I sincerely appreciate his many contributions to rails, and his shaping of rails, but it is beyond time to cut ties. He's clearly not interested in rails any longer.
DHH founded Rails World (as far as I know). What a wonderful way to tell the whole community to F'off than to sell tickets to your conference then tell them not to use the technology. If DHH wants to vibe code everything in rust/assembly or whatever claude tells him to do, let DHH do his own thing, and let's part ways.
> "Lean in to the max possible. Because the utopia is almost here."
Man. I use AI daily (in a more nuanced, HITL way) but this is turning into some Jim Jones shit. It's a tool, dude. Relax. I'm all for encouraging people to build and create things but it's just downright fucking spooky to see how many people are kneeling at the altar with their respective sacrifices.
I moved from Ruby+Rails, though some other frameworks that I had no choice in (inherited the projects), to my new place of refuge: Kotlin+http4k.
Kotlin is a very acceptable Ruby-with-types. Even better than the new Ruby with optional types. It reads the same, it writes very similar, and it produces very similar "style" of code. I like the be on the FP side; Kotlin (as Ruby) allows that. I dont mind some OO in there; Kotlin (as Ruby) is okay with that. The benefit is a much larger community, JetBrains products that work well (and have free versions for Kotlin) and the JVM (interop with the Java ecosystem means there's a lot of libs you can use).
http4k is a library much like Rack in Ruby. It does a bit more, but essentially they are similar.
I prefer SSR over SPA. With Ruby I used HAML. Now I use kotlinx.html, which is "just Kotlin" (it compiles as Kotlin, allows me to put breakpoints, and mix in bits of logic --in Kotlin obviously-- where i need it. Much better than HAML (or ERB, or...).
I never liked Ruby's ORM. I just dont like ORMs. So I wrap functions over SQL statements that are strings. I do my SQL interpolation with Jdbi. Works very well, and, no ORM.
The test suite runs really fast and tests with a live db. I test that all SQL statements still work (one test per SQL statement; with a non-empty result to ensure the row decoding works).
All libraries (JARs) together amount to 11MB. That's all! I really like little libraries. As a reference SpringBoot (java's Rails) or Hibernate (java's ActiveRecord) require at least 15MB each!
Overall I'm happier here than with Rails. I just like static typing more nowadays, and prefer a "bunch of libs stringed together for my project" over a "framework".
I really appreciate Rails and DHH's approach though: I learned a lot about web development by using it (and Rack, and Merb). Much more than from Django or PHP or JSP/etc. But I'm okay with having moved on.
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.
> so they’re using LLMs to build native applications for every platform they support.
People say LLMs will let us build native apps instead of Electron, but is that missing the point? I thought people turned to Electron for a reason: building a fast, rich, collaborative Markdown editor on macOS is notoriously hard. Neither SwiftUI nor AppKit makes handling those rich interactions easy. AI can do wonders, but can it really overcome the inherent limitations of macOS's native UI frameworks?
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.
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!
You can tell what type of framing the article will be about AI by what social media they choose to use and link in the footer of their website. It never fails.
You're fucking rails programmer. You're the best of of the best. This is goddman Top Gun I'm looking at here
-- DHH, Rails World 2026 opening keynote, moments before calling everyone loser
The author should stop whining and complaining. Be grateful for what DHH contributed all these years for rails. Also,RoR is open source, so nothing prevent the author to contribute/participate to rails governance/features if he's not happy.
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.
Rails, PHP, django, and all rapid app development frameworks all made an important tradeoff between development time and system performance. Rails would struggle with more than a few dozen QPS. You might get 100, but not 10k, 100k or anything near the capability of the hardware (even 20 years ago)
That tradeoff is no longer necessary. There is little benefit to making such an expensive tradeoff, at a time when the hardware cost is skyrocketing.
Stop clinging to old tools as if they were a religion.
DHH may have chosen an unwelcome audience (at first) for that message, but what value is preaching to the choir? He has a long relationship with the Rails community, and it's an honest , timely and relevant message.
'Overrated Ruby programmer finally tries fast languages in domains they are clearly better suited to than Ruby, now that he does not need to write the code himself. He unsuprisingly draws the wrong conclusions and also inevitably mentions his Linux for techbros project, since this is his conference and his keynote.'
so glad I chose Python way back in 2005. The emergence of Rails with Ruby's horrendous perl-esque syntax (oh, and "convention over configuration", a terrible idea borrowed from PHP) and the showboat personality of DHH at the top (which has gone mostly predictably) only inspired me to improve Python's ecosystem even more. I'd like to say Python has come out on top in terms of remaining relevant.
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
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.
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..
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.
I must admit I haven't run the numbers, but if this can be trusted, sync PHP isn't far off from golang - while async does rather well?
I probably would only reach for PHP if I needed to run on shared hosting (or rather, my customers did) - in which case few other technologies would compete, obviously.
PS: golang is much faster at cpu - in this case one might argue a fairer comparison would use a compiled extension on the php side IMNHO - as that seems a likely path if a real project was cpu bound on a few small functions.
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.
What I do not understand with the "languages do not matter"/"frameworks do not matter" is ultimately the following:
What a good language or a good library (and to a lesser degree also a good framework) does is to pre-compress ideas into well understandable and composable chunks.
Examples:
`printf("foo %d, %3.2f %s", ...)` abstracts/compresses a general strategy of shuffling bytes into the correct ascii/utf-8... format.
An LLM could also write the raw assembly or bytecode for doing the same thing, but for one it would take much more tokens and to apply this pre-invented concept, and second without the concept already invented there would be no "information pattern" in existence that the LLM could have learned or refer to.
`list.map(...).filter(...)...` are patterns that (when applied strictly in a functional sense) go hand in hand with laws like `map` not affecting the number of elements, and filter producing no new elements etc...
These are also patterns that are already invented and depending on the language these restrictions are checked. Just reading `map` somewhere can tell you (and the LLM) a lot, and writing `map` instead of while, for or jmp will capture and express much more information. LLMs would not have been able to learn these concepts if they did not already exist. And even if such a general pattern would be discovered by an LLM somewhere inside its learnt parameters, it would not haven given this pattern a name that it could/would tell you. And if you do not know the name for such a concept how have a much harder time prompting the LLM.
Expressing computations in a well understood algebra allows for symbolic manipulation and simplification. like `5 + 3 == 3 * 5 == (1+1+1) * 5 == (5+5+5)...`. But algebraic manipulation requires a symbolic language with precise rules to describe what manipulation is allowed. In AI-speak you could say the language itself is a harness or a sandbox to guide and restrict whats possible. Doing advanced math proofs is only possible for LLMs because languages like LEAN provide a strict guideline to build upon.
In short, two extremes: If LEAN is so great at proofing correctness and LLMs are so good at LEAN, why is not from today on everything (windows, linux, basecamp, hey, gcc, rustc, blender...) translated into LEAN? Why bother with rust at all? On the other hand if languages do not matter anyway and LLMs are able to recognize all the pattern on their own, why not let the LLM output and iterate on the binary bytecode to generate a self contained binary directly?
LLMs would need way more tokens using langs/frameworks that dont have native features already built in? Even with LLMs I would take 10x the amount of time/tokens until I have something I could've just done with Laravel in the first place.
A more concrete example: Laravel has a built in rate limiter, with Go I'd either have to tell Claude to install some rate limiter package from some random ass dev or implement its own which would consume tokens/time...
Also your argument about PHP/Laravel being risky is pretty funny as everything is risky and most of the internet runs on PHP...
> I’d love to stop paying attention to him, but I build applications with Rails, so his actions affect me and my clients.
DHH purpose-built a tool so this guy could build a career on it. The guy delightfully uses the tool to get rich. And he wants to hate DHH--probably does--but no, DHH *owes him more*. And has lots of advice for DHH about how to manage his own creation.
The entitlement in 2026 is so wildly off the charts.
Why does the author know better than DHH how to lead rails? How does the author know how the community will react to the keynote?
> The problem is that he stood up at Rails World and told everyone that he was moving his product off Rails
Maybe the author doesn't understand the use-case for rails? I think DHH does. With enough success, there comes a day that you move your product off of rails.
Rails is great for agentic coding, which DHH also said.
Yeah, the author's opinion would be way more justified if Rails were an open-source project with thousands of contributors and not just the hard work of DHH himself in total isolation.
The author's opinion about the direction of rails would be more justified if he was a contributor, which he doesn't appear to be.
But no, you mischaracterize my position, which is that his opinion would be way more justified if he was critiquing someone who had led a failure, or if he had some really valuable insight that DHH didn't have, or if he had led something even more successful than what DHH has managed.
I'm not seeing how DHH's success has any bearing at all. The captain has announced that the ship is sinking. In fact, he left in a lifeboat several months ago. Whether or not he was a good captain has nothing to do with how the remaining passengers should handle his departure.
Related:
Rails World 2026 Opening Keynote [video]
https://news.ycombinator.com/item?id=49817680
> 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.)
A chatbot is worse than a CLI app: a CLI app does exactly what you ask for, and has a manual documenting exactly what command do what, and the output is consistent, the same command does the same thing period.
A chatbot using an LLM of course not, it suffers from hallucinations, it may do what you want but there is a change it won't and you have to fight it to get the desired result.
Chatbots are far WORSE than traditional UI for everything. If some product has a chatbot functions it's the first thing I disable, if it's not possible to disable it, I avoid the product.
And GUI applications are typically preferred, at least for the normal people and not us nerds, to CLI applications, since you know people like moving a mouse and clicking on buttons (or tapping them on a touchscreen) that learning commands: a chatbot doesn't make the CLI experience less awful for the average user, and for the nerd user, he prefers to use the CLI directly (replace asking the chatbot with man or --help and you don't need to emit tons of CO2 and transmit your personal data to a datacenter on the other side of the world to do stuff you did with MS-DOS)
> a CLI app does exactly what you ask for, and has a manual documenting exactly what command do what, and the output is consistent, the same command does the same thing period
This is a very software-engineery point of view and totally false for the ordinary user. Heck, it is even false for me as a software engineer.
> since you know people like moving a mouse and clicking on buttons
No, they like well-designed user interfaces, and the UI design of a typical CLI is abysmal.
> Heck, it is even false for me as a software engineer.
Amen
Honestly, the gap from knowing which command line tool you probably need, to the command that does what you need... Prior to AI I have replicated probably a thousand command line capabilities in Ruby because I just couldn't be bothered.
> the UI design of a typical CLI is abysmal
The nice thing about a CLI is that even if you don't like the interface you're given, it's trivial to put an interface you do like in front of it. Much harder to do that with a point and click interface.
> a CLI app does exactly what you ask for, and has a manual documenting exactly what command do what
*a small percent of apps behave like this
> it may do what you want but there is a change it won't and you have to fight it to get the desired result
The vast majority of all software made in the last ten years falls into this category. This includes the goddamn operating system itself.
I don't think you're making the argument you think you're making.
>> Chatbots are far WORSE than traditional UI for everything. If some product has a chatbot functions it's the first thing I disable, if it's not possible to disable it, I avoid the product.
The chatbot we added to our B2B product is by far the most popular addition we've made this year. Our users are not tech-savvy, they use a lot of apps everyday and don't want to have to learn and keep up with just another UI. So they like being able to type their wants and needs in plain language (or speak it into their phone, if they are in the field) and get a plain language response back with embedded images and charts.
YMMV of course.
Popular and far worse is not really an unusual combination
> So they like being able to type their wants and needs in plain language (or speak it into their phone, if they are in the field) and get a plain language response back with embedded images and charts.
I note you didn't mention accurate and reliable.
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.
As a developer/user I hope for that outcome too — if everybody is using your app through an agent you might as well cut the maintenance cost and drop the GUI, or at least have a nice API alongside it to make it nicer for the agent. But I wonder what it does to the financial incentives to produce software.
I absolutely prefer a UI over talking to a chatbot. That sounds horrific.
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.
For sure! One of the big draws of malleability is that you can adapt it to your particular needs. Natural language is a UI just as much as a WIMP GUI, and for some tasks or some people it's a great one.
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.
What's an example of an app / UX that you really love which other apps may rely on chat for? I'd love to check them out.
"I think chat is a great entry point for many experiences. The approachability and flexibility are unmatched."
Just wait a few months/years and then some smartasses will come with a novel approach nobody ever has thought of before. Let's call it "context menus". They will give rapid access to the most used features without the tedious typing.
Until MacOS 27 the text context menus had items "Writing Tools" and "Proofread". Quick and efficient. MacOS has dropped these items and replaced with "Ask Siri". Now I have to type "proofread" every time and pray Siri agrees that it should proofread the selected text. Once it has done that, do i have to type "replace"? I don't even know.
There is a reason why UIs became popular. Command lines are fine but hard to discover and tedious to use. With AI it's even worse. You can't know for sure the AI interprets your commands in the way you intended.
I like this way of branching and adding context for the user. It would be interesting to make it more generalizable to other texts.
You gave me an idea :). The original motivation was to explore the Bible like I explore Wikipedia. I think this UX for Wikipedia would be really amazing. Someone should build it. I hope I don't get the itch to do it this weekend!
https://trysojourn.app/writings/explore-the-bible-like-wikip...
> 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.
> 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.
Yes you caught me out in a bit of exaggeration there. For the topmost level of tasks people typically do want a low-latency, high-bandwidth UI for displaying and manipulating the information they care about.
> "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"
Yes, this is the crux of the whole discussion. The paradigm is called "Intent-based UX".
>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.
Never because a lot of software is written for the human to use.
>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.
In case it wasn't clear, that was intended as a somewhat satirical representation of the position I was discussing :) An important part of any ‘universal UI’ — and arguably the hardest part of building it — has to be that it allows feedback from the API about what and how to display, which is always in tension with the malleability/universality aspect. People are trying to solve that for chatbots right now, with limited success so far.
> 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.
I think the popularity of these chat interfaces disagrees with that to some extent. We do already have malleable software for people who can program — the problem has always been bringing it to everyone else.
> 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.
Exactly this. Each new hype cycle, everything must be shoe horned into the hot new technology. So now there's a push to use chatbots for everything, why even have an interface? Just ask the chatbot to make one for you! Because the user totally knows what they want and what works, we've been wrong all these decades when it comes to UIs and customer preference. /s
> 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.
The last thing people want is interacting with a chatbot for anything that doesn't require a chatbot.
> in terms of functionality and value to users, software ought to be malleable and composable.
No, it shouldn't. The last thing people want is for software to change from under them, or be replaced with the bullshit that is a chatbot.
> plaster a ‘programmable’ interface on top of unstructured data/interface meant for humans
Ah yes. I can imagine everyone "plastering programmable interfaces" on top of daily stuff they want to do. Like buying a ticket to a museum. Ordering Doorsash. Sending a meme to a friend. Renting a car...
Most managers don't read the code of their direct reports. They just trust that the code is "good enough" and that there are enough other processes in place to catch bugs before they cause too much damage. I think I'm a pretty skilled programmer, or I'm at least good enough at interviewing to convince other people of that, but it's pretty obvious from comparing LLM generated code to code I'd write myself that in many domains LLMs are superior to me. They do make mistakes, but so do I, and those mistakes are eventually found and corrected.
We're in the very early stages of LLM driven programming, so it's hard to say how it will all shake out, but my anecdotal experience is that LLM written software is very reliable and easy to extend and develop. I have a side project that is about 90% LLM generated code (about 25k lines of production code and a similar amount of test code). This is a revenue generating product and I've had no issues with reliability, security, or performance.
For what it's worth this app is a rails app and I have no plans to switch to anything else. Rails works nicely, the LLMs extend it easily, and almost everything is I/O bound so I don't need C++/Rust level performance.
> I think I'm a pretty skilled programmer, or I'm at least good enough at interviewing to convince other people of that, but it's pretty obvious from comparing LLM generated code to code I'd write myself that in many domains LLMs are superior to me.
there's an important caveat here - LLMs absolutely can write better code than me, but they can also write far worse code, and often don't seem to be able to tell the difference. I find myself spending a lot of time prompting the bots to refine their code in specific ways that I only know about because I read the generated output.
Too much discourse creates a false dichotomy of "awesome, wonderful, hand-crafted code" vs "shitty AI slop."
A lot of hand-crafted code is pretty bad. This is true even with talented engineers: there are often edge cases they did not think of... and in many cases, could not have thought of.
And AI code is pretty good if it's steered and vetted by a knowledgeable engineer. It is clear to me, and has been clear for a long time, that "talented engineer plus AI" is the winning combination and will remain that way for at least the near future.
I still review PRs, all of which are written by agents. I almost never have meaningful feedback to offer unless it's feedback on the architectural approach. And even then, a lot of architectural/coding patterns that I've been a stickler for in the past mean less to me now because those patterns served to create maintainable code for human beings, which just isn't a priority anymore.
Yeah let’s be real there was a ton of slop around before AI
"If every product is used by an agent driving a CLI, what’s going to differentiate Basecamp or Fizzy from the cheapest alternative?"
At that point, why even bother with "driving a CLI"? I have a hard time seeing how this all doesn't go away soon. At the current trajectory, I am not seeing a future where software like Basecamp or Fizzy or the cheapest alternative are competitive with "Claude, build a basecamp-style project management tool for my team."
I don't mean to say that thoughtfully built, opinionated software doesn't have intrinsic value, I believe it will always be "better" in certain aspects...I just can't fathom that a market for it will exist in very short order.
I would LOVE to be talked out of this perspective.
I’m building a language learning application [1]. It uses spaced repetition, built upon FSRS, an open source algorithm.
I’ve spent the last three years tweaking away at this algorithm. There are so many little details that have had to come together to make it an enjoyable experience. For example, take the one problem of balancing multiple language: What is the best way to balance multiple languages? How should you switch between them, and how often? What happens if you are over performing in one language and underperforming in another? What happens if you have more reviews in one language than another that isn’t in line with your priorities? How do you deal with competing learning speeds and language priorities? Spiky review burdens? What happens when you change your language priorities?
This is probably the most trivial part of the algorithm, and it took years of trial and error and dozens of iterations to get it to feel right. It requires knowing about SRS, the FSRS algorithm, language learning principles, and even then tons of experimentation, trial and error, and hundreds of days of daily usage.
I’ve asked LLMs every step of the way what to do. I’ve probably taken <1% of the advice I was given. Just asking an LLM “build an SRS app that balances multiple languages” would produce a result, but one that would definitely be terrible to use, and probably would end up slowing you down, not speeding you up. Explaining to it any of the issues that you would come across when using it will likely suggest to changes that will only make things worse, based on the thousands of terrible ideas I’ve seen confidently produced.
The hard part of a product is not the idea, but the experience of using it. The valueable work is normally not in the big feature specs, but the hundreds of little paper cuts that have all been smoothed over. The time saved is not because you don’t have to code it, but is from not having to become an expert in several different fields.
[1] https://phrasing.app
> The hard part of a product is not the idea, but the experience of using it.
solid
Phweww - 100% agree and am seeing that with my app as well! It's been one of the most joyful pieces of building it, is that I am really making something for myself and have been using it and continually adding the things that I want.
This is the process that nothing can do for us.
The phrase I've found useful is Yegge's "Crystalized Cognition" https://steve-yegge.medium.com/software-survival-3-0-97a2a62...
Claude can 100% build you your own basecamp quickly, but there is a lot of good thinking that has gone into a product. Edge cases. Integrations. Clarity of thinking and ways to extend it. Agents love standing on the shoulders of good crystalized cognition (grep, curl etc), but I think that extends even beyond base CLI tools.
Which is not to say that "cheapest alternative" won't be much more important than it is now, but the tools that will succeed are the ones that solve clear problems with accessible CLI/tool-call like interfaces and take significant load off the agent running, while doing it efficiently and cost effectively so they are clearly better than building it yourself.
To be fair, there will be a ton of margin collapse and that will be unachievable by a lot of current orgs / structures.
Why waste tokens and ops team time and developer bug chasing time when you can get a signed contract with guaranteed uptime and support, and have those people be building something you can sell instead?
It's all opportunity cost.
Edit: throw in mandated security audits and maintenance for SOC2 compliance or whatever else you're on too, depending on the industry you're in.
People don’t actually want to build software. There will still be a market for hosted software that feels like magic. The next shape and UX is still getting fleshed out.
Also: the coded apps that AIs build are unmaintainable without a tech background. They may work for exactly their proposed happy-path and that may be great. But over time I can’t see how it’s possible these apps get maintained.
In the current/legacy market, people accept bugs in software because software was expensive and the alternatives are often few for that same reason.
Tomorrow's software will need to be _perfect_, or else it won't differentiate from "Claude, build a basecamp-style project management tool for my team".
Why would you build an app at all? Why wouldn't Claude just be the app itself? You ask it to set up your UI in the web app and you just use Claude for your entire workflow.
We're only a few persistent widgets and a better persistent storage story away from this possibility.
> Why would you build an app at all? Why wouldn't Claude just be the app itself?
Because then you don't have to keep spending tokens to use the app.
This is kind of like Alan Kay's idea in the 70s/80s for the Smalltalk image being the software that users customize to their needs instead of buying the software, except now it's a chatbot/agent interface instead of a customizable, integrated Smalltalk IDE.
described this way, his vision sounds more like an excel spreadsheet than an agent
I know this is not exactly a nuanced take, but why would anyone take advice about the future of technology whose contributions are now limited to an opinionated email app? I appreciate that tech is and will change even more, but relegating an entire ecosystem to the dustbin because you're feeling bullish about LLMs seems...premature.
DHH is the creator of rails and you are listening to a very cherry picked take, like all of the internet these days.
His whole argument which I agree with is summed up in a section where he shows a clip of himself 21 years ago saying “look at how much code I’m not writing” and that is the core thesis of rails. And agents provide a better solution than rails with less downside and more upside. So now that the core reason for rails has been overturned, instead of holding onto an old inferior solution to a problem, he has moved on because he is a value driven pragmatist at heart.
He literally built rails to write code as close to English as possible. Expressiveness, get code out of your way so you can focus on solving the non technical problems, stop getting stuck in engineering decisions and focus on business and UX, etc. Now whether his values were truly accomplished some people can argue but what those values are is pretty clear.
DHH created rails for himself and he has been unabashedly firm on his own values, it’s Steve Jobs esque, provides great clarity and focus but pisses people off who deviate from that focus.
Lots of people jumped on rails but don’t share DHH exact values. They see rails as a community ownership not a DHH ownership and they believe in the framework beyond just a tool to solve problems. More specifically they rely on it and helped build it up well beyond “just a tool to write code more like English” to a robust, well maintained usable platform you can build and run sophisticated real world applications with.
DHH has left rails because it no longer is the right solution for his set of values, that’s it. Others in the community rely on Rails to run their systems and will continue to do so until the end of time because let’s face it Rails has been pretty mature since rails 5/6 and despite all the exciting “progress” it’s just a solidly good framework that doesn’t really need to keep up with the trends.
The Ruby on Rails community has always been hard to separate from DHH.
The fact that he went on stage at a Ruby on Rails keynote and talked about his current passions instead of Rails is kind of typical for his style of leadership. The Ruby on Rails project and community were always the DHH show, even though there were years where they tried hard to act like it was an independent community run project now.
This late in the game, I think most RoR fans who are committed enough to attend a RoR conference have aligned themselves with DHH more than RoR, which is why you see some positive responses to a RoR keynote that didn't talk about RoR.
Agree, DHH is a bit like Elon - some folks are all-in on him while others see him as toxic.
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.
Yup - this! A big ol' experiment, we shall see how it goes. I'd be curious (if they exist) on some larger / older orgs with internet scale customer bases that are full in on AI development with limited human reading of it to see how they fare.
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.
>The actual code and architecture is where it still lacking IMHO.
My experience is that the more structure and constraints you can place on what the LLM/Agents actually do, the better they perform. If you just let them run wild a la "make me an app that will make a million dollars MRR, no mistakes", you get a clusterfuck. And it gets more clusterfucky the longer it goes on.
> 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).
dhh did just what you did and apparently made a bunch of mistakes in his powerpoints.
I don't understand what you mean by "just what you did". I'm not making PowerPoint presentations.
vary similar processes. vibe code/vibe create a presentation. he also knew what "shape the graph should look like" but still had errors in his powerpoint. if you can't trust it with a powerpoint i'm not sure why you can trust it for other low stakes things.
Have you got any sources? The only thing I can find is the 2026/2006 mix-up which feels like a classic typo rather than AI mistake. There are other typos there which makes it less likely the presentation was fully generated. And it means that the result wasn't reviewed - looking at code is irrelevant in comparison.
20+ years of software experience.
Coding part of the job (as in „typing with my bare hands“) is gone. Now I get to spend more time making product decisions, capturing constraints and executable specs. Resulting code is boring, consistent and gets the job done.
Aren’t executable specs not code?
> 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.
oh I meant "reading" is slower not "running", but I guess you may still be right for large context. The article is about that though (a dev giving up on reading code entirely because that would be too slow).
Do you have 100% trust in all devs you work with?
Most code just has to be good enough.
I don't read the code my LLM produces unless I am investigating the code. I actually don't know Kotlin, or React.
My version of "code review" is "test failure investigation" and I have a hard rule in my repos that agents never modify existing tests while they're implementing features. This means that when I run the tests after they do a bunch of stuff, I see all the tests break. Mostly they're stale assertions and we patch them up. Sometimes they're regressions and we patch those up, and sometimes I notice something dumb and dive deep into a facet of the architecture that can be improved, spend some time exploring it then get the agent to implement.
I think it's a better approach than trying to read everything and catch bugs or improve quality because you wind up focusing the things that actually matter in the real world rather than the things you think might matter.
This is how I've always approached working with offshore devs too. Focus on testing for quality control, not "code quality". After all, you're going to look at the code you wrote 5 years ago and think it's shit anyway right? So all your code is shit.
Regarding "lack of understanding", here's a recent anecdote: I had a bug in a production (but relatively new) system. The customer was texting me saying that they couldn't scan a QR code because it kept "skipping and glitching". They sent me a short video. I described the problem to the agent and it figured out WAY faster than I would have been able to that the customer's clock was set incorrectly. They turned on network time and bingo bango, the thing worked straight away.
I don't thing "comprehension debt" matters at all, because if you want to know something about the code you ask the agent. I can't remember how anything works after 12 months anyway, so I would frequently have to spend ages grepping my own code when a customer came back and asked me to change something in a system we hadn't touched since last year. Asking an agent the same thing takes minutes and is way more accurate (and fun!)
>Regarding "lack of understanding", here's a recent anecdote: I had a bug in a production (but relatively new) system. The customer was texting me saying that they couldn't scan a QR code because it kept "skipping and glitching". They sent me a short video. I described the problem to the agent and it figured out WAY faster than I would have been able to that the customer's clock was set incorrectly. They turned on network time and bingo bango, the thing worked straight away.
That only describes a happy path though -- I also had many instances where there's an issue and just describing it to an agent immediately identifies a fix and it all goes faster compared to me having to "load up" the flow of codebase into my brain first. But I also still have instances where it thinks it identifies an issue correctly, spits a fix which doesn't work and looks wrong. You point out that it does not make sense because of X, it agrees and spits out a new fix, which is also wrong and you start out on these back and forth wild goose chases, at this point I usually give up and do it the old fashioned way by understanding what is actually happening. If it is within an agent loop, there may be no back-and-forth to waste your time but then you pay with wasted tokens when it will eventually gives up or you stop it.
>I don't thing "comprehension debt" matters at all, because if you want to know something about the code you ask the agent. I can't remember how anything works after 12 months anyway, so I would frequently have to spend ages grepping my own code when a customer came back and asked me to change something in a system we hadn't touched since last year. Asking an agent the same thing takes minutes and is way more accurate (and fun!)
I would question the last part. In my mind the more you let go of control over your codebase the more likely that it will drift way from a place where it is still comprehensible to you, and also your comprehension skills atrophy, and with that, your ability to ask good questions and to prod your agent in a correct directions weakens, leading to more wild goose chases and burned tokens. This is all keeping in mind that for throw away or small applications, maintainability is not that of important of a value so this doesn't affect all codebases.
I dunno, I've built a production billing system for my small telecom company, a first version of a Multiplatform app with some novel technical features, and multiple internal tools for a company I work for, which replace a bunch of tools that were strung together using various off the shelf tools. I've been working with agents for about a year. I haven't noticed any cognitive or comprehension decline. I've built things that would have taken a team of offshore devs multiple months on my own in 4 - 6 weeks, including my own coding agent harness which runs an LLM gateway and has mobile, desktop and web apps which is now in use by non-technical colleagues to build and maintain apps on the same platform.
I don't know any more about KMP, Kotlin, Compose, Bash or React than I did a year ago. I'm not that familiar with any of those technologies (well, I am pretty familiar with bash but not to the level at which it's coded by agents), and I have never run into a situation where I felt like it would be better or faster for me to learn them and go hunting through the code to find some problem or other.
Maybe I'm heading towards a cliff somewhere in the future, but based on my experience of building software for 20+ years I'm not feeling anything but optimism so far.
Fair, but based on your experience surely you would agree that 1 year is not really enough time to start seeing codebase design issues from accumulated cruft, misaligned intents and other maintainability issues, this app is still in the honeymoon phase.
Haha I’ve seen apps that never got RELEASED because of code base design issues. As I said maybe there’s a cliff somewhere but I’ve managed enough teams where I wasn’t reading the code to have an understanding of what unsalvagable looks like. I’m not seeing any red flags!
> I described the problem to the agent and it figured out WAY faster than I would have been able to that the customer's clock was set incorrectly.
:blinks: The architecture of your service relied on customer clocks being correct? That is, you built a distributed service without a clock synchronization primitive that relied on the clocks being sychronized?
I don't know man, even AWS gives you cryptic errors if you have a drifting clock and try to perform some operations. Feels like a pretty forgivable mistake.
I’m not sure that deploying a custom clock synchronisation system would be warranted to show a countdown timer on the screen. The fix is to accept that the interface may be potentially inaccurate by a few seconds and send the relative time rather than the expiry time. Also probably to make the expiry UI stable (ie. have a “try again” button rather than flipping back to the start screen when the timer expires).
I also think that expecting that a computer connected to the internet in 2026 has the correct time isn’t too much of a long shot and things like 2fa QR codes rely on correct timing anyway.
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).
> Does anyone actually use Hey?
In the talk he said all Hey's traffic can be served on a Raspberry Pi. I think that pretty much answers your question.
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)
If you cancel, 37signals let you keep your hey.com address and auto forward mail to a new email address. :)
They also say that this is “just a courtesy” and not to rely on it.
BDFL works great as long as the D remains B.
When the B wants to F their D in your L, that's no good.
I already migrated all of my projects off rails, moving to fastapi, due to a combination of DHH's political bs and Ruby's fumbling of progressive typing/type hints. I actually just completed the migration a couple weeks ago.
I'm now doubly-glad since it seems like, indeed, the bdfl has lost both the plot and the B. The fact that Omarchy is also some weird corporate-sponsored AI-pilled linux reskin is further concerning.
In retrospect, his jamming of things like thruster, hotwire, etc etc into the framework and then now basically abandoning them has me grateful I didn't adopt them, even though I thought they seemed pretty well-intended at the time.
Funny, I migrated my FastAPI project to Rails 2 years ago and couldn't be happier.
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.
this ignores utilization and throughput
Peak throughput per day is 3k req/m.
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".
How does one run Windows 95 Paint in 2026? Are there people who earnestly use old school Windows tools?
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.
What are the newer more modern frameworks? How are they better than Rails?
Well, you have these:
- Rust: Axum, Actix Web
- Go: net/http + Chi, Echo
- C#: ASP.NET Core
- Java/Kotlin: Spring Boot 4, Quarkus
- Elixir: Phoenix
- TypeScript: Fastify, NestJS
- Python: FastAPI, Django
But they fill different niches, there's no way I'm going to choose Rust+Axum as much as I love Rust for an ecommerce/CRUD vs something as batteries-included and expressive like Rails or Django.
Sorry, but I need to know what makes Rust+Axum non-niche for ecommerce/CRUD.
There are some baffling picks here. Several of these are super barebones minimal frameworks that doesn't have even a faction of Rails capabilities.
And yet people build sophisticated apps with them anyway, because there are plenty of components you can bring in piecemeal in any language ecosystem. You can even do this in Ruby without Rails.
By way of example, "react doesn't have a router" hasn't stopped it from becoming the dominant frontend framework.
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.
Rails has died many deaths over the years. I suppose its ironic that yet another one will be at the hands of its creator, as part of the keynote of a Rails conference he created because the community tried to have one conference where he wasn't the focus of attention.
All this does is justify the people that have been trying to move on from DHH for years. If his politics didn't do it, or his bullying, maybe the fact that he doesn't even use Rails himself will pull the wool from their eyes.
Rails itself will continue. I see no reason to stop using it.
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.
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."
Oh man! now I really need to see an AI edit of the presentation were he storms out at the end to the tune of Simply the Best... Shit! I cant get it off my head
I get the whole “we don’t have to read the code anymore” Schtick from most product devs, and DHH I guess is at his core a builder / product dev whatever.
But the development of something like rails pushed forward the state of the art in ways that LLMs now replicate.
The point being like - someone has to keep writing programming languages and frameworks and libraries. Like - someone has to be thinking what the code looks like for LLMs to have patterns to match against, right?
> someone has to be thinking what the code looks like for LLMs to have patterns to match against, right?
Assuming no new paradigms on the hardware side that no longer fit into our current programming models, do they? Rails' claim to fame was eliminating "XML sit-ups" to improve the developer experience, but who cares how many "sit-ups" LLMs need to do?
> who cares how many sit-ups LLMs have to do?
At large enough scale, I suspect it'll become a problem. At the moment part of the appeal is how effortlessly models absorb menial work, but I do wonder if eventually it'll be too wasteful at large scales to sustain it. Maybe not, though.
The future is long.
Rails didn’t really push forward the state of the art, though. Not compared to something like DirectToWeb in WebObjects, where instead of static code generation, it did dynamic site generation with open-ended rules.
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.
These people who refer to them selves as a "Rails Engineer" (or substitute any other language/framework) and fail to realize that there are other tools in the box are of course first against the wall in the AI-driven future.
A carpenter who only knows how to use a hammer isn't a very good carpenter.
Why is Rails a hammer not Milwaukee/DeWalt/Makita/etc? A carpenter with only DeWalt brand power tools will do just fine.
Not if the job provides only Makita.
And before you say "a carpenter can switch from DeWalt to Makita just fine": that's why the analogy was made with a hammer.
Rails is the most cult-like, anti-learning, anti-choice and even anti-engineering technology I have ever used. It does NOT want you to make your own choices, it does NOT want you to decouple from the framework, it does NOT want you to grow. It’s frightening.
I mean, in an app that uses Rails by-the-book, you won’t even find a class instantiation. No call to new. You won’t find a class that does not inherit from a framework bass class either. The framework handles everything, don’t worry.
People are reading into moving to native apps for each OS for an email app as a move away from Rails or that Rails is dead. The hot-take headline could be "Web applications are dead!" Rails, Django, Laravel, HTMLX, every one of them is in the same spot Rails is in.
We as an industry have been abusing HTTP and HTML for 2+ decades now by building web apps that were traditionally installed client/server applications or standalone client applications. There was a time in the industry that managing all the OS versions, patches, etc. was extremely labor intensive, hence the move to the web. If the cost of building native apps is near zero, in comparison to before AI, then how many web applications are better suited to client/server apps?
Take everyone's favorite app (sarcasm) - ticket tracking for IT or software work. Back in the day (late 90's) this was an installed app, the UI was extremely responsive and restrictive. People building native apps in Visual Basic didn't have to deal with HTML, CSS, and all the trade-offs of a markup language for an application, they had modules/components they could build for UIs. There wasn't weird DOM hierarchies, a data transform to text, send it over HTTP with auth, protect the web server that is open to anyone on the planet to hack, transform from text to data types, save to a database. The native app had a database driver in it or nearby and you did SQL from the app to your database server.
We can containerize application runtimes now. Look at what 37signals did with ONCE as an example, yes they are Rails apps but they could be anything that reduces IT install time compared to the '90s.
My takeaway from that keynote (watched the whole thing) is we need to re-think everything in software: process, tech stacks, architecture, etc. as the industry moves forward. AI has advanced a lot in what it can do in the last 10 months, it might plateau at some point and become another usable tool, but what it opens up is the ability to do things differently because the cost of creating (and throwing away crap output and re-creating) is very cheap.
The web as an application delivery model is very complicated compared to building small native apps. If your average Joe or Jane is going to be creating apps, I would think the thing to reach for is not web.
IMO, something like Basecamp would not be any better as a 'native' app. (probably worse as web tech makes the 'polish' more accessible.)
Not to mention, those VB client/server apps were not as popular with users as HN likes to reminisce. And modern IT departments have often completely banished that stuff.
Well naturally, Basecamp is collaboration software that class of apps probably belongs on the web.
There are probably others that don't need HTML user interfaces. I wasn't suggesting to use VB but there has to be modern UI native/client app frameworks or libraries. The problem IT departments had (speaking from personal experience) was the variation of client machines, DLL "hell" (shared library version conflicts) and patching. If the app is delivered and run as a container on the client's machine, a lot of those issues go away.
RIIR when? On a more serious note frameworks like Rails are getting less interesting because generating the boilerplate got significantly cheaper with LLMs.
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”.
If it is all true then, given the talk, we can establish those truths as not yet widely recognized. The point of the talk was, after all, to convince you of these ostensible truths, which would not resonate if it was already the prevailing understanding. Thus we can surmise that the "old way" persists because the masses don't yet understand those truths or are still adjusting.
From the talk it’s clear, Rails needs to be forked.
isn't https://mosscap.dev/ a fork?
Yet to be determined if they actually ship or do stuff at a reasonable rate. It only has any notoriety because of the subject matter and jumping on the hate-DHH train.
I guess they've been "laying the groundwork" of a fork that claims to just want to rename things and do little else for over a month?
Heh. It's always funny how people like that don't see their irony of being "inclusive" of "all backgrounds" just after having made a long list of people who they will throw out immediately for vague transgressions that are based on rumors and innuendo.
Where's the irony? They are happy for anyone to be a part of their community, unless you are making other in their community feel unwelcome. It's spelled out in their code of conduct for you. If you're making innuendos that make other people feel unwelcome, you are not welcome
List of people thrown out as per the linked site: > nazis, transphobes, racists, or any kind of bigotry
Which part is the vague transgression?
because once you attempt to start to apply any label it becomes more and more vague. If I am a black man from South Africa who hates white people for perpetuating the Apartheid, am I welcome or am I a racist? If I am a man who's own father transitioned to being a woman and I no longer feel comfortable around trans-people because I lost my 'father figure', am I a transphobe or am I welcome? I understand these are deliberately obtuse examples. I bring them up because I never know where on the spectrum the line is drawn for these labels yet people will gladly declare somebody a 'nazi' because their dad watches Fox News. Even asking the question "when does somebody on the right go far enough to be considered a fascist?" often is met with the retort "defending nazis makes you a nazi".
I'd be curious to know your answers to these because they seem rather obvious to me..
Just because some people calling someone a nazi are wrong doesn't mean everyone calling someone a nazi is wrong.
We both know what the 'answer' is because we are normal people who understand nuance - a skill many people have lost as they have come to have their ideals defined by their identity, not the other way around.
> Just because some people calling someone a nazi are wrong doesn't mean everyone calling someone a nazi is wrong.
Sometimes they aren't just wrong, they are the loudest.
From this reply your answer could still be read either ways and that someone is still a nazi regardless of how loud someone is.
Those of the conservative persuasion love to use the loudness of some people to invalidate all condemnations of nazis, right or wrong.
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)
To be clear for anyone reading, the “personal ideology” here is racism with a white supremacist leaning.
Aside from the actual politics, DHH is clearly in "fuck you mode". I certainly don't trust that he's going to make decisions in the interest of the broader rails community.
speak for yourself, I never compare people to shoot wolves
That post called for deportation and not killing of illegal immigrants. If you people ever interact outside your bubble, those are normal opinions held by normal people (even though I would not consider DHH normal) and you people are snowflakes.
In any case railers are screwed (or railed, if I may). Either use the upstream which DHH is going to slopify and slowly kill, or use these forks by left-fascists who might happily sabotage you for perceived wrongthink in future.
In the absurd post-truth future we find ourselves in a situation where wrong think just means anything right of what Hasan Piker thinks on a given day.
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
No surprise.
2007-01-20, by David H. creator of Rails:
(15:11:12) DHH: before fastthread we had ~400 restarts/day
(15:11:22) DHH: now we have perhaps 10
(15:11:29) Zed S.: oh nice
(15:11:33) Zed S.: and that's still fastcgi right?
The main Rails application that DHH created required restarting ~400 times/day.
Twenty years ago, for a brand new web framework written from scratch, and by then they had already fixed it.
Every web framework was trash at the time. And the alternative was custom PHP code probably ridden of SQL injections.
I used TurboGears and restarting your web server with a cron job was a pretty common suggestion to "handle" memory leaks.
As Zed said, it was fastcgi. But yeah, Rails 1.x got a lot of hype before it had a functional application server.
While I mostly agree with DHH's take on this particular technological cycle, this is a very well thought out criticism.
Rails needs hard break from DHH. He has been toxic for the rails community for a long time. I sincerely appreciate his many contributions to rails, and his shaping of rails, but it is beyond time to cut ties. He's clearly not interested in rails any longer.
DHH founded Rails World (as far as I know). What a wonderful way to tell the whole community to F'off than to sell tickets to your conference then tell them not to use the technology. If DHH wants to vibe code everything in rust/assembly or whatever claude tells him to do, let DHH do his own thing, and let's part ways.
From the DHH talk discussed here:
> "Lean in to the max possible. Because the utopia is almost here."
Man. I use AI daily (in a more nuanced, HITL way) but this is turning into some Jim Jones shit. It's a tool, dude. Relax. I'm all for encouraging people to build and create things but it's just downright fucking spooky to see how many people are kneeling at the altar with their respective sacrifices.
I moved from Ruby+Rails, though some other frameworks that I had no choice in (inherited the projects), to my new place of refuge: Kotlin+http4k.
Kotlin is a very acceptable Ruby-with-types. Even better than the new Ruby with optional types. It reads the same, it writes very similar, and it produces very similar "style" of code. I like the be on the FP side; Kotlin (as Ruby) allows that. I dont mind some OO in there; Kotlin (as Ruby) is okay with that. The benefit is a much larger community, JetBrains products that work well (and have free versions for Kotlin) and the JVM (interop with the Java ecosystem means there's a lot of libs you can use).
http4k is a library much like Rack in Ruby. It does a bit more, but essentially they are similar.
I prefer SSR over SPA. With Ruby I used HAML. Now I use kotlinx.html, which is "just Kotlin" (it compiles as Kotlin, allows me to put breakpoints, and mix in bits of logic --in Kotlin obviously-- where i need it. Much better than HAML (or ERB, or...).
I never liked Ruby's ORM. I just dont like ORMs. So I wrap functions over SQL statements that are strings. I do my SQL interpolation with Jdbi. Works very well, and, no ORM.
The test suite runs really fast and tests with a live db. I test that all SQL statements still work (one test per SQL statement; with a non-empty result to ensure the row decoding works).
All libraries (JARs) together amount to 11MB. That's all! I really like little libraries. As a reference SpringBoot (java's Rails) or Hibernate (java's ActiveRecord) require at least 15MB each!
Overall I'm happier here than with Rails. I just like static typing more nowadays, and prefer a "bunch of libs stringed together for my project" over a "framework".
I really appreciate Rails and DHH's approach though: I learned a lot about web development by using it (and Rack, and Merb). Much more than from Django or PHP or JSP/etc. But I'm okay with having moved on.
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.
> so they’re using LLMs to build native applications for every platform they support.
People say LLMs will let us build native apps instead of Electron, but is that missing the point? I thought people turned to Electron for a reason: building a fast, rich, collaborative Markdown editor on macOS is notoriously hard. Neither SwiftUI nor AppKit makes handling those rich interactions easy. AI can do wonders, but can it really overcome the inherent limitations of macOS's native UI frameworks?
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.
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.
Without knowing your reference, I guarantee he said something like "If X is being a fascist, then I'm proud to be a fascist!"
Not because I keep up with DHH (at all), but just because yours is a recognizable genre of comment from people who lie on the internet.
I just kept singing this to the tune of that "What about men?" song from Portlandia...
What about Rails, What about Rails, What about Rails
etc
but in all seriousness good points Jared.
You can tell what type of framing the article will be about AI by what social media they choose to use and link in the footer of their website. It never fails.
You're fucking rails programmer. You're the best of of the best. This is goddman Top Gun I'm looking at here -- DHH, Rails World 2026 opening keynote, moments before calling everyone loser
The author should stop whining and complaining. Be grateful for what DHH contributed all these years for rails. Also,RoR is open source, so nothing prevent the author to contribute/participate to rails governance/features if he's not happy.
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
Rails, PHP, django, and all rapid app development frameworks all made an important tradeoff between development time and system performance. Rails would struggle with more than a few dozen QPS. You might get 100, but not 10k, 100k or anything near the capability of the hardware (even 20 years ago)
That tradeoff is no longer necessary. There is little benefit to making such an expensive tradeoff, at a time when the hardware cost is skyrocketing.
Stop clinging to old tools as if they were a religion.
DHH may have chosen an unwelcome audience (at first) for that message, but what value is preaching to the choir? He has a long relationship with the Rails community, and it's an honest , timely and relevant message.
A snarky talk tldr could be
'Overrated Ruby programmer finally tries fast languages in domains they are clearly better suited to than Ruby, now that he does not need to write the code himself. He unsuprisingly draws the wrong conclusions and also inevitably mentions his Linux for techbros project, since this is his conference and his keynote.'
so glad I chose Python way back in 2005. The emergence of Rails with Ruby's horrendous perl-esque syntax (oh, and "convention over configuration", a terrible idea borrowed from PHP) and the showboat personality of DHH at the top (which has gone mostly predictably) only inspired me to improve Python's ecosystem even more. I'd like to say Python has come out on top in terms of remaining relevant.
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
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.
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..
> 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.
Ok?
I must admit I haven't run the numbers, but if this can be trusted, sync PHP isn't far off from golang - while async does rather well?
I probably would only reach for PHP if I needed to run on shared hosting (or rather, my customers did) - in which case few other technologies would compete, obviously.
https://phpbenchlab.com/php-vs-nodejs-vs-go-vs-python-io-ben...
> PHP 8.5 vs Node.js vs Go vs Python: I/O Performance Under Real Database Load (2026)
Thought it could warrant some discussion - maybe someone will spot obvious errors?
https://news.ycombinator.com/item?id=49845870
PS: golang is much faster at cpu - in this case one might argue a fairer comparison would use a compiled extension on the php side IMNHO - as that seems a likely path if a real project was cpu bound on a few small functions.
https://phpbenchlab.com/php-8-5-vs-nodejs-vs-go-vs-python-cp...
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.
If the language doesn't matter, why aren't all LLMs outputting assembly code directly for maximum performance?
What I do not understand with the "languages do not matter"/"frameworks do not matter" is ultimately the following:
What a good language or a good library (and to a lesser degree also a good framework) does is to pre-compress ideas into well understandable and composable chunks.
Examples:
`printf("foo %d, %3.2f %s", ...)` abstracts/compresses a general strategy of shuffling bytes into the correct ascii/utf-8... format. An LLM could also write the raw assembly or bytecode for doing the same thing, but for one it would take much more tokens and to apply this pre-invented concept, and second without the concept already invented there would be no "information pattern" in existence that the LLM could have learned or refer to.
`list.map(...).filter(...)...` are patterns that (when applied strictly in a functional sense) go hand in hand with laws like `map` not affecting the number of elements, and filter producing no new elements etc... These are also patterns that are already invented and depending on the language these restrictions are checked. Just reading `map` somewhere can tell you (and the LLM) a lot, and writing `map` instead of while, for or jmp will capture and express much more information. LLMs would not have been able to learn these concepts if they did not already exist. And even if such a general pattern would be discovered by an LLM somewhere inside its learnt parameters, it would not haven given this pattern a name that it could/would tell you. And if you do not know the name for such a concept how have a much harder time prompting the LLM.
Expressing computations in a well understood algebra allows for symbolic manipulation and simplification. like `5 + 3 == 3 * 5 == (1+1+1) * 5 == (5+5+5)...`. But algebraic manipulation requires a symbolic language with precise rules to describe what manipulation is allowed. In AI-speak you could say the language itself is a harness or a sandbox to guide and restrict whats possible. Doing advanced math proofs is only possible for LLMs because languages like LEAN provide a strict guideline to build upon.
In short, two extremes: If LEAN is so great at proofing correctness and LLMs are so good at LEAN, why is not from today on everything (windows, linux, basecamp, hey, gcc, rustc, blender...) translated into LEAN? Why bother with rust at all? On the other hand if languages do not matter anyway and LLMs are able to recognize all the pattern on their own, why not let the LLM output and iterate on the binary bytecode to generate a self contained binary directly?
What exactly would make those systems 100x more maintainable?
LLMs would need way more tokens using langs/frameworks that dont have native features already built in? Even with LLMs I would take 10x the amount of time/tokens until I have something I could've just done with Laravel in the first place.
A more concrete example: Laravel has a built in rate limiter, with Go I'd either have to tell Claude to install some rate limiter package from some random ass dev or implement its own which would consume tokens/time...
Also your argument about PHP/Laravel being risky is pretty funny as everything is risky and most of the internet runs on PHP...
> I’d love to stop paying attention to him, but I build applications with Rails, so his actions affect me and my clients.
DHH purpose-built a tool so this guy could build a career on it. The guy delightfully uses the tool to get rich. And he wants to hate DHH--probably does--but no, DHH *owes him more*. And has lots of advice for DHH about how to manage his own creation.
The entitlement in 2026 is so wildly off the charts.
Why does the author know better than DHH how to lead rails? How does the author know how the community will react to the keynote?
> The problem is that he stood up at Rails World and told everyone that he was moving his product off Rails
Maybe the author doesn't understand the use-case for rails? I think DHH does. With enough success, there comes a day that you move your product off of rails.
Rails is great for agentic coding, which DHH also said.
Yeah, the author's opinion would be way more justified if Rails were an open-source project with thousands of contributors and not just the hard work of DHH himself in total isolation.
The author's opinion about the direction of rails would be more justified if he was a contributor, which he doesn't appear to be.
But no, you mischaracterize my position, which is that his opinion would be way more justified if he was critiquing someone who had led a failure, or if he had some really valuable insight that DHH didn't have, or if he had led something even more successful than what DHH has managed.
I'm not seeing how DHH's success has any bearing at all. The captain has announced that the ship is sinking. In fact, he left in a lifeboat several months ago. Whether or not he was a good captain has nothing to do with how the remaining passengers should handle his departure.