Reviewing Agent Code on Cursor Origin

When an agent writes the change, the writing stops being the hard part. Reading it becomes the job. That is a different skill from authoring: you are reconstructing intent from a diff, checking it against what you actually asked for, and deciding whether you trust it enough to merge.

The trap is volume. Agents produce changes faster than you can carefully read them, and the temptation is to approve on vibes. The whole point of a review layer built for agents is to keep human attention on the changes that need it and take the rest off your plate.

Where you start reading matters more than how carefully you read. Open the request first, whatever you actually asked for, and then go looking in the diff for the parts that answer it. Reading in file order does the opposite. You reconstruct the agent's reasoning from its own output, nodding along because each step follows from the one above it, and you never check the whole against what you wanted.

The cost of getting that backwards is a missed omission more often than a missed bug. A diff shows what changed, and the thing agent work gets wrong, in my experience, is what it quietly left out: the migration with no backfill, the new conditional branch with no error path. Read the request for anything in it you cannot find anywhere in the diff.

Tests, file list, description, in that order, before you read a line of logic.

Start with the tests, less for their content than for how they relate to the code file. Tests added alongside new behaviour is the ordinary case. When the tests were edited so the new behaviour passes, that needs a reason, and the reason should be in the change description or you should go and ask for it.

Then the file list. Scope creep shows up there before it shows up in the logic, and a change scoped to one endpoint that also touched the shared config is worth a question before you read a word of it.

The last check tends to be the one that gets skipped: read the change description against your original request rather than against the diff. When a person writes both, they agree by construction. When the description is generated from the diff, it summarises what the change did, which is no evidence that what it did was what you asked for.

You don't have to wait for Origin to put review automation in front of agent output. These ship now and work on GitHub and GitLab.

Graphite, the team behind Origin, also ships an AI reviewer (Diamond) and a stack-aware merge queue. Those are Graphite products today, and they hint at the shape of Origin's review layer, but they are not the same thing as Origin.

Which of the three you adopt first matters less than people assume, with one exception. The in-editor pass is the cheap one, because it happens while the change is still local and unpushed, so if you only put one thing in place, put that one. Catching a wrong approach in the editor costs you a follow-up prompt; catching the same thing on a pull request costs a review cycle and a rebase.

Coverage of the Compile demo described a review experience aimed at agent work specifically, including from your phone. The pieces below are the ones reported. Cursor's cloud agents do already have web and mobile control, so the direction is real even where the Origin specifics aren't confirmed.

• Reviewing agent-generated diffs and leaving inline comments, as you would on a pull request.
• Looking at screenshots of an agent's visual output, useful when the change is UI.
• Starting, unblocking and redirecting agent tasks remotely, including agents running on your local machine.

The mobile piece is the one I keep changing my mind about. Taken as a convenience it is minor, since nobody is going to judge a large refactor on a phone screen. Taken as a statement about who is holding up the merge, it is the most revealing item in the reported set, so that is the reading worth planning around. It assumes the agent has already finished and the change is waiting on a person who is away from their desk.

Two things stay with a person: deciding whether the change matches the intent, and owning the result after it lands. The pipeline below automates everything around those two, and the gates show where each automated pass fits.

Where that deliberate human step sits is the part of the diagram worth arguing with. Putting it at the merge assumes review attention is scarcer than merge capacity, which holds for most teams and not for all of them. If your test suite is slow and every landing already waits on it, a human pause at the merge mostly reshuffles a queue you already had, and reading earlier in the editor buys more.

Team size changes the shape of this too. On a small team the reviewer is often the person who wrote the prompt, so the intent check collapses into self-review, and it is weak in a specific way, because you remember what you meant rather than what you typed. On a larger team the reviewer did not write the prompt, so the request has to travel with the change. Paste the ask into the description yourself before anyone else opens it.