This is a strong article with a distracting headline. Challenge for commenters: can you discuss the content without getting caught up in the headline?

My favorite paragraph:

> The fact that AI wrote 1M LOC and then refined it over the course of the next couple of months to produce a reliable piece of software that is currently running on millions of developer machines is absolutely mind blowing. And you can say, “well it’s not that impressive because they had an oracle to compare against, so it was simple to go from one language to another”, but I think that’s selling this entire thing short. If you can build a verification system and give proper direction, AI can produce a highly complex, highly sophisticated piece of software and it can continue to refine it until it just works.

For me, this captures what's special about the Claude Fable 5 and GPT-5.6 Sol class of models. 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.

Reducing problems to that state and designing that environment remains a skill, and one that I expect we will be paid handsomely for.

Simon - I hope this is not a rude question, but do you work with other engineers?

To me it’s a purpose fit solution that does actually show what LLMs are capable of. Just in the best case, with the most well defined constraints one will be able to work with.

It proves that with a sufficient spec, it can do a lot of work. The spec is always the problem though - to make the spec correct enough, one has to go thru the same process as coding it. Will LLMs surface the right tradeoffs, let alone make them? Working w frontier models all day, I can say resoundingly no, and not for a long while I think. Always looking for examples of things going well though if folks have some to share.

> Reducing problems to that state and designing that environment remains a skill, and one that I expect we will be paid handsomely for.

This seems to be what AI these days seems almost super humanly good at. See coding or math I guess.

But it does beg the question, why would a programmer using AI as a tool be worse than a programmer building the harness and environment and asking AI to go hogwild? The latter is definitely faster but if it's the former, atleast I will have an understanding how the system works. Weather that is valuable is an open question as far as I am concerned

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

This is a terrible, shallow article, that is about what you'd come to expect.

> If you can build a verification system and give proper direction,

That's called programming. The Bun tests and oracle are the result of years of programming. If you have to spend years programming an oracle before, programming is not ended. This is not just the headline claim. They are also making the claim in the article. `What I mean by this is that I think the act of writing code manually and having other humans review it to create useful, working software is headed for extinction.`

I'd also note the $165,000 figure is cited for the 11 day sprint, but this has only been released months later with both employees and agents hammering away at it. The true cost of this rewrite is likely in the millions.

There's also the quality angle. It's taken as a given that because Claude Code is using it in production, it must be quality software. This couldn't be further from the truth. Claude Code is absolute dogshit software that nobody in their right mind would even consider using if Claude didn't gatekeep their subscription subsidy token rates behind it. It is the absolute worst of any possible harness that anybody uses seriously.

Don't get me wrong, this is impressive in some degree. It is a genuine feat of software engineering to have written a class of programs that can generate other programs of this scale. I use LLMs daily for various classes of tasks because they are helpful tools. But the claims of its relevance and impact are wildly, wildly overstated. Note also the exponential growth in Github commits, and yet there is not a single piece of non-LLM related, LLM-generated software that I use, or existing software that I have felt has improved as a result of adopting full LLM-based workflows. There is no massively popular new software that regular end consumers are using, just a bunch of .md file wrappers for certain types of developers to obsess over while failing to provide value to non-developers. To the contrary, software in general appears to be degrading even more rapidly than it already was, with major Windows issues, Github issues, outrageous security breaches [as a result of woefully incompetent security practices rather than amazingly competent offensive practices], etc. becoming more and more common.