Hacker News Reader

Comment by juliangmp | Hacker News Reader

I feel like we need to heavily differentiate between a rewrite and an AI rewrite.

For instance, the TypeScript rewrite in Go was done mostly by humans and took a year before it was released. That is how you rewrite software that people can trust.

AI is a great use for this kind of boring, rote translation where precision is important. Humans are quite bad at it and tend to make mistakes. In either case the focus should be on improving testing, not trying to manually verify if the translation was correct by eye.

With programs large enough tests aren't going to ever be enough. Formal verification might work, but then who checks the specification for bugs?

In the case of rewrites, the specification is the original behavior, no? bugs and all.

There is often no spec, just the old code, copied with the old bugs and with new ones sprinkled on top.

Deciding if two programs do the same thing is provably impossible in the strict mathematical sense.

I really wonder where all of these people who believe that tests perfectly encapsulate the behaviour of software come from. Maybe it's because LLMs happen to work better when you give them acceptance criteria and people struggle to distinguish between "better" and "good"?

The real test is years in production. Over time your test suite grows when bugs are found and fixed, but not every bugfix necessarily gets a test, and it's very rare that a bugfix is exhaustively tested. Relying on the test suite as a directional indicator that your vibecoded rewrite functions something like the original is probably sensible. But it isn't "done" until you've run it in production for at least as long as the original. And that's where it all falls apart, because maintenance will be a nightmare. Nobody knows how the new thing works.

Ladybird's Rust port of the JS engine was a good example. Compare the output byte-for-byte, run both in production (with the new code disabled but checked) before releasing. It was LLM-translated but done carefully.

I have an issue with the precision of generated code.

LLMs sometimes confidently leave things out or they will overbuild.

I use them all the time but mistakes happen. It's not exactly a scalpel, more like a sledge hammer.

If precision is important then non deterministic AI is simply not a good tool.

What about human written software makes it more reliable than LLM written software?

is it the craftsmanship, or the deliberate decision making of industry veterans?

It's the notably poor quality of LLM-generated code

As opposed to the incredible code that humans are known to write...

If attention is all we need then what is better

Hours of human attention

or a few seconds of AI attention?

I am not just talking about writing the code but the brainstorming that goes into it.

I mean, yes? Every engineer on my team produces better code than Claude. There are plenty of examples of excellent human produced code, so this argument always falls flat for me.

> mostly by humans

`mostly` is doing a lot lifting here. The Go rewrite uses plenty of copilot. The reason you trust it is because you trust the people doing the rewrite.

Many projects that were done by humans and took a year can certainly not be trusted.

Not sure it’s so simple. I think close to 100% of new ambitious projects are going to leverage AI at least to some degree. I know a couple that have strict no-AI policies (e.g. Zig), but it’s a tiny minority i think.

So how much AI usage does it make it an “AI rewrite”?

When the majority of the code is written by AI, it is more than 50%.

Dunno. I got rather the impression that it's ambitious single-developer projects with no intention of maintenance which leverage those 'AI' code generators the most.

Who wants to contribute to an unmaintainable code base?

> I think close to 100% of new ambitious projects are going to leverage AI at least to some degree.

Once the free money dries up that number will rapidly tend towards 0%.

> So how much AI usage does it make it an “AI rewrite”?

Any amount.

A human rewrite without maintenance is just a hobby project. An AI rewrite is just wasting tokens for god knows what?

rewrites feel like an area where LLMs are better suited than humans imo

It’s mostly grunt work and LLMs are well suited for translation tasks (iirc transformers arch was originally invented for translation)

It’s just a build step now.

nope. any rewrite will be an AI rewrite soon.

It's not that... It's a rewrite by project maintainers vs a fork.

We already have a well established term for AI rewrites.

I agree but I think from Bun we learned that a project with really good tests and enough tokens can be converted from one language to another quite good!

It is more and more the future. No human would want to rewrite one technology to another because it is too marginal a gain. AI on the other hand does not give a shit.

You underestimate what people are willing to do just for fun.

Yeah like what do they think the people porting doom to everything possible are thinking?

> No human would want to rewrite one technology to another

Except for when they do, like the new TypeScript...

