When Claude Cowork finishes a task, do not merge on vibes. Read the plan it followed, read the diff it produced, run the result, and check the edges. Then decide: merge it, send it back with notes, or take over the last mile yourself.
Autonomous work is fast, and that speed is exactly why review matters. The agent can touch ten files in a minute. Your job shifts from writing the code to deciding whether the code is correct and safe to ship. This guide gives you a checklist you can run every time, so review becomes a habit instead of a gut call.
Why is reviewing AI-generated code the real skill now?
In a live chat you watch each step and can interrupt. Cowork runs in the background and hands you a finished changeset. By the time you see it, the decisions are already made. That is the trade: you gave up moment-to-moment control in exchange for getting your time back. Review is where you reclaim the control that matters, the final yes or no.
A good review answers three questions in order. Did the agent solve the right problem? Is the solution correct? Is it safe to merge into a shared branch? If any answer is no, you do not merge. You send it back or finish it yourself.
Read the plan before the code
A strong Cowork run produces a plan: the steps it intended to take and why. Read this first, before a single line of the diff. The plan tells you what the agent thought it was doing, and the most expensive failures are not bad code, they are correct code solving the wrong problem.Common gotchaDo not start with the diff because it loads fastest and looks like the real work. A clean diff with green tests will sail through your read and still be wrong-problem code, since neither the diff nor the tests know your intent.Read the plan against your brief first, and only open the diff once the scope matches.
Compare the plan against your brief. If you asked it to add rate limiting to the login route and the plan describes rewriting the whole auth module, stop there. The diff might be flawless and still wrong, because the scope drifted. Catching that at the plan stage saves you reading hundreds of lines that should not exist.
If you are not getting a clear plan out of your runs, that is a briefing problem. See briefing Claude Cowork for how to ask for a plan up front and constrain the scope.
Read the diff like a reviewer, not an author
Once the plan checks out, read the diff. The discipline here is to read it as if a stranger wrote it, because effectively one did. Do not assume good intent fills the gaps.
Look at the diff as a whole first, then file by file. The fastest way to see exactly what changed is the same command you would run on any branch:
# See which files changed and the size of each change
git diff --stat main
# Read the full diff against the base branch
git diff main
# Review one file at a time when the change is large
git diff main -- src/auth/session.tsRead every file the agent touched, including ones you did not expect. An unexpected file in the diff is a signal, not noise. It usually means the scope grew or the agent took a shortcut you would not have taken.
As you read, ask:
- Does each change map to the goal? If a hunk does not serve the stated problem, question it.
- Did it touch files outside the agreed scope? Config, build files, and unrelated modules are the usual surprises.
- Did it delete anything? Removed code is the easiest thing to miss in a diff and the most likely to cause a regression.Common gotchaReviewers skim the green added lines and skip the red deleted ones, so a quietly dropped guard clause or null check slides through.Read the deletions as carefully as the additions, and ask why each removed line was safe to remove.
- Are there new dependencies? A new package in your manifest is a security and maintenance decision, not a detail.
Claude Code itself can give you a first pass here. Its desktop app shows local changes in a diff view, and the review action examines the diff and leaves inline comments on likely bugs and risky patterns before anything leaves your machine. Treat that as a helpful second reader, not a substitute for your own read. The agent reviewing its own work catches obvious issues; it does not catch wrong-problem issues, because it does not know your intent the way you do.
Should I run the code before I trust it?
A diff that reads well can still be broken. Reading code proves the shape of the change. Running it proves the behaviour. Do both, in that order.
Run the tests first, then run the thing itself:
# Run the test suite the project already has
npm test
# Start the app and exercise the change by hand
npm run devIf the change has a user-facing effect, click through it. If it is an API change, call the endpoint. If it is a script, run the script on real input. The point is to observe the actual behaviour, not to read a claim that it works.
Watch for the gap between "tests pass" and "the feature works." Cowork can write tests that pass and still miss the real requirement, especially if the tests only check the happy path it implemented. Passing tests are necessary, not sufficient.
What edge cases should I check in AI-generated code?
Autonomous agents are good at the main case and uneven at the edges. The main case is what the brief described, so it gets the attention. The edges are where shipped bugs live. Go looking for them on purpose.
| Edge to check | What to look for |
|---|---|
| Empty input | Does it handle an empty list, blank string, or missing field without crashing? |
| Invalid input | Does it reject bad data clearly, or pass it downstream silently? |
| Errors and failures | Are errors caught and surfaced, or swallowed so failures look like success? |
| Boundaries | Off-by-one limits, the first and last item, a value at exactly the threshold. |
| Concurrency and state | Does running it twice do the right thing, or duplicate work? |
| Security | New input that reaches a query, a file path, or a shell. Any secret in the diff. |
You do not need to test all of these every time. Pick the ones that match the change. A pure formatting change has few edges; a new endpoint that takes user input has many. Spend your review budget where the risk is.
Should I merge, send back, or take over the change?
Once you have read the plan, read the diff, run it, and checked the edges, you make one of three calls. Naming them explicitly keeps you from defaulting to "merge because it is probably fine."
Merge when the plan matched the goal, the diff is clean, it runs, and the edges hold. This should be the common case for well-briefed tasks.
Send back when the problem is upstream of the code: wrong scope, a misunderstood goal, or a design that needs rethinking. Do not hand-fix a wrong-problem result, because you will be polishing something that should not exist. Sharpen the brief and re-run. A send-back is a briefing fix, not a failure.
Take over when the approach is right but the finish is off: a missed edge case, a test gap, a small correctness bug. When the gap is small, finishing it yourself is faster than a full re-run. Use your judgement on the line between a quick fix and a re-run; if you find yourself rewriting more than you keep, send it back instead.
Send-back notes that fix the problem
A vague send-back ("this is wrong, try again") gets you another wrong result. Treat the send-back like a fresh brief that names the specific failure, so the next run does not repeat it.
The pattern that works: state what you wanted, state what it did, then give tighter constraints for the retry. The contrast between the two is what stops the agent repeating the mistake.
How do I review a Cowork branch without blocking my own work?
If you review a Cowork change on the same checkout you work in, you are stuck waiting while it runs, and a half-merged change can pollute your working tree. A git worktree gives you a separate folder for the agent's branch, so you can keep working in your main checkout and review the result in isolation.
# Create a separate folder checked out to the agent's branch
git worktree add ../review-cowork cowork/rate-limit
# Or create a brand-new branch and folder in one step
git worktree add -b review/rate-limit ../review-cowork main
# See all the worktrees you have open
git worktree list
# Remove the review folder when you are done
git worktree remove ../review-coworkInside ../review-cowork you can run the tests and the app against the agent's branch without disturbing your own work. When you are satisfied, merge from there or push and open a pull request. When you are done, remove the worktree to keep things tidy. The same isolation trick is covered in depth in keep parallel agents from clobbering each other with git worktrees.
Let the PR carry the safety checks
For shared work, do not merge a Cowork branch straight into the main branch from your machine. Open a pull request and let your existing checks run. The PR is where review becomes auditable: the diff is recorded, CI runs, and a teammate can weigh in.
# Push the reviewed branch and open a pull request
git push -u origin review/rate-limit
gh pr create --fill
# Watch the checks until they finish
gh pr checks --watch
# Merge only after checks pass
gh pr merge --squashClaude Code can monitor this for you. After a PR is open, it tracks the PR status, including CI check passes and failures, using the GitHub CLI under the hood. Optional automation can attempt to fix CI failures and merge once all checks pass. Useful, but the same rule holds: automation handles the mechanics, you own the decision. Turn on auto-merge only for changes you would have approved by hand anyway.
If your repo is not connected to GitHub yet, connect Claude to GitHub first so PR status and checks are visible in one place.
A review checklist you can reuse
Keep this short list next to you for every Cowork result. Five minutes here saves an afternoon of debugging a bad merge.
- Read the plan. Does it match the brief and the right problem?
- Read the full diff. Does every change serve the goal?
- Check for surprises: extra files, deletions, new dependencies.
- Run the tests. Do they pass and do they cover the real requirement?
- Run the thing. Does the behaviour match what you wanted?
- Probe the edges that matter for this change.
- Decide on purpose: merge, send back, or take over.
- For shared work, merge through a PR with checks, not straight to main.
The habit that makes Cowork safe
The reason autonomous work is worth it is that the upfront brief and the after-the-fact review are both cheap compared to writing the code yourself. The brief is covered in briefing Claude Cowork. The review is this guide. Run both every time and the loop is trustworthy: you describe the outcome, the agent builds it, and you verify it before it ships.
Skip the review and you are not saving time, you are deferring it to a future debugging session at a worse moment. Read the plan, read the diff, run it, check the edges, then decide. That sequence is the whole job now, and it is a fast one once it is a habit.