Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

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.

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.

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.

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.

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

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.

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.

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.

    node + npm + vitest + vite

    bun

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.

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/

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.

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.