Your hypothetical developer wouldn't be using notepad because they're unaware of other editors, they'd be using it because they evaluated other editors and concluded that, for whatever reason, they would be worse for them. I'd be fascinated to hear why they came to that conclusion, but I'm not going to tell them they're wrong if they're performing acceptably, aren't constantly breaking CI because the linter rejects their code, etc. Everyone is different, and I'm not narcissistic enough to think the fact that I would be way less productive without my modal editor, LSP, linter, terminal multiplexer, etc. justifies forcing everyone else has to adopt my exact setup.

The cap is moderately above the high subscription tiers, and managements/the executives were clearly extremely concerned about how expensive it would be if we all or even mostly came close to hitting it. I heard that they originally wanted to go lower but the developers in the pilot program blew past their planned limit very quickly.

As for the company, its almost entirely B2B SaaS (I think it has some offerings that are used by consumers, but they're mostly/entirely paid for by another business on behalf of their customers), and they have developers all over the world, although the headquarters and biggest group of developers is in silicon valley (my office is in the midwest).

Agreed. The better comparison is Deno, which does roughly the same thing (wrapping a c/c++ javascript engine to create a serverside runtime). Deno was smaller, but per line of code/file it had just over half the unsafe as the bun slop rewrite. There are also examples of unsafe blocks that are just locally incorrect [0], meaning you don't even need to read outside the function and it's definition to determine that the entity doing the porting (in this case claude) didn't understand how unsafe rust works.

> I am skeptical why Bun was even an acquisition target in the first place, other than pulling stunts like this.

From what I've heard, it sounds like the author had become fully hooked by LLM coding before the acquisition, so I don't think we know enough to conclude that this was premeditated by Anthropic. I think the more likely trigger is that Bun had just bragged about how they'd forked the zig language for a performance increase and attacked zig for it's no-AI policy, only for a zig core team member to point out that the code couldn't be upstreamed even if it had been hand written [1].

The better point, IMO, is how this is an example of how AI use/addiction makes developers who fall into it loose the ability to judge code quality, particularly for code they prompted for themselves. From what I've heard of Mr. Sumner and the team at oven from before AI, I very much doubt code of this poor quality would have been allowed anywhere near the main branch before LLMs.

[0] https://github.com/oven-sh/bun/blob/d2a6506dfad4c3ef3dddb9ae...

[1] https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

Second, I think you're overestimating how hard sharding is here. There are plenty of use cases for which sharding isn't just easy to set up, but the natural thing you'd be likely to do even without scale. Things like e.g. a helpdesk SaaS, where each customer/organization has it's own independent data.

Third, a large part of the point is that you are unlikely to know ahead of time you're going to "scale like that". As I already pointed out, most SaaS apps do not end up having many users. For some that's intentional, but for others the reason is that they simply never caught on. For those cases (and they're the vast majority), cosplaying as a much larger app is a complete waste. It's much better to wait until you're successful enough to need to switch and then use the revenue you now have to solve the scaling problem you ran into.

Fourth, as an aside, ironically the other (slightly less) easy way to shard superficially resembles a common way people cosplay as netflix: splitting your data by domain as "microservices" (although there's a good chance they don't need to be independent processes/on independent machines).

1. Your unit tests are exacting enough to fully specify the unit. In that case, congratulations, your unit tests are the code. They're also probably much more awkward to write, maintain, etc. Also, the compilation step to go from the unit tests to the actual code is now orders of magnitude more expensive, requires a SaaS to even work, etc.

2. Your unit tests are not that exacting and still leave ambiguity, edge cases, etc. In that case it very much matters what's in the blob of code, because while it could be a correct implementation of what you wanted, it could also be something else entirely that just happens to be correct for the part you did specify.

Having looked at a bunch of known or suspected (based on the intent of the code and/or what I know about the developer(s)) LLM generated rust, there's only a few explanations here:

1. You're way better at prompting than (virtually) anyone else.

2. You're vastly overestimating how good the rust code it produced is.

3. You handheld the model throughout and made lots of edits.

4. Your hand written rust code is very bad.

Because from every example I've seen, these models write horrible rust. Sure, it may technically pass all the tests, but it's horribly pessimized, badly organized, doesn't even attempt to use the type system, if there aren't bugs now there will be the second it tries to refactor or add a new feature, etc. etc.

(I also strongly suspect that the same would be true for other languages, but I can detect it in rust more easily because it's my main language)

Fair. Question though, is this when compared to competitive programmers, or developers in general?

> extremely strong performance (super-p90-engineer) on say language-to-language porting

I'd need to see the methodology here and could easily be wrong, but I suspect this is largely down to "faster" and "willing to do a lot more of it without complaining"

> RE-bench (ML research engineering benchmark from METR) is already clearly above human perf

This pretty much has to be "relative to devs who don't specialize in that area", because if it wasn't the frontier labs wouldn't be paying a fortune to hire ML researchers.

> Mythos clearly has superior cyber capabilities

Based on Daniel Stenberg's experience with it [0], it seems like it's at best roughly on par with human experts. It's advantage is cost/speed.

> Also, why do you discount speed and cost so much?

Because in all the domains LLMs are applicable to, getting something cheaper/faster at the expense of quality isn't new or particularly interesting.

> Every model iteration is a significant bump up in performance according to a lot of complementary and principled measurements. What's been the thing that hasn't been true?

That they were good enough. To reuse the baby analogy, if every week your friend told you that their infant child was now heavier than an elephant (while acknowledging that the baby was lighter than one the previous week), and every week that turned out not to be true, it wouldn't be a defense of your friend to argue "ah, but the baby was heavier every week than the week before".

Also worth noting that as of ~8 months ago, while benchmark scores were steadily increasing, merge rates (aka whether the code was "good enough") were not [1].

> thats a bit of a crazy ask.

Why? If you use LLMs to do anything you're basically doing that already, it's just that the scope of your Y is smaller. Either the benchmarks are irrelevant and you're using something else to determine when that's appropriate for a given Y, or you do in fact have a value of X for the Y's you've handed over to LLMs.

> Yet one side has a mountain of hard evidence and the other side has...an outdated n < 20 METR study using Sonnet 3?

There's a lot of irony here, because by far the most common pro-LLM coding argument is "I feel like I'm producing good code faster with them", followed by "this other person feels like they're producing good code faster with them".

Also note that the most important part of the METR study you reference wasn't the slowdown they observed, it was the dramatic disagreement between what the participants thought the impact of AI was vs what it actually was. That isn't dependent on the model.

[0] https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-v...

[1] https://entropicthoughts.com/no-swe-bench-improvement