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.
Quick check
You paste an empty list and the button does nothing at all. Is that a bug?
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.
Should I add tests before shipping a small project?
How do I know when it is done?
Try it yourself
A finished project, a review list, and one item on that list you cannot undo.