What does code review mean when nobody reads the diff?

Cursor is building Origin, a git forge for the agentic era. The pitch is throughput. Twenty-two commits a second into a single repo. Hundreds of thousands of clones an hour. A hosting layer built on the assumption that thousands of agents, not people, are the ones writing the code.

It is an impressive answer to a real bottleneck. But it answers the wrong one.

The bottleneck was never writing code. It was trusting it. Git was built for humans committing a few times a day, and review sat naturally in that gap: someone read the change before it landed. Speed the commits up to machine rate and the gap does not disappear. It just stops being somewhere a human can stand.

So the review does not go away. It gets delegated. One engineer approves dozens of agent changes in bulk, or hands the review to another agent. And here is the question the throughput numbers skip: when review is delegated to an agent, what has actually been reviewed?

If the answer is that a check ran and a box went green, that is not review. That is a receipt. A forge that records a review happened is not the same as a forge where the review changed what shipped. The first is documentation. The second is governance. The gap between them is where the trouble lives, and agent-scale commit rates do not close that gap. They widen it, twenty-two times a second.

Origin is a genuinely serious piece of infrastructure. But owning the forge does not answer who attests that a change was substantively reviewed, on what basis, by what independent of the thing that wrote it. Build the fastest software factory in the world and you still have to answer that. Faster just means you answer it sooner, or you find out you never did.

The industry is racing to industrialise how agents write and merge code. The question worth asking is whether it is industrialising the review, or just the record of it.