Hacker News Reader

Comment by qsera | Hacker News Reader

I think it makes sense to stay away from large code bases built using LLMs until it is proven that it is possible to also maintain such code bases using LLMs or using reasonable human effort.

View on HN

It's alarming how people instantly jump to conclusions that Bun is now "AI slop".

Bun has been almost entirely worked on by LLM's for ~6 months now, long before the Rust re-write (source: https://x.com/jarredsumner/status/2054525268296118363). It already has been proven that LLM's can maintain such codebases.

Bun never was great in terms of stability. It has been vibe coded for 6 month but code was reviewed by a person.

>It already has been proven that LLM's can maintain such codebases.

Proven is a strong word. In my experience AI fails miserably at anything beyond junior level tasks. We will see soon, once bun goes into production.

> Bun never was great in terms of stability

It's very easy to throw shade like this on software if you've got a bugbear with it. I'm sure you can even come up with a bunch of these "stability" problems when challenged on it. I know I could, for basically any large piece of software that I've ever used.

But really, is bun worse in this regard than any other similarly ambitious open source software within it's first few years?

see that's fine with me if they want to take a year or two of human time and do the rewrite properly

this is a piece of software with no architecture, and whose owners have no regard or respect for architecture. I can virtually guarantee that on average every bug they fix will create one new bug, because that's what it's like to work on software with no intentional architecture

What are you talking about?? Bun in Rust is a port, almost exactly the same code base on a different syntax. The architecture did not change at all. Amazing how people comment without even knowing what they are talking about.

