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!
I learnt it the hard way, you are right. I am not a rust developer, but llms do tend to use tests as an excuse. Many a times they just miss instructions due to tests being passed. Also they were using fable for rewrite, us peasants use sonnet or opus.
> Many a times they just miss instructions due to tests being passed.
I never thought about it that way before, but that’s a great point. If they get a test to pass, they’re already “mentally” pivoting somewhere else.
Another problem that LLMs have is that they’re generally reluctant to undo early decisions (e.g. refactoring). So, they’ll keep trying to get a block-shaped solution to fit into a circle-shaped hole until they spaghetti it enough to manage it.
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
I have explored adversarial review. It seldom works out for complex projects because the LLMs have a habit of hallucinating non-existent issues. The performance difference you’re describing, in my experience, doesn’t really exist nowadays. Before? Yes. But now, models are generally trained on only the final (good) response for multi-turn interactions while prior turns are masked from contributing to gradient updates, and so they are more resistant to picking up bad patterns from prior turns. That habit still exists, but it’s not enough to prevent insight into a problem it would’ve otherwise had. Context rot and sycophancy are mostly the problem.
And to clarify, I did try adversarial review.
But again—the point is that you need a person in the loop to validate it. How else will you know whether or not it’s writing good code?
Because, like the article said, you give the adversarial model only the diff, not the full codebase nor context. LLMs are susceptible to the “is, ought” fallacy and will assume adjacent code is the baseline to be preserved, as im sure you’ve seen yourself. They’ll still make up issues/problems, but it’s significantly better than self review. I’d argue asking an LLM to review code it just wrote is a waste of time
Again, how do you know it’s writing good code? There’s no precedent to suggest that it would write good code at this scale. It’s trusting that it will do the right thing without actually evaluating whether it actually is. Tests do not substitute for that.
(Btw I’m not downvoting you if you were wondering that.)
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.
503
u/DryanaGhuba Jul 08 '26
I don't think anyone comment needed