The premise of vibe coding cuts against its own review step

Vibe coding, as Andrej Karpathy named it in early 2025, is the practice of describing what you want in plain English and accepting the output without reading much of it. The pitch is openly aimed at people who do not write code: kids, founders without a technical co-founder, product managers between roles, anyone with an idea and no willingness to learn TypeScript first. That is the user. That is the person the product surface is designed to delight.

Now look at the standard advice for shipping AI-generated code. Read the diff. Run the tests. Audit before you commit. Werner Vogels has been writing all year about verification debt. The Sonar 2026 State of Code survey put a number on it. Every responsible post on the topic ends with some version of: trust but verify, and verify means read.

Both halves are coherent on their own. Together they describe a workflow whose generation step and review step are aimed at different people. The generation step works for anybody with a sentence. The review step works for somebody who can read a unified diff. If the person at the keyboard is the first kind, the review step quietly becomes a no-op.

Faster does not fix it

The default reflex is to make review cheaper: better diff UI, smaller changes, inline annotations, AI-generated review comments on AI-generated code. All of those help if the reviewer can read. If the reviewer cannot read, they help nothing. A non-coder looking at an annotated diff is a non-coder looking at an annotated diff. The mismatch survives every speed improvement, because the bottleneck is not how long review takes. It is what review is.

That is why this is a skill bottleneck, not a workflow bottleneck. You cannot scale around it from the generation side. You have to move the review surface to something the reviewer can actually parse.

The move: review what the user already wrote

The thing a non-coder can read is the sentence they just typed. They wrote it. They understand it. They can compare it against the screen in front of them. That comparison is a real review unit. It catches a large fraction of bad turns: the AI did the wrong thing, the AI did part of the right thing, the AI did nothing visible at all.

In mk0r the implementation of this is mechanical, not aspirational. Every successful agent turn ends with one git commit inside the sandbox. The commit message is the first line of your prompt, trimmed and sliced to 120 characters. Here is the relevant code, lifted verbatim from src/app/api/chat/route.ts:

const msg = (typeof prompt === "string" ? prompt : "")
  .split("\n")[0]
  .trim()
  .slice(0, 120) || "Agent turn";
const sha = await commitTurn(sessionKey, msg);
if (sha) send({ type: "version", sha, message: msg });

That message: msg is what later renders in the Version History panel. Each prior turn shows up as a small card, and the card's primary content is the prompt itself (src/components/version-history.tsx line 119):

<div className="text-sm text-zinc-700 truncate">
  {e.message || "(no message)"}
</div>

The Revert button right next to it calls /api/chat/revert, which checks out the target tree as a new commit (revertToSha at src/core/e2b.ts line 1951). The reviewer never reads code. They read their own English, look at the preview, hit Revert if the two do not agree. That is the whole loop.

The agent picks up the part the reviewer can't

There is a class of review work that even a careful non-coder cannot do from the preview alone: did the page actually load, did the console throw, did the imports resolve. That work is mechanical and legible to the agent. So it lives there.

The agent boots inside the VM with a CLAUDE.md that hardcodes a five-step browser check it must complete before reporting any UI change as done (src/core/vm-claude-md.ts lines 273-283):

Line five is the one that matters. It moves the cheap, mechanical part of review (did it render, did it throw) out of human review time and into agent generation time. What is left for the human is the part that always needed a human anyway: does this match what I actually wanted. That part the non-coder can do.

What this honestly does not solve

The structural workaround buys you the prototype layer. It does not buy you the production layer. Three places where it goes thin, in decreasing order of how often they bite:

• Off-screen logic. A scheduled worker, an API endpoint with no caller yet, a piece of state that never renders. The browser check sees a green page; the broken behavior lives elsewhere. There is no escape from reading that diff if you want to be sure.
• Coarse turns. The unit is one turn, not one change. If a single prompt produced five logically distinct edits, you cannot bisect inside the turn. You can revert the whole thing or accept the whole thing.
• Quietly bad data. The screen renders. The numbers underneath are wrong. The form validates and stores the wrong field. No amount of preview-watching catches this. Eventually you owe somebody who can read code a real pass.

That is the boundary. Inside it, a non-coder gets a real review loop for the first time. Outside it, the original bottleneck is still waiting.

One thing to take away

When the next vibe coding tool you try shows you a session-wide diff and asks if it looks good, notice that you have just been handed a review unit you cannot read. The fix is not to learn to read it. The fix is to insist on a review surface that maps to what you actually know: the sentence you wrote, the screen in front of you, a one-click way back if those two disagree. Anything past that line is real engineering, and it still costs real review skill. Pretending otherwise is how prototypes ship with credentials in localStorage.