Real-time code review: reviewing together instead of in comments

Asynchronous pull request review is the industry default for good reasons: it respects people’s focus, it works across time zones, it produces a durable record, and it scales to teams that could never get into a room together.

It should stay the default. But a minority of changes are far cheaper to review with both people present, and the tell is easy to recognise once you know it — a review thread twelve comments deep that should have been a ten-minute conversation.

What asynchronous review is bad at

Questions with branching answers. A reviewer asks why the cache is keyed this way. The author explains. That answer raises a second question. Each round trip costs hours of wall-clock time, and there may be five of them. The same exchange spoken aloud takes four minutes.

Disagreements about approach. Written disagreement between people who cannot hear each other’s tone escalates with impressive reliability. A comment meant as a neutral question reads as an accusation; the reply is defensive; the next comment is longer and more careful, which reads as colder. This is the most common source of genuine interpersonal damage in engineering teams, and it is almost entirely a property of the medium.

Large or structural changes. A 900-line diff touching fifteen files cannot be understood by reading the diff, because the diff does not show the shape of what changed — only the lines. Reviewers cope by approving it, which is the well-documented failure where review quality collapses past a few hundred lines.

Anything where the reviewer lacks context. If the reviewer has never seen this subsystem, the first forty minutes of their review is orientation they must do alone from a diff, which is the worst possible format for orientation.

When to switch to synchronous

Use these as triggers rather than judgement calls.

• The thread passes about ten comments. A hard rule works better than a feeling here, because the point at which a conversation should have moved is only obvious afterwards.
• Any comment is longer than a paragraph. Writing at length in a review box means the point is too complex for the medium.
• The disagreement is about approach, not details. Naming and style survive asynchronous review fine. Architecture does not.
• The change is large or crosses ownership boundaries.
• You notice irritation — in them or in yourself. This one overrides all the others. Nothing good follows from continuing.

Running the session

Thirty minutes, a voice call, and a shared editor with the code in it that both people can type in.

That last requirement is the one people skip, and it is what separates a real-time review from a screen-shared presentation. If the reviewer can only watch, they are reduced to dictating coordinates — “line 40, no the other one” — and most of their smaller observations go unsaid because raising them is not worth the friction. When both people can edit, a suggestion is a two-second change rather than a paragraph.

The author drives the tour, briefly. Five minutes, no more: what problem this solves, the shape of the solution, and which parts the author is least sure about. That last item is worth asking for explicitly — authors usually know exactly where the weak spots are and will not volunteer them in writing.

Then the reviewer leads. They read; the author answers questions and stays quiet otherwise. Resisting the urge to narrate is harder than it sounds and matters — a reviewer who is being talked at is not reading.

Fix small things immediately. Naming, a missing guard, an awkward conditional: change it there and then, together, and move on. These are the items that clog an asynchronous thread with disproportionate overhead, and eliminating them live is most of the speed advantage.

Do not fix big things live. Structural changes made under time pressure with someone watching are how a review session turns into an unplanned rewrite. Write them down and end the session.

Write the outcome into the pull request. Non-negotiable. A synchronous review leaves no trace, which means the decisions have no record and anyone who was not there — including both of you in six months — cannot reconstruct why the code looks like this. A short summary comment listing what was discussed, what changed, and what was deliberately left alone preserves the thing asynchronous review was good at. Skipping it is what makes people distrust synchronous review, and rightly.

The variant worth knowing: review before the code exists

The cheapest review happens before implementation. Fifteen minutes in a shared document, sketching the approach in pseudocode, function signatures and a list of the cases that have to work.

Objections at this stage cost nothing, because nothing has been built. The same objection raised on a finished pull request costs a day of rework and arrives after the author has become attached to the design — which is a real psychological effect, not a character flaw, and it is why late structural feedback is so often resisted.

For anything expected to exceed a few hundred lines, this is the highest return on time available anywhere in the review process.

Some things stay asynchronous

Do not overcorrect. Async is better for:

• Small, self-contained changes, which is most of them.
• Anything where a reviewer needs time to think properly.
• Teams spread across time zones, where scheduling costs more than the review saves.
• Reviews whose value is largely the record — security-relevant changes, anything with a compliance requirement.
• Any case where a written comment would be perfectly clear. If it fits in two sentences and has one obvious answer, write the two sentences.

The underlying point

Synchronous and asynchronous review are not competing philosophies. They are tools with different costs, and the mistake is using one exclusively.

Async is cheap per review and expensive per round trip. Sync is expensive to schedule and nearly free per exchange. So the right rule is mechanical: as soon as a review needs more than a couple of round trips, the arithmetic has flipped — and continuing to type at each other past that point is a choice to pay the higher price.

The same logic decides when a change wants a pairing session instead: if the review is going to be a conversation anyway, having it before the code is written is cheaper than having it afterwards.