Not really. Transpilers have existed since forever.

The hard part is all the edge cases. (And LLMs don't solve this problem; they probably akshually exacerbate it.)

Node has 4-6 weeks without a meaningful release (other than security stuff) pretty much every December. I think the criticism in the article is unfounded and whomever needed/wanted a release should have asked first instead of writing an "angry" blog post.

(I'm a Node.js maintainer)

I look forward to the postmortem!

- How many people have updated Claude/Bun to the latest version.

- How many subscribers care about reporting issues. Most of them are forced to use the tool against their will and have mentally checked out already. Why report issues if your employer values slop code anyway. Just log the hours and keep your head down. Maybe it is not expedient for the AI narrative to report issues!

- How many subscriptions are real vs. bulk distiller accounts.

- If subscriber numbers are inflated.

Judging by the weird Claude Code Github issues page, there are suspiciously few new issues: about 2 to 3 a day only vs. alleged subscriber numbers of 4 million.

Short-termism at its peak. Code maintainers will learn the hard way how to set the boundaries between ai-generated code, and human maintainable code.

Also if you whip something up, you tend not to care for it as much as something you took the time to create in a "proper" manner.

> Bun is the quintessential AI slop project at this point. Inheriting that is no easy task. 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. It will likely require most subsystems to be rewritten.

They're refusing to accept human-authored contributions. They're using LLMs to do the work. The author says they'll use LLMs to de-slop what they think is slop, and humans are banned from contributing.

I don't think you should take this seriously.

No one on their team had Rust experience

If it was about Claude Code itself, they could have rewritten it. They keep saying they don't even write code any more, so it shouldn't even matter what language it's in.

I think they're taking things "gradually" as they are under a lot of scrutiny and no rush for full release.

If you explore Github, you're gonna see thousands of abandoned game engines, compilers for made-up languages. And that has been happening since before the LLM era.

I used to be part of an OS messaging board in the early 2000s and almost everyone had their own OS. A dozen people or so could even run Firefox! I remember (now legend) Terry bothering us to check out LoseThos or GodOS or whatever was its name, but quite a few people had OSs that could do more than that.

Not all software needs to be commercial to be useful, even if it's just for a learning experience. I have learned a lot from those experiments, even if they're not polished.

But it seems like we're finally starting to accept that "accidentals" like network effects, ownership, accountability, etc. are important. Of course, that's why many of us fled to technical corners in the first place - because the "accidentals" become tied up with things like nepotism, unfair and arbitrary judges from random humans who don't understand your merit, the need for bullshitting more than real technical value. Supposedly, anyways.

I worked for a startup that stopped feature development and did a complete rewrite of a huge codebase. I was assigned to a side project during this time and missed the entire rewrite process. I came back to a completely rewritten codebase.

There was almost no learning curve, despite being in an entirely different language. The core architecture, data structures, and concepts were the same.

If you read the Bun blog post on how they did it, their rewrite was similar: The first step was getting it into a new language, not rearchitecting it from scratch.

I think they did it the right way based on my pre-LLM. Rewriting into a different language as fast and basically as possible is important for getting the team switched over quickly. Rewriting into a different language in X days is actually a good goal to minimize.

What do you think of https://scramblequest.app and https://wordpeek.app ?

I have never looked at any of the code for them

edit: Yeesh, misread your comment as "word games" not "word clones" and was very confused about the claim. Probably should have noted my confusion and re-read.

The main issue that justified the rewrite were memory bugs, especially related to interaction with GC managed Javascript objects. There is no fully general way to prevent those bugs in Zig, and I don't see any claims that they did so in Buz.

I consider typing to be secondary to software engineering, but I do concede that for those cases that typing really is the bottleneck, LLMs can certainly be of value.

Those cases are rare, though.

I imagine the $800k or whatever this has cost is coming out of Anthropic's marketing budget, so they can make a big splash about it.

To the contrary, I think any problem with this release would be jumped on harshly so they're being more careful than usual. There's not a rush for the community to move to 1.4 and any issues could poison the community trust.

Bun is a major part of the web ecosystem, having it developed by them via AI, sounds like a gigantic pr win.

Thankfully now I have some good material to post-rationalise my intuitive dislike

We can't have commited and involved people working on opensource stuff and simultaneously avoid drama when their sence of identity/beliefs/pride is devalued.

You and me both friend!

There's a laundry list of reasons to be skeptical about LLM results in general. The biggest one is that LLMs are excellent at creating output that looks right but is nevertheless still wrong.

In this particular case, there's also a specific reason: This is obviously a marketing stunt regardless of whether the claimed results hold up. Anthropic has a long history of just lying and making shit up, so any results are subject to extra scrutiny.

There are so many non-quantifiable properties to evaluate of the 'before' and 'after' codebases. Choices and preferences to be had about languages, language porting in general, and LLM coding.

After all that, pretend we could have a clear convincing distillation of the port and want to go apply the lessons learned. If someone doesn't get LLM porting results as good as Bun did, or it cost them substantially more in tokens, then they're "holding it wrong." If someone is underwhelmed by Bun's results, then it was just a proof of concept and the models have gotten so much better in the last 6 months anyway you can't compare.

I'm consistently skeptical about new tech whether it is NoSQL or Blockchain or Serverless. Some of the things I'm skeptical about fail and some succeed.

I think there are tons of learnings to be shared about how to do this stuff, but it seems like it's all blocked behind arguments over whether AI is the best or worst thing ever, and penis-measuring contents about how to hold the tool. The net benefit is a very open question, and both the doom and gloom perspective and the AI booster perspective are valuable and have a lot of things right. But there's a dearth of information about what things work, what things don't, what happens in the process of using AI, how to adjust one's behavior and which of those adjustments is harmful even if effective.

But then, I'm part of the problem. I keep meaning to write up a series of experience reports, but it's a lot of work. More fun to vibe a new feature into existence, or to finally fix a UI wart...

This is from July 8, 2026. And while you did link it in your article, what else are you expecting?

By default, Claude Code updates itself all the time without asking for permission, so I'd say most users are on the latest versions.

I will have to steal it for an upcoming AI tools meeting I have at work.

Also, pretty clever as centering a div w/ CSS has been notoriously difficult to achieve.

I think with sequential approach (translate -> make idiomatic) it is easier. However, I am not sure that monetary difference is going to be as stark as $165k vs 3 engineers/year. Especially, if you consider that no one knows that is what in the code at the end.

Sure, you can argue that now it doesn’t matter — agents and all that, but I am not so sure.

It means shrewd.

E.g. we should keep our wits about us when someone is making big hyperbolic claims about LLM that they directly benefit from, because maybe they have a motive to mislead either themselves, or us

I never thought of this from this perspective but indeed it seems to be totally true.

[0] https://bun.com/blog/bun-in-rust

It was never that large but it did have a shot at getting more popular - until this drama.

No one worth their salt is building on Bun anymore, the creators and maintainers of bun have demonstrated their complete lack of care around engineering and support. It’s just too risky.

Supposedly they used a game engine to render their TUI but I’ve never had an FPS game do that.

We recently started cross-compiling all the builds on Linux arm64 and that made it a little faster (I wrote a CLI tool to download the correct macOS headers for cross-compilation). We also have a daily cron job that asks claude to make the slowest tests faster while adding more assertions.

"We at WC Duck recommend WC Duck"... I'm left scratching my head, if you'd care to spell out what the saying means for non-Dutch I'd appreciate it :)

[1] What it actually proved is up for debate.

> Anthropic is dogfooding this, the machine is still ticking along, and Anthropic employees are directly involved.

The problem is that your article's central claim is that there hasn't been a Bun release since the Rust rewrite - which can be read as implying that the rewrite hasn't been used in production.

But it's been used in production on millions of machines running Claude Code for over a month!

I think failing to acknowledge that hurts the credibility of the article. It's been a heated discussion point in this thread already.

And most executives are figuring this into their calculus right now because they were burned badly during COVID. Meta, Google, etc were loose with hiring and engineers flocked from their lower-paying companies in droves. The brain drain was real.

One public company I was at lost nearly 2/3rds of their engineers and mostly to Meta (granted, they had other problems but it was mostly about money -- the offers were excessive). Then market conditions forced them to freeze hiring and they've had a slow exodus of senior talent since as the firefighting has become constant.

AI adoption has only accelerated problems for them.

We've taken this "only two years and then leave" philosophy to an extreme and now companies are totally justified in not investing in their engineers anymore.

To actually get the safety benefits of Rust in a real way you have to rework those files to not treat eachother as C code. This is the interesting and the difficult part of a rewrite in Rust, and one that an unsupervised LLM rewrite is probably not even going to attempt.

I don't think this latter stage has actually happened with Bun's codebase. The result of the Rust rewrite in Bun's case is actually less safe than the Zig it is replacing, especially because (I am told) a lot of the new Rust code is unsound (introducing UB).

It took TypeScript a year to go from announcing tsgo to releasing TypeScript 7.0. That work was done in parallel; here the work is being done serially — and it’s likely to take much less than a year for a new release.

I was hoping for more push back against https://bun.com/blog/bun-in-rust - which is pretty thorough and has some decent arguments and reasoning for why they did the rewrite.

Are you expecting them to live-tweet their work or something?

I get that there's a baseline of unsafe that's necessary, but I was under the impression that some of those unsafes were in places where they could be replaced by more idiomatic Rust at a later date.

Yeah, but the people authoring those learned something.

> I used to be part of an OS messaging board in the early 2000s and almost everyone had their own OS.

Great example! I, too, once had my own toy OS, and browsed OSDev wiki nonstop. The thing is no one in the OS dev community were writing things they intended to place in front of actual users!

The difference now is that these incomplete projects:

a) Don't leave their owners any wiser than when they started, and

b) Are actually intended by their owners to be used by actual users.

