Hacker News Reader

Comment by rcoder | Hacker News Reader

In ~25 years or so of dealing with large, existing codebases, I've seen time and time again that there's a ton of business value and domain knowledge locked up inside all of that "messy" code. Weird edge cases that weren't well covered in the design, defensive checks and data validations, bolted-on extensions and integrations, etc., etc.

"Just rewrite it" is usually -- not always, but _usually_ -- a sure path to a long, painful migration that usually ends up not quite reproducing the old features/capabilities and adding new bugs and edge cases along the way.

View on HN

Classic Joel Spolsky:

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

> the single worst strategic mistake that any software company can make:

> rewrite the code from scratch.

Steve Yegge talks about this exact post a lot - how it stayed correct advice for over 25 years - up until October 2025.

Time will tell. I’d bet on Spolsky, because of Hyrum’s Law.

https://www.hyrumslaw.com/

> With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

An LLM rewriting a codebase from scratch is only as good as the spec. If “all observable behaviors” are fair game, the LLM is not going to know which of those behaviors are important.

Furthermore, Spolsky talks about how to do incremental rewrites of legacy code in his post. I’ve done many of these and I expect LLMs will make the next one much easier.

>An LLM rewriting a codebase from scratch is only as good as the spec. If “all observable behaviors” are fair game, the LLM is not going to know which of those behaviors are important.

I've been using LLMs to write docs and specs and they are very very good at it.

That’s a fair point — I agree that LLMs do a good job predicting the documentation that might accompany some code. I feel relieved when I can rely on the LLM to write docs that I only need to edit and review.

But I’m using LLMs regularly and I feel pretty effectively — including Opus 4.5 — and these “they can rewrite your entire codebase” assertions just seem crazy incongruous with my lived experience guiding LLMs to write even individual features bug-free.

When an LLM can rewrite it in 24 hours and fill the missing parts in minutes that argument is hard to defend.

I can vibe code what a dev shop would charge 500k to build and I can solo it in 1-2 weeks. This is the reality today. The code will pass quality checks, the code doesn’t need to be perfect, it doesn’t need to be cleaver it needs to be.

It’s not difficult to see this right? If an LLM can write English it can write Chinese or python.

Then it can run itself, review itself and fix itself.

The cat is out of bag, what it will do to the economy… I don’t see anything positive for regular people. Write some code has turned into prompt some LLM. My phone can outplay the best chess player in the world, are you telling me you think that whatever unbound model anthropic has sitting in their data center can’t out code you?

Well, where is your competitor to mainstream software products?

What mainstream software product do I use on a day to day basis besides Claude?

The ones that continue to survive all build around a platform of services, MSO, Adobe, etc.

Most enterprise product offerings, platform solutions, proprietary data access, proprietary / well accepted implementation. But lets not confuse it with the ability to clone it, it doesnt seem far fetched to get 10 people together and vibe out a full slack replacement in a few weeks.

If the LLM just wrote the whole thing last week, surely it can write it again.

Broken though

* With a slightly different set of assumption, which may or may not matter. UAT is cheap.

And data migration is lossy, becsuse nobody care the data fidelity anyway.

If an LLM wrote the whole project last week and it already requires a full rewrite, what makes you think that the quality of that rewrite will be significantly higher, and that it will address all of the issues? Sure, it's all probabilistic so there's probably a nonzero chance for it to stumble into something where all the moving parts are moving correctly, but to me it feels like with our current tech, these odds continue shrinking as you toss on more requirements and features, like any mature project. It's like really early LLMs where if they just couldn't parse what you wanted, past a certain point you could've regenerated the output a million times and nothing would change.

Reply on news.ycombinator.com