# Reviewing the whole thing before you call it done

Course: Claude Code from Zero — https://zero2vibecode.com/learn/claude-code
Canonical URL: https://zero2vibecode.com/learn/claude-code/4-3-final-review

You reviewed every turn. Now review the thing they add up to — as a whole, as a stranger, with fresh eyes on the parts nobody has looked at twice.

Every turn was reviewed. That still leaves a gap, because nobody has looked at what the turns add up to.

## Read it as a stranger

Open the project as if you have never seen it. Read the files top to bottom, in the order a new person would.

You are looking for the seams:

- Two functions doing nearly the same thing, built in different turns.
- Code that is no longer reachable, left from an approach you abandoned.
- The same idea named three different ways.
- A comment describing behaviour that changed two turns later.

None of these break anything today. All of them are why a project becomes unpleasant to return to.

## Run it like a stranger too

Not the happy path you have typed forty times. The ugly ones:

- Empty input. No input at all.
- Absurdly large input.
- The wrong kind of input entirely.
- Two clicks in fast succession.
- Reload the page halfway through.

**Errors are part of the product.** 
When something goes wrong, does the person see a helpful sentence, or nothing at all? "Nothing happens" is the single most common failure in agent-built projects, because nobody ever tested the sad path.

## Ask the agent to review, then check it

This is a genuinely good use of a fresh session:

> Read this project and list problems: duplicated logic, unreachable code, unhandled failures, anything hardcoded that should not be. Do not change anything.

You will get a list. Some items will be real and you would not have spotted them. Some will be style opinions. At least one will be wrong.

Take the list. Do not take the verdict. Verify each item yourself, then decide which ones matter for a project of this size — and remember that "the agent said it was fine" is not a review, it is the same system marking its own homework.

**Ask a second time, differently.** 
Two review passes in separate sessions, with differently worded requests, find noticeably different things. It is cheap, and it works because each session goes looking with a different starting assumption.

## The checks you do yourself

**Secrets.** Search the project for keys, tokens, passwords, personal paths. Look in the files you never open — configuration, examples, comments. If a real key ever reached a commit, deleting it later does not undo that: rotate it.

**Dependencies.** Is there anything in your dependency list you do not recognise? Ask what it is for and whether it is really needed.

**The README.** Does it still describe what the thing does? Can someone else run it from the instructions, on a machine that is not yours?

**Your one sentence.** Does the project do the thing you set out to build? Not more, not less.

**Good enough is a real standard.** 
This is a small project, not a bank. It does not need perfect test coverage or a threat model. It needs to work, fail politely, keep no secrets in public, and be understandable to you in three months.

<Faq>
  
  
</Faq>

## Try it yourself

A finished project, a review list, and one item on that list you cannot undo.