OpenClaw is reportedly sitting on north of 2,500 open pull requests. That's the number to hold in your head for the rest of this.
Not a backlog. An accumulating failure state.
Armin Ronacher has the cleanest analogy for what that feels like: a Starbucks overwhelmed by mobile orders. No clear line, no reliable wait estimate, no real cancellation path unless you escalate and make noise.
That is what a lot of "AI-first" engineering teams now feel like from the inside. You can't triage, you can't review, and many of the PRs can't be merged after a point because they've drifted too far out of date — and the person who opened them has lost the will to see it through.
The tempting read is that this is a tooling problem. It isn't. It's queueing theory.
Code generation went to near-zero. Review didn't. Input started growing faster than throughput, and when that happens, a bigger bathtub does not fix overflow. It just gives you a larger volume of water to drown in.
Ronacher's line is exact: "if input grows faster than throughput, you have an accumulating failure." At that point backpressure and load shedding are the only things that keep a system operable.
So of course everyone is reaching for the same fix, and it's the same shape every time: a bot that reads every PR, scores its risk, auto-approves the safe ones, and escalates the rest to a human.
According to Claire Vo, she built Merge Mommy in a single Codex session — a Vercel Eve agent that scores each PR across six risk dimensions (blast radius, reversibility, data security, ops impact, verification gap, change surface), auto-approves the low-risk ones, and pings her in Slack for the rest. She says it cleared her backlog.
Mews reportedly built the same shape and called it Moxly. Built on Claude Code, it inspects every PR and applies one of four labels: low, medium, high, critical — an estimate of blast radius, explicitly aimed at incident prevention, not style.
By the end of their pilot, Moxly had reportedly labeled north of 97% of their PRs, and per Mews, nobody manually overrode a label the entire time.
Here's where it gets interesting, and where most of the coverage stops reading too early.
Mews' own postmortem is blunt about what the bot accomplished on its own: nothing.
Their words: "The bot on its own would not have changed anything. We already had AI review running before Moxly; what AI review couldn't do was change human reviewer behavior."
Read that twice. They already had an AI reviewer commenting on every PR. Adding a better, risk-scoring AI reviewer did not move the bottleneck.
What moved it was a sentence in a policy doc: "what actually changed behavior was the explicit policy update giving reviewers permission to do less when the bot said it was safe to do less."
What actually changed behavior was the explicit policy update giving reviewers permission to do less when the bot said it was safe to do less.
That's the whole product. Not the model. The permission.
On PRs Moxly labeled low-risk, a human reviewer is now explicitly allowed to skip the line-by-line read and review the change at a higher level: does the framing make sense, is the approach reasonable, does the shape fit. On anything medium or above, the old line-by-line norm stands.
Nothing about that requires machine learning. It requires an org willing to say, in writing, that a class of changes no longer needs a human to read every line.
That is a hard thing for engineering organizations to say out loud, because of what a review signature has quietly meant for the last decade.
Mews names it precisely. A review approval was never only about catching bugs. It was ownership diffusion: "I read this, I understood it, and I accept some share of responsibility for what it does."
That signature was the load-bearing wall of collective ownership. It's how team codebases stayed legible and how accountability got distributed across the people who maintained them.
So when you tell a reviewer they can approve a low-risk PR without reading it, you're not just saving them thirty minutes. You're changing what their signature attests to.
The signature used to mean "a human read this." Now, on the low-risk lane, it means "a human agreed with the bot's assessment that this didn't need reading." Those are not the same claim, and pretending they are is where the risk lives.
This is the real design work, and it has almost nothing to do with which review bot you pick. The bot is trivial — Vo built hers in one prompt with a few steering turns. The org policy change is the entire game.
The questions that actually matter are governance questions. Who is permitted to approve? What does an approval now certify? When a merge goes wrong and nobody read it, who is accountable — the author, the approver who trusted the label, or the team that wrote the policy that said trusting the label was fine?
Ronacher gestures at the same fracture from the open-source side. In the old textile factories, the individual weaver stopped carrying responsibility for a bad piece of cloth. A defect became the factory's problem, and the cloth was just replaced. He worries we're moving the whole layer of responsibility elsewhere — into "single-use plastic software."
That's the uncomfortable end state his essay lands on. If machines write the code and machines do the most capable first-pass review, then what reaches a human "would already have passed the most critical possible review of the most capable machine." Support tickets go straight to machines to implement, for other machines to review, "for humans to rubber stamp in the morning."
Rubber-stamping used to be the failure mode you were trying to prevent. In this design, it's the intended workflow.
And here is the failure that makes the whole thing bite — and it's a policy failure, not a model failure.
Per the account, a 1,400-line PR, generated mostly by Cursor over a two-day stretch by a competent mid-level engineer. Tests passed. Linter happy. The PR-bot left two minor nits and an approval.
It merged clean. And it introduced a second pattern for handling timezone-aware datetimes that contradicted one established eighteen months earlier in a different module.
The author didn't notice because the AI didn't notice. And the AI didn't notice for a reason no amount of model quality fixes: "the contradicting module was not in the context window."
That cost a two-day rewrite nobody had budgeted. But notice the shape of it: this is exactly the class of change a risk-scoring bot would happily wave through. Low blast radius on the surface. Clean tests. Two nits. It looks safe by every dimension the bot measures.
The thing that would have caught it was a senior reviewer holding eighteen months of system context the bot structurally cannot hold. And that is precisely the reviewer your new policy just told to stop reading low-risk diffs.
I'll leave the verification-infrastructure fix to the correctness people. The point here is narrower, and it's about who's on the hook. When that bug ships, the policy has to have an answer for accountability, and "the bot approved it" is not an answer a customer or a regulator will accept.
So the compounding blind spot is real, but blaming the model misreads it. The bot did its job — it scored what it could see. The org made the decision to route a whole class of changes past human eyes. If nobody is accountable for a merge nobody read, that's not a limitation of the AI. That's a hole in the permission structure.
Which reframes the question every team adopting this is actually answering, whether they've written it down or not.
The winning teams aren't the ones with the best review bot. Everyone can build the bot in an afternoon. The winning teams are the ones who did the harder thing: rewrote the permission structure deliberately, decided in writing what a signature now means, and named who owns a merge when the signature no longer means "a human read this."
Mews figured this out by accident and had the honesty to say so — the policy line moved behavior, the bot didn't. That's the lesson hiding in plain sight in their postmortem.
The bottleneck was never really the queue. It was the belief that every change needs a human to read it, colliding with a volume of code no human review culture was designed for.
You can keep that belief and throttle the input, the way Ronacher describes some projects auto-closing PRs and taking OSS vacations. Or you can give it up and route the risk.
Either way, the decision is an org design decision. The bot is a rounding error. The question that keeps you up at night is not "is the code correct." It's "who is accountable for a merge nobody actually read."
Answer that one, in writing, before you ship the bot. Not after.