YHK - yet another hacker news clone

I’m not scared of code, but I agree: Rails does a good job at restricting reinventing the week. The Rails blog has been doing a great job giving guidance on getting best results with agents too: https://rubyonrails.org/2026/10/13/agents-on-rails-stage-3

I feel like a good web framework with an orm - makes sense. Am I wrong here?

Err yes, of course it does.

The article is not good in some areas.

Yes, the initial claim that good software still has value, even if written by humans, is true - high quality is always nice to have.

But the author then states this:

"The fact that an LLM now writes the code does not mean any abstractions we made before are suddenly less important or less useful."

Now - here the author makes a mistake that assumingly LLMs would lend benefit to the important of HUMAN written high quality software. But this makes no sense. If AI is really viable and useful then it SHOULD NOT NEED humans anywhere. Nor SHOULD it matter how much OTHER software that is good, exists - if AI works well. Perhaps current AI depends on existing data but I would not be surprised if AI becomes good, eventually, that it really does not need humans in order to write high quality code. Perhaps AI is not there yet, perhaps it will take a while - but there is no practical reason as to why LLMs would need human-written code. That just does not compute here.

"When we build a product for people we should be focused on solving their actual problems rather than writing job queues and ORMs and I believe that still holds true for a situation where an LLM writes 100 percent of the code."

But ... why? If a LLM can write the software well, humans are not needed. LLMs write for the people already. AI skynet replaced the human.

"To get back to the decision of whether to let LLMs rewrite everything in Rust: in the end a person is responsible for the software and will have to explain the decisions being made."

DHH was exposed on twitter when he had AI write software and then he crisitized alternatives to what he autogenerated, e. g. "elixir sucks". Well, now everyone knows that DHH is not a good programmer; and even not a good businessman either. If you let AI write code you yourself can not write because of lack of skills, yet then use this to praise AI and critisize e. g. Elixir, without being able to refute the counter-arguments made by José and others then sorry - that's just a promo campaign DHH and the AI tech bros run here. Besides, it is also interesting how the author does not mention DHH at all - DHH literally announced the death of rails when he did his AI-Rust promo. That is a post-mortem on Rails - if I were to use rails, which thankfully I don't (yet ruby powers all my web-needs and has so for +21 years), I would be very worried, since rails is literally dead. People just don't want to admit to it. (Ruby also is sinking, which is unfortunate, but looking at the mistakes made by the ruby core team in the last +2 years, I am no longer surprised: see https://po-ru.com/2026/10/18/why-im-no-longer-updating-this-... and then look at the ruby core team, which is now officially called Mr. Claude)

>The answer is simple: yes, I do think Ruby on Rails or frameworks in general still make sense. For the same reasons they always have: providing structure, not reinventing the wheel, security updates, free performance improvements and new features on updates to name a few benefits.

I think the author pulls a bit of a bait and switch arguing for 'frameworks in general' rather than ruby or rails themselves.

The 'rust rewrite' approach is a non starter strawman, mostly because if you have a running company or project there's probably a shitton of dev experience you're inmediately burning, you introduce a ton of risk, etc.

But for new projects, I think the ruby (and rails) tradeoffs are looking a lot worse than 5 years ago. Placing developer experience at the forefront, arguably at the cost of other stuff, looks a lot worse as manual coding disappears. And conversely, automatic guarantees (type checking, etc) start looking a lot better when you don't need to manually add boilerplate.

> The implication being of course that writing code is now extremely cheap and you can build anything you like in any language, so why not choose to rewrite everything in Rust?

I've been out of web dev for a while now and forgot these people exist. Why would you even compare framework with a language? Why would you want an AI to build a custom web framework around Rust? Why would you want to never read the code AI writes? It's infinitely easier for me to have a conversation with AI about something I know and understand.

even dhh basically admitted that it was obsolete recently

Correct title: Do (web development) frameworks still make sense despite LLMs?

The article barely has anything to do with RoR.

No, it does not. The reasons are not technical though - the main reason is the project being led by a person who does not use it or in fact write any code, and on top of that is obviously not quite mentally stable. Depending on such a project brings too much risk.

Using frameworks and libraries in general still makes sense though, as it is chiefly concerned with code reuse.

I don't personally use Ruby on Rails, but there's a strong benefit from a framework or system that has been pressure tested in the real world with a lot of eyes on it - especially open-source ones that are the result of the accumulated judgement of many users.

Many solutions that seem obvious are less than so after a bit of prodding - but without that sort of discussion or pressure both humans and agents will often land on the thing that works first.

Where it tends to really matter these days are on the opinionated decisions... i.e. the trade-offs, things that can't be clearly validated etc.

