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.

▲

contextcost 6 hours ago | parent | next [-]

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.

▲

sheeshkebab 6 hours ago | parent | next [-]

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

▲

giancarlostoro 5 hours ago | parent [-]

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.

▲

sheeshkebab 4 hours ago | parent [-]

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

	▲	giancarlostoro 2 hours ago \| parent [-]
		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.

▲

skeeter2020 5 hours ago | parent | prev [-]

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?

▲

Zakis1 7 hours ago | parent | prev [-]

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.

▲

nicce 7 hours ago | parent | next [-]

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

▲

ramon156 6 hours ago | parent | prev | next [-]

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

▲

kikimora 6 hours ago | parent | prev | next [-]

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.

▲

esperent 6 hours ago | parent [-]

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

▲

conartist6 5 hours ago | parent [-]

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

▲

brabel 5 hours ago | parent [-]

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.

▲

thayne an hour ago | parent | next [-]

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.

	▲	adampunk an hour ago \| parent [-]
		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?

▲

soraminazuki 3 hours ago | parent | prev [-]

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.

	▲	brabel 40 minutes ago \| parent [-]
		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.

▲

wiseowise 5 hours ago | parent | prev | next [-]

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

	▲	skeledrew 4 hours ago \| parent [-]
		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.

▲

lioeters 5 hours ago | parent | prev | next [-]

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.

▲

j_bum 5 hours ago | parent [-]

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

▲

sleples 5 hours ago | parent | next [-]

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.

▲

wiseowise 5 hours ago | parent | prev | next [-]

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

▲