> I have learned a lot from those experiments, even if they're not polished.

Would you have learned as much if you told a magic box "Make me an OS" and then slapped your name on it and uploaded it to GH?

Temple OS :)

This is fine so long as the author is learning something (questionable) and not polluting the commons with "I made this in a weekend" vibe slop.

> If you read the Bun blog post on how they did it, their rewrite was similar: The first step was getting it into a new language, not rearchitecting it from scratch

They eventually might regret this, when they are trying to get rid of the last lines of unsafe code. Rust needs to be written differently before you can write safe things to perform fast when compared to other languages or unsafe code. It takes a lot of experience before you can see it.

In case of ccc (claudes C compiler) they just did not use any tests, though they are many existing C testsuite. They just stopped, when it finished compiling the kernel, still failing hundreds of tests.

Rewriting a runtime with well-defined interfaces and behavior is quite different from rewriting a user-facing application under active development by a decent chunk of their organization.

Migrating to Rust in a one-to-one translation with unsafe blocks does not make the code any more safe initially. It might provide tools to do a significant refactor that solves lifetime issues with Rust's help, but I haven't seen evidence that they've done that either. They're also embedding a large C++ codebase, JavaScriptCore, so there are always going to be unsafe areas and touchpoints where memory issues could live, and Rust won't magically solve them.

