Well so far we've been using humans to clean up the code that humans ruined in the first place, it's hardly a logical fallacy

LLMs are as good as the operator directing them.

I’d say I fall in the “AI skeptic but willing to use it” category. If LLMs can actually clean up after themselves it would actually be a game changer.

I came here to post the same thing. But this is addressed later in the same paragraph:

> But hopefully better development practices, with a human in the driver’s seat, and a focus on reducing technical debt and writing idiomatic Zig, mean that in a few weeks or months there will be a presentable codebase that serves as a drop-in replacement for Rust Bun 1.4.0.

So the intention here is simply more steering. Or perhaps better steering (code structure appears to be a matter of taste... I had a very perplexing chat with a friend yesterday who insisted that four backend processes were required to serve a single HTTP request...)

This was always the plan. Code is no longer written by humans, code is LLLM output of broken slop that is mostly software-shaped, impossible for humans to read and make sense of it (because it makes no sense). So the only solution is that all code is intended to be read and written by machines. The human-in-the-loop era was always a stopgap.

Yeah, good luck with that one though. LLMs are terrible at deslop, or they wouldn't slop in the first place.

This is the present and future, willingly or not.

Engineering is about design and plan and architectural integrity and qa. Not writing code anymore.

You have no idea, to slop-circle is getting more common.

In 2025, sometimes I decided to put a slop LinkedIn post to ChatGPT (back then) to deslopify.

Now, the slop circle is everywhere.

Your PO uses automations to create tasks? Half of the comments are bot slop? Links to documents never edited or read by another human? A lazy three sentence description of a task requirement you would have gotten previously sounds like a dream. Now everything generates pages long texts and you can't possibly go through the slop without AI agents. You need your agents comb through the slop and demystify the task for you.

Same with the other end... Slop PRs will be reviewed by your agents, hoping you catch 2-3 issues so that you can pretend you did a review. The author didn't do a review on their generated slop, but sure, let's pretend reviewers still review code.

TFA says the whole codebase is 600k, so that would be 1.8% dead code. IME dead code is much more common in larger codebases as figuring out that code is dead becomes more non-local and changes over time create dead code at a distance. I'm also not sure if the 11k was trivially dead (`if (false) { dead_code(); }`) or if it was more subtle (e.g. dynamically-dispatchable code that can't logically be called).

The 1.8% feels high if it's trivially dead. When I've run simple static analysis on decent codebases before, it's been much lower. For non-trivial dead code, it might be low. E.g. a lot of projects have piles of "dead" code behind ancient feature flags that would never be switched.

A small amount of dead code is fine. E.g. it might not be worth deleting utility methods that you happen to remove the last use of if they are simple and you might re-add a use later. Generated code is often dead since it's not worth specifying to the generator exactly what will be used. Other times, deleting dead code can lead to a valuable cascade of other deletions and simplifications.

At my last company I cut 8k lines from a 10k component and fixed every major bug in the process. It wasn't "dead" per se, but if you start by cleaning up one little bad abstraction then that opens opportunities for the next one and the one after that till eventually all you're left with is software which actually does what it's supposed to.

That hasn't been a unique experience either -- quite the opposite. Codebases bloat over time. The only thing astonishing to me is that in something as large as Bun they only found 11k lines.

The Zig compiler compiles lazily and does not detect dead code. (Read: functions that are not called from any compiled functions)

I'm astonished that anyone is astonished by this amount of dead code in any large code-base. That's like 10 somewhat normal sized PRs worth of code.

After the all the noise surrounding the forking of the Zig compiler in order to speed up builds, I'm really surprised that this isn't the top comment. The fact that a one-man team achieved 1s build times proves pretty conclusively that slow build times were entirely result of negligent development practices, and that the fork was a complete misallocation of time.

The people who originally worked on Bun themselves would disagree with your point (but their situation was based on the premise that they did not take the steps required to leverage incremental compilation): https://zackoverflow.dev/writing/i-spent-181-minutes-waiting...

And, unrelated to Bun, I too would disagree. You don't want to have to wait minutes for a build to complete before you can run the test suite, or even just know if there was a semantic error in your code. Build times are 100% a bottle neck for big-enough projects.

> It’s a Herculean task, though.

I believe it’s spelled Sisyphean.

Breaking: JavaScript developers create three new frameworks/kits while you were reading this sentence.

> Can't we just go back to node + npm + vitest + vite?

You're kind of stating the reason for the buzz there: one runtime that does everything you need rather than cobbling together a dozen different tools.

Not that there's a problem cobbling together different tools made to do a job, each tool has a purpose and solves a problem, but having all problems solved out of the box is very convenient.

Bun does offer an additional major advantage, i.e. the bundler has a runtime API, so the same process that serves your assets can also bundle them in memory without having to coordinate an external bundler writing static files to disk.

There’s a project Nub that is meant to bring the benefits of bun to node, which you might appreciate. It also may articulate that gap as to why people like using bun.

https://nubjs.com

>Can't we just go back to node + npm + vitest + vite?

The mere enumeration shows how bad it is.

Every new framework gets buzz on HN and is forgotten a day later. Meanwhile 99% of developers never left node + npm + vite in the first place.

At this point, I'm not sure anyone should still be using npm.

Node is too slow, plain and simple.

I've experimented a lot with all nodes up to 24 latest and bun has consistently led to sizeable speed ups.

As AI will only get better, accepting contributions can also be automated.

The tendency is that open source will die as a collective effort, except for some hardcore stakeouts. AI will become the repository owner. The rest of us just doesn't care enough.

This puts users in control.. just pay and you get your feature in a version generated just for you.

What's the situation with Deno these days? I care about having a fast/secure/modern JS environment and I've been burned by node.js in the past.

I'm not that optimistic for Bun with all the recent churn/slopcoding but the pitch of "use this one good TS tool for everything" is appealing.

What if adding features wasn't the scope and just providing a fast and memory efficient runtime that doesn't pretend to be everything at once.

> Bun users who don't care about slop will continue to use Bun

What slop does Bun create or cause?