Concerns with his politics aside, I do think there's a truth to what he's talking about here, and that he is just spelling out the reality that developers are, or shortly will be, facing. For many this will be deeply uncomfortable to hear.
It is notable that his perspective in this talk is very much from a developer-user side rather than someone who is responsible for the framework itself. That surprises me, and I suspect it is not a good omen for Rails.
For all of this embrace of agentic development, there is nothing here on how they are adapting the framework for this new agentic development reality. Agents do currently work well with Rails, but there's nothing here pushing things forward as best as I can see.
I know for my own projects I've largely moved to Elixir/Phoenix, for similar reasons to his use of Rust... I didn't want to have to learn it, but now I don't have to and I get to benefit from its strengths.
> Concerns with his politics aside, I do think there's a truth to what he's talking about here
One thing the AI era has changed for me is how easily I spot Gell-Mann amnesia, of which this is an unfortunately strong example.
His politics, even putting aside their nature, are framed with deliberate misuse of facts and data; why would he be someone to listen to in any depth on any other topic?
I think a lot of people haven't actually watched his talk and don't understand what he is saying. If you watch the talk, he is not anti-rails. He is just very pro- agentic coding.
What he was saying in his talk was that his customers (people using Hey for email and calendar) never really wanted hybrid web-native apps, they want native apps (like most people prefer on mobile). His business could never afford to have a dev team that built and supported six different native apps, so they always built using hybrid web-native stuff using Turbo Native.
Now that his development team has access to agentic coding, they can build and maintain six mobile native apps. For his app, the back end part then becomes small and simple and they can reimplement it in rust to reduce server cost.
His point wasn't that rust is better than ruby, or anything like that. His point was that agentic coding allows smaller teams to do bigger things. For most people building on rails, their customers don't need native mobile apps (I know mine don't) and for them Rails is a fantastic choice for agentic coding.
Rails is so into agentic coding that they publish benchmarks of how effective different models are for building with rails:
TLDR: DHH isn't anti-rails, he is pro-agentic coding. Rails is great with agentic coding. AI doesn't mean layoffs, it means your teams can do much more than they could do before.
> Rails is so into agentic coding that they publish benchmarks of how effective different models are for building with rails
To each their own, but I think using Rails in the era of agents is probably a mistake. It has 2 big problems IMO.
(a) A ton of footguns that an agent can and will miss on occasion, and as we manually review less and less code, we will also miss it, and
(b) security on the web has become increasingly important due to hostile AI agents, and while rails has great secure conventions (see (a)), it's still easier to screw up something and not catch it until after it's deployed because there are simply less guardrails in place (dynamic types, no compile, slow tests, generally bad performance profile).
Rust is used a lot. Elixir/Phoenix comes up often. You’re looking for something statically typed with string guarantees and as FP as possible to make unit testing easier.
Rust for sure. Builds become a problem eventually though. Elixir is much more interesting now that they added types (I think they're doing more with this still?).
In my experience, Go. It was designed to be idiot-proof. It's very verbose, not very expressive, compiles fast for quick feedback loops, strict autoformatter, plenty of examples in models' training data.
Do the teams fully understand the code that they are committing? Are the teams reviewing each others code or are agents? When agents do all the coding, and perhaps the reviewing, and the patching what is left of the team? People lose connection to their work, and the social bonds between workers begins to erode.(1) DHH's speech seems like a weird eulogy for the entire Rails community, although many of us saw this coming several years ago.
Also, I hate native apps. FWIW most devs I know actively try to avoid them.
> That surprises me, and I suspect it is not a good omen for Rails.
I had a fairly opposite reaction: Knowing what you can't be and how much less important your past work is going to be is good. If there are good reasons for more people doing less in Rails, then the creator is probably the person you want to be most level headed about that.
Nothing that he said is just him espousing the truth. It is the world as he and all the other AI-pilled people wish it to be. It is a world they want to convince everyone is inevitable. There are still a lot of people outside of tech bubbles that don't like the direction AI is going and don't want to embrace what these companies are doing or how the government is handling it.
And honestly, do people really think everyone is just going to become an "energized creator"?
AI is not as big of a productivity boost as compilers were but it is not zero. Back then, SQL was created and marketed as something “managers could use”, another parallel to the current cycle. This whole hype cycle is something we’ve seen before and IMO, we should know better how to handle it this time around. It’s a bit disappointing to hear the same arguments every time.
This has nothing to do with programming or productivity. I am addressing the fact that people like DHH and his fans are in the habit of framing the future as written and that you can either embrace it or get crushed. Embracing it is giving OpenAI, Anthropic, et. al your approval to keep on going. I'm not denying that AI can do the job a lot faster.
But he himself promotes such a future too. This is a conflict of interest.
You can say "ride the wave", but this is more - this is helping the wave become huge. And cashing in too. Sorry, but I no longer buy any of what these guys do. To me they seem like BigBro ad-clowns.
> Agents do currently work well with Rails
According to whom? And not everyone wants to become dependent on corporate-agents sucking them dry financially. We all know the increase-in-cost will come with regards to tokens, after the get-hook addiction phase is over.
I literally just patched an AI-generated API endpoint on a new service at work that shipped without any auth whatsoever, because AI was re-implementing the auth token check method individually in each child controller instead of implementing once in a before_action hook. That's Rails 101 stuff and the app is small. It was so obvious that I saw it right away just reading the code, I didn't even set an agent loose to do an initial inspection. It was a real "yeah I still got it" moment for me.
I'm on board with the idea that agents are going to write most of the code, but not checking it is just insane to me, based on some of the things I've seen committed in commercial codebases recently.
One of the strengths of Rails was that it helped developers who maybe didn't always know the "best way" to build things to build in a standards compliant way – not that you couldn't do things like return a 200 for Not Found if you really wanted to etc.
I'm always pleased when working with a dev who has Rails experience even if they've since moved stack, as often they have picked up and learned the value of these good behaviours. Perhaps it's as much a community thing as a framework thing, or combination of both.
Agentic development definitely still has room to improve, but I suspect that there is some future framework (maybe even language) designed to help minimise these types of mistakes.
Interesting that all the patterns Rails adopted for humans to write better code can't easily be funneled into the LLM doing the job now. Seems like it should be.
Types are great. No nulls are great. Exhaustive switches are great. Derive macros and Serde are great. Detailed errors are great.
However Rust has one serious problem, BUILDS. It’s slow and it takes up a ton of space and memory. You will be working around this on any sizeable codebase. Using cargo check to ration your compiles, a dedicated build box, etc. Now imagine you're using it for a web application with compiled maud templates... you're potentially waiting minutes to see your changes.
If we accept that over half of the people building with rust are using agents (I'm sure this is much higher in reality), then you should also accept that there is a ton of time and resources spent on building / compiling. Optimizing this should probably be a top priority. They need someone who will be fanatical about shaving time and memory use from the build process.
I think the issue with Rails, as a long time developer in that ecosystem, is that much of the default assumptions are a) not common (not so far off-piste that a human can't get used to them, but outside the center of the bell curve), and b) not explicit. So it's very common to do things like install a plugin that has across-the-repo effects but that is only documented in e.g. the config directory and the bundle. Unlike, say, NPM, when you install a new package where you explicitly have to e.g. import it everywhere you want to use it.
As time has gone on Rails has gotten better about this, but it still means that "your rails" and "my rails" are different enough that AI could easily get confused.
As you say, the other aspect is the intense dynamism which works against AI, which again prefers to have everything explicit and reasonable about from the text.
So I ended up going back to Javascript after a brief 12 year digression into Ruby. I still love Ruby but it's just not the right language for the current environment and team structures - typescript is "worse is better" in the right ways that it's a much better choice for both frontend/backend being the same and better type systems.
> Agentic development definitely still has room to improve, but I suspect that there is some future framework (maybe even language) designed to help minimise these types of mistakes.
Maybe there will be one day, but what are the odds that it will meaningfully move the needle for existing platforms such that manual code review is unnecessary? "Blindly trust the output" is not a feasible security posture today.
I sat front row for David's talk yesterday morning. Having talked with him the day before, I’ll admit… I wasn’t particularly surprised (nor unprepared).
A bit of a field report from #RailsWorld: the vibe here is far from doom and gloom. Quite the contrary. Wherever our industry is headed, most of us are still employed as menders… tending to systems that customers rely on and businesses are quite happy to keep paying for.
Most of us aren’t waking up to a blank canvas and designing the architecture of the future. We’re inheriting decisions made years ago, updating old patterns, working around constraints, and keeping this shit running reliably.
I think these newer tools give us an opportunity to wonder a little more about the systems we’ve inherited. To unpack why things work the way they do. To tinker with assumptions we haven’t had the time, confidence, or permission to revisit… and share what we learn so the next person, or agent, has an easier time.
That deployment model we picked eight years ago? Worth another look. Some of our web apps probably wish they were native apps. And there are plenty of architectural decisions we’ve been living with mostly because… well, we’ve been busy living with them.
There’s plenty of understandable anxiety about what these tools mean for our work. I’m increasingly curious about what they give us permission to revisit.
Once my keynote is published, I’ll share more about a little programming-language-adjacent framework I’ve been working on for approaching exactly this kind of curiosity.
How can Rails live long if no one creates new things with it? Our web applications aren't like the Pyramids at Giza. DHH literally said that even without a blank canvas (Hey's backend) they were still able to re-write the backend in Rust and are not looking back.
That sure sounds like any savvy business should pivot away from Rails and Ruby in general as fast as they can, assuming they have tokens to burn. Personally, I built my career on Python, but any new thing I build is almost always in Go or Rust. Why mess with an interpreter if you don't have to?
To be fair, this is true of most of AFK world. Things start seeing a lot less doomy and gloomy when you're actually outside talking with other humans. Seems to mostly be online and various darker corners where they're dooming and glooming.
the algorithm is programmed to deliver it. Better engagement metrics with misery and anger than joy and hopefulness. (yes I know that you will reply 'but I prefer the joy and hope', but that's not the case across the wider population)
So far a Rust rewrite's success rate directly, probably super linearly, correlates with the presence of a good, well designed test suite. This is why Bun's rewrite and others are successful. I anticipate that this will be true for the 37Signals rewrites.
I want to learn a couple of things once they are done:
1. Once the test suite assistance is over, how do features get built in their backends and continue to maintain the same quality. LLM test writing is a bit trickier as it often favors what Randy Coulman called tautological tests back in the day. It takes a lot of work to get them not to do this, so I am guessing folks at 37Signals will read at least this part. I can't imagine zero Rust read at all.
2. Over the years they had a few innovations in their domain design, ones that Rails made easier to do, for instance their delegated type pattern. Will Rust replicate this, and how would one know without reading it, or perhaps it does not matter? Furthermore, how do newer patterns emerge? and how does our arsenal of better abstractions keep growing?
I don't have the answers but I am glad there is a chance we can learn said answers.
I was hoping there will be news on Rails 9.0. Feels like this is the end of Ruby Rails.
Hey is not even a Ruby Rails App anymore. And indirectly admitting Ruby is slow considering they manage to cut 99.9% of CPU with their rewrite in Rust.
I hadn't connected the dots until you mentioned it, but yeah this keynote indirectly says it's the end of Ruby and Rails. Ruby was designed to be coded by humans, and DHH says it's the end of coding by hand.
Unfortunately yes because Rails has always been a framework of extraction. Now they are not even coding anymore there is nothing to extract. No one is a programmer but everyone is a maker.
Those performance numbers mean nothing considering they went from rendering every single view of a highly interactive app solely on their servers to moving all rendering to the clients. It’s possible the backend logic of the app could have run on 10 hosts running Ruby as well.
I agree it seems like the end of Ruby on Rails. I personally hope a fork will come along as a spiritual successor, because I still love building web apps this way.
Serious question: Is there a framework that is better suited for agents? There must be something out there that makes agents fly through development with minimal token expense.
An agent that was looking at the log output from a program in a typical language, and also looking at the code for that program, would have a lot of unanswered questions related to "how do I iterate on this?" Maybe there's a kubernetes cluster involved somewhere. Maybe it there's a cloud storage bucket. Maybe there's dashboards and metrics and telemetry hosted by servers that the agent doesn't know the name of.
Elixir runs on the BEAM which lets you do hot code reloading process at a time. And these are much more lightweight than your typical OS process. So you can do things on the BEAM which would be just crazy to do on other achitectures. Like if you have a server which needs to do something for a million users, it would be insanity to run a million separate OS processes for the job. But BEAM processes are so lightweight that you can do that.
And since they support hot code reloading, you can patch the code for just your user's process in a sort of "what-if" experiment. Other architectures would require you to implement separate test environments or complicated feature flag systems, but the beam lets you just reach out and change it for just the process you care about--you're not baking the experiment into an OSI image or anything so dangerous as that... blast radius is kept small.
And the process by which you would carry out this experiment, it's all doable at the elixir shell. You connect to the BEAM and make changes. That's a tremendous reduction in context that an agent needs to load--context which would otherwise instruct the agent about how to reason about the deploy process and how to wall off your experiment from others so as to not cause problems with it is just answered implicitly by how the BEAM works.
Elixir compiles to BEAM bytecode, so you get all of this because the BEAM is cool. As for Elixir as a language... I don't think there's anything agent-specific about it. Gleam might be a better choice since it's statically typed and also compiles to BEAM bytecode, but it's not as popular as Elixir.
I don't understand what is supposed to come next. So its not Ruby on Rails anymore. What is it? Are agents going to magically convert all the RoR ecosystem to Rust or Whatever?
But yes, I think RoR's selling feature was developer ergonomics, which suddenly seems less of a benefit if developers aren't the ones writing the code. Readability and conciseness still has benefit, but the trade-off of worse performance (and less static checking) is suddenly more questionable.
> Readability and conciseness still has benefit, but the trade-off of worse performance (and less static checking) is suddenly more questionable.
There is an issue with this idea - we write software, we read it, we make sure it does what it should do, that it’s implement in a sensible and efficient way, and, most importantly, we make sure the tests do what they should do.
If you no longer write the code, it’s harder to understand it. If you don’t write the tests, you need to trust the LLM did both jobs correctly (multiple adversarial LLMs can help), but, ultimately, it’s code you can no longer claim you understand. And you can’t really be sure it does what you want until you understand it.
Shit, I'm also hosting with them. Somehow I missed that post. I've been watching Kurt's AI-pillness advancing over time, but I didn't expect it to metastasize so quickly.
What a strange time. Kurt himself writes that they've had the best quarter ever, and yet he feels confident enough to steer the ship in a completely new direction.
Where did he say that? I listened to it yesterday and AFAIK he only said "I don't know where the line between native vs web will end up in the future" (now that we can generate native apps easier)
Keep in mind DHH is working on an email app, it makes sense he sees native as the default option for that over pushing everything through the web when the barrier to entry lowered dramatically.
Hotwire is not explicitly a cross-platform concept. It's primarily a way to build web apps in the browser which is not going away any time soon. The only difference is in 2026 you're just more likely to vibecode a native mobile app than build a web/React Native version. Likewise you may build a native Desktop version instead of an Electron wrapper.
That's cool, but like with most things, I think the manager types will misunderstand:
- A lot of this is looking at an existing app and/or code for reference.
- The people doing/guiding this are skilled.
- People have thought about what to make.
Otherwise they hear "20 minutes" and think AI can spit out a logical or good product from no reference or planning.
I'm not here to defend DHH --- but I think "AI" has materially changed since 2024. I think that it's entirely reasonable to have shifted perspective on the technology and its applications since 2024.
>DHH has only written web software and knows nothing about serious software development.
I don't particularly like DHH either but web software is definitely serious. Shopify (which you seem to have confused with Spotify) runs on Rails. So does GitHub.
Those are both huge platforms handling a ton of traffic. If GitHub isn't "serious software" then what is?
Oh c'mon, there were three million ways you could express this feeling with some class... And you went for "can't even get the company names straight" ?
Reddit would have about 15 comments alluding without never revealing, all of them smart, classy and funny. The rest would be complete trash probably.
It is notable that his perspective in this talk is very much from a developer-user side rather than someone who is responsible for the framework itself. That surprises me, and I suspect it is not a good omen for Rails.
For all of this embrace of agentic development, there is nothing here on how they are adapting the framework for this new agentic development reality. Agents do currently work well with Rails, but there's nothing here pushing things forward as best as I can see.
I know for my own projects I've largely moved to Elixir/Phoenix, for similar reasons to his use of Rust... I didn't want to have to learn it, but now I don't have to and I get to benefit from its strengths.
One thing the AI era has changed for me is how easily I spot Gell-Mann amnesia, of which this is an unfortunately strong example.
His politics, even putting aside their nature, are framed with deliberate misuse of facts and data; why would he be someone to listen to in any depth on any other topic?
What he was saying in his talk was that his customers (people using Hey for email and calendar) never really wanted hybrid web-native apps, they want native apps (like most people prefer on mobile). His business could never afford to have a dev team that built and supported six different native apps, so they always built using hybrid web-native stuff using Turbo Native.
Now that his development team has access to agentic coding, they can build and maintain six mobile native apps. For his app, the back end part then becomes small and simple and they can reimplement it in rust to reduce server cost.
His point wasn't that rust is better than ruby, or anything like that. His point was that agentic coding allows smaller teams to do bigger things. For most people building on rails, their customers don't need native mobile apps (I know mine don't) and for them Rails is a fantastic choice for agentic coding.
Rails is so into agentic coding that they publish benchmarks of how effective different models are for building with rails:
https://rubyonrails.org/ai
TLDR: DHH isn't anti-rails, he is pro-agentic coding. Rails is great with agentic coding. AI doesn't mean layoffs, it means your teams can do much more than they could do before.
It’s his business decision to save on native app development costs to increase his (generous?) profit margins.
He explicitly said he still loves ruby as a language and thinks Rails is well suited for a future with AI coding.
It's interesting how this stuff gets spun on social media by people who don't watch the content.
To each their own, but I think using Rails in the era of agents is probably a mistake. It has 2 big problems IMO.
(a) A ton of footguns that an agent can and will miss on occasion, and as we manually review less and less code, we will also miss it, and
(b) security on the web has become increasingly important due to hostile AI agents, and while rails has great secure conventions (see (a)), it's still easier to screw up something and not catch it until after it's deployed because there are simply less guardrails in place (dynamic types, no compile, slow tests, generally bad performance profile).
Also, I hate native apps. FWIW most devs I know actively try to avoid them.
(1) https://www.uclawjournal.org/how-ai-destroys-institutions/
I had a fairly opposite reaction: Knowing what you can't be and how much less important your past work is going to be is good. If there are good reasons for more people doing less in Rails, then the creator is probably the person you want to be most level headed about that.
(They can, of course, still be wrong)
And honestly, do people really think everyone is just going to become an "energized creator"?
You can say "ride the wave", but this is more - this is helping the wave become huge. And cashing in too. Sorry, but I no longer buy any of what these guys do. To me they seem like BigBro ad-clowns.
> Agents do currently work well with Rails
According to whom? And not everyone wants to become dependent on corporate-agents sucking them dry financially. We all know the increase-in-cost will come with regards to tokens, after the get-hook addiction phase is over.
I'm on board with the idea that agents are going to write most of the code, but not checking it is just insane to me, based on some of the things I've seen committed in commercial codebases recently.
I'm always pleased when working with a dev who has Rails experience even if they've since moved stack, as often they have picked up and learned the value of these good behaviours. Perhaps it's as much a community thing as a framework thing, or combination of both.
Agentic development definitely still has room to improve, but I suspect that there is some future framework (maybe even language) designed to help minimise these types of mistakes.
Is it types? Are types the answer? Is it rust?
However Rust has one serious problem, BUILDS. It’s slow and it takes up a ton of space and memory. You will be working around this on any sizeable codebase. Using cargo check to ration your compiles, a dedicated build box, etc. Now imagine you're using it for a web application with compiled maud templates... you're potentially waiting minutes to see your changes.
If we accept that over half of the people building with rust are using agents (I'm sure this is much higher in reality), then you should also accept that there is a ton of time and resources spent on building / compiling. Optimizing this should probably be a top priority. They need someone who will be fanatical about shaving time and memory use from the build process.
As time has gone on Rails has gotten better about this, but it still means that "your rails" and "my rails" are different enough that AI could easily get confused.
As you say, the other aspect is the intense dynamism which works against AI, which again prefers to have everything explicit and reasonable about from the text.
So I ended up going back to Javascript after a brief 12 year digression into Ruby. I still love Ruby but it's just not the right language for the current environment and team structures - typescript is "worse is better" in the right ways that it's a much better choice for both frontend/backend being the same and better type systems.
Maybe there will be one day, but what are the odds that it will meaningfully move the needle for existing platforms such that manual code review is unnecessary? "Blindly trust the output" is not a feasible security posture today.
When designing systems, you want the important details to be right. Especially with authentication and authorization.
From an architecture level, you can know which classes are important to review and which ones are not.
ALL DHH's AI opinions are sponcon.
But he has great flagging support and his perception management agency will suppress this one, too.
A bit of a field report from #RailsWorld: the vibe here is far from doom and gloom. Quite the contrary. Wherever our industry is headed, most of us are still employed as menders… tending to systems that customers rely on and businesses are quite happy to keep paying for.
Most of us aren’t waking up to a blank canvas and designing the architecture of the future. We’re inheriting decisions made years ago, updating old patterns, working around constraints, and keeping this shit running reliably.
I think these newer tools give us an opportunity to wonder a little more about the systems we’ve inherited. To unpack why things work the way they do. To tinker with assumptions we haven’t had the time, confidence, or permission to revisit… and share what we learn so the next person, or agent, has an easier time.
That deployment model we picked eight years ago? Worth another look. Some of our web apps probably wish they were native apps. And there are plenty of architectural decisions we’ve been living with mostly because… well, we’ve been busy living with them.
There’s plenty of understandable anxiety about what these tools mean for our work. I’m increasingly curious about what they give us permission to revisit.
Once my keynote is published, I’ll share more about a little programming-language-adjacent framework I’ve been working on for approaching exactly this kind of curiosity.
In the meantime… keep showing up. Keep wondering.
Long live Ruby. Long live Rails.
p(bloom)
That sure sounds like any savvy business should pivot away from Rails and Ruby in general as fast as they can, assuming they have tokens to burn. Personally, I built my career on Python, but any new thing I build is almost always in Go or Rust. Why mess with an interpreter if you don't have to?
To be fair, this is true of most of AFK world. Things start seeing a lot less doomy and gloomy when you're actually outside talking with other humans. Seems to mostly be online and various darker corners where they're dooming and glooming.
I want to learn a couple of things once they are done:
1. Once the test suite assistance is over, how do features get built in their backends and continue to maintain the same quality. LLM test writing is a bit trickier as it often favors what Randy Coulman called tautological tests back in the day. It takes a lot of work to get them not to do this, so I am guessing folks at 37Signals will read at least this part. I can't imagine zero Rust read at all.
2. Over the years they had a few innovations in their domain design, ones that Rails made easier to do, for instance their delegated type pattern. Will Rust replicate this, and how would one know without reading it, or perhaps it does not matter? Furthermore, how do newer patterns emerge? and how does our arsenal of better abstractions keep growing?
I don't have the answers but I am glad there is a chance we can learn said answers.
Hey is not even a Ruby Rails App anymore. And indirectly admitting Ruby is slow considering they manage to cut 99.9% of CPU with their rewrite in Rust.
I agree it seems like the end of Ruby on Rails. I personally hope a fork will come along as a spiritual successor, because I still love building web apps this way.
Elixir runs on the BEAM which lets you do hot code reloading process at a time. And these are much more lightweight than your typical OS process. So you can do things on the BEAM which would be just crazy to do on other achitectures. Like if you have a server which needs to do something for a million users, it would be insanity to run a million separate OS processes for the job. But BEAM processes are so lightweight that you can do that.
And since they support hot code reloading, you can patch the code for just your user's process in a sort of "what-if" experiment. Other architectures would require you to implement separate test environments or complicated feature flag systems, but the beam lets you just reach out and change it for just the process you care about--you're not baking the experiment into an OSI image or anything so dangerous as that... blast radius is kept small.
And the process by which you would carry out this experiment, it's all doable at the elixir shell. You connect to the BEAM and make changes. That's a tremendous reduction in context that an agent needs to load--context which would otherwise instruct the agent about how to reason about the deploy process and how to wall off your experiment from others so as to not cause problems with it is just answered implicitly by how the BEAM works.
Elixir compiles to BEAM bytecode, so you get all of this because the BEAM is cool. As for Elixir as a language... I don't think there's anything agent-specific about it. Gleam might be a better choice since it's statically typed and also compiles to BEAM bytecode, but it's not as popular as Elixir.
But yes, I think RoR's selling feature was developer ergonomics, which suddenly seems less of a benefit if developers aren't the ones writing the code. Readability and conciseness still has benefit, but the trade-off of worse performance (and less static checking) is suddenly more questionable.
Have a look at fly.io facing similar issues, another platform whose value prop was dev ergonomics: https://fly.io/blog/kurt-scott-money-sprites/
There is an issue with this idea - we write software, we read it, we make sure it does what it should do, that it’s implement in a sensible and efficient way, and, most importantly, we make sure the tests do what they should do.
If you no longer write the code, it’s harder to understand it. If you don’t write the tests, you need to trust the LLM did both jobs correctly (multiple adversarial LLMs can help), but, ultimately, it’s code you can no longer claim you understand. And you can’t really be sure it does what you want until you understand it.
What a strange time. Kurt himself writes that they've had the best quarter ever, and yet he feels confident enough to steer the ship in a completely new direction.
dhh says 37signal's apps for Hey (their email platform moving to native)
backend for their email platform is now Rust - written by agents
says Rust produces small binaries - cutting number of servers needed from 110 to 10. hell they could serve peak traffic on a Raspberry Pi
says now that agents write all the code - use faster / native languages.
rails or ruby hardly get a mention besides that they might be well placed to capture web apps written by agents.
Keep in mind DHH is working on an email app, it makes sense he sees native as the default option for that over pushing everything through the web when the barrier to entry lowered dramatically.
Hotwire is not explicitly a cross-platform concept. It's primarily a way to build web apps in the browser which is not going away any time soon. The only difference is in 2026 you're just more likely to vibecode a native mobile app than build a web/React Native version. Likewise you may build a native Desktop version instead of an Electron wrapper.
- A lot of this is looking at an existing app and/or code for reference. - The people doing/guiding this are skilled. - People have thought about what to make.
Otherwise they hear "20 minutes" and think AI can spit out a logical or good product from no reference or planning.
(I also smell the wild racism wafting off DHH. Really, don't give this man your attention. Don't break cordon.)
https://world.hey.com/dhh/as-i-remember-london-e7d38e64
I don't particularly like DHH either but web software is definitely serious. Shopify (which you seem to have confused with Spotify) runs on Rails. So does GitHub.
Those are both huge platforms handling a ton of traffic. If GitHub isn't "serious software" then what is?
Reddit would have about 15 comments alluding without never revealing, all of them smart, classy and funny. The rest would be complete trash probably.