Reading AI code before merging: the unit of merge is the bug

Yes, but be honest about what 'merging' means in your setup. If your AI coding loop produces a single PR that bundles 8 to 15 prompts worth of changes, you are not going to read it. Nobody reads a 1,400-line AI-generated diff line by line, and the tests passing tells you the obvious bugs are gone, not the subtle ones. The actionable answer is structural: shrink the merge unit so the read fits in 30 seconds. The pattern that works is one prompt produces one commit, one diff, and you decide to keep that single diff or undo it before issuing the next prompt. mk0r is built around this shape (commitTurn at src/core/e2b.ts line 1759, runs after every successful turn), but you can recreate it in Cursor or Claude Code by committing after every accepted change and using git reset HARD to revert turns you do not like.

The handler in src/app/api/chat/route.ts line 1008 reads `const msg = prompt.split("\n")[0].trim().slice(0, 120) || "Agent turn"`. Then it calls commitTurn(sessionKey, msg). commitTurn runs a six-step script inside the VM: cd /app, git add -A, git diff --cached --quiet (short-circuit to NOCHANGE if nothing staged), git commit -q -m '<msg>', git rev-parse HEAD. The whole tree is committed every turn. The commit message is the first line of your prompt. So `git log --oneline` reads like the chat panel, in chronological order, with real diffs attached.

Line 1772 of src/core/e2b.ts handles this: `if git diff --cached --quiet; then echo NOCHANGE; exit 0; fi`. The script echoes NOCHANGE and exits zero. commitTurn returns null. No commit lands. The history stack does not grow. So chatty turns where the agent only fetched something or thought out loud do not pollute the log. Every entry in `git log` corresponds to an actual change, which is exactly what you want a review surface to be.

Yes. /api/chat/cancel posts to the in-VM ACP cancel endpoint. The agent stops. commitTurn short-circuits because git diff --cached --quiet passes (nothing was staged). No commit lands. You stay on the same active SHA. This is the cheapest pre-merge gate there is: if the diff streaming into the preview looks wrong, cancel before the turn lands. Zero commits, zero pollution, full reset of the current prompt. The undo button is for the case where the turn landed and you only realized after.

Because human attention scales with the size of the thing. A 12-line diff with a clear commit message reads in 10 seconds. A 1,400-line diff bundling 8 prompts is functionally unreadable; the reviewer either skims and approves or rage-rejects, neither of which is a real review. Every existing piece on this topic argues yes-read or no-trust-the-tests assuming a fixed chunk size. Shrinking the chunk turns the argument into a non-question. You can read a 30-second diff between prompts without it slowing the loop, and you cannot read a multi-prompt PR without breaking the loop entirely.

Click the undo button in the chat panel, or call POST /api/chat/undo. Internally, undoTurn at src/core/e2b.ts line 1855 walks activeIndex back by one in historyStack, calls revertToSha(sessionKey, prevSha, 'Undo to <sha>'), which runs `git checkout <sha> -- .` followed by `git add -A` and `git commit --allow-empty -m '...'`. You end up on a fresh commit whose tree matches the prior turn. Redo is the symmetric operation; activeIndex moves forward. The history stack never loses entries, so you can flip back and forth between turns to compare without re-prompting.

Yes, if you wire it yourself. In Claude Code or Cursor, after every accepted change run `git add -A && git commit -m "<first line of your prompt>"` (a shell alias makes this one keystroke). To undo a single turn use `git reset --hard HEAD~1`. The unit becomes the same: one prompt, one diff, one optional undo. The reason it usually does not happen is friction: nobody types the commit command after every accepted suggestion, so 6 prompts smear into one diff, and then you are back to the unreadable chunk. The mk0r approach is to remove the friction by committing automatically server-side; you can recreate it locally with a 5-line pre-tool hook or a tiny script.

The same per-turn log carries forward. There is a deeper write-up on the post-deployment review surface at /t/vibe-coding-production-review-tail. The short version: `git log --oneline` is the prompt history, `git show <sha>` is one prompt's diff, and the unit of review is the same whether you are reading before merge or auditing after. The structural fix to chunk size pays off twice.

Often no. For a weekend prototype where the failure mode is 'demo does not work' and the blast radius is your own laptop, treat the AI like a fast first draft and trust the preview. The pre-merge read earns its keep when (a) the code touches auth, payments, or user data, (b) the diff will become a load-bearing piece of something that ships, or (c) you are stuck and need to understand what the agent actually did before issuing the next prompt. For everything else, the preview is the read. mk0r leans into this with a live mobile preview iframe that updates as the agent writes, so the visual is the dominant signal and the source is there for when you need it.