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.
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.
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.