> Electrobun aims to be a complete solution-in-a-box for building, updating, and shipping ultra fast, tiny, and cross-platform desktop applications written in Typescript. Under the hood it uses bun to execute the main process and to bundle webview typescript, and has native bindings written in Objc, C++, and several core parts written in zig.
I have to say, this whole saga is extremely interesting. Not just from a popcorn-enjoyer's point of view, but as a bit of a bell weather for 2026 software dev.
Time will tell. I predict this is just the same 20 year pattern of: people on the internet are irate about $latest_thing, and everyone will move on to some other hot topic.
But surely, whether or not the Internet mob moves on has no bearing on what actual lessons to learn from this saga. Will the vibe rewrite turn out to be a disaster or are LLMs already capable of writing human level code at this scale? That question is interesting no matter the level of attention this gets.
For some reason, when thinking about this, the visual of all the scientists at CERN camping out for the results of the Higgs Boson experiment jumped into my mind.
This is not as big an experiment as that. But, for software dev, it feels very significant.
What's funnier to me is none of them seem to want to abandon npm which keeps getting exploited and hacked. NPM has been the source of just how many industry wide hacks? Three major ones, and a massive supply-chain industry wide campaign against npm. But yeah, bun is the real concern here.
I think we need to smell the coffee and review npm and scrutinize it because it is getting dangerously out of hand.
From my perspective it is a synthesis of "It is difficult to get a man to understand something, when his salary depends upon his not understanding it." and "but npm is the source of all the shiny shiny!".
This is a very uncharitable interpretation of the twitter post: "It’s a combination of anthropic’s stance of not doing human reviews or any kind of rational roll out and stabilization."
They mention nothing about agents being used, rather focus on humans in the review cycle and some sort of gated roll-out process. Why we would bin these practices in the name of a faster release cycle is an important question & debate.
I kind of agree, but it goes both ways. Has Jarred said that there was no review? I know that he stated that rust bun passes tests. Now, I don't know the amount or quantity of coverage, but as a thought experiment, let's assume they are good. What does that count for?
I'm saying that AI is going to develop software from here on. I don't think you can expect that a human is going to review every line of code. Not that it's good, but that's just how it is. It's not so different from manufacturing. A human is not reviewing every weld. I see a lot of sloppy beads, but in a lot of cases, it's good enough.
I kept checking the thread for responses and finally realized it, but too late to edit. I will probably wake up in a few days from a nightmare about this misspelling on HN. Happens all the time, no joke.
I think that in my mind, it was always some sort of weather related bell, like you ring it, when the weather changes.
Hopefully the sheep reference will help me remember.
I think it makes sense to stay away from large code bases built using LLMs until it is proven that it is possible to also maintain such code bases using LLMs or using reasonable human effort.
I have an idea on how to tell if a codebase is rotting under AI Agent maintenance.
We can collect and analyze how the coding agent reads code during programming tasks, and see if the code access and token consumption are steadily increasing for similar development tasks. If the code readability doesn't degrade for the agent, the maintainability of the codebase should be fine.
We judge long-term quality of human codebases (at least OS) by ongoing activity; for LLM codebases maybe a consistent or increasing level of activity is a bad smell?
Turns out that if they're unusable by LLMs they're likely unusable by human devs. If you follow sane clean coding principles (like not having godclasses) it turns out coding agents (and humans!) can understand and navigate your codebase, especially if you use recognizable patterns, even with very light documentation.
It's alarming how people instantly jump to conclusions that Bun is now "AI slop".
Bun has been almost entirely worked on by LLM's for ~6 months now, long before the Rust re-write (source: https://x.com/jarredsumner/status/2054525268296118363). It already has been proven that LLM's can maintain such codebases.
It's very easy to throw shade like this on software if you've got a bugbear with it. I'm sure you can even come up with a bunch of these "stability" problems when challenged on it. I know I could, for basically any large piece of software that I've ever used.
But really, is bun worse in this regard than any other similarly ambitious open source software within it's first few years?
see that's fine with me if they want to take a year or two of human time and do the rewrite properly
this is a piece of software with no architecture, and whose owners have no regard or respect for architecture. I can virtually guarantee that on average every bug they fix will create one new bug, because that's what it's like to work on software with no intentional architecture
What are you talking about?? Bun in Rust is a port, almost exactly the same code base on a different syntax. The architecture did not change at all. Amazing how people comment without even knowing what they are talking about.
I think what they're is all is well as long as they aren't told that LLMs are doing most of the work. Being in the know is the issue here IMO as they would've continued using without a word otherwise.
It's alarming how people are willing to overlook the obvious in-your-face sloppiness of the Bun rewrite. A million lines of code in 9 days, pushed to main branch, forced on the existing userbase irresponsibly.
Nobody understands the code, nor will they be able to maintain it without AI service as an external dependency. Give me a break, I'm not running that monstrosity on my machine. Everyone running production software should move away from Bun purely as a technical decision.
This is my first time hearing about Electrobun it sounds like it could be a good alternative to electron. Their site mention CEF bundling as an option has anyone tried this?
While I'm certainly sceptical of pure LLM (re)-written software, I would have to assume in the case of the cyberattack vector that Anthropic used their new Mythos model to adequately test against.
Maybe someone has more info of them mentioning that.
so they are defending the LLM-generated code using another one of their LLMs, against attacks from yet other LLMs? So regardless of the outcome and impact on us, they win?
I have a very, very hard time believing that. Surely the acquisition left his wealth largely in the form of Anthropic stock, so his personal definition of success is "rep Anthropic so my stock goes up" and at that point he has succeeded.
Me, I still have to be competent to succeed. I don't just get to declare that because I used AI the effort was a success, and I have 0 desire to work with those kinds of people.
Realistically speaking, when Anthropic acquired Bun, they naturally would have needed a narrative showcasing that their AI excels even at relatively new languages like Zig. But since the Zig camp explicitly declared an anti-AI stance, it makes perfect sense why things played out this way. It's a understandable business realit
To upper-middle class people, their job is a religion. Investing in a programming language is a decision to gamble thousands of hours of your life for a programmer. At some point of projects shifting away from your language, your mortgage and your children's tuition will be affected.
For example, we (and many others) depend heavily on numpy. It's been around for decades and heavily battle tested. If someone came out with a new version of numpy vibe-code rewritten in a week, with assurances that "all tests pass", do you think we would adopt it? Absolutely not. We would have no confidence that there aren't some latent bugs or that we can fully trust the results.
It has nothing to do with AI having rewritten it, it has to do with being battle tested over time. If a team of humans had rewritten it in a week, I wouldn't trust or use it either.
>it has to do with being battle tested over time. If a team of humans had rewritten it in a week, I wouldn't trust or use it either.
"it was made in a week" gets repeated a lot on HN, but the PR wasn't a release. They've been working on the rust rewrite for more than a month and it hasn't shipped.
I'm not joining the chorus condemning Bun for the vibe-rewrite, and I think it's fascinating whether it turns out to be a complete trainwreck or not. But FFS, it should have been a separate repo.
They're two completely different codebases... even if they are 100% feature parity, it's 100% different code. They should absolutely be separate from each other, with different issues lists. Clean separation of two different codebases isn't a strange concept...
Its not 100% different code though. Docs, build instructions, C++, Typescript...
The issues should absolutely be kept. The rewrite was file by file translation so logic bugs would remain. It's valuable to ensure the memory bugs are in fact fixed. Starting the issues from nothing does not make any sense to me.
Judging by the comments, Bun as a company doesn’t give a single shit about community. The only reason it is in the same repo is tracking down issues, discussions, etc. Those would be hard to migrate.
Right, but it's my understanding that it was done as a PR that was merged to `main`. Sure, anyone could find the last Zig commit and branch off of that, so I guess it's all po-tay-to po-tah-to.
This whole thing of shunning bun is a goofy protest against AI in general by a bunch of programmers about to transition from vastly overpaid to mostly unemployed, sometimes thinly disguised as quality concerns and piggybacking a little bit on the anti-"rewrite it in rust" train.
Still, I can't help but entirely support it. I don't want hard dependencies on gigantic megacorps, or on any single provider who can go rogue. Should have always been able to switch between them, and any of them who made that difficult should have been the ones to be shunned. Completely dropping support for bun is equally bad imo, because now your choices are limited to Microsoft and deno, making deno close to a single point of failure.
Although I have to wonder what would happen if Anthropic threw a couple of bucks at electrobun (lol, not really.)
> This whole thing of shunning bun is a goofy protest against AI in general by a bunch of programmers about to transition from vastly overpaid to mostly unemployed, sometimes thinly disguised as quality concerns and piggybacking a little bit on the anti-"rewrite it in rust" train.
It is interesting how you find millions of people put on the street “goofy”, all while concentrating wealth in the hands of a couple of hyperscalers.
Great, the author speaks out what everyone thinks but cannot say, either due to being invested in the hype or due to effectively having a gag order from their employers:
In many a brand name company now tokenmaxxing is the name of the game; CryptoBase, FacePaper, AntiqueOptics, tinyflacid, they all use AI usage metrics as part of their perf review these days.
They should probably change the name then.
[delayed]
Electrobun repo: https://github.com/blackboardsh/electrobun
> Electrobun aims to be a complete solution-in-a-box for building, updating, and shipping ultra fast, tiny, and cross-platform desktop applications written in Typescript. Under the hood it uses bun to execute the main process and to bundle webview typescript, and has native bindings written in Objc, C++, and several core parts written in zig.
I have to say, this whole saga is extremely interesting. Not just from a popcorn-enjoyer's point of view, but as a bit of a bell weather for 2026 software dev.
Time will tell. I predict this is just the same 20 year pattern of: people on the internet are irate about $latest_thing, and everyone will move on to some other hot topic.
But surely, whether or not the Internet mob moves on has no bearing on what actual lessons to learn from this saga. Will the vibe rewrite turn out to be a disaster or are LLMs already capable of writing human level code at this scale? That question is interesting no matter the level of attention this gets.
I'm believe projects that pin old versions or maintain their own shoddy fork will be left behind. Deprecation is fine.
For some reason, when thinking about this, the visual of all the scientists at CERN camping out for the results of the Higgs Boson experiment jumped into my mind.
This is not as big an experiment as that. But, for software dev, it feels very significant.
What's funnier to me is none of them seem to want to abandon npm which keeps getting exploited and hacked. NPM has been the source of just how many industry wide hacks? Three major ones, and a massive supply-chain industry wide campaign against npm. But yeah, bun is the real concern here.
I think we need to smell the coffee and review npm and scrutinize it because it is getting dangerously out of hand.
Also Rubygems, Packagist, PyPi
From my perspective it is a synthesis of "It is difficult to get a man to understand something, when his salary depends upon his not understanding it." and "but npm is the source of all the shiny shiny!".
People are going to be using a lot less software if the selection criteria include not being no agents.
This is a very uncharitable interpretation of the twitter post: "It’s a combination of anthropic’s stance of not doing human reviews or any kind of rational roll out and stabilization."
They mention nothing about agents being used, rather focus on humans in the review cycle and some sort of gated roll-out process. Why we would bin these practices in the name of a faster release cycle is an important question & debate.
I kind of agree, but it goes both ways. Has Jarred said that there was no review? I know that he stated that rust bun passes tests. Now, I don't know the amount or quantity of coverage, but as a thought experiment, let's assume they are good. What does that count for?
yes, because as we know from history without agents there is no internet or technology or anything
What do you mean?
I'm saying that AI is going to develop software from here on. I don't think you can expect that a human is going to review every line of code. Not that it's good, but that's just how it is. It's not so different from manufacturing. A human is not reviewing every weld. I see a lot of sloppy beads, but in a lot of cases, it's good enough.
Trivia: The term is "bellwether," i.e. a wether (castrated sheep) wearing a bell, used to guide the flock.
I kept checking the thread for responses and finally realized it, but too late to edit. I will probably wake up in a few days from a nightmare about this misspelling on HN. Happens all the time, no joke.
I think that in my mind, it was always some sort of weather related bell, like you ring it, when the weather changes.
Hopefully the sheep reference will help me remember.
I think it makes sense to stay away from large code bases built using LLMs until it is proven that it is possible to also maintain such code bases using LLMs or using reasonable human effort.
I have an idea on how to tell if a codebase is rotting under AI Agent maintenance. We can collect and analyze how the coding agent reads code during programming tasks, and see if the code access and token consumption are steadily increasing for similar development tasks. If the code readability doesn't degrade for the agent, the maintainability of the codebase should be fine.
We judge long-term quality of human codebases (at least OS) by ongoing activity; for LLM codebases maybe a consistent or increasing level of activity is a bad smell?
Mist of human written codebases are unusable for llm dev by that definition.
Turns out that if they're unusable by LLMs they're likely unusable by human devs. If you follow sane clean coding principles (like not having godclasses) it turns out coding agents (and humans!) can understand and navigate your codebase, especially if you use recognizable patterns, even with very light documentation.
One of these days you’ll learn about “enterprise” code
I have seen good enterprise code and bad enterprise code. Clean Code suggests progressive rewriting of bad code.
When you touch a file you have an opportunity for code clean up, add unit tests to ensure your changes break nothing, and refine the code.
It's alarming how people instantly jump to conclusions that Bun is now "AI slop".
Bun has been almost entirely worked on by LLM's for ~6 months now, long before the Rust re-write (source: https://x.com/jarredsumner/status/2054525268296118363). It already has been proven that LLM's can maintain such codebases.
> It already has been proven that LLM's can maintain such codebases.
Is it? Seems like bugs in Claude Code are getting out of hands. That project has a bit more lifetime.
Worked on by LLMs is fine, but the rust pr proved no one is reviewing anymore. You cannot review 1M LOC in 5 days.
Bun never was great in terms of stability. It has been vibe coded for 6 month but code was reviewed by a person.
>It already has been proven that LLM's can maintain such codebases.
Proven is a strong word. In my experience AI fails miserably at anything beyond junior level tasks. We will see soon, once bun goes into production.
> Bun never was great in terms of stability
It's very easy to throw shade like this on software if you've got a bugbear with it. I'm sure you can even come up with a bunch of these "stability" problems when challenged on it. I know I could, for basically any large piece of software that I've ever used.
But really, is bun worse in this regard than any other similarly ambitious open source software within it's first few years?
see that's fine with me if they want to take a year or two of human time and do the rewrite properly
this is a piece of software with no architecture, and whose owners have no regard or respect for architecture. I can virtually guarantee that on average every bug they fix will create one new bug, because that's what it's like to work on software with no intentional architecture
What are you talking about?? Bun in Rust is a port, almost exactly the same code base on a different syntax. The architecture did not change at all. Amazing how people comment without even knowing what they are talking about.
Very amazing indeed. Here you are making bold assumptions about a huge pile of code not a single human being has ever read in any meaningful amount.
> Bun has been almost entirely worked on by LLM's for ~6 months now
So what you’re saying is that this boycot is 6 months overdue?
I think what they're is all is well as long as they aren't told that LLMs are doing most of the work. Being in the know is the issue here IMO as they would've continued using without a word otherwise.
It's alarming how people are willing to overlook the obvious in-your-face sloppiness of the Bun rewrite. A million lines of code in 9 days, pushed to main branch, forced on the existing userbase irresponsibly.
Nobody understands the code, nor will they be able to maintain it without AI service as an external dependency. Give me a break, I'm not running that monstrosity on my machine. Everyone running production software should move away from Bun purely as a technical decision.
Do you use Claude code on your machine? That seems mostly vibe coded
Claude Code isn’t a runtime that I use to execute my code with.
If you use it to write code for you, then it kind of is, indirectly.
1. I don't use Claude Code, no.
2. It's amazing that a CLI wrapper is as buggy as it is.
3. Nevertheless, it's useable, and maybe for a CLI that's enough. I don't want a JS runtime running production to be the same mess.
that seems comparable to taking a dev-time dependency, while bun is a runtime dependency. THey need to be treated very differently.
This is my first time hearing about Electrobun it sounds like it could be a good alternative to electron. Their site mention CEF bundling as an option has anyone tried this?
While I'm certainly sceptical of pure LLM (re)-written software, I would have to assume in the case of the cyberattack vector that Anthropic used their new Mythos model to adequately test against.
Maybe someone has more info of them mentioning that.
I wouldn't be surprised if the kinds of security issues LLMs tend to create are the exact types of security issues LLMs are bad ar detecting.
so they are defending the LLM-generated code using another one of their LLMs, against attacks from yet other LLMs? So regardless of the outcome and impact on us, they win?
Jarred said this had nothing to do with Mythos or Anthropic.
I have a very, very hard time believing that. Surely the acquisition left his wealth largely in the form of Anthropic stock, so his personal definition of success is "rep Anthropic so my stock goes up" and at that point he has succeeded.
Me, I still have to be competent to succeed. I don't just get to declare that because I used AI the effort was a success, and I have 0 desire to work with those kinds of people.
The concept of a "useful fool" is apt here.
At this point I am wondering if anyone will be forking the Zig Bun to something else.
That name is quite near the infamous Electron, is it similar?
TIL electrobun. How does it compare against electron?
It’s really only a matter of time until someone forks the Zig version of Bun.
What a slap in the face to all the Zig developers that spent their time, effort and probably even some money contributing to it.
Realistically speaking, when Anthropic acquired Bun, they naturally would have needed a narrative showcasing that their AI excels even at relatively new languages like Zig. But since the Zig camp explicitly declared an anti-AI stance, it makes perfect sense why things played out this way. It's a understandable business realit
Add todo item: learn zig.
Chill dog, it’s a programming language not a religion
To upper-middle class people, their job is a religion. Investing in a programming language is a decision to gamble thousands of hours of your life for a programmer. At some point of projects shifting away from your language, your mortgage and your children's tuition will be affected.
I’m so glad as a Python developer none of this religious bullshit enters into the equation. Exactly why I left Scala behind.
What a weird take. Might as well give up on anything you care about, as its only an "x"
You shouldn’t feel slapped in the face if someone chooses a programming language you don’t like. Full stop.
This makes a lot of sense.
For example, we (and many others) depend heavily on numpy. It's been around for decades and heavily battle tested. If someone came out with a new version of numpy vibe-code rewritten in a week, with assurances that "all tests pass", do you think we would adopt it? Absolutely not. We would have no confidence that there aren't some latent bugs or that we can fully trust the results.
It has nothing to do with AI having rewritten it, it has to do with being battle tested over time. If a team of humans had rewritten it in a week, I wouldn't trust or use it either.
>it has to do with being battle tested over time. If a team of humans had rewritten it in a week, I wouldn't trust or use it either.
"it was made in a week" gets repeated a lot on HN, but the PR wasn't a release. They've been working on the rust rewrite for more than a month and it hasn't shipped.
I'm not joining the chorus condemning Bun for the vibe-rewrite, and I think it's fascinating whether it turns out to be a complete trainwreck or not. But FFS, it should have been a separate repo.
What? Why? Git has branches...
They're two completely different codebases... even if they are 100% feature parity, it's 100% different code. They should absolutely be separate from each other, with different issues lists. Clean separation of two different codebases isn't a strange concept...
Its not 100% different code though. Docs, build instructions, C++, Typescript...
The issues should absolutely be kept. The rewrite was file by file translation so logic bugs would remain. It's valuable to ensure the memory bugs are in fact fixed. Starting the issues from nothing does not make any sense to me.
Judging by the comments, Bun as a company doesn’t give a single shit about community. The only reason it is in the same repo is tracking down issues, discussions, etc. Those would be hard to migrate.
Right, but it's my understanding that it was done as a PR that was merged to `main`. Sure, anyone could find the last Zig commit and branch off of that, so I guess it's all po-tay-to po-tah-to.
This whole thing of shunning bun is a goofy protest against AI in general by a bunch of programmers about to transition from vastly overpaid to mostly unemployed, sometimes thinly disguised as quality concerns and piggybacking a little bit on the anti-"rewrite it in rust" train.
Still, I can't help but entirely support it. I don't want hard dependencies on gigantic megacorps, or on any single provider who can go rogue. Should have always been able to switch between them, and any of them who made that difficult should have been the ones to be shunned. Completely dropping support for bun is equally bad imo, because now your choices are limited to Microsoft and deno, making deno close to a single point of failure.
Although I have to wonder what would happen if Anthropic threw a couple of bucks at electrobun (lol, not really.)
> This whole thing of shunning bun is a goofy protest against AI in general by a bunch of programmers about to transition from vastly overpaid to mostly unemployed, sometimes thinly disguised as quality concerns and piggybacking a little bit on the anti-"rewrite it in rust" train.
It is interesting how you find millions of people put on the street “goofy”, all while concentrating wealth in the hands of a couple of hyperscalers.
I doubt any sane human will continue using Bun.
In this industry, that leaves most of us.
Great, the author speaks out what everyone thinks but cannot say, either due to being invested in the hype or due to effectively having a gag order from their employers:
https://xcancel.com/YoavCodes/status/2058170216408813583#m
The bun rewrite was Anthropic's Vietnam and the open source community needs to react and and build resistance.
In many a brand name company now tokenmaxxing is the name of the game; CryptoBase, FacePaper, AntiqueOptics, tinyflacid, they all use AI usage metrics as part of their perf review these days.