I have read comments about this on X, here, and other places, yet I have ever seen there be proof this is an actual productivity boost.
I use Claude Opus (4.5, 4.6) all the time and catch it making making subtle mistakes, all the time.
Are you really being more productive (let’s say 3x times more), or just feel that way because you are constantly prompting Claude?
Maybe I’m wrong, but I don’t buy it.
I've had some good initial results in going from typst to .tex with Claude (Opus 4.5) for an IEEE journal paper - idiomatic use of templates etc.
the issue is that 4.8 is optimizing for visible epistemic caution, not just task completion. that is useful when the user needs uncertainty surfaced, but annoying when the output contract is already strict. the best model for serious work is not always the smartest one. it is the one that follows the operating mode without turning the work into a commentary track.
https://next-episode.net
It's a (now more than 20 years old) TV tracking website and community.
I've been using Claude 4.5 Opus (now 4.6) more and more these days modernizing and redesigning sections that haven't been touched for a decade or two. I don't trust LLMs much, but by breaking the work into small, self-contained tasks and testing constantly - I'm making surprisingly fast progress.
It used the best tests it could find for existing compilers. This is effectively steering Claude to a well-defined solution.
Hard to find fully specified problems like this in the wild.
I think this is more a testament to small, well-written tests than it is agent teams. I imagine you could do the same thing with any frontier model and a single agent in a linear flow.
I don’t know why people use parallel agents and increase accidental complexity. Isn’t one agent fast enough? Why lose accuracy over +- one week to write a compiler?
> Write extremely high-quality tests
> Claude will work autonomously to solve whatever problem I give it. So it’s important that the task verifier is nearly perfect, otherwise Claude will solve the wrong problem. Improving the testing harness required finding high-quality compiler test suites, writing verifiers and build scripts for open-source software packages, and watching for mistakes Claude was making, then designing new tests as I identified those failure modes.
> For example, near the end of the project, Claude started to frequently break existing functionality each time it implemented a new feature. To address this, I built a continuous integration pipeline and implemented stricter enforcement that allowed Claude to better test its work so that new commits can’t break existing code.