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.
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.
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.
How certain are you about that? <a href="https://guides.rubyonrails.org/v2.3/plugins.html" rel="nofollow">https://guides.rubyonrails.org/v2.3/plugins.html
Back in the very early days you would have used script/plugin install (svn url)
Here's one of my mirror repositories migrated from SVN into git. <a href="https://github.com/jaggederest/acts_as_voteable" rel="nofollow">https://github.com/jaggederest/acts_as_voteable
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.
Yeah. I'm going through an exercise right now with a large codebase where I'm split some of it up into crates so that iterating on specific parts incurs less build overhead. Literally changing my architecture... which annoyed me a bit, but it does make sense.
Sounds like OCaml has the answer then. It has the equivalent of all the great things you described in Rust, plus compile speeds similar to or better than Go. Agents should be able to blaze through changes with it.
> 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 still review PRs, but rarely suggest changes. The most meaningful reviews come from our review bots. I mostly review broad architectural decisions as a way to keep abreast of changes in the codebase. There's a cohort of engineers I work with who I would be perfectly okay with letting the clankers review, approve, and merge their PRs. But there's a larger cohort of engineers who need what I would call a directional code review.
Agile is dead. It presumed writing the code was the slowest part of the cycle. Now it makes more sense to only start writing code when the requirements are known as the code is quick and low cost to change if/when the requirements change later.
Agreed, this is very critical point, I always thought big part of software engineering is the art and science of managing ever-growing complexity.
The part I'm still not sure about is the 2nd point, I just don't know how good those LLMs will get at managing complexity and how important is for human to understand the details of the code. I'm personally not sure yet..I could imagine a future where we have have much more higher level tools to manage the comprehension and complexity challenges. Or it could be that LLMs will never fully comprehend the full architecture and humans will always be needed for that kind of big-picture analysis. I really don't know, and frankly I don't think anybody knows.
robgough · · focus · HN ↗
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.
CodingJeebus · · focus · HN ↗
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.
robgough · · focus · HN ↗
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.
efields · · focus · HN ↗
Is it types? Are types the answer? Is it rust?
jaggederest · · focus · HN ↗
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.
alehlopeh · · focus · HN ↗
jaggederest · · focus · HN ↗
Back in the very early days you would have used script/plugin install (svn url)
Here's one of my mirror repositories migrated from SVN into git. <a href="https://github.com/jaggederest/acts_as_voteable" rel="nofollow">https://github.com/jaggederest/acts_as_voteable
rapind · · focus · HN ↗
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.
efields · · focus · HN ↗
rapind · · focus · HN ↗
yawaramin · · focus · HN ↗
CodingJeebus · · focus · HN ↗
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.
prescriptivist · · focus · HN ↗
timhh · · focus · HN ↗
whazor · · focus · HN ↗
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.
aogaili · · focus · HN ↗
In Software Engineering, we learned about requirements, testings, system design, UMLs, etc, and those seems to be more relevant than ever.
everfrustrated · · focus · HN ↗
whazor · · focus · HN ↗
1. You get complexity back at the speed that you add code. Also the complexity compounds.
2. As a human you are still responsible for your code, and you need to understand how the important parts of the code base work.
When you combine these problems, you get a complicated code base where you don't understand the important parts.
That is why software design is getting a comeback. It actually helps with both problems. Less complexity and more understanding.
aogaili · · focus · HN ↗
The part I'm still not sure about is the 2nd point, I just don't know how good those LLMs will get at managing complexity and how important is for human to understand the details of the code. I'm personally not sure yet..I could imagine a future where we have have much more higher level tools to manage the comprehension and complexity challenges. Or it could be that LLMs will never fully comprehend the full architecture and humans will always be needed for that kind of big-picture analysis. I really don't know, and frankly I don't think anybody knows.
senderista · · focus · HN ↗
rason-yang · · focus · HN ↗
[dead]