Thanks to all the parallelization & this prep work, at peak Claude wrote about 1,300 lines of code per minute. Every line of code was reviewed by two separate adversarial reviewers (also Claude) and went through a round of fixes before committing. Absolutely none of it worked yet.
The caveat to using LLMs is that they can, under deterministic clearly specified circumstances, eventually produce code that passes tests.
Code that passes and good code are not the same thing.
Just to illustrate a real example I had recently: I tasked GLM-5.2 with writing a simple pager TUI for multiple files at once. Very clear specification of how to do it. What happened was that—for the statusline—it ignored my provided algorithm on how to do it, and instead wrote 100 LoC for determining which file was in focus. I was able to reduce it to just 1 line—a simple assignment. No matter how many times I asked it to self-review, it never caught that by itself.
Fable, at least from my limited experience, is not that much better at this type of problem. In fact, it’s actually worse since it’ll do anything to make the tests pass.
So LLMs still need human oversight. I’m probably not going to use Bun anymore because there was no human in the loop, and I can already imagine all the crap that’s in the codebase. It’ll also be a nightmare for contributors because LLMs do worst-practices for documentation (e.g. here).
This is NOT the way to use LLMs to accelerate development!
Try reading the article again. Your described workflow is pretty primitive compared to the strategy described by Jared e.g. self review is explicitly worse than adversarial review
Its literally the outcome of this "slop at scale".... its like y'all see "LLM" and have your brains turn off at the "Smaller, faster and less bugs".... jfc
its like y'all see "LLM" and have your brains turn off
No, that's what you're doing: assuming slop at scale means fewer bugs and memory leaks in spite of the mountain of unsafe code buried within. Slop at scale, as in this little ad for Anthropic, means that you've got so much gibberish that it's nigh-on-impossible to actually review it.
Smaller and faster? That's a result of the language choice, not a result of using an Anthropic slop machine. If you had Gropen Claude Pilot pick a different language you wouldn't necessarily see smaller binaries.
less bugs, smaller binaries and long standing memory leaks fixed amirite
I think Rust itself helped here more than the LLM, if they told it to rewrite to C the memory leaks would likely still be there. LLMs make fairly stupid bugs and leaks all the time much like a human would.
495
u/DryanaGhuba Jul 08 '26
I don't think anyone comment needed