So in the end I think we'll find that these sorts of frameworks etc. will continue to be, and possibly become more important - when your use case matches the intent and goals of the tool. This opinion differentiator is likely also the thing that combats the current issue of proliferation of quickly-built tools that more or less do the same thing.

Rails is slow, and it has little tooling. If it was me I would have used Go so that compiler would give the LLM some errors and narrow its error window, is way faster than Ruby and makes way more sense to have a way faster code than a slow one for the same price, everyone can read Go code and it is so narrow in the possible space of decisions that an LLM can never write usual spaghetti that it writes in other languages to save tokens... I think the problem is in looking at Rust as the alternative.

Did anyone try to rewrite Rails in Rust yet?

Did it ever?

For low bandwidth and personal web sites, aka small and not hacker juicy targets, probabably depends on the user tech tastes more than anything else.

I’ve never been a rails dev, but it popularized opinionated MVC, correct?

For that reason I would avoid it these days. MVC helps coordinated teams of people move faster on small to medium sized projects. It does this at the price of heavily coupling your front and backend. I believe rails couples the DB as well, or can? (Showing my ignorance of the Ruby world here)

We’re all developing with AI now. When things are coupled, AI breaks them. More than this though, with AI you want a completely decoupled frontend that knows nothing about the structure of the backend for maximum iteration speed. You want formal DTOs and other isolation abstractions small teams hate because they provide the decoupling that only large teams (or AI) benefit from.

Fully decoupled, you can build your frontend out on fake (AI generated) data, reworking the whole UI 12 times without thinking about the backend and database at all.

Rails (I’m speculating) makes small talented teams more effective. One person can do more. But if the price is coupling, and you have unlimited AI labor that will never be intimately familiar with the code, then you still pay that price without getting the human oriented benefits.

Never personally liked Rails, but I see folks in my circles now convincing themselves they are 100x productive having Claude write web apps with no frameworks in whatever random combo of tech they chose. The end result looks like they should have just used Rails and done this in a few days instead of weeks or months of tokens.

We have a an aging rails monolith that gets cast aside whenever there's more important work to do, which is most of the last 8 years or so. The maintainer (my old boss) stopped deploying properly and there was code drift on prod.

He left, my time freed up because claude, and I gave claude the directive of making an API to use with a Vite frontend so we can rebuild the UX carefully with user input along the way, and the end result will be running the monolith in parallel while users migrate to the new platform, monitoring, then phasing out the rails app. I'm skipping over a lot of the details, but so far so good, there's a light at the end of the tunnel.

If I was rebuilding the same app today, I'd still probably use rails as the API layer. The conventions are great, it's readable for when you need to read it... before AI the JS community was forever hunting for the "rails for node" and never got it. I think that says something.

This article has revealed my naive interpretation of Betteridge's law to be inaccurate. The law is unbroken here despite my initial reaction to the contrary; its subject isn't the naive boolean value of the question, but the broader intent of if the question disproves the underlying null hypothesis.

Unrealted: As others have pointed out, the contents of the article are scoped broader than Rails. If we pursue that derail: Rust is still, in my opinion, not a better choice for web programming than Ruby nor Python. It's fine for small HTTP services, where there's a proliferation of (often-Tokio-based) Flask-like Frameworks. There is still a dearth of Django or Rails like ones, which I prefer for websites.

I don’t think dynamic languages like python/ruby/php (I know there have been improvements regarding type checking, still) should be used anymore in the face of ai-generated code. The advantages of these kind of languages are not as relevant as before

Unless scale or resources are a concern, I see absolutely no reason to use anything else for CRUD apps. I sure as hell won't be writing any `sql` statements in nextjs anytime soon.

I mean, if we're not gonna read any code ever again, who cares?

Why don't we have the AI output machine code binaries. Surely that's even better!

To be clear, I think this is ridiculous and I'll still use Ruby/Rails for web apps because it's tested, it works and I can read it without relying on a paid black box translator.

Once/if the paid black box becomes so good we no longer care, then it'd be stupid to force it to use an inefficient language just for the sake of it.

I just tell ma agents to drop a cgi-bin/ folder on my server and just perl it out. Who cares, I don't wanna look at the code. lol. just kidding :D

As long as frameworks and languages offer some novel eval to the agents, they’ll remain advantageous for certain projects. Rust is the most obvious case, giving the agent a borrow checker.

I think the frameworks with strong batteries-included conventions also offer unique guardrails for agents building more ambitious apps. Those conventions allow for highly opinionated linters and well-worn migration paths, which become an eval advantage.

Eventually we will develop new languages and frameworks that are tailored to agents maintaining projects on epic time horizons. Until then, we can squeeze free evals out of these existing convention-laden technologies.

"The fact that an LLM now writes the code does not mean any abstractions we made before are suddenly less important or less useful." - I think maybe it does, we just don't know it yet.