They get abandoned because they get generated on a whim.

Sunk cost fallacy can be a feature: if you have spent a lot of blood, sweat, and tears on a project, you are more likely to push it through adversity and the doldrums that inevitably one will encounter. If all it took was one of those momentarily brilliant ideas and a prompt on Claude to produce something, there is no attachment whatsoever to it.

Speaking as the ‘average programmer’, I have dozens of brilliant ideas per day that don’t stand the test of time or scrutiny, and the very few that pass the filter don’t seem that interesting days later, or worth the effort at all.

Ideas have always been cheap. Now, proof of concepts have become as cheap. I don’t care about your Show HN unless you have spent a month on it.

> Now if that's further migrated to safe Rust, put into production & gathered feedback from lots of users, yes then you have something.

Obviously they have to start somewhere if they want to get to safe rust with a considerable degree of battle testing. So they decided to start with just a transliteration and go from there.

I think the Zig people are really just concerned that maybe Zig itself is a DOA language because it doesn't offer enough over C for any serious use and their flagship project has now abandoned it.

Just search "segfault" on the Zig issue tracker and you'll see why people are starting to be skeptical of the future utility of such a language in the face of something like Rust.

> How is that better than the Zig codebase you started with?

In contrast with the Zig codebase, you now have clear well-scoped unsafe boundaries you can iteratively fix one by one. This was not the case before.

> There's so much good stuff in this post.

The post starts off so cynical. I know a few people at anthropic and oai and the simplest explanation also matches my observations that they actually believe what they say. That agents will be doing the bulk of the programming in the not so distant future. They believe they themselves will be out of jobs at that point.

They aren't managing some message and trying to teach the anti AI folks a lesson.

But it’s really the same old problem we’ve seen for decades. Developers write code. Owners declare victory. Owners rid themselves of expensive opex. Owners sell the division or try to keep the project limping along but all they see is vaguaries from the new cheap guy who they keep telling isn’t good enough for a raise, company hemorrhages money and eventually sells for a song.

They’ve just found a way to explore that logical fallacy even faster.

> Can't help to think of a recent HN post about most AI-generated projects being abandoned within months. Why?

> Because value of a project is not in the code produced. It's in the amount of battle-testing that code has seen.

I'm not convinced this explanation is self-evident enough to assert without any justification. I can think of at least one other plausible one, which is that maybe most side projects in general get abandoned after a certain amount of time, and being able to write the code a lot faster means that the point of diminishing returns for personal utility, enrichment, or pleasure are reached a lot faster.

the rust is merged into main https://github.com/oven-sh/bun

and the rust version has been live in claude code since june 17th.

I read a decent chunk of the rewrite.

It’s inaccurate to call it a rewrite. It’s more a transliteration - it matches the original Zig almost exactly but the syntax is different.

And yeah, unsafe blocks anywhere that rust would have complained

So it’s highly likely that the “rewrite” is exactly as reliable as the original.

(It sure feels like this was done for Anthropic marketing reasons, the more I think about it.)

> Can't help to think of a recent HN post about most AI-generated projects being abandoned within months. Why?

I'm gonna offer an alternate theory. Because AI-generated projects are so cheap, there's no need to amortize them by advertising and creating a community. It works for you, you don't change your workflow, so there's no need to expand it. In this model, most AI-generated projects are done within days, not abandoned.

>Can't help to think of a recent HN post about most AI-generated projects being abandoned within months. Why?

Because most projects are abandoned within months. Why should they be any different in that respect?

> Because value of a project is not in the code produced. It's in the amount of battle-testing that code has seen.