That was before good end to end models though, they started it in 2024 where it was in 2025 that models were capable of long term continuous work.

I'd %100 prefer an opus 4.8 rewrite over %99 of the time. Unless Fabrice Bellard is rewriting the stuff I need, I'd prefer AI over a human coder.

Or, you know, you can use Postgres. It's right there for you.

why? if a rewrite is better/faster/secure, why not? (I'm not saying PGrust is better, I didnt even install it, my perspective is in general)

Of course, if the rewrite is all of those things, then it seems like a good option. The whole point is how do we know if it actually is better.

Because it is not trustworthy, which is really the most important thing.

AI is an average coder.

It was trained on all code the code that could be found.

Not just code written by genius programmers like Carmack and Bellard.

Given that it's average, I'd prefer a human coder above average :)

Which you will necessarily have if they’ve completed a Rust rewrite.

You haven't been using AI extensively I presume...

I've been programming a long time and considered myself among the top in my domain and AI agents using like GPT 5.5 etc. are much better than me.

> You haven't been using AI extensively I presume...

Ex falso quodlibet

> I've been programming a long time and considered myself among the top in my domain

I am not trying to attack you, but you considered yourself that... I don't know whether you actually were and frankly I don't care.

LLMs learn a distribution during pre-training, not only an average.

Then, by giving them context or by post-training, you can make them sample non-average parts of the distribution they learned.

> Then, by giving them context or by post-training, you can make them sample non-average parts of the distribution they learned.

How do you derive that something is "below average" or "average" or "above average"?

Well, it’s up to the user or post-trainer of the LLM what they believe to be above average. Then they can design around that.

In the case of real world LLMs and post-training, what is above average is defined roughly as: labeled good by expert humans, and scoring high on RL environments related to coding like debugging, passing tests, or running efficiently and verifiably correctly.

> How do you derive that something is "below average" or "average" or "above average"?

One technique is RLHF: have an human expert assess it.

Mhm, I just wonder how many samples they get and how much time they have to come to the conclusion.

Like a short example is easier to grade, but not in the same ballpark as a whole codebase.

>How do you derive that something is "below average" or "average" or "above average"?

How do you? I mean, that was your point basis.

I dont think Opus 4.8 is an average coder, with my own experience (I have coded 20 + years before even llms existed) it is anything but average. I don't think training data alone determines the success of these models, there are lots of reinforncement learning principles and fine tuning takes place, a crappy code in the dataset doesnt hold those llms scoring high in benchmarks, I dont think an average programmer can score 70% (opus 4.8) in SWE Bench Pro, which is a good one.

I think Opus 8.4 is a below average developer, but maybe I have just worked with good developers and have a skewed perspective of what the average is.

I would say it's an average coder when it comes to writing functions because it keeps using regex. It might pass a benchmark but doesn't pass the smell test.

That is not how it works. IF it was condemned to be average models wouldn't be constantly improving, given that humans aren't getting better.

Is there any measurable difference in quality between the two, or are you just going on "vibes"? Is there a correlation between the quality of the manually written code and AI generated code driven by the same dev?

Such crude takes only cause unnecessary friction. If you have a black box that spits out code, and you are unable to distinguish the quality between a top tier dev and an AI inside the black box, then the distinction is unnecessary. Most of the code on the internet is already a black box to you. What percentage of code running on your machines have you vetted by who wrote it and code quality?

AI coding isn't going anywhere and will likely end up generating most code going forward so instead of rejecting it outright or arbitrarily categorizing it we need to focus on solid quantitative and qualitative measures of code and functionality regardless of who wrote it.

Didn't the initial rewrite of Bun into Rust have an ocean of "unsafe" in it, and wasn't it entirely dysfunctional?

Yes, that was the point. It made unsafe behaviour visible in a way that could be addressed. I hadn't heard any reports of it being dysfunctional.

I have read up on it again, and while it was entirely dysfunctional at the very early stages, it quickly came up to par or beyond, with the LLM especially helped by the huge test suite written in Typescript, different from both Zig and Rust.

However, Jarred still describes a lot of unsafe, and usage of Miri in continuous integration.

