Hacker News Reader

Hacker News

Comment by shdtabasum | Hacker News Reader

Parent Full thread

shdtabasum

LOL, this kind of things will happen when projects like Bun (https://github.com/oven-sh/bun) are running on auto. :)

View on HN

More than 50% of the recent commits are from robobun, jesus

It's AI all the way down.

An issue reported by a person account but post made by AI. https://github.com/oven-sh/bun/issues/39800

AI (robobun) responds and creates PR. https://github.com/oven-sh/bun/pull/37459

AI (coderabbit, claude, github actions) review the PR, AI (robobun) applies the fixes.

Some AI back and forth.

A human finally merges the PR.

Not gonna lie, it's kind of beautiful.

Some guy, profiling his linux distro, wonders why ssh connections are a few hundred milliseconds slower than expected, finds there PR introduced and RCE backdoor and p0wns the whole project.

Seriously, this is driving me insane. The XZ hack told us what we had to do to secure our supply chain, and instead we went ahead and implemented a worldwide standard for NLP-to-action and figured we'd worry about the guardrails later. Mad.

ref: https://en.wikipedia.org/wiki/XZ_Utils_backdoor

As it should be if not more. What's wrong with it?

Here's the most recent nontrivial one as of this comment: https://github.com/oven-sh/bun/commit/d4de65e9a43224a14591ad...

The code change makes no sense and should do nothing. The commit message described a very deep investigation into garbage collection on the C++ side. Some object is being kept alive when the test requires it to be collected, and changing the code in this way allegedly prevents that. But wouldn't you think there would be a better way to ensure an object gets collected, like setting the variable to null?

The comments in the code don't make a lot of sense either. Something so obscure and brittle has to be explained extremely clearly.

While the issue might be real, this commit is so far away from the locus of normal that it's sending red alert. Plus a hallucination is very likely with such a long investigation - once an LLM agent starts investigating it just assumes there is a problem. And this is the 1 out of 1 robobun commit that I looked at.

Edit: here's the next one: https://github.com/oven-sh/bun/commit/72ec6e2594892455df0090...

Make sure the fs module keeps working if someone freezes or seals its exports table. I was wondering who was going around freezing random tables from other modules, so I checked the linked issue - robobun reported the issue, too. Why? I'm skeptical of whatever robobun was doing when it decided that it was necessary for code outside of a module to freeze their export tables. It needs a very good justification.

The first is, annoyingly, a relatively common problem and solution when dealing with GC lifetimes in tests. Few interpreters/JITs want to generate extra instructions to null out stack slots or pre clobber registers to ensure something becomes collectible at a specific point. Eager nulling of a variable often gets removed by dead store elimination or even just from being a disconnected SSA node. I've written extra nested scopes or wrappers in Java to deal with this in tests.

Don't know anything about the second one.

If this is needed in tests it needs to be known how it works, it needs to work consistently, and it needs to be documented how it works. It can't be an ad-hoc deep investigation and random fix each time. The comment should then be just // ensure foo is no longer a GC root, see gc_roots.md

It needs a comment for sure. I always write a little helper utility to manage that when I need it.

This will result in pretty low quality software.

I've had opus 5 along with its AI code reviewer agree to do some pretty stupid shit.

Opus 5 is only usable when Sol is reviewing its output.

Opus 5 is a trash model

Wait till you see what some people agree to.

Ah the good old "AI isn't bad because people are bad too" argument

Wow...

I am currently using bun, but may have to switch. I can't see how this can possibly turn out well in the long run...

3.3k open issues holy shit

and all of high quality

https://github.com/oven-sh/bun/issues/39797

And 5K PRs. I'm crying.

> 5k PRs

Wow, is Bun the record holder for number of PRs?

I recall GitHub recommends to keep the number of PR to a certain level due things such as GitHub Actions slowing down.

Nixpkgs has 11k open PRs at the moment (a lot of them routine version bumps and such), so no. But then Nixpkgs isn’t a piece of software in the conventional sense: the monorepo does contain a few of those, but most of it is a giant collection of basically-independent build scripts.

that's the interesting part : forges are being abused.

Sure AI workflows might be a non-negligible share of all that usage but still the point is that initially forges existed to help developers collectively share a state then solve problems. Nowadays they are basically online filesystems with better notifications for other software to interact with and only optionally developers actually communicating.

You never could scale tulip buds so quickly - progress! ;-)

Strange to think they are probably triaged by LLMs at this point

AI finding issues in code and reporting them so that an AI can review and triage them for another AI to fix.

That seems to be what's happening. Like 2-4 bots talking to each other, then Jarred Sumner just does the final merge with little comment.

https://github.com/oven-sh/bun/pull/39743 https://github.com/oven-sh/bun/pull/39735

github-actions: "If you need a paragraph-long comment to justify why the workaround is OK, the code is wrong — fix the code"

robobun: "The ordering is load-bearing: reclaiming before this block made is_dead_request true and hung a parked textStream read (caught by body.test.ts in CI). The comment pins that constraint."

Ah, well, if something is load-bearing, then I guess that settles it. Need a comment to pin that constraint, in case a read is parked. These are words that normal humans commonly use in these ways.

(Always striking how much Claude obsesses over the minutiae of method contracts and side effects, exhaustively documenting them in comments. It’s much happier figuring out how to reorder some method calls with nonobvious side effects so the code works than it is refactoring them not to do unexpected things!)

I mean, isn't that the dream?

I don't know if that's sarcasm or not. I know it doesn't work, but that's the future we've been promised, right?

If the same AIs don't hallucinate and create bugs in the first place.

I don't know how much my own time is wasted on Claude imagining API response formats that never existed.

It's certainly someone's dream: https://devhumor.com/media/dilbert-s-team-writes-a-minivan

> I mean, isn't that the dream?

Unironically: no.

Why it doesn't work? It is working for me. It is working for bun. It is working for others who actually embraces it and puts in the work to get it working.

I recognize your username from other comment threads and would classify you as a bun fanatic, but even so, I’d hold off on saying, “it’s working for bun,” until 1.4.0 has been out of canary for, like, more than 24 hours. Most real users haven’t onboarded to it yet.

so first it was rust rewrite bad. Then rewrite with ai can never work. Then it will be riddled with bugs. It'll crash. It'll take years to fix.

On the other hand, rewrite was mostly done in record time. New version added massive number of features. Also huge bug fixes. Being used by Claude code by millions of people. Successfully used by some others even in canary. After release, multiple companies immediately switched due to massive amounts of resource savings and performance gains (and publicly posted about it).

Can there still be problems? Yes, I'm sure there will be. But denying the feat Oven pulled off with Bun in last few months is nothing but phobia/fud.

Many people are already posted about testing new bun version and I have yet to see a single post where the issue is the latest versions of bun. In some cases people posted it doesn't work but that's due to node compatibility etc and it didn't work on previous version either.

One does not need to be bun fanatic to see and call things as they are.

PS: I like bun because I hate how js ecosystem requires 100s of packages to do anything and bun is aiming to include batteries. This is good.

sadly someone didn't have free unlimited Fable and Opus like Bun team does

Let's just say my dream does not involve babysitting some robot

Who promised it?

Not my dream…

And...? It just shows how active and big the project is.

Reply on news.ycombinator.com