A vibe-coded pull request needs the same review as any other change. The difference is that the code may look finished before anyone has checked whether it solves the right problem.
Start by recovering intent. Then map the change, trace important values through the repository, test the failure paths, and review security separately. Do not approve it because the demo works. Do not rewrite it only because an AI agent wrote it.
For a small change, the AI-generated code review checklist is a useful starting point. This guide is for the larger pull request that arrived polished, broad, and difficult to reason about.
The short version
Use this sequence:
- Ask the author to state the intended behavior.
- Group the changed files by what they do.
- Separate mechanical edits from behavior changes.
- Trace one important input from the boundary to its final effect.
- Read the callers, types, schemas, and rules outside the diff.
- Test the failure that would be most expensive to miss.
- Check authorization, secrets, dependencies, and data exposure separately.
- Decide which parts to keep, revise, or rewrite.
The point is to make the pull request explain itself before you spend hours reading every generated line.
1. Recover the intended behavior
Ask the author to answer these questions without reopening the agent transcript:
- What user or system behavior changes?
- Which repository components enforce that behavior?
- What assumptions did the coding agent make?
- What is still uncertain?
- Which failure would cost the most in production?
"I asked Cursor to add billing" is not enough. Neither is a transcript of twenty prompts. A reviewer needs the expected behavior, the boundaries of the change, and the evidence used to check it.
A useful statement might be:
When a workspace reaches its monthly review limit, new reviews stop before model usage begins, while existing results remain available.
That sentence gives you something to test. It also exposes questions the implementation may have skipped. Which timezone resets the limit? What happens when two reviews start together? Can an administrator override it?
If the pull request cannot answer questions like these, ask the author to complete a useful pull request description before detailed review starts.
2. Map the change before reading every line
Start with the file list. Group files by purpose:
- schema or database changes
- dependencies and generated files
- refactoring
- new business behavior
- API or interface changes
- tests and fixtures
- deployment and configuration
Mark migrations, authentication, authorization, payments, queues, external requests, and infrastructure. Then note where the change crosses a boundary.
A new form may send a field the API ignores. A migration may add a column that a background job never fills. A generated workflow may deploy an image with a different environment-variable name. These bugs are easier to see in a map than in a long diff.
3. Separate mechanical edits from behavior
Generated pull requests often mix formatting, renames, dependency changes, refactors, and new behavior in one branch. That makes every later decision harder.
Ask the author to split the pull request when the groups can be reviewed independently. A good split usually keeps:
- mechanical preparation, such as a rename or generated update
- the behavior change and its tests
- deployment, migration, or rollout work that needs its own review
Do not split by arbitrary file count. Keep code, tests, schemas, and configuration together when they describe one behavior. The guide to splitting large AI-generated pull requests covers the trade-offs.
4. Trace one value through the system
Choose the value that carries the most risk. It might be a workspace ID, user ID, price, permission, external URL, retry count, or model request.
Follow it from the input boundary to the final side effect:
- Where does it enter?
- Which type or parser validates it?
- Which functions transform it?
- Which database query or external request consumes it?
- What happens when it is missing, duplicated, stale, or owned by another tenant?
This catches errors that a happy-path demo hides. The value may change units, lose its tenant scope, use the wrong default, or reach a side effect before authorization runs.
5. Read outside the diff
The diff shows edits, not the contracts those edits must obey. Open the callers, definitions, types, schemas, neighboring routes, repository rules, and relevant tests.
Look for:
- callers that rely on the old return value
- database constraints the new code does not satisfy
- a safer pattern elsewhere in the repository
- feature flags and configuration defaults
- retries or jobs that can run the new operation twice
- documentation that states a behavior the code changed
This is where a repository-aware AI code reviewer can help with a first pass. Treat its findings as leads. It cannot recover a product decision that exists only in somebody's head.
6. Spend time on the failure path
The demo path is usually the part an agent understands best. Start with the inconvenient case instead.
Ask what happens when:
- the request is repeated
- two workers update the same record
- an external API times out after accepting the request
- the user loses permission halfway through the flow
- a migration runs before every process has been upgraded
- the input is valid but belongs to another workspace
- the model returns malformed or unsupported output
- the queue retries after a partial failure
For each case, write the expected result before reading the implementation. Otherwise the implementation will quietly define the behavior for you.
7. Review security as its own pass
Do not treat a passing test suite as a security review. Check the boundaries directly:
- authentication and authorization
- tenant or workspace ownership
- untrusted input reaching SQL, shell commands, templates, or URLs
- secrets in logs, errors, fixtures, and client bundles
- new dependencies and install scripts
- outbound requests and server-side request forgery
- retries that duplicate payments or other side effects
- generated infrastructure and workflow permissions
The security review for AI-generated code has examples and a reusable checklist.
8. Make tests challenge the implementation
Generated tests often copy the implementation's assumptions. A test that passes only proves that the code and the test agree.
For each important behavior, ask:
- What failure should this test catch?
- Would the test fail if the authorization check disappeared?
- Does it cover another tenant, an empty result, a retry, or a concurrent update?
- Does it assert an outcome or only that a helper was called?
- Can the test pass while the user-visible behavior is wrong?
Break the behavior on purpose when practical. If the test stays green, it is not protecting the behavior you thought it was. See why AI-generated tests miss bugs for more examples.
Decide what to keep, revise, or rewrite
Keep code when the intent is clear, the boundaries are correct, and the tests exercise the risky behavior.
Revise code when the design is sound but the implementation is hard to follow, the error path is incomplete, or the tests leave an important case unprotected.
Rewrite code when the pull request has no stable intent, crosses unrelated boundaries, duplicates a safer repository pattern, or makes a high-impact decision the author cannot explain.
The goal is not to punish the use of an AI agent. It is to leave the repository with code that a human can explain and maintain.
A review sequence that works
For a large pull request, use four passes:
- Read the description and file map. Decide whether the change is reviewable.
- Trace the highest-risk behavior through the repository.
- Attack failure, security, and data-boundary cases.
- Run tests and inspect the final diff for generated clutter, stale comments, and unrelated edits.
If the pull request still feels impossible to explain after the first pass, stop reviewing line by line. Ask for a smaller change or a better description.
Frequently asked questions
Should I reject code because an AI agent wrote it?
No. Review the behavior, evidence, and failure paths. AI-generated code needs verification, not a different standard of style.
Should I rewrite a large AI-generated pull request from scratch?
Only when the current structure makes the behavior unsafe or impossible to verify. First try to recover intent, split mechanical work, and isolate the risky boundary.
Is a green test suite enough?
No. Tests can repeat the implementation's assumptions and miss authorization, concurrency, data-flow, and rollout failures.
Can an AI reviewer handle the first pass?
Yes, when it has enough repository context and the team checks its findings. Use it to find leads and repeated rule violations. Keep product decisions, accepted risk, and the merge decision with people.