Funnily enough, RAII is cited as a major benefit of rewriting from Zig to Rust, while C++ already has RAII. I wonder if C++ and Rust are more suited to larger programs than Zig, unless the architecture in Zig is handled carefully.

The LLMs may have seen larger codebases in Rust, helping them to cope better.

There's still no release of rust-bun so then it might just not exist (until it proves itself).

Yesterday we learned that it’s been shipping with Claude Code since mid June, so it has a lot of active users already.

Also, the unsafe footprint seems reasonable — the bulk of it in FFI wrappers.

> Is there a correlation between the quality of the manually written code and AI generated code driven by the same dev?

If the dev doesn't vet the code, it doesn't matter how good quality a dev they would be if they wrote the code - they didn't. Sure, the dev would probably drive the initial architecture discussion better and some people are using AI in small batches with tests and vetting everything, but some previously great devs are throwing in PRs that touch hundreds of files at once with one commit.

A lot of people I previously considered great developers have become people I would not recommend for a job in the past 2-3 years.

> If you have a black box that spits out code, and you are unable to distinguish the quality between a top tier dev and an AI inside the black box, then the distinction is unnecessary.

Sure, but this is just begging the question. If nobody could tell, the term 'slop' wouldn't have become so popular.

You must be replying to a different comment. Seems completely unrelated to what I wrote. I never claimed that there wasn't AI slop. My point is that there are different levels of code coming out of AI, both due to the quality of the model and harness, and the quality of the engineer that is driving it. Thus you can't just bucket all AI developed code the same.

100% there is slop created by humans and really solid code bases generated by AI driven by a meticulous developer. You are making the exact error I was addressing, which is bucketing all AI code as the same.

I quote-replied to your comment, so I doubt it was unrelated.

> I never claimed that there wasn't AI slop

No, but you implied that a top tier dev doesn't produce slop when using AI.

> If you have a black box that spits out code, and you are unable to distinguish the quality between a top tier dev and an AI inside the black box

My point was that "if" is doing a lot of heavy lifting here and you're coming very close to begging the question.

> bucketing all AI code as the same.

Most people are not "top tier devs" and over time this will probably become more true. Even if I accepted your premise that "top tier devs" only generate solid code bases with AI, the ease of entry and the ease of spitting out thousands of lines of code means the ratio of bad AI to good AI will not go in a good direction unless it becomes too expensive for non "top tier devs" to use. Given this, I think it's fair to assume AI code is low quality until proven otherwise.

Yes most people are not top tier devs and most code is slop whether written by AI or not. I've probably dug through tens of thousands of code bases in my over 30 year career as a software engineer and most are slop.

I also did not claim that all "top tier devs" would always produce better code with AI, but the qualification for a "top tier dev" in this case would be someone who verifies code multiple ways to make sure it is correct. I've seen amazing code come from bad interns that was reviewed mercilessly by season devs, and there's absolutely no reason it would not be the same with AI generated code.

You do realize that you can review the entire architecture and code line for line even if it's AI generated right? My black box comment did not mean you couldn't see the code, it meant you don't know whether a machine wrote it or not.

You've dug through tens of thousands of code bases? 30 years would give you ~10,950 days, so you'd have to be digging into 2 code bases per day, every single day without any breaks for 30 years straight, to get to "tens of thousands".

When I read things like this it makes it very hard to give any credence to the rest of your pro-AI arguments, because it just seems incredibly likely that you're a bullshitter.

Yes, roughly. I try out open source projects as a hobby and a vocation. I've looked at dozens in a day sometimes. It doesn't take more than a few minutes to figure out if the code is slop.

BTW, I'm not alone in my opinion on AI:

https://www.reddit.com/r/LocalLLaMA/comments/1uxbrw4/linus_t...

> Is there a correlation between the quality of the manually written code and AI generated code driven by the same dev?

Aren't you making a strawman argument ? AFAIK this project is not made by an official PostgreSQL core developer, so the entire premise of your argument is invalid.

I phrased that improperly which made you and probably others misunderstand. What I meant is, is the quality of AI generated code correlated with the developer? The answer is yes, a bad dev will absolutely produce worse code using AI than a good developer - the point being that there isn't just one level of quality of code coming out of AI, even with the same model and harness.

Reply on news.ycombinator.com