We spend a few thousand dollars a month in AI code review costs.
Compare that to the cost of human code review which can take up a third of an engineer’s time. You’re looking at $50-100K a year per engineer fully loaded in code review costs.
If AI assists in code review (not even replaces – we still do human review ourselves), you could spend thousands a month per engineer and still come out ahead.
Ironic that this comment talks about cost without weighing the numbers.
It’s gotten pretty good too. My employer has a team that wrote their own code review bot with the checks and values we care about and it has gotten quite good over the last six months.
People will just use the best tool for the job, putting aside some time it takes for practices to propagate.
Native date pickers suck, are ugly, and have no customizability, and look inconsistent between user agents. They don’t even really conform to the OS either (other than iOS). Everyone uses JS. Chrome’s native date picker shipped with a monospaced input font, for crying out loud.
Position sticky is amazing and the behavior is better than what JS can give you. A lot of people use it. Not much UI to make consistent between user agents.
Make the platform actually good and consistent and people will use it. Native APIs are always the better choice if they accomplish your need.
This is great. People always talk about how important the harness is and yet we have so few harness benchmarks. Agree with sibling commenter that ‘harness x model’ is needed.
People always talk about how Cursor harness has some secret sauce; would like to see how that one stacks up.
Thanks! V1.1 is set to add more harnesses and evaluate a broader range of models. We're moving to a full harness × model matrix to uncover interaction effects and release a complete harness-model compatibility map.
I am looking forward to your findings on home-field advantage. It's natural that Claude Code will work better with Anthropic models. If we know by how much, it will inform many of us.
I’m not sure if the underlying data is counting subscription use for Fable, which is where a lot of people are using it because token pricing is very expensive. I wouldn’t be surprised if this was counting enterprise token usage only. As rich as enterprise customers are, they’re not exactly willing to double the cost of SWE salaries on tokens.
Either way, a model used to solve the top 10% of problems that people use AI to solve for, being used 10% of the time … seems like it’s in a decent place.
I find Fable indispensable, and measurably better than alternative models, for complex feature development in an existing codebase. It’s the closest thing I’ve seen to nearly one-shotting features. Even still, I only use it for the hardest features and Opus 5 does a good enough job on the rest.
Very much agree on Fable. Over the past month or so it has shown to be the only Anthropic model that can understand a largish dbt model codebase. Opus 5 gets almost everything wrong. (High reasoning on both)
More importantly other way cheaper models can do what Opus 5 does. So you can pay for Claude to use Fable 5 exclusively for harder stuff and planning, then get the same value you'd otherwise get from switching back to Opus by using other cheap LLMs for day-to-day coding tasks.
Yeah as soon as CFOs realized AI was racing to become one of the most expensive line items along with salaries and AWS bills, they started cracking down on the most expensive ones.
I’ve never had an agent fail to write the actual implementation. Has it done so badly, yes, but not nothing but tests. This sounds to me like a rare case that doesn’t generalize.
If the general idea is that these agents write too many tests, sure I guess? ‘Too many tests’ doesn’t sound like a failure case of engineering to me; typically software has had too few tests. Also, a lot of the power of these agents is their ability to self-verify and correct, which the test loop is a part of.
Nobody is making you pay this supposed tax. Just tell it not to write tests.
Y'all need to try PR review tools that split PRs into chapters. Stage was the best product in this space, but Linear Review has it, Graphite has it, and some other tools too. You get the full contexts while each piece is still reviewable individually.
For me absolutely not. Fable 5 has been a step function change in the ability to hand off stuff to Claude. Opus 4.5 was itself a step function but I was still steering that significantly. Fable is one-shotting stuff that took multiple redirections in 4.5.
From my view Fable has been pure marketing bullshit, my workflows peaked at 4.6, Fable is neither smarter, its language is more annoying and it breaks stuff more easily.
I'm with you 4.6 is still King for me although all models require careful attention to ensure they maintain taste. If you don't know enough about what you're doing to keep the code clean yourself they will all add complexity and drift with time until you get to a point that you must rely on the model to fix it because you no longer understand it. That's a situation I hope to never find myself in.
Exactly, the most important part is to still engineer the schematics 100%, diagram whats going on and steer it towards these set-in-stone standards and patterns, otherwise you'll have no idea whats going on fast.
I good exercise for me is to constantly look at the folder structure and skim the code, i don't have to approve every line, but the primitives, the datastructures and other skeleton should be human readable, hand writable in an easy maintainable way following existing standards / libs. etc - so you can continue if suddenly all AI disappeared.
This is phenomenal. I know everyone is asking for their pet feature in this thread, but I would really like to see this in split keyboard format. They are much more comfortable to use since they put your wrist in a more natural position. And there are hardly any good split mechanical wireless keyboards – and certainly none this thin.
Great work on this and congratulations on the launch!
And to be specific, the METR study was using the Cursor harness with Claude Sonnet 3.5/3.7, along with other models of that era of the participant’s choosing.
Which is ancient at this point, and half a year older than the November 2025 inflection point when agentic coding got really good.
The original article is from August 2025, and the overall message to not trust ‘how it feels’ and rather measure outcomes seems right to me despite the outdated figures. On my team at least, we are seeing a noticeable inflection in work shipped with AI according to Weave.
From the article, the 30,000 changes a month are in the monorepo, and Claude Code is in a separate repo. So it’s not the TUI that has 1,000 PRs a day.
I could easily see 1,000 PRs a day on the backend. Big tech was doing more than that pre-AI.