The reviewer is not in the IDE
The author is in Cursor, Claude Code, Codex, or Grok Build. The reviewer is not. They are on a phone in an Uber, on another laptop in a standup, or half-listening in a meeting with one free hand. They should not clone the repo, install the agent, or watch a screenshare just to leave a comment on a plan that is still changing.
That split is the product. I keep saying it because teams keep papering over it with process. "Just hop on a call." "Just clone and open the file." "Just join my agent session for a second." Each of those pulls the reviewer toward the author's chair. The useful direction is the opposite: pull the plan into a surface the reviewer already has.
Two jobs, two chairs
If you are the author, your job is to keep the file on disk and keep watch running. If you are the reviewer, your job is to read and comment. The agent session is not a requirement for either side of that split.
I learned this the hard way when I tried to "just share my screen" for a twenty-minute plan review. Calendar tax. Bad audio. I kept scrolling past the section they cared about. They could not leave a durable note on a line. When we hung up, half the feedback lived in my head and half lived in a Slack thread about a screenshot. The agent never heard any of it until I pasted a summary into the prompt an hour later. That is not review. That is telephone.
The page they open should be the live document, not a screenshot and not a gist. If the agent rewrites a section, the open tab updates. Inline threads stay on the lines they were left on, even when the surrounding markdown moves. That is the difference between reviewing a file and reviewing a photograph of a file.
You can feel the chair mismatch in smaller moments too. Someone asks for a "quick look" at a cutover plan. You are mid-session. They are walking between buildings. The only way you know how to share is to pull them into your world: your editor, your clone, your agent UI. They say they will look later. Later never arrives with the same cheap rewrite window. The plan hardens. The agent starts executing. The second opinion shows up as archaeology.
What people do when the reviewer is elsewhere
Screenshare or pair in your IDE. High bandwidth once. Fine for "talk me through this paragraph." Bad for "leave three comments while I keep working." No line-anchored threads the agent can pick up later. The reviewer still needs access to your machine or your calendar.
"Just clone the repo." Full context, and friction. The still-moving local file is not on their machine. The agent session stays with you. If review requires a repo clone, you already lost the wedge. You also invent a sync problem: their checkout is not your live plan.md. I have watched people lose twenty minutes to "I pulled, which branch is the plan on?" while the agent kept rewriting the author's disk.
Invite them into the agent session. Same context as you. They need agent access and ceremony. Sometimes that is the right call. Often it is overkill for "does step four make sense?" Browser-only review is not "everyone drives the model."
Slack paste. Interrupts now. Freezes a snapshot. You lose the live file. The teammate comments on yesterday's plan while the agent rewrites today's.
Early PR for a comment UI. Familiar. Also commits the plan so someone can use GitHub comments. Wrong timeline if the file is not commit-ready. That trap is its own post. The reviewer cut is simpler: they should not need your IDE even before git exists.
Each path filters who can participate. Requiring your IDE, your clone, or your agent seat is not a process preference. It is a quieter way of deciding fewer people look, later, with more friction, after the cheap moment has passed.
Browser plus link
gander watch plan.md
Hosted watch gives you a short URL. Every save updates the hosted page. Your reviewer opens it. Docs-style inline threads. No install for them. No IDE, no repo, no agent account. You keep the session. They keep a browser.
When they mean action, they start a comment with @agent. That lands in your session via MCP. The agent edits the local file. The same link updates. Notice what the reviewer does not get. They do not get your agent seat. They do not get write access to your disk. They get a live view and threads. Action still runs through the author's session on purpose. Browser-only review is not "everyone edits the same shared doc." It is "everyone can read and comment while the file still lives where the agent can change it."
Local gander plan.md --watch is a different command. Local preview. No share URL. No comments. Useful when you are alone with the buffer. Useless when the reviewer is on a phone. Say the full phrase out loud if it helps: hosted gander watch for someone else, local --watch for yourself.
Install MCP once so the session hears the summons (gander mcp install), or fall back to gander comments. Human-only threads stay human. That split matters as much as the browser itself. Most comments are conversation. A few are instructions. The reviewer should be able to leave both without borrowing your chair.
Why the browser is not a preference
IDE review sounds reasonable until you count the cost. Clone. Open. Find the file. Hope it matches what the agent just saved. Ask for a screenshare when it does not.
Phone review sounds unserious until you need a second opinion in a hallway between meetings. A link works. A clone does not.
Async review sounds like a process document until you notice that most "quick looks" are async by default. The reviewer is not free the moment the plan lands. The live page waits. The Slack paste ages.
The browser is the lowest common surface that still supports line-anchored threads on a moving file. That is why the product bet sits there, not in "better screenshare" or "invite them into Cursor."
I used to treat browser review as a compromise for people who could not "really" join. That was backwards. The people who cannot join are often the ones whose judgment you need most: the on-call who owns the service, the lead between rooms, the teammate who already lived through the last migration. Designing for their chair is not lowering the bar. It is removing a tax that had nothing to do with the quality of the review.
A concrete afternoon
Picture this. Your agent finishes a first pass of plan.md at 3:40. Your lead is in back-to-back meetings until 5. You have two choices that feel productive and are not.
Choice one: wait. You stare at the plan alone. You tweak wording. The agent offers to "just start on step one." You let it. By 5 the lead opens a PR you opened out of habit and comments on a world that already moved.
Choice two: send the live link at 3:41. They open it on a phone between rooms. They leave two comments: one human thread about naming, one @agent on the rollback section. You keep working. The agent rewrites the rollback. The same tab they reopen at 5 still has their threads. Nobody cloned anything. Nobody sat in your IDE. Nobody invented a commit so GitHub would show a diff.
That afternoon is the whole argument. The reviewer is not in the IDE. Design for the chair they are actually in.
When the plan is finally commit-ready, open the PR. GitHub review is the right tool then. We do not replace it. We sit in the gap before the file should be in git at all, and before the reviewer should need your whole setup to leave a note. Before git, not instead of git. Browser first, because that is where the second human actually is.
Who gets a say
When review only works if the reviewer borrows the author's whole setup, you have already decided the answer. Fewer people look. They look later. They look with more friction. The cheap moment (plan still soft, rewrite still free) is gone.
Think about the last three people who should have looked at a plan. How many of them had your IDE open, your repo cloned, and time to join your agent session? If the answer is "one, maybe," your review process already filtered the other two out. Not because they lack judgment. Because the surface demanded your chair.
Send the link. Keep the session. Let the teammate use the browser they already have. The plan stays on your machine. The review does not have to. The reviewer is not in the IDE. Stop designing the loop as if they were.