lunar_mycroft

We've had a long discussion only because you refuse to admit that a very simple solution would work (despite completely failing to show how it wouldn't). The problem is that your opinion is not in fact proof that you're right.

First, GP's proposal already addresses that. If both are present, CLAUDE.md would be used. Second, that is solved with a settings toggle. Read a boolean from .claude/settings.json and disable the new behavior if it's true (or false, depending on what you want to name the setting). third, you skipped the second part of my question: "how would implementing it the way Anthropic did address that?" Implementing the same behavior through multiple layers of abstraction and an order of magnitude more code doesn't solve the issue you mentioned.

Bonus forth point: why is this critical to solve for claude code, but not for all the other harnesses which have all converged on AGENTS.md for this purpose?

How, exactly, would the proposed solution (combined with a setting to disable it) break, and how would implementing it the way Anthropic did address that? Be specific.

Just saw this now. The two aren't remotely in conflict. The _rewrite_ (from zig to rust) almost certainly didn't result in the performance improvements they're claiming, because rust and Zig are roughly equivalent in that regard. We know that they included other changes with the 1.4 release (in other words, 1.4 is not just 1.3, but in rust this time), so it's far more likely that those changes are responsible, not the rewrite.

1. Ironically enough, I (GP) am a software developer.

2. How exactly do our jobs depend on a thing which has been around for far less time?

At this point, I find myself hoping for a AI triggered mass casualty event that's not at a civilization destroying level, because that seems like the only thing that might actually stop these people from driving our entire species off a cliff before it's too late (edit: besides running into some natural obstetrical that stops them from developing a powerful enough model).

The announcement also makes it very clear that 1.4 isn't just a rust port of 1.3. Rust is my favorite language and it can be a bit faster than other systems languages in the right circumstances (because the compiler can make optimizations based on assumptions that wouldn't hold without the borrow checker), but numbers like those seem far more likely to be the result of other changes than the language shift.

I think that the bun rewrite actually supports the oppposite conclusion in a lot of ways:

