To me the most interesting fact about this fork is that it has proven that Bun could have had fast builds all along.
To be fair, there are caveats still in place today: Zig incremental compilation does not yet support aarch64 and only the linux linker supports binary patching, but it's just a matter of time before all major platforms are conquered.
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.
GP is talking about the fork of the Zig compiler, not the rewrite of Bun into Rust.
Anthropic submitted to patch the Zig compiler to improve Bun compilation times, it was rejected. One reason it was rejected is that it contained AI-generated code, which is against the community guidelines, but more importantly, it would have been rejected regardless of AI use. They claimed a 4x improvement, something like going from 2 minutes to 30 seconds, but, according to the Zig team, it made compilation non-deterministic, and missed on the real improvement they worked on, which was sub-1s incremental builds.
"Buz" shows that the fork submitted by Anthropic wasn't needed as Bun can now compile under 1s (incrementally), which is much better than the 30s they achieved with their patch.
It is likely that this rejection, especially the "no AI" aspect of it encouraged Anthropic to move away from Zig.
Is there anything suggesting that Bun even attempted to submit their Zig patches? As far as I know, they were stuck 2 versions behind. With the amount of changes and Zig already working on incremental I'm not sure what the point would have been.
Yes it was never attempted, the whole communication on social media about the AI policy was completely detached from the reality of the engineering work being done on either side.
"A large percentage of bugs from that list are use-after-free, double-free, and "forgot to free" in an error path. In safe Rust, these are compiler errors and RAII-like automatic cleanup with Drop. Compiler errors are a better feedback loop than a style guide."
"At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library. I expect this number to go down over time as we refactor from a faithful Zig port (which had no greppable unsafe keyword) to idiomatic Rust, but we are going to continue using C & C++ libraries like JavaScriptCore so it will always have more unsafe than pure Rust projects."
That one’s interesting to me because it speaks to both sides of the debate. Yes, safe Rust is good for catching those kinds of errors at compile time. But also, it should theoretically be very easy for a compiler to avoid those problems in Zig, too, if you are using the language the way it wants to be used.
Which, from what I’ve experienced so far, does seem to take a whole lot more effort if you’re using a coding agent. I spend an incredible amount of time making sure mine doesn’t bloat our codebase with Java-flavored Python, and all the noise and defects and performance problems that it brings.
> But also, it should theoretically be very easy for a compiler to avoid those problems in Zig, too, if you are using the language the way it wants to be used.
agreed. in my side project im tinkering with a memory safety checker in zig that intercepts a compiler artifact, and it works better with idiomatic zig, problematic code is when you try to write c-isms in zig -- so i basicallt tell the checker to reject c-isms that create ambiguity for safety checking.
IMO it's the same problem with Rust. LLMs are trained on vast quantities of code that violate Rust soundness in safe code.
LLMs are prediction engines: you can move the needle (heavily) on the predictions from lazy to correct by construction, but the defaults even on high end models like Opus are always riddled with shortcuts.
LLMs can produce coherent & safe Rust 1.92, LLMs can produce coherent Zig 0.16, but that's dependent on in context learning & instruction following.
> that's dependent on in context learning & instruction following
Not just that. For Rust in particular, since unsafe code is uncompilable code (unless explicitly marked "unsafe"), the LLM is essentially forced to continue iterating even if the code already works but is unsafe, until it finds an implementation that's both correct (per the spec) and safe (per the compiler). That's the difference from Zig, where "make the code safe" is essentially part of the spec, and so may be missed by the LLM and not be discovered by a human until there's an observable runtime issue, or CVE.
Yup. But that also gets to the “they’re both right” angle. Zig’s convention may not be how the Bun developers wanted to work, but it’s a good choice for the kinds of projects Zig is designed for. Which overlaps a bit with, but isn't the same as, Rust’s intended use cases. For example, I might rather go with the Zig philosophy if I’ve got hard memory constraints and want to avoid dynamic memory allocation.
Which, ironically, is something I’d love for my browser’s JavaScript runtime to do. But I can also respect others not wanting that.
I'm optimistic for that refactoring. But if one in 30 lines sprinkled all over everywhere is unsafe then you haven't actually done much to improve safety. When you have a large percent of fully safe functions and modules, that's when you're making a difference. Counting the lines is not a very helpful metric.
> Counting the lines is not a very helpful metric.
Seems self-contradictory.
And they did say they're working to reduce the unsafe code over time. That huge percentage of memory bugs that they were able to better triage and fix due to the port was also them improving safety.
The other part of that line is important. Measuring lines is better than nothing but the distribution is much more important. If they're scattered all over that's a bigger downside than the line reduction is an upside.
If you want good metrics, measure functions and data structures without unsafe. Not lines.
> If you want good metrics, measure functions and data structures without unsafe.
I doubt it, as it's possible a substantial amount of those unsafe areas can't even be removed, given the project's dependent on C/C++ libraries. Without proper calibration those metrics won't tell the full story, and with calibration the incentive for the story will decrease over time with the unsafe refactoring. I doubt the distribution of the unsafe code really matters that much; what matters is proper handling, wherever it is, so stability and security isn't compromised.
The way I'm thinking of it is that they ported Bun from Zig to Unsafe Rust, and are still working on now porting it from Unsafe Rust to Rust (not 100% safe, but a reasonable amount).
The original Zig code is metaphorically one big unsafe block. Even if the Rust port is made up of 3% unsafe blocks, that still means 97% of the original Zig code has been made safe (in the Rust sense).
The safety of safe rust is created by extremely strong and subtle invariants that unsafe rust must maintain perfectly (or all bets are off). The idea that a program with tens of thousands of lines of vibe coded unsafe Rust is memory safe is mind boggling.
IME agents are extremely happy to write more or less convincing // SAFETY: comments (most Rust code in the training set has these just before unsafe { - also it often works in unit tests). However, miri remains broadly unimpressed by comments.
Of note, even that 97% of original code that is now "safe in the rust sense" could violate invariants through safe blocks that cause memory-safety issues. I can't say exactly how the LLM-ported Rust code made use of unsafe but see https://www.ralfj.de/blog/2016/01/09/the-scope-of-unsafe.htm...
No, but when the compiler isn't enforcing anything, how do you know which ones are safe and which ones are not? If we ignore declarations etc. and only consider statement lines that read or write memory, then any such line of Zig (or C, or C++, or any other unsafe language) can be classified as a potentially unsafe — not just today, but in the future, since safety bugs can be generated upstream by giving out pointers that aren't valid or concurrency-safe.
> If we ignore declarations etc. and only consider statement lines that read or write memory, then any such line of Zig (or C, or C++, or any other unsafe language)
Surely it's obvious that's trivially untrue?
Also, literally no code is safe from potential future upstream changes.
Anyway, I'm not arguing zig has the same safety guarantees as rust. That would be silly. But the weird binary thinking around memory safety is equally silly. People want things to be simple, but you really can't come to good conclusions by trying to pretend things are simpler than they are and through a lack of analysis and thinking.
Since they did a one-to-one translation to start with, hypothetically, if these were the true numbers, you could probably get a static analysis tool to guarantee you that 97% of the zig code was safe and tell you which of the 3% were unsafe. Zig has a lot more syntax and conventions to encourage safe code compare to C after all. It just doesn’t have way to mark which parts are safe or unsafe.
An LLM could probably also trivially give you accurate reviews saying which parts were unsafe and in need of tests or reviews. I mean, considering their LLM budgets they could probably have had nightly reviews running every night for years before spending more than their Rust rewrite.
Not that I think Rust rewrite was a bad idea. Rust is a good fit for this kind of project. I say that as a Zig enthusiast. It’s just that their stated motivation and reported results are kinda BS. If they just wrote “we just like Rust and thought it’d be cool to see of LLM could do the whole rewrite”, and left it at that, I think it’d be a more honest description of the motivation. The rest is just rationalisation.
No you cannot get a static analysis tool to guarantee 97% of zig code was safe. Well, you can - the tool is called the borrow checker.
Do you know what's infinitely cheaper and faster than an LLM running nightly reviews of all of the code and infact mathematically provable that the code (and any new code) is memory safe? It's called the borrow checker.
it seems like a reasonable enterprise to intercept the data dependency graph from the zig compiler and subject it to analysis to prove memory safety parameters:
They have made it very clear that the mechanical translation is the starting point, and are refactoring to remove as many unsafe declarations as possible.
This is an example of technical problems being easy but organization being hard imo. It is stupid if you think about it from a theoretical perspective but they didn’t want to use this feature for some reason.
Probably because they did their fork of zig for fast compilation before and they didn’t want to just discard it and use this
Do the caveats mean that it could _not_ actually have had fast builds on all the platforms it supports? (Honestly asking if I connected the dots correctly here, this is not a snarky "actually" rethorical question...)
The pearl clutching about AI is insane to me, as if code quality was perfect before 2022. We have been seeing a decline in software quality for a long time coming now. A lot of AI hatred is not even based on seeing something genuinely bad, its just prejudice for the sake of prejudice. If I could view into two parallel worlds, one where I vibe code something, release it and tell people it's vibe coded, and another where I do the same but tell no one, codebases are both the same and I still reviewed the code, had the model fix issues with code quality and bugs, and genuinely invested hours of my time to raise up, in the universe where I don't mention AI, people will likely sing praises, in the universe where I do mention AI, people will not even review or view a single line of code, they will close the tab, hop back on HN and complain that it's AI slop, without any reasonable reason.
Blind AI hatred is just insane to me and it goes against the spirit of HN, we're not supposed to just go "ITS BAD CODE" here, we are supposed to have actual engaging conversations. Too much of HN devolves into "ITS SLOP" instead of "Hey, I know you're leaning on the AI a bit, but here's what's wrong with the code: ...." which would be more constructive and fall better in line with what I've expected from HN and seen for years, until recently.
AI fatigue and AI prejudice should not be confused for one another, sure you can have both, but most people who hate AI blindly just have AI prejudice at this point.
> "Hey, I know you're leaning on the AI a bit, but here's what's wrong with the code: ...."
I'm generally in agreement, but I think current corporate/productivity culture and AI is a bad mix that makes this quote/sentiment feel impossible. All of the current incentives are set up to push out as much sloppy code as possible, and AI is the perfect machine for doing that in huge quantities, to the point where reviewing all of it is impossible. It's not really AI's fault (imo). There's plenty of ways to use it to design more elegant, understandable, maintainable systems. But unfortunately that's going to take a cultural shift, and part of that cultural shift involves people pushing back against AI as it's used today.
I do agree, if someone's just going to shove what you say to an AI at what point do you ask "do we need to replace you with a shell script?" before they stop being overtly reliant on AI, that's a bridge too far for me, and I am all for letting Claude hack away at code for a while, and then review the code and refine it, a lot of the time even if its not perfect, it gets me like 80 to 90% of the way there, especially if I tell it HOW I want it written, and to consider edge cases.
You can make them output what you would've written yourself, but that would be slower than writing it yourself, so no one does that - but it’s trivially true.
Skilled engineers may still vibe and not care. Beginners may be thorough and experiment and ask till they get the design right even if they don't spot it immediately, just caring does a lot.
Incidentally I’ve always thought that about working on cars, but more like skilled mechanics may still vibe and not care. Amateurs may be thorough but much slower, may need to do a lot of research before every step. Just caring does a lot.
I agree with you about “thoroughness” being key here, but I’d additionally advocate that we need to leave room for people to make some slop learn it.
Part of the learning process, whether you’re a “skilled” or “unskilled” engineer (or not an engineer at all, and noting that going from one to the other is just a matter of learning), is being able to “vibe and not care.” Yes, it’s also helpful to identify things that might not work out theoretically in advance, using the things we learn in our CS programs. But coding with LLMs is a brand new modality, and we are all indeed just learning to work with them.
I think alternating vibe coding with vibe-assisted DRYing/cleaning is ultimately a workflow enhancer that can make better software faster. But engineers have to be allowed to make some slop to learn it.
I'm about to release some tooling that's been very effective for me.
Essentially, there's a few ways LLMs write "bad" code that is different from how people write "bad" code.
We've got pretty good tooling to catch the ways people write bad code - it just happens to be much easier to do with static analysis (and is less noise prone).
The ways LLMs write bad code is typically 1) bad architecture - hard to detect in the ways that are really important, 2) unnecessary state and control flow (and decisions based on state), 3) bad / inadequate tests.
Methods to detect these problems have existed for ages, but they've never caught on because it's typically too difficult to tune them to have high signal / noise for humans, and AFAIK - no one else tried putting them all together and seeing how LLMs work with it.
LLMs are great at sorting through signal / noise -> so you can help surface potential issues with metrics that would be too noisy for humans, but seems to work pretty well for LLMs to find the source of architectural problems and design better solutions (from my experience - may be biased, I built the tooling to literally solve this problem for the main project I'm working on).
Can you elaborate on the tests thing? I'm new to testing, and AI agents recently voluntarily added an large number of tests to one of my projects. I've been learning a lot by reading them, and it seems like a great habit to develop.
But they're also writing some very strange code and some very strange tests. I don't know what good practices look like here, so when something looks strange to me I can't trust my own judgment, whether it's actually smelly or just a pattern I'm not used to yet.
--
On a side note, I recently had an agent implement a major architectural change. It turned out to have done it completely backwards, in a way that was pointless. (Improved nothing and actively made things worse.) However it had supplied generous tests for the new code, and of course all the tests passed...
So it had "proven the correctness" of something which was completely incorrect.
I later realized that even formal verification would not have prevented this. It would have just written a mathematical proof that the wrong code was correct.
If I had to do a 'code quality' checker I think I'd try to use some combination of syntax tree analysis, data flow analysis, and LOC changed.
Something like that.
Too many new nodes in the syntax tree, or a sub-tree that appears sufficiently similar to another sub-tree (for various definitions of similar), data-flow/side effects gets more convoluted, too many LOC, and so on.
LLMs can clean up after themselves if you steer them. It's not very hard. I often have a two-step dance I do where the LLM first outputs some code and then I prompt it to fix the types up to my standards. I haven't found a way to prompt it with any number of skills or CLAUDE.mds or anything else to get it to do it the way I want on the first pass, but it's not that hard to just fix it afterwards. It's a fast enough process that it feels fine using it. One can even make a case for it being a decent way to operate anyhow; make a sketch, then firm it up isn't entirely unlike my manual coding process was anyhow.
The main problem is that pointing an LLM at a codebase and telling it to just "make it better" taps out pretty quickly. That is, not that there's zero juice to squeeze there, but there's not a ton. You can get a bit of improvement but it also rapidly starts changing things just to change things, which I'm not even going to complain about all that much because there's a sense in which it is simply doing as you asked.
So you still need human taste and direction. This will be especially true for something the size of that codebase where you can only hold small fractions of the actual code in the context window at once. Summaries only get you so far.
I asked an agent for some high level cleanup and refactoring. I found that I ended up disagreeing with most of the structural changes. Some of them were necessary, some were beneficial, but largely it turned straight line code into abstract factory manager type stuff.
More broadly I've found that making code more elegant (e.g. by removing duplication) increases the cognitive load, because now you can't just read the code anymore but need to mentally "decompress" the higher level structures and indirection into the straight line code, the "code that actually runs."
If it wasn't clear, I don't ask the agent to "clean up my code". I ask it to "take this map[string]string you pass around with constant keys and turn that into a structure" or "extract this API provider out into an interface and make everything using it use this interface instead" or other concrete instructions.
LLMs, to a first approximation, already did as well as they could on the first pass. You can get a bit more out of them by asking them to just try harder, but not much. Whereas if you go in with specific changes they are pretty good at implementing them.
This especially matters because my personal style deviates from the common practices. This may also be why I can't get it to just happen by prompting for it. But if you walk it through it's perfectly capable of transforming the code into a better style, and it's still way faster than trying to write it from scratch.
> LLMs can clean up after themselves if you steer them. It's not very hard. I often have a two-step dance I do where the LLM first outputs some code and then I prompt it to fix the types up to my standards.
My experience has been the opposite. I prompt it and it generates something that mostly works, but steering it into something that would actually be maintainable is an exercise in futility. GPT-5.5 uses up my entire allocation of tokens in just reading the context docs and doing a single shot task.
> aven't found a way to prompt it with any number of skills or CLAUDE.mds or anything else to get it to do it the way I want on the first pass, but it's not that hard to just fix it afterwards.
I've yet to find a way to get an LLM to actually follow the instructions in CLAUDE/Agents.md It very quickly gets to a point where it forgets explicit instructions such as "run clang-format on all .h/.cpp files that you touch", and saying "our coding standards can be found at <link to Notion/Confluence>, please ensure all code adheres strictly to this standard" is ignored. I'd also say that the first pass of the code is very often not even close to how it _should_ be implemented so it's not just review and patch up, it's rearchitect + restructure 50% of the code.
> it also rapidly starts changing things just to change things,
Agreed. LLM's are (very good) text generators. They are good for generating code, and left to their own devices they will generate and generate and generate. Getting them to edit, simplify, and foresee future problems is something that people keep saying "use the latest model, it's amazing (despite saying that about the last 3 models" or "you just need to use <harness|framework>" or "your agents.md needs to contain XYZ" will solve.
"My experience has been the opposite. I prompt it and it generates something that mostly works, but steering it into something that would actually be maintainable is an exercise in futility."
I've seen others have this experience, too.
It would be interesting to sit us down next to each other for a day or two and compare how we do things, but I suspect much less than that won't reveal much of interest.
It is weird to me how often I have to remind the models about their skills or CLAUDE.md (or equivalent). Though I've sort of taken it as just another way I can impact the process, because sometimes I'm happy for them to forget a particular skill for a moment... particularly when I want it to just do a thing based on my prompt and it decides to invoke the "OK let's design this super carefully" skill. I've gotten a lot of use out of that one but I'm pretty comfortable having to explicitly invoke it.
> It would be interesting to sit us down next to each other for a day or two and compare how we do things, but I suspect much less than that won't reveal much of interest.
I'm inclined to agree. If I had to write a hypothesis, I would say that is' likely that people like me underestimate the capability of the tools, and people who disagree likely underestimate the amount of manual steering and/or overlook the things that I find offensive!
> I've yet to find a way to get an LLM to actually follow the instructions in CLAUDE/Agents.md
I'll give you a hint: do you rely on people to do the right things, or do you have automated unit, integration, and e2e testing? Do you have linters? Do you have static analysis that automatically runs and will block when violated?
If you are verifying humans, why aren't you verifying LLMs?
Yes, and agents are generating code that fails those checks regularly. I wouldn’t accept a junior engineer saying “oh I just submit my code and see if the tests pass, let me know if they’re failing and I’ll fix them”. Pre commit hooks are disable-able and LLMs have shown they’re more than willing to say “tests were failing before this change” when they weren’t, or to use python scripts to self escape their sandbox restrictions.
You have to treat it like a co-worker send you PRs for review. You review, ask to improve/cleanup stuff and it'll follow up. You can even ask it to remember so it follows the patterns in future. Even better, if you work with it to come up with a design first and then send it coding, you often don't need as much cleanup as the desired architecture is agreed upon early.
I would tell my co worker “this code has so many issues that I’m not actually reviewing it. Please make sure it meets the project standards before sending it back to me”if it happened twice I’d talk to their manager.
See my other comment here [0] - I’ve not found it possible to actually have the agents follow the explicit instructions. Even single shot tasks once the context window fills up (which it does, very very fast, and repeatedly if you use subagents) will ignore very explicit instructions.
- discuss the plan, dos-and-donts, instructions and have them add it to a PLAN_FEATURE.md with the goal, non-goal, non-negotiables, technical details on the top.
- come up with phases to implement your thing. P1, P2, ... P8.. whatever
- in each phase add simple one line TODOs with as much explanantion of the task as needed e.g, - [ ] Update DB schema, - [ ] Generate migrations
- Ask the agent to go one phase or todo at a time depending on complexity.
- if the context fills up, /clear the window and just ask it to do the next line.
- if you wrote up all you care about in the plan properly, it'll follow what you need it to do.
I'm assuming based on the special unicode angled quote marks that this is copy/pasted from an AI? I don't understand why people would type a lot more into an AI just to copy a comment this short, which would be at least 10x faster to just type by hand.
OP here - no AI used in the writing of any of my replies on this site. iOS does this when quoting [0]. I don’t think it’s in the spirit of this site to jump on me rather than the content of my comment either way.
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.
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.
Not entirely my experience. LLMs can be good at two things, but unable to be good at them _at the same time_. I've had some success with getting decent simplification suggestions out of them.
you'd be amazed how many do just that and are incredibly bad at anything else that does not involve opening up an IDE that spoon feeds them everything they need.
> I’ve cut over 11,000 lines of completely dead code from Bun. I can’t think of another project whose codebase was so neglected as to reach 11K lines of dead code. I’ve also rewritten and modernized parts of the codebase, trying to rely more on Zig’s stdlib. In the process, countless bugs have also been fixed.
This is astonishing. Is anyone else surprised at this dead code figure? Is it a feature of large projects I've just never noticed?
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.
LLMs from 1+ years ago approached solving every problem by adding additional code and not cleaning up or adding strange unnecessary backwards compatibility (and often still do this kind of thing - "all tests green")
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.
That makes total sense (though it would be nice if it could do that detected, I suppose), but what makes less sense to me is the accumulation of unnecessary code (and presumably unit tests for that code) that isn't removed as soon as it's no longer needed.
I don't understand - wouldn't this be observable by the person making the change? They used to call this function / use this class and now they don't any more? Even if it's inside a conditional compilation block.
in practice the exponential explosion of options may become intractable. lets say you have 10 compilation flags with 10 options each. not syre you want the compiler scanning through all that on each pass
Yes - I was only talking about when a person removes some code from use, removing the code as well as the call to the code. I wasn't meaning the compiler at all (although it would be nice if the compiler could autodetect it, as you say, that could become tricky).
That requires a person to be making that change. If the change is vibe coded and the person is only checking that the tests pass, it's not hard for cruft to accumulate.
This effort makes me think of the tick-tock oscillation between features and code stewardship I’ve experienced on every agent heavy coding project
Tick: go hard after features, build a correct and extremely messy version
Tock: digest what was done, deslopify, improve project aspects that go beyond feature correctness: performance, maintainability, general fragility / sensitivity to change
My experience is spending a day vibe coding a working application. Then a week unslopifying it to make it a viable software project that can sustainably accept more features without the house of cards collapsing.
You sort of did this pre-AI, but then the professional human coder had a stronger mental model of the system, and IMO was going slower that the switch from tick to tock wasn’t as jarring
No, I did the opposite. First refactor the code base to make a new feature fit naturally in it later on. Then hopefully the new feature is easy to implement cleanly and correctly first time.
The only times I’ve had to go back and do things again “properly” was when the feature itself was not designed properly or didn’t fit at all even after I tried to adapt it to fit which happens rarely, and mostly for experimental things that no one knows exactly how they should work.
I think the only solution is to actually look at the code and ensure that it's not just duplicating logic all over the place and is actually maintainable. Coding models love taking shortcuts to break encapsulation or duplicating things that shouldn't be duplicated.
> To that end, I’ve cut over 11,000 lines of completely dead code from Bun. I can’t think of another project whose codebase was so neglected as to reach 11K lines of dead code.
I don't contribute to open source projects often but deleting dead code has never been a big priority in any project I've worked on unless it's creating real technical debt or it's something easy clean up as part of a bigger migration (similar to what you did here). The point is you had time to look at that stuff and take the risk of deleting it while big projects have a hundred other priorities on Github Issues and customer complaints.
This is what I like to call performative performance programming. I _LOVE_ performance as much as the next guy. And build times should be as close to 0 seconds as possible.
But this is approaching diminishing returns and I guarantee that your CURRENT bottleneck is not build times.
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.
> TLDR; The Zig compiler takes about 1 minute and 30 seconds to compile debug builds of Bun. Zig's language server doesn't do basic things like type-checking, so often have to run the compiler to see if my code works.
90 seconds to less than 1 second. That's astonishing
It’s not so astonishing when you mention that incremental compilation has been only recently added to Zig and is still experimental. This astonishing change, if I understand it correctly, is achieved simply by migrating to the latest version of Zig and enabling this experimental feature.
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.
With Bun, I have a single dependency which gives me: bundling, runtime, package management, test runner, SQLite, Postgres connectivity, S3 utilities, sane APIs (compare Bun.serve to whatever the heck I had to do in Node), routing…
Basically, Bun is giving us something between Rails and the .Net framework for Typescript. It’s become an (almost) standalone runtime for running low-dependency apps.
Throwing out a couple more benefits: bun is faster than node, dramatically so in some specific cases (websockets). Bun also has been doing a great job at building out core libs that probably don't make sense for node, such as the native inbuilt sqlite module, thereby reducing your dependency graph.
People shit on the node/npm ecosystem relentlessly for the typical inauditable deep dependency graph, and bun makes substantial improvements to that situation.
Edit: bun recently added an inbuilt api for manipulating images (resize, change formats, etc). Another good example of them adding native/faster functionality that replaces significant dependencies (in this case, likely sharp: https://www.npmjs.com/package/sharp?activeTab=versions)
I rather replace bun with deno, given that now both bun and deno are written in Rust, and Deno have even more node compatibility than bun. Deno and Node both runs on V8, while Bun runs on JSC, and Deno has a killer feature that you don't have to even run npm install to use package, you can just top-level import or await import an URL (given that you allowed it with a command prompt or bypass it competely with -A but discouraged).
I've used Deno, CucumberJS and Playwright to write E2E test suites. Zero npm install and not even deno.json or package.json
Is this the old monolith vs micro-services argument?
I guess this boils down to 'how granular and function specific are your building blocks?' and where you draw the lines programmatically: library interfaces in a single program/executable, API/ABI between two or more programs/executables, HTTP API/other transport protocol across network boundaries between two or more programs/executables, and so on.
I'm not sure I'm slicing this along the correct abstractions, though.
The unix philosophy pertained to simple composable limited cli tools. Most of which, at least the initial bunch, where written by the same handful of people, too, and one of each only: no several competing programs to awk and grep and cut and so on with widely different philosophies. At worst you had e.g. different implementations (like Sys V vs BSD vs GNU), and even that was already bad enough.
Once you get to programming language tooling, "do one thing and do it well" is not necessarily the best course, especially when you get leaking abstractions and limited interoperability and messy choices to make where no tool is standard.
Why? Is fewer things always better? How far should it be consolidated? Taking it to an extreme, would having a tool named Everything that does anything you could imagine in relation to web dev be better?
Doesn't have to be always, it often is however. Imagine how better this would be with fewer things: https://xkcd.com/1987/
>Taking it to an extreme, would having a tool named Everything that does anything you could imagine in relation to web dev be better?
Taking it to an extreme, why not?
If it was just a tool that did everything for a language (compile, dependencies, formatting, linting, debug, profile), I'd be totally OK. I'd also be ok with a handful of different tools, all by the same team/project, with the same shared vision and interoperability in mind to begin with.
> 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.
Seriously. The only way to use it is to be a very religious person. You have to pray every single time you use it that your system doesn't become compromised.
> I don’t think any human should sacrifice their sanity untangling this mess of 600K lines of slop code. For that reason, I will not be accepting any human-coded contributions until I deem the project to be in a sane enough shape.
Very funny to see a "no humans allowed" contribution policy, and the absurd part is that the rationale actually makes sense.
I'm interested to see where this goes. Is it possible to "deslop" something of this magnitude?
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.
You're way ahead of the folks here and they've made you pay for it.
Yeah, with AI you can just fork code, get a fix/feature added, and then have AI fold back in changes if you even care about them.
Maybe people didn't realize you meant that the collective effort of human maintainers is what's dying? As AI gets better it becomes even more trivial to drive a project. The idea of bike-shedding with other people or campaigning to get in some feature that's critical to you becomes pointless.
Just last month I forked libghostty to have AI implement some features I wanted for my personal terminal project, then last week I started getting AI to build me my own terminal engine in Swift.
It came up with its own smart architecture like splitting the execution plan vs render as pty feeds come in, and many other nice things I wouldn't have had the foresight to consider on day 1 had I started the project myself. Not to mention it would have taken me many months of time I don't have.
Granted, it's a week of daily work to get it to a point where I'd use it, and probably another week of polish to where I'd swap libghostty for it. Especially with my slower AI workflow that guarantees robust, well-designed code. But I've written no code, the writing is on the wall, and this is the worst AI will ever be.
This does anything but put the user in control. I also think that arbitrary new features on established platforms are not in any close future as it already burns many tokens for you to instruct your agent to fork something and add x, y, z.
AI will improve more rapidly than you imagine it will. Open source has been built around rituals that will go the way of the LP: for the nostalgic enthusiast only. This project already shows nobody cares enough now, let alone a year from now.
AI is already better than 90% of my colleagues, and none of them can write an exploit, or instantly draw on the breadth of information it can. So all they do is chaperone. Well, that will be gone too in a few years. What will remain are example repositories that serve as the starting point to add your own special feature. The curated set may well become private again, as a competitive advantage.
I'd also like to see a (kind of) opposite approach: a fork of zig using only AI contributions. This is more as conceptual art or an experiment, rather than because I strongly support AI. But it would be fun to see how the two projects evolved....
How did they end up there? There was another project trying to savage what is left of Zig Bun and turned it into a smaller runtime. I hope may be the project could both work together.
I maybe am reading too much into this, but it's weird to me that a zig lead would be posting about an AI-only project despite zig's stance on AI. Maybe zig's official stance isn't that well supported in their own community.
Very interesting, but without an ecosystem I doubt this person can keep maintaining it long term. Bun users who don't care about slop will continue to use Bun, those who care will go back to Node.js, and there isn't much left for this project. It is a gigantic task to maintain a JS runtime and add features.
Deno doesn't seem to have as much momentum ever since Bun showed up, and there is concern about the status of the company. I doubt anyone wants to rely on Deno at this time.
Node.js has come a long way, and its support for TS is fairly good these days. Of course it's not an "all-in-one" experience, but I really don't know if it matters. Setting up a bundler is easier than ever, and for complex/niche use cases, you'll likely need webpack instead of whatever comes with Bun. Let alone all the other options that take care of the entire build toolchain.
Choosing a runtime just for the tools it brings isn't as good a decision it seems.
saw another project based on pre-rust bun and this is another one
never use bun and sometimes this make me wonder, are we enter a phase the supply way > requirement or people just build stuffs and not care serious usage anymore?
As a software engineer these days, I can't say i do not use Agent to help work done, but i am really a bit of tired to see so much solutions while not talk about what problem they are trying to really solve
This is a personal pursuit from what I can tell. I wouldn't use any opinion or judgment from this person to reach any conclusion about "the Zig community". This is just unnecessary.
If this person can stick to these goals and keep maintaining the project (which I do highly doubt), I don't see how this can possibly be a bad thing.
To me the most interesting fact about this fork is that it has proven that Bun could have had fast builds all along.
To be fair, there are caveats still in place today: Zig incremental compilation does not yet support aarch64 and only the linux linker supports binary patching, but it's just a matter of time before all major platforms are conquered.
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 port was a political decision. It's now the runtime for claude code first and it must align itself in that ecosystem by becoming fully vibe code.
I'm pretty sure they forked Zig long before it supported incremental compilation. In fact, it's still experimental and not enabled by default.
A significant part of the port was also for the built-in safety. Unsafe code just... fails to compile.
Turns out there's a journey here.
GP is talking about the fork of the Zig compiler, not the rewrite of Bun into Rust.
Anthropic submitted to patch the Zig compiler to improve Bun compilation times, it was rejected. One reason it was rejected is that it contained AI-generated code, which is against the community guidelines, but more importantly, it would have been rejected regardless of AI use. They claimed a 4x improvement, something like going from 2 minutes to 30 seconds, but, according to the Zig team, it made compilation non-deterministic, and missed on the real improvement they worked on, which was sub-1s incremental builds.
"Buz" shows that the fork submitted by Anthropic wasn't needed as Bun can now compile under 1s (incrementally), which is much better than the 30s they achieved with their patch.
It is likely that this rejection, especially the "no AI" aspect of it encouraged Anthropic to move away from Zig.
Is there anything suggesting that Bun even attempted to submit their Zig patches? As far as I know, they were stuck 2 versions behind. With the amount of changes and Zig already working on incremental I'm not sure what the point would have been.
Yes it was never attempted, the whole communication on social media about the AI policy was completely detached from the reality of the engineering work being done on either side.
Yep, on rereading my comment I totally failed to make this clear. Cheers.
The port was line for line and full of unsafe code. It didn't prevent any bugs. They're not using Rust for its strengths.
You should give the article[0] a read.
"A large percentage of bugs from that list are use-after-free, double-free, and "forgot to free" in an error path. In safe Rust, these are compiler errors and RAII-like automatic cleanup with Drop. Compiler errors are a better feedback loop than a style guide."
"At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library. I expect this number to go down over time as we refactor from a faithful Zig port (which had no greppable unsafe keyword) to idiomatic Rust, but we are going to continue using C & C++ libraries like JavaScriptCore so it will always have more unsafe than pure Rust projects."
[0] https://bun.com/blog/bun-in-rust
That one’s interesting to me because it speaks to both sides of the debate. Yes, safe Rust is good for catching those kinds of errors at compile time. But also, it should theoretically be very easy for a compiler to avoid those problems in Zig, too, if you are using the language the way it wants to be used.
Which, from what I’ve experienced so far, does seem to take a whole lot more effort if you’re using a coding agent. I spend an incredible amount of time making sure mine doesn’t bloat our codebase with Java-flavored Python, and all the noise and defects and performance problems that it brings.
> But also, it should theoretically be very easy for a compiler to avoid those problems in Zig, too, if you are using the language the way it wants to be used.
agreed. in my side project im tinkering with a memory safety checker in zig that intercepts a compiler artifact, and it works better with idiomatic zig, problematic code is when you try to write c-isms in zig -- so i basicallt tell the checker to reject c-isms that create ambiguity for safety checking.
> using the language the way it wants to be used.
This sounds like just the coding conventions dependency they're trying to avoid.
IMO it's the same problem with Rust. LLMs are trained on vast quantities of code that violate Rust soundness in safe code.
LLMs are prediction engines: you can move the needle (heavily) on the predictions from lazy to correct by construction, but the defaults even on high end models like Opus are always riddled with shortcuts.
LLMs can produce coherent & safe Rust 1.92, LLMs can produce coherent Zig 0.16, but that's dependent on in context learning & instruction following.
> that's dependent on in context learning & instruction following
Not just that. For Rust in particular, since unsafe code is uncompilable code (unless explicitly marked "unsafe"), the LLM is essentially forced to continue iterating even if the code already works but is unsafe, until it finds an implementation that's both correct (per the spec) and safe (per the compiler). That's the difference from Zig, where "make the code safe" is essentially part of the spec, and so may be missed by the LLM and not be discovered by a human until there's an observable runtime issue, or CVE.
> LLMs are trained on vast quantities of code that violate Rust soundness in safe code.
Why is your reasoning behind this? Most Rust code in the wild does not use unsafe. Most projects don't have a single line of unsafe.
Yup. But that also gets to the “they’re both right” angle. Zig’s convention may not be how the Bun developers wanted to work, but it’s a good choice for the kinds of projects Zig is designed for. Which overlaps a bit with, but isn't the same as, Rust’s intended use cases. For example, I might rather go with the Zig philosophy if I’ve got hard memory constraints and want to avoid dynamic memory allocation.
Which, ironically, is something I’d love for my browser’s JavaScript runtime to do. But I can also respect others not wanting that.
I'm optimistic for that refactoring. But if one in 30 lines sprinkled all over everywhere is unsafe then you haven't actually done much to improve safety. When you have a large percent of fully safe functions and modules, that's when you're making a difference. Counting the lines is not a very helpful metric.
> one in 30 lines
> Counting the lines is not a very helpful metric.
Seems self-contradictory.
And they did say they're working to reduce the unsafe code over time. That huge percentage of memory bugs that they were able to better triage and fix due to the port was also them improving safety.
The other part of that line is important. Measuring lines is better than nothing but the distribution is much more important. If they're scattered all over that's a bigger downside than the line reduction is an upside.
If you want good metrics, measure functions and data structures without unsafe. Not lines.
> If you want good metrics, measure functions and data structures without unsafe.
I doubt it, as it's possible a substantial amount of those unsafe areas can't even be removed, given the project's dependent on C/C++ libraries. Without proper calibration those metrics won't tell the full story, and with calibration the incentive for the story will decrease over time with the unsafe refactoring. I doubt the distribution of the unsafe code really matters that much; what matters is proper handling, wherever it is, so stability and security isn't compromised.
The way I'm thinking of it is that they ported Bun from Zig to Unsafe Rust, and are still working on now porting it from Unsafe Rust to Rust (not 100% safe, but a reasonable amount).
The original Zig code is metaphorically one big unsafe block. Even if the Rust port is made up of 3% unsafe blocks, that still means 97% of the original Zig code has been made safe (in the Rust sense).
The safety of safe rust is created by extremely strong and subtle invariants that unsafe rust must maintain perfectly (or all bets are off). The idea that a program with tens of thousands of lines of vibe coded unsafe Rust is memory safe is mind boggling.
IME agents are extremely happy to write more or less convincing // SAFETY: comments (most Rust code in the training set has these just before unsafe { - also it often works in unit tests). However, miri remains broadly unimpressed by comments.
Of note, even that 97% of original code that is now "safe in the rust sense" could violate invariants through safe blocks that cause memory-safety issues. I can't say exactly how the LLM-ported Rust code made use of unsafe but see https://www.ralfj.de/blog/2016/01/09/the-scope-of-unsafe.htm...
Not every line of zig is "unsafe".
No, but when the compiler isn't enforcing anything, how do you know which ones are safe and which ones are not? If we ignore declarations etc. and only consider statement lines that read or write memory, then any such line of Zig (or C, or C++, or any other unsafe language) can be classified as a potentially unsafe — not just today, but in the future, since safety bugs can be generated upstream by giving out pointers that aren't valid or concurrency-safe.
> If we ignore declarations etc. and only consider statement lines that read or write memory, then any such line of Zig (or C, or C++, or any other unsafe language)
Surely it's obvious that's trivially untrue?
Also, literally no code is safe from potential future upstream changes.
Anyway, I'm not arguing zig has the same safety guarantees as rust. That would be silly. But the weird binary thinking around memory safety is equally silly. People want things to be simple, but you really can't come to good conclusions by trying to pretend things are simpler than they are and through a lack of analysis and thinking.
Since they did a one-to-one translation to start with, hypothetically, if these were the true numbers, you could probably get a static analysis tool to guarantee you that 97% of the zig code was safe and tell you which of the 3% were unsafe. Zig has a lot more syntax and conventions to encourage safe code compare to C after all. It just doesn’t have way to mark which parts are safe or unsafe.
An LLM could probably also trivially give you accurate reviews saying which parts were unsafe and in need of tests or reviews. I mean, considering their LLM budgets they could probably have had nightly reviews running every night for years before spending more than their Rust rewrite.
Not that I think Rust rewrite was a bad idea. Rust is a good fit for this kind of project. I say that as a Zig enthusiast. It’s just that their stated motivation and reported results are kinda BS. If they just wrote “we just like Rust and thought it’d be cool to see of LLM could do the whole rewrite”, and left it at that, I think it’d be a more honest description of the motivation. The rest is just rationalisation.
No you cannot get a static analysis tool to guarantee 97% of zig code was safe. Well, you can - the tool is called the borrow checker.
Do you know what's infinitely cheaper and faster than an LLM running nightly reviews of all of the code and infact mathematically provable that the code (and any new code) is memory safe? It's called the borrow checker.
it seems like a reasonable enterprise to intercept the data dependency graph from the zig compiler and subject it to analysis to prove memory safety parameters:
(my wip experiment: ) https://github.com/ityonemo/clr
They have made it very clear that the mechanical translation is the starting point, and are refactoring to remove as many unsafe declarations as possible.
They turned every hidden memory safety bug into a grep'able memory safety bug. That's step 1 and a massive win.
That may have been the case for the initial iteration a few months ago, but is it still true?
This is an example of technical problems being easy but organization being hard imo. It is stupid if you think about it from a theoretical perspective but they didn’t want to use this feature for some reason.
Probably because they did their fork of zig for fast compilation before and they didn’t want to just discard it and use this
Do the caveats mean that it could _not_ actually have had fast builds on all the platforms it supports? (Honestly asking if I connected the dots correctly here, this is not a snarky "actually" rethorical question...)
> To this end, LLMs will be used extensively to deslop...
So we're using LLMs to clean up the code that LLMs ruined in the first place? We’ve reached peak tech in 2026.
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
The pearl clutching about AI is insane to me, as if code quality was perfect before 2022. We have been seeing a decline in software quality for a long time coming now. A lot of AI hatred is not even based on seeing something genuinely bad, its just prejudice for the sake of prejudice. If I could view into two parallel worlds, one where I vibe code something, release it and tell people it's vibe coded, and another where I do the same but tell no one, codebases are both the same and I still reviewed the code, had the model fix issues with code quality and bugs, and genuinely invested hours of my time to raise up, in the universe where I don't mention AI, people will likely sing praises, in the universe where I do mention AI, people will not even review or view a single line of code, they will close the tab, hop back on HN and complain that it's AI slop, without any reasonable reason.
Blind AI hatred is just insane to me and it goes against the spirit of HN, we're not supposed to just go "ITS BAD CODE" here, we are supposed to have actual engaging conversations. Too much of HN devolves into "ITS SLOP" instead of "Hey, I know you're leaning on the AI a bit, but here's what's wrong with the code: ...." which would be more constructive and fall better in line with what I've expected from HN and seen for years, until recently.
AI fatigue and AI prejudice should not be confused for one another, sure you can have both, but most people who hate AI blindly just have AI prejudice at this point.
> "Hey, I know you're leaning on the AI a bit, but here's what's wrong with the code: ...."
I'm generally in agreement, but I think current corporate/productivity culture and AI is a bad mix that makes this quote/sentiment feel impossible. All of the current incentives are set up to push out as much sloppy code as possible, and AI is the perfect machine for doing that in huge quantities, to the point where reviewing all of it is impossible. It's not really AI's fault (imo). There's plenty of ways to use it to design more elegant, understandable, maintainable systems. But unfortunately that's going to take a cultural shift, and part of that cultural shift involves people pushing back against AI as it's used today.
I do agree, if someone's just going to shove what you say to an AI at what point do you ask "do we need to replace you with a shell script?" before they stop being overtly reliant on AI, that's a bridge too far for me, and I am all for letting Claude hack away at code for a while, and then review the code and refine it, a lot of the time even if its not perfect, it gets me like 80 to 90% of the way there, especially if I tell it HOW I want it written, and to consider edge cases.
LLMs are as good as the operator directing them.
The error bars on that one are too large to fit on screen, but yes.
You should see the error bars between human programmers.
Only if you have a tiny screen.
You can make them output what you would've written yourself, but that would be slower than writing it yourself, so no one does that - but it’s trivially true.
Well, we've been saying this about infinite monkeys too.
> infinite monkeys
Welcome to the dev community!
I'd say as thorough rather than good.
Skilled engineers may still vibe and not care. Beginners may be thorough and experiment and ask till they get the design right even if they don't spot it immediately, just caring does a lot.
Incidentally I’ve always thought that about working on cars, but more like skilled mechanics may still vibe and not care. Amateurs may be thorough but much slower, may need to do a lot of research before every step. Just caring does a lot.
I agree with you about “thoroughness” being key here, but I’d additionally advocate that we need to leave room for people to make some slop learn it.
Part of the learning process, whether you’re a “skilled” or “unskilled” engineer (or not an engineer at all, and noting that going from one to the other is just a matter of learning), is being able to “vibe and not care.” Yes, it’s also helpful to identify things that might not work out theoretically in advance, using the things we learn in our CS programs. But coding with LLMs is a brand new modality, and we are all indeed just learning to work with them.
I think alternating vibe coding with vibe-assisted DRYing/cleaning is ultimately a workflow enhancer that can make better software faster. But engineers have to be allowed to make some slop to learn it.
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'm about to release some tooling that's been very effective for me.
Essentially, there's a few ways LLMs write "bad" code that is different from how people write "bad" code.
We've got pretty good tooling to catch the ways people write bad code - it just happens to be much easier to do with static analysis (and is less noise prone).
The ways LLMs write bad code is typically 1) bad architecture - hard to detect in the ways that are really important, 2) unnecessary state and control flow (and decisions based on state), 3) bad / inadequate tests.
Methods to detect these problems have existed for ages, but they've never caught on because it's typically too difficult to tune them to have high signal / noise for humans, and AFAIK - no one else tried putting them all together and seeing how LLMs work with it.
LLMs are great at sorting through signal / noise -> so you can help surface potential issues with metrics that would be too noisy for humans, but seems to work pretty well for LLMs to find the source of architectural problems and design better solutions (from my experience - may be biased, I built the tooling to literally solve this problem for the main project I'm working on).
Can you elaborate on the tests thing? I'm new to testing, and AI agents recently voluntarily added an large number of tests to one of my projects. I've been learning a lot by reading them, and it seems like a great habit to develop.
But they're also writing some very strange code and some very strange tests. I don't know what good practices look like here, so when something looks strange to me I can't trust my own judgment, whether it's actually smelly or just a pattern I'm not used to yet.
--
On a side note, I recently had an agent implement a major architectural change. It turned out to have done it completely backwards, in a way that was pointless. (Improved nothing and actively made things worse.) However it had supplied generous tests for the new code, and of course all the tests passed...
So it had "proven the correctness" of something which was completely incorrect.
I later realized that even formal verification would not have prevented this. It would have just written a mathematical proof that the wrong code was correct.
i find that the easiest way to make sure you have robust tests is to do strict red/green cycles for each feature and bugfix in your codebase.
You forgot to include link to your tool.
If I had to do a 'code quality' checker I think I'd try to use some combination of syntax tree analysis, data flow analysis, and LOC changed.
Something like that.
Too many new nodes in the syntax tree, or a sub-tree that appears sufficiently similar to another sub-tree (for various definitions of similar), data-flow/side effects gets more convoluted, too many LOC, and so on.
An LLM could probably figure out how to use it now.
But it doesn't yet have a coherent UX unless you're me.
Hopefully, I'll iron that out over the next week and I'll update you.
I’ll keep checking.
https://ponytail.dev/
LLMs can clean up after themselves if you steer them. It's not very hard. I often have a two-step dance I do where the LLM first outputs some code and then I prompt it to fix the types up to my standards. I haven't found a way to prompt it with any number of skills or CLAUDE.mds or anything else to get it to do it the way I want on the first pass, but it's not that hard to just fix it afterwards. It's a fast enough process that it feels fine using it. One can even make a case for it being a decent way to operate anyhow; make a sketch, then firm it up isn't entirely unlike my manual coding process was anyhow.
The main problem is that pointing an LLM at a codebase and telling it to just "make it better" taps out pretty quickly. That is, not that there's zero juice to squeeze there, but there's not a ton. You can get a bit of improvement but it also rapidly starts changing things just to change things, which I'm not even going to complain about all that much because there's a sense in which it is simply doing as you asked.
So you still need human taste and direction. This will be especially true for something the size of that codebase where you can only hold small fractions of the actual code in the context window at once. Summaries only get you so far.
I asked an agent for some high level cleanup and refactoring. I found that I ended up disagreeing with most of the structural changes. Some of them were necessary, some were beneficial, but largely it turned straight line code into abstract factory manager type stuff.
More broadly I've found that making code more elegant (e.g. by removing duplication) increases the cognitive load, because now you can't just read the code anymore but need to mentally "decompress" the higher level structures and indirection into the straight line code, the "code that actually runs."
If it wasn't clear, I don't ask the agent to "clean up my code". I ask it to "take this map[string]string you pass around with constant keys and turn that into a structure" or "extract this API provider out into an interface and make everything using it use this interface instead" or other concrete instructions.
LLMs, to a first approximation, already did as well as they could on the first pass. You can get a bit more out of them by asking them to just try harder, but not much. Whereas if you go in with specific changes they are pretty good at implementing them.
This especially matters because my personal style deviates from the common practices. This may also be why I can't get it to just happen by prompting for it. But if you walk it through it's perfectly capable of transforming the code into a better style, and it's still way faster than trying to write it from scratch.
> my personal style deviates from the common practices.
The closest I could get to mine was by telling it to write like a Unix hacker. Hahaha
> LLMs can clean up after themselves if you steer them. It's not very hard. I often have a two-step dance I do where the LLM first outputs some code and then I prompt it to fix the types up to my standards.
My experience has been the opposite. I prompt it and it generates something that mostly works, but steering it into something that would actually be maintainable is an exercise in futility. GPT-5.5 uses up my entire allocation of tokens in just reading the context docs and doing a single shot task.
> aven't found a way to prompt it with any number of skills or CLAUDE.mds or anything else to get it to do it the way I want on the first pass, but it's not that hard to just fix it afterwards.
I've yet to find a way to get an LLM to actually follow the instructions in CLAUDE/Agents.md It very quickly gets to a point where it forgets explicit instructions such as "run clang-format on all .h/.cpp files that you touch", and saying "our coding standards can be found at <link to Notion/Confluence>, please ensure all code adheres strictly to this standard" is ignored. I'd also say that the first pass of the code is very often not even close to how it _should_ be implemented so it's not just review and patch up, it's rearchitect + restructure 50% of the code.
> it also rapidly starts changing things just to change things,
Agreed. LLM's are (very good) text generators. They are good for generating code, and left to their own devices they will generate and generate and generate. Getting them to edit, simplify, and foresee future problems is something that people keep saying "use the latest model, it's amazing (despite saying that about the last 3 models" or "you just need to use <harness|framework>" or "your agents.md needs to contain XYZ" will solve.
"My experience has been the opposite. I prompt it and it generates something that mostly works, but steering it into something that would actually be maintainable is an exercise in futility."
I've seen others have this experience, too.
It would be interesting to sit us down next to each other for a day or two and compare how we do things, but I suspect much less than that won't reveal much of interest.
It is weird to me how often I have to remind the models about their skills or CLAUDE.md (or equivalent). Though I've sort of taken it as just another way I can impact the process, because sometimes I'm happy for them to forget a particular skill for a moment... particularly when I want it to just do a thing based on my prompt and it decides to invoke the "OK let's design this super carefully" skill. I've gotten a lot of use out of that one but I'm pretty comfortable having to explicitly invoke it.
> It would be interesting to sit us down next to each other for a day or two and compare how we do things, but I suspect much less than that won't reveal much of interest.
I'm inclined to agree. If I had to write a hypothesis, I would say that is' likely that people like me underestimate the capability of the tools, and people who disagree likely underestimate the amount of manual steering and/or overlook the things that I find offensive!
> I've yet to find a way to get an LLM to actually follow the instructions in CLAUDE/Agents.md
I'll give you a hint: do you rely on people to do the right things, or do you have automated unit, integration, and e2e testing? Do you have linters? Do you have static analysis that automatically runs and will block when violated?
If you are verifying humans, why aren't you verifying LLMs?
Yes, and agents are generating code that fails those checks regularly. I wouldn’t accept a junior engineer saying “oh I just submit my code and see if the tests pass, let me know if they’re failing and I’ll fix them”. Pre commit hooks are disable-able and LLMs have shown they’re more than willing to say “tests were failing before this change” when they weren’t, or to use python scripts to self escape their sandbox restrictions.
They can. You just have to steer them
Can you share a transcript of an LLM generated feature/bug fix that you steered into being good quality?
You have to treat it like a co-worker send you PRs for review. You review, ask to improve/cleanup stuff and it'll follow up. You can even ask it to remember so it follows the patterns in future. Even better, if you work with it to come up with a design first and then send it coding, you often don't need as much cleanup as the desired architecture is agreed upon early.
I would tell my co worker “this code has so many issues that I’m not actually reviewing it. Please make sure it meets the project standards before sending it back to me”if it happened twice I’d talk to their manager.
Sure - define your project standards in the repo or agent's skill and tell it just that.
See my other comment here [0] - I’ve not found it possible to actually have the agents follow the explicit instructions. Even single shot tasks once the context window fills up (which it does, very very fast, and repeatedly if you use subagents) will ignore very explicit instructions.
[0] https://news.ycombinator.com/item?id=49036222
- discuss the plan, dos-and-donts, instructions and have them add it to a PLAN_FEATURE.md with the goal, non-goal, non-negotiables, technical details on the top. - come up with phases to implement your thing. P1, P2, ... P8.. whatever - in each phase add simple one line TODOs with as much explanantion of the task as needed e.g, - [ ] Update DB schema, - [ ] Generate migrations - Ask the agent to go one phase or todo at a time depending on complexity. - if the context fills up, /clear the window and just ask it to do the next line. - if you wrote up all you care about in the plan properly, it'll follow what you need it to do.
I'm assuming based on the special unicode angled quote marks that this is copy/pasted from an AI? I don't understand why people would type a lot more into an AI just to copy a comment this short, which would be at least 10x faster to just type by hand.
OP here - no AI used in the writing of any of my replies on this site. iOS does this when quoting [0]. I don’t think it’s in the spirit of this site to jump on me rather than the content of my comment either way.
[0] https://apple.stackexchange.com/questions/299505/ios-11-defa...
Not sure about op but if I post here from my phone I get those. Example: “quoted string”
huh interesting, I've never realized this, is it iOS or android?
It’s a macOS thing too. I turn it off because it burns me when copying code
iOS
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...)
[dead]
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.
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.
Yeah, good luck with that one though. LLMs are terrible at deslop, or they wouldn't slop in the first place.
Not entirely my experience. LLMs can be good at two things, but unable to be good at them _at the same time_. I've had some success with getting decent simplification suggestions out of them.
Still ironic, of course.
This is the present and future, willingly or not.
Engineering is about design and plan and architectural integrity and qa. Not writing code anymore.
> Not writing code anymore.
If you were an L6+, it was already not really about that.
It's kind of amazing to me that people think the only thing engineers do and the only value they bring is writing code.
I have no idea what an l6 is, is this a big corp rat race thing?
https://www.levels.fyi/jobs?searchText=L6
So a rate race thing. As I thought.
you'd be amazed how many do just that and are incredibly bad at anything else that does not involve opening up an IDE that spoon feeds them everything they need.
> I’ve cut over 11,000 lines of completely dead code from Bun. I can’t think of another project whose codebase was so neglected as to reach 11K lines of dead code. I’ve also rewritten and modernized parts of the codebase, trying to rely more on Zig’s stdlib. In the process, countless bugs have also been fixed.
This is astonishing. Is anyone else surprised at this dead code figure? Is it a feature of large projects I've just never noticed?
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.
LLMs from 1+ years ago approached solving every problem by adding additional code and not cleaning up or adding strange unnecessary backwards compatibility (and often still do this kind of thing - "all tests green")
It was trivially dead
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)
That makes total sense (though it would be nice if it could do that detected, I suppose), but what makes less sense to me is the accumulation of unnecessary code (and presumably unit tests for that code) that isn't removed as soon as it's no longer needed.
hard to detect. what if a whole code branch is used by macos and you're on x86?
I don't understand - wouldn't this be observable by the person making the change? They used to call this function / use this class and now they don't any more? Even if it's inside a conditional compilation block.
The hard to detect is the compilers technical reason for not doing the analysis. Maybe it will one day.
In practice, it's annoying to track if those small util functions become dead code.
i did not say "Impossible to detect"!
in practice the exponential explosion of options may become intractable. lets say you have 10 compilation flags with 10 options each. not syre you want the compiler scanning through all that on each pass
Yes - I was only talking about when a person removes some code from use, removing the code as well as the call to the code. I wasn't meaning the compiler at all (although it would be nice if the compiler could autodetect it, as you say, that could become tricky).
That requires a person to be making that change. If the change is vibe coded and the person is only checking that the tests pass, it's not hard for cruft to accumulate.
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.
Same reaction here. 11,000 lines is nothing for a project this large.
It's bog standard, very mild technical debt.
It's less than I'd expect, given how Bun was developed. I'm sure there's plenty more of that to be had in that codebase.
This effort makes me think of the tick-tock oscillation between features and code stewardship I’ve experienced on every agent heavy coding project
Tick: go hard after features, build a correct and extremely messy version
Tock: digest what was done, deslopify, improve project aspects that go beyond feature correctness: performance, maintainability, general fragility / sensitivity to change
My experience is spending a day vibe coding a working application. Then a week unslopifying it to make it a viable software project that can sustainably accept more features without the house of cards collapsing.
You sort of did this pre-AI, but then the professional human coder had a stronger mental model of the system, and IMO was going slower that the switch from tick to tock wasn’t as jarring
> You sort of did this pre-AI
No, I did the opposite. First refactor the code base to make a new feature fit naturally in it later on. Then hopefully the new feature is easy to implement cleanly and correctly first time. The only times I’ve had to go back and do things again “properly” was when the feature itself was not designed properly or didn’t fit at all even after I tried to adapt it to fit which happens rarely, and mostly for experimental things that no one knows exactly how they should work.
I think the only solution is to actually look at the code and ensure that it's not just duplicating logic all over the place and is actually maintainable. Coding models love taking shortcuts to break encapsulation or duplicating things that shouldn't be duplicated.
> To that end, I’ve cut over 11,000 lines of completely dead code from Bun. I can’t think of another project whose codebase was so neglected as to reach 11K lines of dead code.
How long has this person been programming?
Over a decade. I should've clarified, I meant "trivially dead" code that's not called by anything. Can you think of another project with that much?
I don't contribute to open source projects often but deleting dead code has never been a big priority in any project I've worked on unless it's creating real technical debt or it's something easy clean up as part of a bigger migration (similar to what you did here). The point is you had time to look at that stuff and take the risk of deleting it while big projects have a hundred other priorities on Github Issues and customer complaints.
Bun, but managed by someone who values code quality? Sign me up. It’s a Herculean task, though.
> It’s a Herculean task, though.
I believe it’s spelled Sisyphean.
the fifth labour of Hercules was cleaning the Augean stables, which this undertaking seems very much alike
But Hercules eventually finished, I think what koolba is saying is this task can't be finished.
Is one ever truly finished rebuilding an entire code-base one piece at a time?
Thank you! Yes it will be a lot of work. But it will only get easier.
This is what I like to call performative performance programming. I _LOVE_ performance as much as the next guy. And build times should be as close to 0 seconds as possible.
But this is approaching diminishing returns and I guarantee that your CURRENT bottleneck is not build times.
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.
> TLDR; The Zig compiler takes about 1 minute and 30 seconds to compile debug builds of Bun. Zig's language server doesn't do basic things like type-checking, so often have to run the compiler to see if my code works.
90 seconds to less than 1 second. That's astonishing
It’s not so astonishing when you mention that incremental compilation has been only recently added to Zig and is still experimental. This astonishing change, if I understand it correctly, is achieved simply by migrating to the latest version of Zig and enabling this experimental feature.
I expect it to drop to 300ms once it no longer relies on Mold for linking. Zig's experimental linker can just modify the binary in place.
No. Fast builds are a must for a project like this, in my opinion. This is an important step towards making the project easier to maintain.
Why is there so much buzz around bun? Can't we just go back to node + npm + vitest + vite?
Breaking: JavaScript developers create three new frameworks/kits while you were reading this sentence.
Sir, 2010 was 16 years ago.
And you're already not getting hired because they're not on your CV.
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
What are the benefits, though?
With Bun, I have a single dependency which gives me: bundling, runtime, package management, test runner, SQLite, Postgres connectivity, S3 utilities, sane APIs (compare Bun.serve to whatever the heck I had to do in Node), routing…
Basically, Bun is giving us something between Rails and the .Net framework for Typescript. It’s become an (almost) standalone runtime for running low-dependency apps.
This:
Turns into: That's the benefitThrowing out a couple more benefits: bun is faster than node, dramatically so in some specific cases (websockets). Bun also has been doing a great job at building out core libs that probably don't make sense for node, such as the native inbuilt sqlite module, thereby reducing your dependency graph.
People shit on the node/npm ecosystem relentlessly for the typical inauditable deep dependency graph, and bun makes substantial improvements to that situation.
Edit: bun recently added an inbuilt api for manipulating images (resize, change formats, etc). Another good example of them adding native/faster functionality that replaces significant dependencies (in this case, likely sharp: https://www.npmjs.com/package/sharp?activeTab=versions)
I rather replace bun with deno, given that now both bun and deno are written in Rust, and Deno have even more node compatibility than bun. Deno and Node both runs on V8, while Bun runs on JSC, and Deno has a killer feature that you don't have to even run npm install to use package, you can just top-level import or await import an URL (given that you allowed it with a command prompt or bypass it competely with -A but discouraged).
I've used Deno, CucumberJS and Playwright to write E2E test suites. Zero npm install and not even deno.json or package.json
To say nothing of `bun install` being about 50 times faster than npm, and disabling most post-install hooks by default.
>Can't we just go back to node + npm + vitest + vite?
The mere enumeration shows how bad it is.
I think it's a pretty reasonable split of responsibilities, and not uncommon.
Eg: JDK + maven + junit + tomcat
Making these components pluggable is arguably how we get innovation (eg: yarn/pnpm, jest/vitest, etc)
Is this the old monolith vs micro-services argument?
I guess this boils down to 'how granular and function specific are your building blocks?' and where you draw the lines programmatically: library interfaces in a single program/executable, API/ABI between two or more programs/executables, HTTP API/other transport protocol across network boundaries between two or more programs/executables, and so on.
I'm not sure I'm slicing this along the correct abstractions, though.
Well, do one thing an one thing good as in Unix philosophy?
- Runtime
- Package manager
- Test runner
- Build tool
The unix philosophy pertained to simple composable limited cli tools. Most of which, at least the initial bunch, where written by the same handful of people, too, and one of each only: no several competing programs to awk and grep and cut and so on with widely different philosophies. At worst you had e.g. different implementations (like Sys V vs BSD vs GNU), and even that was already bad enough.
Once you get to programming language tooling, "do one thing and do it well" is not necessarily the best course, especially when you get leaking abstractions and limited interoperability and messy choices to make where no tool is standard.
At the worst case you get this: https://xkcd.com/1987/
Why? Is fewer things always better? How far should it be consolidated? Taking it to an extreme, would having a tool named Everything that does anything you could imagine in relation to web dev be better?
>Why? Is fewer things always better?
Doesn't have to be always, it often is however. Imagine how better this would be with fewer things: https://xkcd.com/1987/
>Taking it to an extreme, would having a tool named Everything that does anything you could imagine in relation to web dev be better?
Taking it to an extreme, why not?
If it was just a tool that did everything for a language (compile, dependencies, formatting, linting, debug, profile), I'd be totally OK. I'd also be ok with a handful of different tools, all by the same team/project, with the same shared vision and interoperability in mind to begin with.
Go got quite close with that.
> 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.
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.
At this point, I'm not sure anyone should still be using npm.
Seriously. The only way to use it is to be a very religious person. You have to pray every single time you use it that your system doesn't become compromised.
But isn't this a problem with the ecosystem and not with the program? I mean, with yarn / etc., you have the same problems, don't you?
pnpm is generally safer and had the age delay much sooner than npm as well.
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.
node is used in prod and bun is faster than node. so using bun directly translates to lower cogs
> I don’t think any human should sacrifice their sanity untangling this mess of 600K lines of slop code. For that reason, I will not be accepting any human-coded contributions until I deem the project to be in a sane enough shape.
Very funny to see a "no humans allowed" contribution policy, and the absurd part is that the rationale actually makes sense.
I'm interested to see where this goes. Is it possible to "deslop" something of this magnitude?
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.
You're way ahead of the folks here and they've made you pay for it.
Yeah, with AI you can just fork code, get a fix/feature added, and then have AI fold back in changes if you even care about them.
Maybe people didn't realize you meant that the collective effort of human maintainers is what's dying? As AI gets better it becomes even more trivial to drive a project. The idea of bike-shedding with other people or campaigning to get in some feature that's critical to you becomes pointless.
Just last month I forked libghostty to have AI implement some features I wanted for my personal terminal project, then last week I started getting AI to build me my own terminal engine in Swift.
It came up with its own smart architecture like splitting the execution plan vs render as pty feeds come in, and many other nice things I wouldn't have had the foresight to consider on day 1 had I started the project myself. Not to mention it would have taken me many months of time I don't have.
Granted, it's a week of daily work to get it to a point where I'd use it, and probably another week of polish to where I'd swap libghostty for it. Especially with my slower AI workflow that guarantees robust, well-designed code. But I've written no code, the writing is on the wall, and this is the worst AI will ever be.
This does anything but put the user in control. I also think that arbitrary new features on established platforms are not in any close future as it already burns many tokens for you to instruct your agent to fork something and add x, y, z.
AI will improve more rapidly than you imagine it will. Open source has been built around rituals that will go the way of the LP: for the nostalgic enthusiast only. This project already shows nobody cares enough now, let alone a year from now.
AI is already better than 90% of my colleagues, and none of them can write an exploit, or instantly draw on the breadth of information it can. So all they do is chaperone. Well, that will be gone too in a few years. What will remain are example repositories that serve as the starting point to add your own special feature. The curated set may well become private again, as a competitive advantage.
>AI will become the repository owner
So Open Source transitions to Public Domain.
Also highly relevant project: Cruller, also uses the pre-rewrite Bun codebase but focuses only on the runtime part for production.
Link: https://ziggit.dev/t/cruller-buns-zig-runtime-continued-on-z...
Discussed on HN: https://news.ycombinator.com/item?id=49017344
Thank god this is written in modern Zig and not Zig88.
Should have called it Bunz!
I'd also like to see a (kind of) opposite approach: a fork of zig using only AI contributions. This is more as conceptual art or an experiment, rather than because I strongly support AI. But it would be fun to see how the two projects evolved....
[dead]
Performative programming
>11K deadcode.
How did they end up there? There was another project trying to savage what is left of Zig Bun and turned it into a smaller runtime. I hope may be the project could both work together.
Here’s my idea.
DinnerRoll
Bun in D!
If someone with an MBA wants to raise capital we can start next Tuesday!
I maybe am reading too much into this, but it's weird to me that a zig lead would be posting about an AI-only project despite zig's stance on AI. Maybe zig's official stance isn't that well supported in their own community.
> modern Zig
Do they mean more modern than the latest tagged release, 0.16.0, released April 14, 2026?
Very interesting, but without an ecosystem I doubt this person can keep maintaining it long term. Bun users who don't care about slop will continue to use Bun, those who care will go back to Node.js, and there isn't much left for this project. It is a gigantic task to maintain a JS runtime and add features.
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.
Deno doesn't seem to have as much momentum ever since Bun showed up, and there is concern about the status of the company. I doubt anyone wants to rely on Deno at this time.
Node.js has come a long way, and its support for TS is fairly good these days. Of course it's not an "all-in-one" experience, but I really don't know if it matters. Setting up a bundler is easier than ever, and for complex/niche use cases, you'll likely need webpack instead of whatever comes with Bun. Let alone all the other options that take care of the entire build toolchain.
Choosing a runtime just for the tools it brings isn't as good a decision it seems.
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.
People will move to a different runtime that provides the features they need.
> Bun users who don't care about slop will continue to use Bun
What slop does Bun create or cause?
Bun is the slop
Seems to be good slop, since Claude Code works so well.
Why do you say Bun is the slop? Does it lack utility?
(without having the answer from GP): your two questions are fully unrelated: first is about long term, second is about only "now".
To try a metaphor: "Why would you grow crops ? Do you lack food on your table ?"
Wouldn't be JavaScript without a new flavor of the month runtime or framework.
And people think there won't be enough demand for AI companies to IPO.
All they have to do is start an LLM-driven bun fight.
what is this obsession with bun and js in general? with all this vibe coding why not fix the reasons we needed js in the first place
We are soooo back
jackie chan meme
This just made the bun team work harder on the weekends lol
Now that no one cares about JS frontend framework, we moved the drama over to JS tooling written in other languages.
One reason I find deno nicer is that the node creator is solid isn't a slopperoo yapping about LLM induced quasi-productivity.
saw another project based on pre-rust bun and this is another one never use bun and sometimes this make me wonder, are we enter a phase the supply way > requirement or people just build stuffs and not care serious usage anymore?
As a software engineer these days, I can't say i do not use Agent to help work done, but i am really a bit of tired to see so much solutions while not talk about what problem they are trying to really solve
[dead]
Stop forking bun.
Use regular Node.js.
Then making something people want.
[flagged]
This is a personal pursuit from what I can tell. I wouldn't use any opinion or judgment from this person to reach any conclusion about "the Zig community". This is just unnecessary.
If this person can stick to these goals and keep maintaining the project (which I do highly doubt), I don't see how this can possibly be a bad thing.
I don't see the irony? LLMs are much better at cleaning up a mess. Using LLMs not properly created that mess in the first place.
> Bun is the quintessential AI slop project at this point.
To call the Bun rewrite "quintessential slop" is all I need to know to not take this person or their project seriously.