You have been building for three months. The product works. Your co-founder has tested it, your friends have tested it, you have run every flow a dozen times and nothing breaks.
Then someone asks whether the code has been reviewed, and there are usually two honest reactions: assuming the AI tools handled it, or quietly adding it to the list of things to sort out after launch. Neither is quite right, and the gap between them is where most launch incidents come from.
What is code review, and how is it different from testing?
Testing verifies that the product does what you designed it to do. Someone signs up, a payment clears, a file uploads. When those pass, testing is satisfied, and testing is genuinely important.
Code review asks a different question: what happens under conditions you never designed for. What happens if someone changes a number in the address bar. What happens when two people click the same button at the same instant. What happens when your payment provider returns an error you have never seen. What happens when a thousand users arrive at once instead of ten.
Those scenarios do not show up in demos. They show up in production, usually in week one, usually at the least convenient moment.
Did the AI already handle this?
Partly. Modern AI tools are very good at producing code that works, and the product in front of you is evidence of that. They are markedly less reliable at anticipating how something fails or gets abused.
That is not a criticism of the tools so much as a description of how they were built. They learned from an enormous amount of code that demonstrates how to do something, and that kind of code routinely omits the error handling and permission checks that would clutter the example. The result is code that is often genuinely good with specific, repeatable gaps. What is vibe coding breaks down exactly which gaps and why.
What does a review actually find?
In AI-built products, the findings cluster in a small number of places. Translated out of engineering language:
| What the finding says | What it means for you |
|---|---|
| Missing authorisation check | Someone can change a number in the address bar and see another customer's data. |
| Unhandled payment webhook | A payment succeeds but your app never records it, so a paying customer looks unpaid. |
| SQL injection risk | A crafted input into a form can read or delete your database. |
| N+1 query | Works with your test data, gets slow at a few hundred users, stops responding at a few thousand. |
| Business-logic mismatch | The maths is subtly wrong, usually pricing, tax, or discounts, and every transaction is slightly off. |
None of these break the demo. All of them break something later, and the last one is particularly unpleasant because it is invisible until you reconcile revenue.
The goal is not to find every imperfection. It is to find the ones that matter before your users find them for you.
How do you review code you cannot read?
You do not read it. You use a tool that reads it and reports in language you can act on. A usable review does three things: names the problem, explains why it matters in plain English, and shows the corrected version. Your job is to decide whether it is serious enough to fix before launch.
That decision is made easy by severity grading:
- CRITICAL: exploitable right now, with no special conditions. Fix before anyone touches the product.
- HIGH: significant risk under specific circumstances. Fix this week.
- MEDIUM: limited immediate risk, real technical debt. First sprint after launch.
- LOW: best-practice issues with no security impact. Fix when convenient.
- PASS: something implemented correctly. Worth reading, because it tells you which parts you can stop worrying about.
A pre-launch sequence that fits in an afternoon
- Review every file that handles login, signup, or password reset. Authentication is where the highest-severity findings concentrate.
- Review everything touching payments, including the webhook or callback that records a successful charge.
- Review every screen that displays user data, checking that one customer cannot reach another's records.
- Write your pricing and permission rules down in one or two sentences and supply them, so the reviewer can check the logic against your actual rules rather than guessing.
- Clear every CRITICAL and HIGH. Schedule MEDIUM and LOW for the sprint after launch.
That is an afternoon, not a fortnight. And it is the difference between finding a critical vulnerability yourself and having a customer, a competitor, or a journalist find it for you.