1. The resulting code was of pretty low quality. Others that bothered to put it through Miri and the like found many soundness issues, but my personal favorite example is this example which is trivially and locally (meaning that someone who has the most basic understanding of unsafe in rust can see it's obviously wrong just by looking at the specific function) incorrect example [0]. This particular example was removed in an apparently unrelated refactor after spending well over a month in the code base without any of the bun maintainers or their agents detecting it, and a quick grep found hundreds of potential similar issues (although many of those are false positives).

2. More generally, it's not clear to me that there was any technical benefit to the rewrite in the first place. The stated reason was for memory safety, but replacing Zig with unsafe rust doesn't actually get you memory safety, and removing the unsafe blocks often requires more extensive refactors to fit within rust's model.

> If you can reduce a problem to a clearly verifiable end state, provide the necessary context, and equip a model with the necessary tools it can usually get to a good solution.

As others have pointed out (and you acknowledge), "reducing a problem to a clearly verifiable end state" is just "programming". What you don't seem to understand is that actually doing that is made harder by using AI, not easier. A sufficiently detailed spec is called "code" [1], the question is what language/notation is best to write it in. The answer is almost never "whatever is closest to what the computer actually executes", as assemblers and later compilers and interpreters demonstrated. But it also isn't several of the things that AI proponents have suggested to replace the latter with.

Take natural language, for example. As Dijkstra pointed out, we've been through this already with math. It used to be that all math was expressed in a way closer to what we'd now call "word problems", but this turned out to be bad. The specialized language of e.g. algebra isn't something mathematicians use to gate-keep, it's way easier to reason in the domain that way than it is in English (or other natural languages). The same is true for programming, once you actually specify what you want to do with enough rigor. It's generally easier to read and reason about code than to do so with natural language specifications.

Another proposal is to use tests and similar automatic verification to specify the program. I suspect that anyone with much experience can already tell whether it's preferable to specify a program through code or through tests, but thankfully we have empirical evidence on this for anyone who has any doubts in the form of e.g. sqlite. Sqlite is probably one of if not the closest any piece of software comes to being fully specified by it's tests. To do that takes almost 600 times as much test code as there is "regular" code. Dr. Hipp even personally weighed in on the implications this has on AI recently [3] . The reason to do testing is that it provides a second independent check for correctness, if you're using it as the *only* check that advantage disappears.

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

[1] https://haskellforall.com/2026/03/a-sufficiently-detailed-sp...

[2] https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...

[3] https://youtu.be/V_qzqY1bb7I?t=2727

> We've normalized science fiction. Go back 5-10 years and ask anyone whether we'd soon have something like LLMs.

LLMs are incredibly impressive. It just doesn't follow from that that they're capable of all the things proponents claim they are.

> I just can't believe that LLM haters really like computers or technology

In a lot of ways the reverse is true. The LLM coding ecosystem seems designed by people who are unaware or actively despise the fact that they have access to a computer, and almost the entire point of LLMs is to make interacting with computers less like interacting with computers and more like interacting with people.

> If you actually used LLMs instead of preaching against them from the sidelines with no real experience, you'd know such statements are wrong.

What about the people who do have a lot of LLM experience and agree with OP?

> That thing cannot do the stuff you say it can. And there is no way I will ever try it. But I know for sure I am right.

If someone claims to be able to fly by strapping bird wing shaped pieces of plywood with feathers glued on to their arms, do you need to personally jump off a tower with them to say they don't work, or can you look at the results of others attempting it and draw conclusions based on that? LLM proponents are making claims about their capabilities which can relatively easily be checked without using LLMs yourself. To pick an example where LLM proponents are correct, anyone who says LLMs can't generate syntactically valid code can be proven wrong fairly easily by producing an example of syntactically valid, LLM generated code.

Further, if you read the rest of the paragraph you responded to, it's clear that this claim is about the state of the industry as a whole. "Software has not improved in quality, got faster, become cheaper to produce (when you exclude the mountain of poor-quality demoware that no reputable organisation would touch with a barge pole), or become more capable." Whether this is true or not is something that can be evaluated without ever having prompted yourself, or even arguably without being a developer at all.

Do you think the LLM reads every page on the internet before generating your answer? Of course not. What happens is that it use some sort of ranking algorithm to pick the pages that are most likely to answer your query and reads *them* (at best. At worst it just makes something up). You aren't avoiding the problems with ranking algorithms by asking an LLM, you're taking all of those problems, adding more problems on top, and pretending that this is somehow better.

Google (as it originally) existed wasn't a source of information, it was an *index* of it. You were trusting google as a source for {search_query}, you were trusting the links it gave as a source (based on your own evaluation). LLMs are fundamentally different, because you are trusting the software to actually generate the information in a truthful way.

If you use google (sans AI), you're putting some trust in their page ranking algorithm. If you use it with AI, you're trusting the same algorithm (since that's how the model gets it's sources), but then you're trusting the model to evaluate the sources for credibility and extract the information you actually want.

Sensible companies don't do a lot of stuff Meta has already been caught doing - sometimes with real consequences (but never enough to actually deter them, of course) - in the pursuit of more data.

Meta literally ran a man in the middle attack to spy on it's user's encrypted network traffic when they used third party apps [0]. More recently (and relevant to this issue), the engaged in industrial scale piracy to get training data for their LLMs [1]. The idea that they have changed since Zuck was a college student creeping on his female classmates and now wouldn't commit actual crimes against their own users in order to get a bit more data is just demonstrably false.

[0] https://www.techradar.com/computing/cyber-security/facebooks...

[1] https://www.tomshardware.com/tech-industry/artificial-intell...

In that case, you'd branch into a separate function/block that runs the calculation. Sure, it's slower than a simple array index to find a coefficient, but you're only incurring that cost when you actually need it and it's still much faster than using polymorphism everywhere instead.

Actually, that video predates the one on clean code.

It won't do that for free, companies (and open source maintainers) will have to pay for the tokens used finding vulnerabilities in their own software. That increases the cost of releasing the same product/feature/amount of code vs what it was before.

Wouldn't that explanation predict that lower ranking employees would be more impressed with AI than higher ranking ones? Because what we actually observe [0] tends to be the opposite. Executives are the most bullish on AI, followed by Managers, with employees having the least adoption.

[0] https://businesschief.com/news/why-are-executives-using-ai-m...

> One nice thing about using React even on the web is that it forces your Backend to be REST right from the start.

The creator of HTMX would disagree with you (as the person who described and coined the term REST)

https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...

LLMs are very impressive. Five years ago, the idea that we'd have software that you could ask - in English, mind you! - to rewrite an entire server side JS runtime and you'd get something which even kind of worked was squarely in the realm of science fiction. But the question isn't "is this impressive?", but rather "should the results of such a rewrite be relied upon?" (and specific to this thread, "is the fact that a use case which only touches a small subset of the features of said result appears to no be completely broken good evidence it should be?")

> Deno for instance have ~0.2x as many unsafes.

Another point of comparison is density of unsafe: the number of unsafe blocks per line of code and/or file. By this metric, Deno has a bit over half the unsafe (because the bun rewrite is significantly more lines of code).

I think 2 is a reasonable concern (and one which has solutions in rust async/await tokio, as FridgeSeal points out). I'm not sure about 1 though. I think having a rough idea what part of your programs are computationally expensive shouldn't be to much to ask of programmers.

I didn't say they made a good, safe port. I literally said the opposite ("especially if you're flexible about actually upholding rust's rules"). You can get a line by line port to compile by just wrapping the parts that violate rust's ownership rules in `unsafe`. You won't have fixed the problem, and it won't be memory safe, but you can do it.

To be fair, you can throw an Arc<Mutex<_>> or Rc<RefCell<_>> at it if you're starting from something that has multiple "mutable borrows", but that adds runtime cost and complexity.

> Which is still a step ahead of Zig

First off, you seem to be under the impression I'm a rust hater. Noting could be further from the truth. Rust is easily my favorite language at this point, I reach for it for basically everything (except quick scripts). While I do like a lot of zig's philosophy, I think at the end of the day the empirical evidence is overwhelming that manual memory management isn't sufficient.

> What's your point, that if we can't do everything perfectly in one step we can't do it at all?

My point is exactly what I initially said: you typically aren't much closer to a (mostly) safe rust codebase if you've done a line by line port to (partially unsafe) rust than you were to start with. Getting to safe rust is very likely to require substantial refactors either way. This doesn't mean you shouldn't do it (on it's own), but it does mean that the bun team's strategy/assumptions are more questionable than they appear to realize.

You can also do one by using `unsafe` liberally, especially if you're flexible about actually upholding rust's rules (as the bun team just did). But either way, you're still stuck with a code base that's going to need extensive refactoring if you want to actually take advantage of rust.

Except that writing safe rust often requires designing the architecture around rust's ownership model, meaning a file by file, line by line translation doesn't necessarily leave you much closer to safe rust than you were at the start.

First, we're talking about a massive rewrite of complex software project which no one has fully reviewed and which the people most familiar with the code base (the bun maintainers) aren't even qualified to do so. As such, the issues people have found are mostly surface level.

But second, you're right, this is an easy thing to search for (especially with LLMs). And yet, the example I linked has been there since may, surviving multiple rounds of review. From this, we can draw a few conclusions: 1) claude (including apparently mythos/fable) fundamentally doesn't "understand" how unsafe rust works, and 2) no one on the bun team is aware that they need to tell it to fix this (if they're even aware that this isn't allowed in the first place).

The reason such trivial defects in a codebase are a red flag isn't so much those specific issues themselves, it's what they reveal about the authors. If you find a lot of obvious defects in some code, it's very likely that there are also many more subtle harder to detect issues as well.

There were/are absolutely plenty of real problems with the resulting code pointed out. Running Miri trivially found soundness issues, `SAFETY` comments that demonstrate that the model in question fundamentally doesn't understand/simulate understanding how unsafe rust works [0], etc.

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

It's funny, because editor choice is also an analogy I use, to argue for the exact opposite conclusion.

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.