Once code review can run in the background, a habit forms: launch it, and don't sit idle while it works. It takes a few minutes anyway, so fix something else in the meantime.
One question. What if that "something else" is the file currently under review?
The reviewer told me first
On 2026-08-25, working on Plotta, that is exactly what I did. I launched the review agent and kept polishing the same files while waiting. The returned review contained an explicit note: the files changed during the review.
Two of its findings were already fixed. I had fixed them in the meantime.
That creates the real problem. The remaining findings refer to which version of the code? Presumably the code as read at that moment — and that code is no longer on disk. Writing up the results, I had to separately record which state each finding applied to. Footnotes on a review, as extra work.
Why this is worse than simple waste
Three things stack up.
The reference point disappears. A review is a judgment about a snapshot. Without the snapshot, it's ambiguous where the judgment applies.
You create a revert risk. If you "apply" a finding that you already fixed differently, you can walk better code back to what the reviewer saw. This is the quietest failure of the three — in a diff it looks like ordinary work.
The reviewer's work is discarded too. Everything spent reading and analyzing code you had already replaced is waste.
What would you do here?
Say the review takes five minutes. Two options:
- Refuse to lose those five minutes and keep editing the same files.
- Freeze the tree and spend five minutes on work outside the review's scope.
Option 1 buys five minutes and then pays a reconciliation cost. For me the reconciliation cost was larger than five minutes.
The procedure I settled on
Commit before launching the review. The subject becomes an unambiguous snapshot, and findings land cleanly on top of that commit.
Don't touch the files under review until results arrive. That's the whole rule.
Spend the wait on work outside the review's scope. There is always plenty:
- writing release notes
- checking store review status
- preparing build artifacts
- tidying notes and documentation
All of it makes real progress without touching a file the reviewer is reading.
If applying the review changes code, discard builds made before it. This one is easy to miss. If you archived and uploaded in the same session, you have to rebuild and re-upload after applying the review — with a fresh build number on iOS. Otherwise the binary sitting in review is pre-review code.
Three things to check
- If a background review is running right now, can you name the files it reads?
- Was
git statusclean immediately before you launched it? If not, the results describe some uncommitted state. - After applying a review, is there still an earlier build uploaded somewhere?
The honest part
The rule is genuinely constraining. The reason to run a review in the background is parallelism, and "don't touch those files" cuts into it.
But it cuts less than it seems. It's rare that editing the reviewed files is the only work available in a session. Release prep, status checks, and documentation are always backed up. You don't lose parallelism — you lose parallelism on the same file.
I've hit the same family of failure in another shape: when several sessions share one working tree, files I never touched ride along in my commit. When the shared resource is the tree, the question always comes back to who saw what, and when.
Do one thing next time: commit before launching the review, then don't open those files until the result lands. A review result that needs no footnotes reads very differently.