Can AI review the pull request you already pushed?

Short answer: Yes, and for most teams that is the better direction to start in. Instead of asking an agent to build the change and a human to review it, a developer finishes the work in their own editor, pushes a branch, links that branch to the work item, and asks the AI to review it. In Crew Orbit this path is analyze-only by contract. The review workflow contains no step that can implement, commit, or push. It ends with a human decision: approve, ask AI to fix, or edit it yourself.

This is the shortest route into a skeptical team, because nothing they value has to be given up first.

Why "AI builds, human reviews" stalls in good teams

Almost every AI delivery platform points the arrow the same way: the agent implements, the human inspects the result. That framing sells well to leadership and dies in the engineering room, because it asks the strongest people on the team to trade the part of the job they are best at for the part they like least.

The refusal is usually rational. A senior engineer holds architectural context that has never been written down, and reviewing a large machine-written change is genuinely harder than writing a smaller one by hand. So adoption stops. And the branches those engineers push still ship with nobody senior looking closely, because the people qualified to review are the people already at capacity.

Turn the arrow around and the objection disappears. Human builds. AI reviews. The team keeps Cursor, Copilot, JetBrains AI, or a plain editor. What they gain is a second pass that never gets tired at 6pm on a Friday, plus a governance layer around work that previously had none: a visible run, recorded findings, and an explicit human gate.

What "analyze-only" has to mean before it is worth anything

"Read-only" is easy to say and easy to fake. A prompt that says please only review, do not modify files is not a control. It is a request to a system that is optimized to be helpful.

Crew Orbit treats this as a workflow property instead. Asking for a review submits the run in review mode, and the backend then forces the analyze-only path. The intent cannot quietly become a delivery run on the way through:

• The run resolves a seeded code reviewer role and a dedicated branch review workflow (or your project's frozen overrides of those templates). Never the default delivery team.
• It deliberately does not resolve the QA engineer role, even though "QA" sounds like the right fit. That role writes tests and commits them, which is exactly the behaviour a review must not have.
• The review workflow template permits no implement, commit, push, or test-writing node at all. There is no step available to misuse.

The difference matters when you have to explain the control to someone who is not going to take your word for it. "The workflow has no step that can write" is an inspectable claim. "We told the model not to" is not.

It reviews the branch you actually pushed

A review of the wrong branch is worse than no review, because it produces confident output about code nobody shipped. So the branch link is explicit rather than guessed. You can link it three ways:

• Branch name: typed directly.
• URL paste: a pull request, compare, or tree URL is parsed into a branch name plus the source link.
• Remote pick: the branch list is fetched from GitHub, GitLab, or Bitbucket using the git credential the project already has.

The diff base is the selected repository's default branch, and you can override it per work item when your team merges into something else. The worker checks out the existing remote branch and computes the merge-base diff against that base.

And when the branch is not there (renamed, force-deleted, or never actually pushed), the run fails loudly with a user-visible reason. It does not create an empty local branch and review nothing, which is the failure mode that quietly destroys trust in a review tool. Linking is deliberate too: there are no push webhooks, so a branch becomes reviewable when a human says it is.

What lands on the work item

Findings belong where the work lives, not in a log file or an object-storage artifact you have to go fetch. When the review completes, the work item moves to review, the queue row reads Waiting for you, and a decision panel appears under the title with:

• The AI findings, rendered inline, with severity when the findings markdown is structured.
• The commits the review saw, with links to them, plus a compare or pull request URL when one is available.

One honest limitation, because you would find it in the first five minutes anyway: file-level diff statistics are not populated. The change summary does not show files changed or lines added and removed, because those numbers depend on metrics the worker does not publish yet. What you get is the findings and the commit and compare links, not a diff dashboard. If a vendor's demo leans on a statistics tile, ask them what happens when it is empty.

Three honest exits

A review that ends in a paragraph of advice and no state change is a chat window with extra steps. The decision panel gives the human exactly three moves, and each one does something concrete:

• Approve & complete: the work item is done.
• Ask AI to fix: starts a normal delivery run carrying your reviewer notes as feedback. Because the source run was a review, the fix run resolves the project's default delivery team rather than the reviewer role. When it completes, the item comes back to review, so the fix is reviewed too.
• I'll edit it myself: returns the item to ready with a note. No run starts, nothing is consumed, and the developer picks it up again.

Note the shape of the middle option. It is not an auto-fix stitched into the review. It is an explicit delivery run that a human chose to start. That keeps the analyze-only guarantee intact and makes the moment you decided to let the AI write code an event with an owner.

What this path does not do

So you can plan around it rather than discover it:

• No push webhooks. Linking a branch is a manual action. Automatic linking on push is a follow-on.
• No write-back to GitHub or GitLab. Findings render on the work item, not as PR comments on the provider.
• No fused multi-repo diff view and no custom review checklists or policy packs yet.
• Reviews are not free. A branch review reserves and meters the same execution-run quota as a delivery run. There is no cheaper review SKU, and pretending otherwise would just move the surprise to your invoice.
• Permissions still apply. Linking a branch needs work-item update rights, submitting a review needs the same permission as submitting a delivery run, and the review is rejected outright unless the item has a linked remote branch and the selected repositories have git credentials.

Who should start here

Start with review-only if any of these sound like your team. Your best engineers are openly hostile to agent-written code. Review is the bottleneck rather than typing. You need an audit story for AI involvement in delivery before you need throughput. Or you want to introduce AI to a codebase where the risk of a bad merge is much larger than the value of a fast one.

There is also a practical reason to enter this way. A team that configures review-only has already done the work: repositories connected, credentials tested, roles and workflows in place, permissions decided. When they are ready to let the AI build something small, the delivery path is one CTA away on the same work item, under the same governance. Nothing has to be re-bought or re-argued.

What you should not do is treat an AI review as a replacement for a human one. It is a second pass that catches the mechanical and the overlooked before a colleague spends attention on them. The merge decision stays with a person, which is why the panel has an Approve button and not an auto-merge.

Related reading: how to review AI-generated code without a black box, where Cursor and Copilot stop helping a team, and what the Model Context Protocol changes for engineering teams.