OpenClaw's review bar moved from the diff to the agent transcript behind it

Review capacity is the fixed input in this system. A human reviewer holds a few dozen diffs in a day, and that ceiling does not move when the other end of the pipe acquires an agent. Nine months, more than 80,000 commits, about 274 days: call it 290 commits a day ^[15]. Nobody reads 290 of anything a day.

So a signal died. Contribution count used to be a cheap proxy for whether a submitter had skin in the project. Josh Lehman describes contributors sitting on hundreds of open pull requests each, mining the repository for things to fix ^[6]. Peter Steinberger's name for the output is "prompt requests" ^[7]. Once a script can file a hundred before lunch, volume ranks nothing, and the maintainers said as much ^[11].

The substitution has conditions. Steinberger's case for the transcript is that it shows how the contributor arrived at the change, and that a screenshot proves they actually ran it ^[12]. That moves the review target from the artefact to the method that produced it, which is a real gain when the artefact is plausible-looking code from a model you cannot interview. Two things have to hold for it to pay. The transcript has to be cheaper to read than re-deriving the change yourself, which fails on any large diff. And the reviewer has to be willing to reject on process grounds alone, with no bug to point at. Worth noting what the interview does not claim: this evidence is described as valuable, not as verified ^[11][12], and nothing in it says a transcript gets checked against the diff.

The reason trust is the sharp question here rather than an abstract one is where the code lands. OpenClaw is a personal assistant that runs on the user's own device and connects to the messaging channels they already use ^[3]. A bad merge does not sit on a server the maintainers can roll back. It ships to machines, with local privileges, next to the user's messages. The same conversation covered software supply chain risk and the balance between agent capability and security ^[4]; from the maintainer's chair those are one problem seen from two ends.

They did not answer the flood by closing the gate. Imperfect submissions get mined for the promising idea, and maintainers refine, rewrite, or finish the work themselves ^[9]. According to Vincent Koc, a good proportion of merged first-time pull requests came from non-developers who used an agent to produce them ^[10]. That raises reviewer effort per merge at exactly the moment reviewer effort is the binding constraint. It is a defensible trade if the marginal idea is worth more than the marginal hour, and it only scales one way, by adding people who can review, which is presumably why the project has no single route into maintainership ^[13].

One ratio is worth watching: 81,000 forks against 388,000 stars, one fork for every 4.8 stars ^[16]. Forks are where submissions originate, so that number is partly a measure of inbound volume rather than admiration. Whatever the trust policy ends up saying, it has to be executable by the people on the bench, and bench size is the only term in this equation the project controls.