Reviewing Agent Code on Cursor Origin

When an agent writes the change, reading it becomes the job. That is a different skill from writing code. You reconstruct intent from a diff, check it against what you asked for, and decide whether you trust it enough to merge.

Volume is the trap. Agents produce changes faster than you can read them carefully, and the temptation is to approve on instinct. A review layer built for agents should keep your attention on the changes that need it and handle the routine checks for you.

Where you start reading matters more than how carefully you read. Reread your request first, then look in the diff for the parts that answer it. Reading in file order does the opposite. You follow the agent's reasoning through its own output, each step seems to follow from the one above it, and you never check the whole against what you wanted.

The order matters most for omissions. A diff shows what changed, so it can't show you what the agent left out, such as a migration with no backfill or a new conditional branch with no error path.

Read your request again and look for anything in it you can't find in the diff.

Check three things before you read a line of logic: the tests, the file list and the description, in that order.

Start with the tests, and look less at their content than at how they relate to the code. New tests next to new behavior are the ordinary case. Tests that were edited so the new behavior passes need a reason, and the reason belongs in the change description. If it isn't there, ask for it.

Then read the file list. Scope creep shows up there before it shows up in the logic. If a change meant for one endpoint also touched the shared config, ask about it before you read a word of the code.

Last, read the change description against your original request, not against the diff. It is the easiest check to skip. When the same person writes the code and the description, the two agree by construction. A description generated from the diff only summarizes what the change did, which is no evidence that it did what you asked.

You don't need Origin to put review automation in front of agent output. These Cursor features ship now and work with GitHub and GitLab, and BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. works on Origin too. Auto-review is on the list because its name suggests a code review, which it isn't.

Graphite, which Cursor agreed to acquire, has review products of its own: AI code review, which its site calls AI Reviews, and a merge queue that its docs call stack-aware. Those are Graphite products, not Origin features, though Origin's release notes now describe a merge queue of its own.

If you only put one of these in place, make it the local pass. Agent Review runs while the change is still on your machine and unpushed. Catching a wrong approach there costs a follow-up prompt, while catching it on a pull request costs a review cycle and a rebase.

Origin's pull requests, in early beta since August 17, 2026, cover the standard review loop. Each one has Activity, Commits, Checks and Changes tabs. You can request reviewers, comment on lines, leave reviews, and merge once reviews and checks pass. You can also ask Cursor about the code you are browsing.

The part built for agent work is Code Tours. A tour walks you through a pull request in the order that makes sense to review it, grouping related changes and explaining each group beside its code. Every pull request on Origin gets one, on its Changes tab. Coverage of the Compile demo described three more review features for agent work, and each now has a documented form:

• Reviewing agent diffs and leaving inline comments works on Origin's pull requests, and Cursor for iOS reviews and merges agents' pull requests from a phone.
• Screenshots of an agent's visual output, useful when the change is UI, can appear in a Code Tour, which may show screenshots and recordings from the cloud agent that wrote the pull request.
• Starting and redirecting agent tasks remotely is what Cursor for iOS does: it starts agents and sends follow-ups to running ones, including agents on your own computer through Remote Control.

The phone is easy to dismiss, since nobody should judge a large refactor on a small screen. Read it as a statement about who holds up the merge: the agent has finished, and the change waits on a person 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 the steps around those two, and the gates show where each automated pass fits.

Where the 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. 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. 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 becomes self-review. It is weak in a specific way: you remember what you meant rather than what you typed. On a larger team the reviewer didn't write the prompt, so the request has to travel with the change.

Paste the ask into the description yourself before anyone else opens it.