MobSessiondocs

Review at write-time

Steer the agent live as code is written, attribute every contribution, and keep pull-request review as the final gate.

Write-time review means your team steers the agent while the code is being written, instead of correcting a finished diff later. Reviewers watch the agent's edits and tool calls live and redirect it with prompts the moment a wrong turn starts.

The usual flow is the opposite: someone opens a pull request, reviewers read a done diff, and the wrong approach surfaces days later. By then the agent has built on the mistake and fixing it is expensive.

Direct, do not just review

After-the-fact review is correction: the work exists, and your job is to find what is wrong with it. Write-time direction shapes the work while it is still cheap to change.

This matters more with an agent, which moves fast and commits to an approach early. See only the result and you inherit every decision it made along the way. Watch the run and you can stop a wrong turn at the first tool call and clear up a vague requirement before it hardens into code.

The shift is from "review the diff" to "direct the run."

How it works in MobSession

A MobSession session is a shared, live view of the agent. Everyone sees the same thing at the same time:

  • Live edits and tool calls. Every file read, command, and edit streams to the whole team in real time.
  • In-the-moment prompts. Anyone can send a prompt to redirect the agent: tighten a requirement, reject an approach, ask for a different design.
  • One queue, one run at a time. Prompts queue and run in order, so two reviewers never talk over each other. See /docs/prompt-queue.
  • Attribution. Every contribution is recorded against the person who made it.

A typical session:

  1. Start a session and share it with the people who should weigh in.
  2. Kick off the agent with the task.
  3. Watch the edits and tool calls stream.
  4. Queue a prompt to redirect when you spot a wrong turn.
  5. Keep steering until the change matches what the team intended.

Everyone watches the same run, so you decide once, together, instead of relitigating in a pull request later.

Who should be in the room

You do not need the whole team. Bring the people whose judgment changes the outcome: the owner of the area you are changing, anyone holding context the agent lacks, and the reviewers who would otherwise block the pull request. Their input front-loads, so the final diff holds fewer surprises.

It complements pull-request review

Write-time review does not replace your pull request. It makes it better. When reviewers have already steered the work, the final diff shows up with its biggest questions answered: the approach is agreed on, the dead ends were never committed, and the people who care have already seen the reasoning.

Pull-request review then does what it does best: a final, durable gate. It is the record of approval, the place for one careful last pass, and the checkpoint your branch protection and CI depend on. Direct at write-time to shape the work, review at merge-time to confirm and record it.

Coming soon

We are extending write-time review beyond the live session: saved session history to revisit how a change was steered, review analytics, accounts for managing who joins, and audit logs. These are in early access and rolling out to teams.

Next steps