Vibe coding review: how to check code nobody read while it was written

Vibe-coded code arrives at review having never been read by a human, including the person who opened the pull request. So the review is the first read the code has ever had, and the numbers say it needs to be a careful one: in "Is Vibe Coding Safe?" (arXiv 2512.03262), 61 percent of SWE-Agent's solutions with Claude 4 Sonnet were functionally correct while 10.5 percent were secure. Correctness and security come apart, and passing tests tells you about the first one only.

What vibe coding actually means

Andrej Karpathy coined the phrase on 2 February 2025 in a post on X: a kind of coding where you give in to the vibes, embrace exponentials, and forget that the code even exists. It was a throwaway line about a real change in how people work. Nineteen months later it describes a large share of what lands in pull requests.

For a reviewer, the defining property is that nobody looked. The author described an outcome, watched the thing run, and shipped. Every assumption the model made about your codebase went unexamined, because examining them was the step that got skipped.

Why a first read needs a different order

Normal review has an author who can answer questions. You leave a comment asking why the retry lives in the handler, and a person who remembers deciding that replies. With a vibe-coded change there is often nobody to ask. The author can tell you what they wanted. They cannot tell you why the code does what it does, because they were not there for that part.

That gap shows in the data. The paper "These Aren't the Reviews You're Looking For" (arXiv 2605.02273) studied 33,596 agent-authored pull requests and found 61.38 percent had no recorded human review at all. Of the review comments that did exist on those pull requests, 71.58 percent came from other agents.

So the review has to be self-sufficient. You need to be able to work out what the change did from the change itself, without a conversation.

Start from the shape of the change

Open a picture of the change before you open a file. What you want in the first thirty seconds is the answer to four questions: which parts of the system are new, which existing parts were modified, what was removed, and which boundaries the change crosses.

The hero render above is a checkout change: five lanes across web, API, workers, data and external services, twenty-one components in all. New capture and retry workers in green. Changed checkout and refund routes in amber. An old v1 charge endpoint and its capture cron struck through in red. Reading that takes a few seconds and it gives you the frame that every file you open afterwards fits into.

Without the frame, a first read on a change that size goes badly in a predictable way. You open the biggest file, follow a call into a second file, find a helper you have not seen, go looking for it, and twenty minutes later you have read a lot and understood the third of the change that happened to be reachable from where you started.

I draw this locally when the pull request does not carry one: npx @coldtea/pr-lens-cli analyze --base origin/main then render, and the SVGs open in any browser. If the change came out of a coding agent session, the agent that wrote it can draw it, with the PR Lens skill installed by npx skills add coldteadotai/pr-lens, and it costs the agent almost nothing because the whole change is still in its context.

Ask what disappeared

The single most useful question on a vibe-coded change is what the model removed or replaced. An agent asked to add a feature will frequently retire something on the way, and deletions are the part of a diff that reviewers skim hardest.

Five components moved in that render, and the interesting one is struck through. Signup no longer sends the welcome email inline. If anything else in the system called that mailer, it is now calling something that has moved, and the diff will not volunteer this because the caller has no changed lines.

On the checkout render at the top, the same question has a sharper edge. A retired POST /charge (v1) endpoint means something out there might still be posting to it.

Trace one path all the way through

After the shape, pick one path and read it properly. GitHub's review checklist allocates minutes five to eight for exactly this, tracing one critical path end to end and checking boundaries and permissions along the way.

Choose the path by risk. Money, authentication, personal data, anything that writes to a shared store. Then read every line on it, including the parts the pull request did not change, because the bug in vibe-coded work is usually at the seam between what the model wrote and what was already there.

This is where the second lens earns its place. Architecture answers what the change touches. Data flow answers in what order things happen, which is the question you need answered before you can trace anything.

Do not accept the tests as evidence on their own

A vibe-coded change usually comes with tests, and the tests usually pass, and neither fact means much. The agent wrote the tests after the code, from the same understanding that produced the code. If it misunderstood the requirement, it misunderstood it consistently in both files.

The check that works is the one GitHub puts at minute nine: require evidence that the new test fails against the old behaviour. Check out the base commit, run the new test, watch it fail. If it passes, the test proves nothing about the change. This takes a minute and it catches an embarrassing number of confident, green, useless test suites.

A drawn review does nothing for this, and I would not want anyone to read this post and conclude that a picture replaces a finder. As of September 2026, Copilot code review, Greptile, Bugbot and Claude Code Review all read the change looking for defects, and on vibe-coded work they earn their keep. Run one of them and read the diagram. They answer different questions and they sit in the same pull request without arguing.

Also read the CI diff before anything else. If the change touches .github/workflows, a coverage threshold, or a test config, read those lines first. The red flags post covers what to look for there in more detail.

The routine, in order

1. Look at the diagram. Name what is new, what changed, what is gone.
2. Read the CI and config diffs.
3. Ask what disappeared, and who used to call it.
4. Trace the highest-risk path line by line.
5. Run the new tests against the old code.
6. Skim the remainder for anything that contradicts the picture.

Six steps, and the first one takes thirty seconds and decides how the other five are spent.

None of this makes vibe-coded code safe. It makes the review honest about what it is: a first read, done by someone who was not there, on code that has never had a human's attention. For the general method behind it, the pillar for this cluster is reviewing AI-generated pull requests. For the case where the codebase itself is unfamiliar to you as well, how to review a pull request you didn't write picks up from here.