Rel: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Yeah, I was just commenting on a LinkedIn post[0] (don't hate the player, hate the game :) ). In it, someone talked about the difference between creating software and owning it.

Creating software with AI is super easy--plan, prompt, test, go, go, go!

Owning software means you're responsible for maintaining it over time, fixing edge cases, operating it well, and more.

If you're building a one-off custom webapp to meet your needs, create away. If you're writing software for a business to run on, you're owning it. My fav article on this topic is this post[1] on durable vs disposable software.

0: https://www.linkedin.com/feed/update/urn:li:activity:7482123...

1: https://www.honeycomb.io/blog/disposable-code-is-here-to-sta...

I've run into a bunch of segfaults in Bun whenever I went slightly off the beaten path, probably from the "horrifying" Zig code. A huge test suite + a clean rewrite with a path towards more safety is how I would go about it too, personally. Now whether I would do that rewrite in Zig or Rust, I'm not sure. But I have high hopes it's going to work a lot better, especially since Anthropic uses Bun heavily.

Are LLMs better at writing Rust than Zig? I'd assume so, there's way more Rust open source code than Zig. And if so, that's a very solid reason to switch IMO.

> Battle-tested, mature code > fresh rewrite.

> Existing Zig codebase has seen X amount of battle-testing. Rust rewrite: 0 (except -I'm assuming- passing test suites).

Not taking a side here in the whole Bun vs. ZSF dispute, but isn't the entire selling point of Rust that you get a bunch of battle-tested guarantees simply from compiling the program? Is there even a metric for battle-tested? I would say something like sqlite is battle tested vs a vibe-coded network server in c, but does that mean rewriting anything in rust truly mean starting all the way back at square one?

Also, didn't Anthropic roll out a version of CC using the Rust rewrite of bun? Surely they didn't just say "works on my machine" and chuck it into production?

I think the mistake people are making currently is that they publicize stuff way too early. I.e. they make a prototype and then put that out there. Possibly with a full product page and all.

People did this also before LLM, but the difference is that now the prototype is a fully functional product in the technical sense whereas before it was little more than a glorified Hello World. The human effort and calendar time used remains roughly the same.

There's gonna be amazing products made with LLM, but it'll take some time. Not as long as it did before, but still significant time.

> To me it reads like Bun was forked. Will the Zig version survive? Will the Rust one? Both? All options ok.

Maintenance of the zig code was abandoned, while the port continued in the same repo, and it's unlikely any work on the zig branch will keep momentum. So yes it forked, but more in the fork+exec sense.

>I don't think Zig community should get triggered on any of this.

As far as I can tell No one from Zig community got triggered by this other than the Zig team. People were angry about Bun switching to Rust not because it is abandoning Zig, but this reckless behaviour of not letting users know up front, no migration path or two parallel version testing and basically trust AI on everything.

The internet was pretty much on Zig's side or at least between Bun and Zig they were Anti-Bun for a lot of things. That was until Zig's reply.

I think the line is between AI-generated and AI-assisted - I have AI assisted projects that I have happily been developing for several months and they are going fine, I feel just as engaged with them as I did with my hand coded projects, but also I am more engaged insofar as I actively manage the architecture and the code, and see to it that the AI is following the plan I have in mind.

people chasing after "one shot" code certainly aren't helping, I agree.

I don't think Zig community is triggered, I think only Zig's creator is triggered because he is afraid of people interpreting this as "Zig is unsuitable for X".

I think a lot of people will, but those who do probably weren't the target audience for Zig in the first place?

> Because value of a project is not in the code produced. It's in the amount of battle-testing that code has seen.

No, this is a classic mistake. The value of a project is in the instantaneous utility it provides integrated over time. Some things are valuable because they are throwaway single shots that do a thing that's hard. In the past, making those was too costly for the value, but as software drops to near-zero in marginal cost they're worth doing.

e.g. the costco receipts site involves clicking through to view receipts and only 10 'view receipt' buttons per page. I might have stuck it out in the past, but instead I just described the problem to my claw-like and gave it my user/pass and it found it for me while I was dressing the baby. It wrote some Playwright code and this and that and drove the browser interactively.

That code is throwaway code but it was quite useful.

> Are Bun users happy with this?

I've gone back to Node.

There was a poll on r/bun with about 2000 votes and only about 30% of users voting they were going to use the Rust version. Can't seem to find it now.

Edit:

The poll was deleted

https://www.reddit.com/r/bun/comments/1u3j4d7/are_you_going_...

Its true about the battle test

I wonder if new version of Bun has the same emotional values in Jarred's mind, I mean he did write it by hand and struggled for a long time and invested a lot of energy.

Meanwhile the rust rewrite just magically appeared to replace it.

Which one is more valuable for a person? High Effort or low effort?

That battle tested bit is so true, always was. It’s hard for engineers to admit their hard work is worthless until they have let other people use and shape it.

Honestly I also think most vibe-coded projects are just.. kind of bad ideas. Which is fine! It's good to be able to determine an idea is bad quickly, there's value in that, but I think people ignore a really important aspect of creativity: the insights you need to have a good idea come from struggling in the muck and struggling in the medium. It's really hard to have good ideas from an ivory tower, you need to get into the details.

I don't even get what they gain by Rust - Bun imports Webkit, which is a C++ project, relying on it for stuff like JITing Javascript. I would say that's a major concern, and making sure the JIT doesn't emit anything broken or naughty is completely outside the scope of Rust.

> Can't help to think of a recent HN post about most AI-generated projects being abandoned within months. Why?

That which can be created with little effort can be dismissed with little fanfare, since it can easily be recreated later if there's a need.

The other category of AI abandonware is one-off stuff. It did its job and there's no further use for it.

Of course the deeper points can be made that relatively few folks were actually using Bun. After all Bun was itself a faster horse compared to the dominant runtimes it was aiming too replace. Ironic, the way this whole meta conversation is playing out.

This is why IBM still sells so much ancient z/OS mainframe code, things like CICS are the most tested code in existence.

I've always viewed unsafe Rust as a sort of last resort you use when you just can't do something safely. Porting something to "unsafe Rust" to me feels pointless, and of course this hasty rewrite was probably not the best idea from any perspective.

> Because value of a project is not in the code produced. It's in the amount of battle-testing that code has seen.

It is in the marketing. Most software engineers are not skilled at marketing, do not have a large audience, and are not willing to spend money on advertising. It has nothing to do with code quality.

> Can't help to think of a recent HN post about most AI-generated projects being abandoned within months. Why?

Because we have a near infinite number of artificial monkeys figuratively typing at a computer keyboard and, once in a while, they spout out something that looks like an acceptable program.

But it's not acceptable: it's sloppy-pasta.

> Because value of a project is not in the code produced. It's in the amount of battle-testing that code has seen.

Yeah. I don't know if we live in the same world as some other HNers: I pay not one but three AI subscriptions: Google (through Google Workspace), Open AI and Anthropic. I'm switching from Claude Code to pi.dev atm.

I'm using LLMs daily. The person next to me too.

LLMs produce shit code. Pure unadulterated shit.

They're extremely useful for many things, including finding bugs. But, to me, they simply suck at fixing them. They write horrible, verbose, code full of bogus assertions and cases that are not handled or not handled correctly.

I do verify the output they produce: the number of time it "works" but I look at the code and see sheer horrors and say stuff like this: "wait, if you replace A by B like you suggest, shouldn't thing X that A makes be done too?". (it's a rethorical question: I know I'm right).

"good catch".

No. It's not a good catch. It's a totally obvious catch that any programmer who's been in this since more a few years (a few decades for me) would catch instantly.

Now if there's one area were they're semi okay'ish is for porting code from one language to another. At least you get a base to start from: if you're lucky. And I suspect it's only looks good if you don't know much about the target language.

Also don't be fooled: we're talking about a company with tens of billions investments that fully knows AI is not enough. You can be sure there are countless programmers fixing, behind the scene, the sheer mess that their AI (with unlimited budget btw) is creating. And then they pretend it's a 100% automated AI rewrite.

AI is not only definitely not enough: it's useful for finding bugs, it's a good rubber duck, but the more and more time passes, the more I'm appalled by the shit code it produces and by the errors they make all the time.

If I wanted to be facetious I'd say that at least we're already --how things moves fast-- long past the point were the kool-aid drinkers explain to us that these thing are intelligent.

It's summer 2026 and, as I type this, the SOTA models all suck at writing code.

Am I still deep into it? Sure am. For basically everything but coding (finding bugs, documentation, translation, generating assets, automating dumb stuff, ...).

Oh well, going back to pi.dev facepalming myself and rolling eyes. I know it's going to be "good".

That's such a bad take. You mention some good things they need to do but ignore the part that those are next steps and will take time.

You are acting like they need to complete everything at once...why?

Bun (rust) is not even released as stable yet and getting extensive usage on Claude code. They are making improvements and fixes. So what's the issue here?

[flagged]

Totally disagree that the value of a project is it's durability. The value of the project is almost entirely disconnected from durability. Value is simply the ability to solve a problem for you. I'll use a bad screwdriver before I use my fingers, even if I prefer good screwdrivers.

Claude Code was a vibe coded experiment, a "what if", that basically consumed software engineering in six months flat. Not because it's durable (it's not), but because the value it provided was so overwhelming.

People will use bad software if the value it provides is high. People will avoid the most durable and battle-tested software ever written if it doesn't actually provide value (solve a problem for them).

"How is that better than the Zig codebase you started with?" - It will be worst, as this will not be idiomatic Rust. That's kind of interesting, BTW, as in next iteration LLM will be trained on tones of crappy code, created as some random rewrites, AI slops, etc., I am curious if someone will be able to curate this or it will be the same process of crapification experienced by Google Search that finally lost the battle with SEO spammers.

> How is that better than the Zig codebase you started with?

It's not better, it's worse given the average bear's assumption about a rust project.

It's more than just the battle testing. Things that are not wanted by a community or by users are not important. AI delusion memes are fairly reductive but a commonality I see in many overtly ai evangelistic groups is an urge to build without motivation and agreement. The yes we can answer AI gives to user's every question is a failure mode trigger. LLMs are missing the filter an engineer with a human body may give you to an idea...

- Why would we do that?

- This seems pointless.

- This is fucking dumb.

I guess the Rust rewrite is the exit path of the Bun's author so that the others could "handle" the code base.

> How is that better than the Zig codebase you started with?

It's worse, and I say this as an avid Rust fan and programmer. Try Miri with the new Bun project. It's currently blowing up. The Rust compiler's non-unsafe aliasing rules still need to hold during unsafe, which are far more complex than writing correct Zig code. That's the trade-off about Rust: The compiler has a ton of clever proofs for safe code, but if you're on your own, you'll have to do the work yourself.