A pull request landed in your queue this morning. 3,400 lines across forty files, opened at 6:12 by a teammate's coding agent. The description is tidy. The tests pass. Nobody on the team has read a line of it.
That PR is not really a request for review. It is a finished thing asking for a signature. The agent finished hours ago, your teammate has moved on to the next task, and every question you ask now costs a round trip through somebody else's context. So you skim it. Approving code you skimmed is a habit, and it is the kind that bites late.
The PR arrives too late
Code review grew up around human-sized changes. A colleague works for a day or two, opens a PR, and the PR is where the conversation starts. That timing made sense when writing was the slow part: by the time a PR existed, real thought had gone into it, and there were never very many at once.
Agents broke the timing. One person can now start five tasks before lunch and have five changesets waiting by the afternoon. Writing became cheap and parallel. Reading stayed serial and human. The PR queue is where that asymmetry piles up.
- agents writing
- 5
- reviewer reading
- 1
- lines read so far
- 0
A PR is also a commitment point. The branch is pushed, the issue is linked, the reviewers are assigned. Rejecting it feels expensive, so a large agent PR tends to get the benefit of the doubt at exactly the moment it deserves less of it.
Review the worktree, not the pull request
The fix is not reading faster. It is moving the review to where the work still lives: the agent's worktree.
While the work is a worktree, it is a changeset, the plain diff between what the agent did and the branch it started from. You can read it before the agent declares itself done. You can put a note on the exact line that is wrong, and the note becomes the agent's next prompt instead of a comment a human has to carry across. And when the direction is wrong, you throw the worktree away and start over, which costs a checkout.
None of this asks new discipline of the author, because the author is a process. An agent does not get attached to its work, does not take a rejection personally, and does not need PR ceremony to be told to try again. The ceremony was for us.
Your teammates' agents are your problem too
On a team the queue is shared whether you acknowledge it or not. Your teammate's agent is writing code that will land in the repository you maintain. If the first time you can see that code is the PR, the PR is doing two jobs at once: introducing the work and defending it.
This is the part Cohalen is built around. A teammate's workspace streams in as a read-only remote workspace: their chat, their diff, their checks, live, while the work is still a worktree. You read their changeset the same way you read your own, and the mechanical questions, does it compile, do the tests pass, is the branch behind, are already reduced to one verdict when you arrive. Nothing else in the category has a team surface at all.
Start smaller than that
You do not need a tool to move review earlier. Two habits help on their own.
Scope each agent to one task. A changeset you can hold in your head comes from a prompt that asked for one thing, and this is the cheapest lever on review time anyone has found. Then state the acceptance criteria in the prompt, what to build and what to test, so the checks answer the mechanical question before you open the diff.
The agents will not slow down for your queue. Either the review moves earlier, or the unread code moves to production.