They chose to use a react rendering to native TUI renderer, which was a source of a lot of performance issues.

AFAIK, they have written a new renderer.

- just because it doesn’t help 99.9% of the companies today it doesn’t mean it won’t help them tomorrow

- 0.01% of the companies employ a much bigger percentage of people

- 99.9% of companies won’t need to do a project of this magnitude

Word is basically an operating system. Unix people like to make fun of Emacs for being one, but Word is basically one, too. And all the features in there are used, otherwise Microsoft wouldn't keep them around.

Can you explain that more?

No GUI developer would ever put this on the same thread.

You can use deterministic linting for `unsafe` usage, have agents target `unsafe`, etc. It's pretty easy. You can even run `miri` against the code and give that as a tool for LLM feedback. I've done this all before and it works fine.

> The result of the Rust rewrite in Bun's case is actually less safe than the Zig it is replacing, especially because (I am told) a lot of the new Rust code is unsound (introducing UB).

I'm unconvinced that this is true. How could you tell? You only know about the rust bugs because rust makes them grep'able/ trivial to verify, there's no way of knowing which bugs existed in zig that didn't translate. Regardless, the problem is now trivial to understand in Rust and start to target.

I guess I'm debating, but it seemed clear enough to me? It proved that AI models and their harnesses are to the point where you can give them some work to do and leave them unattended for a long time, and they'll keep doing productive work for quite a while. This was a novel thing, and quite unclear, at the time the experiment was performed.