Zig and Rust are significantly different languages. If bun has a good architecture in zig (which I don't know if it does or not), that doesn't necessarily mean it had a good architecture for rust. A direct translation of zig code would probably result in pretty unusual rust code, and probably a lot more unsafe usage than if it had been originally written in rust.

I don’t really understand this objection. For every tool that I use, am I supposed to divine the best underlying language for it and then determine whether or not it is written in that language? Don’t I have better things to do?

Because of borrow checker you would build data structures differently in Rust compared to Zig. Automated translation simply maps Zig constructs onto unsafe Rust code. I have no idea how feasible it is to go from totally unique way of using Rust to mimic Zig to idiomatic Rust.

I understand that. That’s a specific example of an inaptness moving from one language to another. That’s not what I’m talking about.

I am asking if we are expected to understand this hypothetical condition about all possible tools that we use. Should I have to worry that something is written in Python when it should’ve been written in C? It just seems like that in order to have a big concern here, I had to be really invested in what language Bun used. I guess the whole matter makes more sense if people are REALLY mad about something else and the choice of language is supposed to serve as a more respectable thing to be mad about.

I'm not saying that bun shouldn't be written in rust. I'm saying that since it was originally written in zig, there were undoubtedly architecture and design decisions that were made that made sense in zig, but not so much in rust. When rewriting something in a different language, especially one significantly different than the original it is common to need to re-architect some things, and mechanically translating line by line from one language is probably going to result in some low quality code, even if the original was decent.

I think that using AI to translate bun from zig to rust might produce a good starting point. But it was done one file at a time, with minimal human review, and I'm skeptical that the result is quality maintainable code.

I don't want to say that skepticism is unwarranted, but I'm not sure we apply this level of scrutiny with any kind of defensible evenness. I just can't think of a single open source project I use where I'm aware of their refactor cadence and practice. I'm just...not checking in on their feature branches and stuff, and I think most people aren't. I couldn't tell you if the uv maintainers work at 3AM while high on drugs or at 9:30 AM wearing FORTRAN blue ties.

I dunno. I think my sense here is that the bun maintainers did something shocking and dramatic using AI and people are shocked and dramatized. They're not WRONG to be so. But I don't know that the shock comes out of any generalized duty of care we have toward open source tooling. I think the uncomfortable point that bun has been releasing for 6 months with smaller AI code edits hasn't really been reckoned with. If we were actually this invested in what was happening, the migration would've begun months ago when it was clear they were using agents to ship code faster than they were willing to review.

What is that tool in relation to the rest of your workshop though? If it's a simple hammer that you can swap out for $20 and you only use it once a month, who cares what kind of metal it's made out of, as long as it works. But if the $6,000 4-axis CNC machine that's at the heart of your machine shop and every minute of downtime on it costs you money, if it's starting to rust, no, you don't have better things to do than to look into what it's made of.

Yeah what if the tool is a JavaScript runner released for free?

What is being expressed here about Bun is using the language of due diligence but doesn’t seem to adhere to any of the sensibilities. Should we all be auditing our toolchains to understand internal decisions that each toolmaker undertakes? Maybe! DO WE? Absolutely not. The level of scrutiny bun is getting is *unusual*. They just did an unusual and dramatic thing, so it’s not surprising. But I just don’t believe that bun is being deprecated due to normal engineering discipline that we are constantly carrying and applying everywhere. That’s…just hard to buy.

We're all only human, so the deprecation happening is gonna have some biasing going on due to how people feel about AI, yeah. JavaScript runners is a whole ecosystem separate from, say, Python. If Python went and said that the next version of Python, we're using this new AI transpiled runtime that we baked for nine days, people would also freak out "due to normal engineering discipline that we are constantly carrying and applying everywhere." The real question then is just how far off from normal is it? Maybe you don't do audits that you think you should be doing, but eg moving from Python 3.10 to 3.12 can be as rigorous or as yolo as you want. And those versions are old, too. Other ecosystems are going to take their time as well. LLVM isn't going to switch over to something AI banged out in nine days. They're going to have a long dragged out period where they run things in parallel for a while until everyone feels okay about it. If they'd even do something like that.

Very amazing indeed. Here you are making bold assumptions about a huge pile of code not a single human being has ever read in any meaningful amount.

The only assumption you need to make is how the process went about, which was described by Jarred on a HN comment when the PR was first discussed: they had prompt that described exactly how things should be translated, for each "pattern" they were using in Zig, an appropriate equivalent was described in Rust. Zig and Rust are not that different, both are system languages and things can be done similarly in both languages, so architecture-wise I would think the exact same thing would work fine. I am not sure whether the LLM actually wrote a transpiler which just followed the rules, or if it did the job itself, since that information is not public yet, as far as I know, but my guess is that the LLM wrote a transpiler to do the job, then reviewed/fixed compilation issues, then fixed tests. And I'm pretty sure some human interaction was part of that as well.

>The only assumption you need to make is how the process went about, which was described by Jarred

This is not how the process went. This is how Jarred thinks it went, a huge difference.

>my guess is that the LLM wrote a transpiler to do the job

My guess is different. I think one agent translated code, another compiled it, feeding errors back into translator to fix. Then last agent modifies code to fix tests. All governed by a set of md files.

So now you've gone from making assumptions to making up wild stories territory. Well, the commit granularity isn't that of transpiler passes, and more importantly, it's completely irrelevant to how the majority of the code hasn't even been read by anyone.

Nobody reviewed resulting code. Maybe all tests are empty and this is why they pass. Maybe tests were modified to pass because this is the only thing LLM could do to make them pass. Maybe it hallucinated something in the process. We have no idea.

We do have an idea, and it contradicts your guess: https://news.ycombinator.com/item?id=48133806

You suggest there is only JS tests that do not need a rewrite? This is crazier than I thought…

I took tests as an example. There are so many other things that can go wrong. Rust and Zig standard libraries may have different semantics not picked up by AI. Like one guarantees insertion order of a dictionary and other does not. Differences in how runtimes react to Linux signals, how they do file IO, etc.

If I were a Bun user I would be moving off from bun unless it has excellent test coverage (which I think it does not). During a normal release cycle I offered a small increment of functionality with small number of issues. Here I’ve been offered a complete rewrite, potentially having thousands of issues. I don’t want to be a guinea pig in this experiment.

I’m genuine curious how this will unfold.

> It already has been proven that LLM's can maintain such codebases.

Is it? Seems like bugs in Claude Code are getting out of hands. That project has a bit more lifetime.

Is it that, or is it just that every software developer, enterprise, dev and non-dev alike has their eyes on Claude Code as the most popular software project ever? Software in general has tons of bugs. People need to understand scale here, and what this looks like in practice. They're doing an incredible job given the circumstances.

> Claude Code as the most popular software project ever

I don't think that's true? The likes of Chrome, Linux, curl, sqlite, etc, are much more widely used.

I'm not being literal. Revolutionary technology arrives on the scene, is extremely visible, changes a whole industry and frankly creates an entirely new economy. All eyes on Anthropic.

They don't get enough credit for being right in the middle of a revolution, yet still managing to ship something that largely works incredibly well, because this thing is a workhorse.

They don't get enough credit? Anthropic is making an insane amount of money. More popular software projects have made exponentially less and have received even less media attention/fame/whatever metric you might use to define success.

> It already has been proven that LLM's can maintain such codebases.

It hasn't. Those are two different scenarios. The first is individual PRs into an existing, majority human-authored and understood codebase where the PRs are initiated and merged by humans even if the code is AI generated. The second is AI rewriting AI written code that no human eye has seen. Bun took a conservative, transliteration file-by-file approach so they still understand the data structures and architecture so they will probably be okay though.

Worked on by LLMs is fine, but the rust pr proved no one is reviewing anymore. You cannot review 1M LOC in 5 days.

> Bun has been almost entirely worked on by LLM's for ~6 months now

So what you’re saying is that this boycot is 6 months overdue?

I think what they're is all is well as long as they aren't told that LLMs are doing most of the work. Being in the know is the issue here IMO as they would've continued using without a word otherwise.

That explains the massive rise in segfaults since they got acquired.

It’s approaching being as buggy as claude code which I’ve had to stop using even though I have 6 months free of max because it just crashes and freezes all the time.

It's alarming how people are willing to overlook the obvious in-your-face sloppiness of the Bun rewrite. A million lines of code in 9 days, pushed to main branch, forced on the existing userbase irresponsibly.

Nobody understands the code, nor will they be able to maintain it without AI service as an external dependency. Give me a break, I'm not running that monstrosity on my machine. Everyone running production software should move away from Bun purely as a technical decision.

Do you use Claude code on your machine? That seems mostly vibe coded

1. I don't use Claude Code, no.

2. It's amazing that a CLI wrapper is as buggy as it is.

3. Nevertheless, it's useable, and maybe for a CLI that's enough. I don't want a JS runtime running production to be the same mess.

Claude Code isn’t a runtime that I use to execute my code with.

If you use it to write code for you, then it kind of is, indirectly.

That is quite the stretch you're making.

I run my code on Emacs as nature intended

that seems comparable to taking a dev-time dependency, while bun is a runtime dependency. THey need to be treated very differently.

Fair point, wasn’t considering it from this angle.

6 months is plenty of time to keep ignoring serious tech debt. I don't think your conclusion follows at all from such a short time.

Yeah, bizarre and sad. And, unsurprisingly, Hacker News seems sympathetic. They are getting very old.

I have an idea on how to tell if a codebase is rotting under AI Agent maintenance. We can collect and analyze how the coding agent reads code during programming tasks, and see if the code access and token consumption are steadily increasing for similar development tasks. If the code readability doesn't degrade for the agent, the maintainability of the codebase should be fine.

Mist of human written codebases are unusable for llm dev by that definition.

Turns out that if they're unusable by LLMs they're likely unusable by human devs. If you follow sane clean coding principles (like not having godclasses) it turns out coding agents (and humans!) can understand and navigate your codebase, especially if you use recognizable patterns, even with very light documentation.

One of these days you’ll learn about “enterprise” code

I have seen good enterprise code and bad enterprise code. Clean Code suggests progressive rewriting of bad code.

When you touch a file you have an opportunity for code clean up, add unit tests to ensure your changes break nothing, and refine the code.

Agree, agentic coding seem to have shifted the trade-off about over-engineering, I found clean architecture is a good practice for coding agent, so every task have a clean and limited context, only a few directly connected classes or interfaces is relevent to any local modification.

We judge long-term quality of human codebases (at least OS) by ongoing activity; for LLM codebases maybe a consistent or increasing level of activity is a bad smell?

Reply on news.ycombinator.com