Obviously, the word "productive" is doing a lot of work there, but in my understanding the intention was nowhere near "commercially viable" or "practically useful", it was more like "not doing stupid shit like writing comments of the form 'This file contains the implementation implementation implementation implementation implementation implementation implementation implementation implementation implementation implementation implementation implementation ...'".

Maybe somewhere in the vicinity of "either passing more tests or generating more valid tests"?

Otherwise all of us would just be able to build bun via a prompt.

Almost all of my prototypes are made this way. "I made this in a weekend", is more often, "I made this in a day". Like any trad-coded project, time to vibe code a backend vs frontend time is 1:N

This is exactly the same as demanding, that people who post their thoughts always post original, useful thoughts. It's just not going to happen. Making something easy will increase the total volume and the majority of that volume will be junk. It's inevitable. What is needed is a search engine for quality software. Perhaps LLMs can do that, since they are better at understanding concepts than generating them.

If this were a major issue then you'd have to always nail your Rust architecture correctly from day 1 to handle future unknowns, and this isn't the case.

More importantly, LLMs are more than capable of figuring out how to rearchitect code and they have no problem making sweeping refactors for you, especially throwaway experimental ones that were way too expensive to do not long ago.

(I don't mean to be critical of the Bun maintainers, who have always been open about the fact that they leveraged the specific context of their project to do this effectively.)

Which is equally terrible and has earned them every single rendering engineer in the world taking the piss out of them when they proudly announced it was as complicated as rendering a video game.

That's such a stupid engineering choice that it really makes one question if the people working at Anthropic have any software engineering ability at all. There's no excuse for running React in a freaking TUI.

If it turns out the rewrite cost stupid amounts of money and leads to a bad outcome, it's just a misleading ad.

We developers now need to explain that to illuminated management and colleagues.

Well it hasn't. "Production" for a language runtime means being generally available for arbitrary use. The engineers that built the runtime using it to release one closed source binary to the public is, at best, an extremely narrow beta test.

I don't agree that using something in a very specific environment is the same as a wide release.

I trust readers will either know the backstory or read the articles I link to. Such is life if they don't.

Why not? A complete test suite exists, so it just boils down to "reimplement this code to reduce the number of 'unsafe' references, while keeping the tests passing" (the last part isn't even needed since Claude loves to run tests and linters anyway).

These are not comparable at all. The bun "rewrite" really is more of a translation of a software that is mainly dogfooded, created with an at best loose regard for a wider ecosystem.

TypeScript 7.0. by comparison is not just a translation from one language to another. It's a true rewrite that at the same time has to consider a massive existing ecosystem (which needs to catch up first or you risk fragmenting it). Plus you might as well consider 6.x part of the effort, since that was the stepping-stone.

Also where bun really is just a runtime implemented with a bunch of glue code plus supporting tooling, TypeScript is much more complex. Change one part of TypeScript and you can get cascading issues somewhere else in the compiler easily. Change something in Bun and you'll likely just break some discrete part.

How odd. Lot of mental gymnastics going on there.

why shouldnt upcoming work be as public as the rewrite itself was?

And .doc files are basically a memory dump.

That's very easy to prevent. Don't let them edit the tests! Run the test suite against a reserved copy.

To release this to the world and not have it be a catastrophe, they need to have confidence that Bun itself satisfies the promises that it has made, both explicitly and implicitly (bearing in mind Hyrum's law!) to all those projects out there using it, none of which are owned by Anthropic and many of which are not source visible to them. It's a much, much higher bar.

Also worth noting simple horizontal centering of divs was never a problem, margin: auto was defined in CSS Level 1 in 1996 [1].

It was vertical centering that took a very long time to crack, which really became trivial with Flexbox which was first drafted in 2009[2] but became available unprefixed in browsers between 2012 and 2014 [3] about 13 years ago.

[1] https://www.w3.org/TR/REC-CSS1-961217

[2] https://www.w3.org/TR/2009/WD-css3-flexbox-20090723/

[3] https://caniuse.com/flexbox

Subnote: I'm not counting the display: table hacks.

https://github.com/microsoft/typescript-go/discussions/411#d...

> But this wasn't a compiler redesign, and the TypeScript to Go move was far more automatable and more one-to-one in its mapping.

So basically the opposite of what you're saying.

that is indeed a roughly accurate definition of what "unidiomatic" means

Eg. goto/jump, bare "except" statements in python, etc... In Rust, unsafe has its uses and is a first class language feature, but it certainly isn't idiomatic to use it to mimic access patterns from other languages (unless absolutely necessary).

But at some point if “moving one of the biggest actively maintained and used codebases to it without anyone noticing” is dismissed as “it doesn’t mean all that much”, then we’ve lost the plot a little bit somewhere.

Claude code interacts with many system processes, files, etc, as well as external APIs. Processes audio via built in dictation. Manages a bunch of nasty auth. Etc etc.

What are the categories of features that wouldn't be exercised by this class of software?

A retrospective is just the reflecting part, without implying you believe it is going to fail and you're looking for some schadenfreude ;)

It was purely about maxing your compensation because changing jobs nets you more than promotions & raises.

I've never met an engineer in my life who truly earned a promotion every year and very few every two. Very few companies have org charts that even support that or have that many levels. This logic/advice only really applies at a few companies and people have adopted it no matter where they work. There's not enough growth/hiring at 95% of companies to even come close. The Peter Principle is also a real thing. Everyone's competence has a ceiling.

There's even an implicit understanding of this that people at smaller companies have inflated titles and you typically rank them down 1-2 levels when hiring/acquiring at larger companies.

Now I do agree that companies haven't been investing in their engineers, but that doesn't also mean this isn't a vicious cycle. Employers and employees are in a mexican standoff and things are only going to get worse until one side comes to its senses. Employers have all the leverage for it to not be them.

For the vast majority of companies the average tenure of an engineer sits between 18 and 30 months. They're also mostly hiring young engineers in their 20s. As an employer what is your upside to making such investments before they're at least mid-career? A lot of people seem to want the world and offer nothing in return for it.

Do you think it would weaken the article?

When I said it would improve the credibility I did mean it. My instinct on reading the article this morning was "this person doesn't know that Claude Code runs on Bun, which weakens their credibility in presenting the argument they are making here."

This seems self-contradictory. If it's just a translation, doesn't that mean it remains fully compatible with that wider ecosystem? All the existing APIs retain identical behavior given the preexisting comprehensive test suite that had to go 100% green after all.

    Do the rewrite that looks like we transpiled our Zig code to Rust. We can gradually refactor it to reduce unsafe usage and look more like idiomatic Rust after Bun v1.4 ships.

The original version of Bun was already a line-by-line (manual) port of esbuild from Go to Zig (also mentioned in this post), so the Zig code already wasn't "Zig-idiomatic" and apparently riddled with problems. That doesn't inspire much confidence in the LLM-translated Rust version tbh.

Which makes the parent comment’s “Bun performance hacks and optimizations” sound a little far-fetched, at least in this scenario I don’t think that’s gonna be the deciding factor. Their vendored JSC is also not touched by this port-rewrite at all whatsoever (still Cpp), so I’m not sure if it’s even possible to hack-improve all that much there.

If you have an LLM or human just start coding up something without nailing down those decisions first, then he/she/it will implicitly make those decisions arbitrarily in the moment (usually based more on pattern-matching than real weighing of alternatives) and the result will be a massive mess.

Ideally for an LLM, you'd hand-write a highly detailed DESIGN.md file to encode those decisions and a suite of test fixtures to enforce them.

However if "replacing small sections of code" is heralded as "the most amazing achievement in software development" then we've all lost the plot a little bit somewhere.

It makes sense both ways, no?

The reality is, of course, most people aren't going to notice. If the functionality and performance is 1:1 why would they? Is it impressive? A bit, but not how you're positioning it. People seem to forget LLMs are good at what they've learned from training data. And the LLM is good at compressing time. The only notable thing about these types of marketing spins is that a rewrite was accomplished in a small time frame that was hard to pull off before LLMs. The actual act of the move is less so.

Did the codebase improve? Is it more performant? I've seen nothing to really stake those claims with any objectiveness. Lastly: what was gained?

Going forward, I will strive to not make leaps that my audience can't follow.

> The goal of a postmortem is to draw meaningful conclusions to help you learn from your past successes and failures. Despite its grim-sounding name, a postmortem can be an extremely productive method of improving your development practices.

You’re taking it very literally here, it does not involve anything being dead or killed.

We’ve used this in the software, games, film and construction industries for decades at this point.

Substitute Mortem for Ship and that’s how people use it.

(also, fwiw, a manual rewrite would be under the same scrunity and suffer from the same skepticism, at least when obviously rushed).

https://en.wikipedia.org/wiki/F2c

Example: https://blog.codinghorror.com/game-development-postmortems/ Note the dual emphasis on both "what went right" and "what went wrong," not just one or the other.

Mostly in the opensource, or marketing-blog spaces. The detailed investigation and fix report was a favorite genre of blogpost. And if someone's bragging about the design of an enhancement, or investigating a bug, then the overall product isn't dead. They're (usually) not talking shit to anyone. It's the bug that's dead. Or security indecent that's over. Or a schedule milestone that's "dead and burred".

It's a 1 chili pepper level of spicy to use a slang term that relates to death. I'd never read it as hoping someone fails. I think people let the corpotalk center of the brain overreact to anything that's not couched in euphemism.

You don't view it as a problem that companies consistently compensate new hires higher than they are their experienced employees?

Hell, I would have been perfectly happy to never change employers in my entire career to date, if my salary had anywhere near kept pace with my peers who were job-hopping.

And yet Claude Code, which is the primary consumer, continues to chug away without any issue (that I, as a fairly heavy user, have encountered).

That's a really strong motivation for the Rust port. It's literally impossible to take a path not leading to an unacceptable outcome because the Rust compiler fails the compile if code no longer marked "unsafe" is still actually unsafe, and the tests fail if the implementation is incorrect. The compiler actively helps to force the LLM to do things properly.

It's not.

Passing an existing test suite just moves the optimistic lower bound to incidental compatibility, it doesn't move it to intentional - "regard" implies you gave it thought.

Plus, it's not just about code: it's also about giving the ecosystem a migration path. Dumping 500k LOC on people and discontinuing development of the zig version effective immediately (there hasn't been a release since and the zig tree is only a reference - the build script is removed afaik) is the opposite of what TypeScript did. If you broke someone's N-API module because of a regression not caught by your suite they're now between a rock and a hard place.

The good news is that there's nobody there to notice. The bun userbase is miniscule* compared to TypeScript's.

* negligible? irrelevant? laughably small? I'm struggling to find an adjective that does the difference justice.

But the article talks about how so much code was written so fast. Seems to me that to create that much code that fast you have to have AI produce both the code and the tests.

So I am not sure in this project if the AI can edit the tests or not. I assume that because this is Anthropic the AI is doing as much as possible, which would include editing tests.

Like, come on already.

What kind of migration path beyond 0 regression do you think is needed? And if the latest Zig version is no longer available, how were at least 2 forks based on it submitted to HN? And what kind of release are you expecting when the team is working to fully migrate to the port (so far it's still marked canary)? If someone's using an untested (ie. very likely unpublished) API, well it sucks to be them but they should know the risks.

And again the self-contradictory argumentation. If the userbase is as miniscule as you imagine then your criticisms are essentially meaningless. No ecosystem worth giving a migration path and nobody's N-API module breaking because of a regression, right?

It depends on the current employee and the incoming employee. They are not interchangeable cogs. Also not everyone consistently provides good value over their tenure -- a lot tend to work hard early and then for various reasons taper off. It's not necessarily their fault, but companies definitely are aware of this.

Personally I tend to value growth of my skillset over growth of income and that has largely informed my movement. I move when there's no longer interesting work if the compensation is at least fair. I've never been about comparing myself to others -- especially when most of my peers' left the industry after 5-10 years.

And you don’t think that has anything to do with incentives (or lack thereof)?

> I've never been about comparing myself to others

Doesn’t have to be about comparing oneself to others. More about the cost of living increasing because software engineering salaries are rising around you…

Yes; I think what I described matches that meaning?

Post-death, as in: "it's over," "activity has halted," "no more work being done."

Death does not necessarily have a bad/negative connotation. It's just the end of something.

This is in contrast to the original comment: "something that went so wrong you had to kill it." Death does not imply something went wrong or that it happened forcefully.

I guess "autopsy" generally is talking about "finding the cause of death" so maybe that has a more negative connotation ("something (bad) happened, causing death, let's find it").

Ah, words with their fuzzy meanings (:

Sure, that's true. It's not really relevant to people who don't speak Latin.

> It’s synonymous with autopsy!

This isn't true. I have no idea how you got here. In English an autopsy is a surgical procedure performed on a corpse for the purpose of identifying the cause of death. In particular, it's a noun. "Post-mortem" in the etymologically literal "after death" sense is an adverb or adjective identifying whatever it is as taking place chronologically after some contextually-specified death.

But, you seem to put some weight on the etymology of a word independently of its current meaning. In that case autopsy "literally means" to witness something personally, as opposed to hearing about it from someone else. (It's "self-eye" in Greek just as post mortem is "after death" in Latin.) Somehow I doubt that's what you had in mind...?

You can go and check if the AI edited the tests yourself: look at the git history of those files in the public Bun repository.

Which makes even less sense as we all know software is never done, unless it truly is dead.

Really? We had language machines for decades that couldn't do it. One that could was only built in the last 2 years max but that's something you expect from language machines? Lol Okay

After spending a lot of time thinking about the language, I came up with a relatively simple algorithm based on the language design - there are a few operators that mutate state, so basically just try combinations of those until your next memory cell contains the thing that you want, then lock those instructions in and advance.

Basically RNG yourself to victory.

The original code for that algorithm is here (python, + my own interpreter): https://github.com/wallstop/malbolge-toolkit/tree/dd942fb981...

I've since llmified it as an exercise.

BUT! The whole reason for this comment is to nerd say that printing stuff is relatively easy if you invest the time in learning the language's primitives and think of programming in it more as algorithms to operate on the op codes instead of literally writing code.

Now, to do more interesting things other than printing - I'd have to spend even more time thinking about the language, which I don't want to

They're not synonymous at all. They don't mean similar things and they aren't used similarly.

A calculator that can find all primes will be cool. A language machine that translates english into JavaScript is cool. A language machine that translates Zig into Rust is cool. Language machines are cool, not awe-inspiring or surprising to me.

Thanks for sharing!

In general I would agree though, and would take it one step further: the agent writing the source code should not even be able to see the tests, nor the agent writing the tests see the source code.