I asked a simple question on Reddit: who is actually reviewing the code their vibe-coding tools write?
The post only received five points, but it generated 57 comments. That mismatch was more useful than a large score. It exposed a behaviour I had underestimated.
As an engineer, I instinctively read the diff. I look at the route, the data shape, the auth boundary and the failure path. Many people building with AI do not work that way. They look at the output: the page appears, the button works and the happy path completes.
That is not a moral failure. It is the promise the tools sold them.
It does mean “review the code” cannot be the only safety advice we give.
Code review is valuable, but it is not a universal interface
Traditional code review assumes the reviewer can recognise risky patterns in the implementation.
They might notice:
- a public route that should require a session;
- a database query returning fields the browser does not need;
- a secret placed in a client-side environment variable;
- an expensive endpoint with no rate limit;
- an error handler that logs personal information;
- a package added for a job the platform already handles.
An experienced engineer should still inspect those things. AI does not make code review obsolete.
But telling a founder who cannot read TypeScript to “check the diff carefully” is not a release process. It is an aspiration.
The release process has to work from evidence they can understand.
Use three review layers
A useful model separates repository health, live behaviour and sensitive boundaries.
Layer 1: make the repository prove it is internally consistent
Run the checks the project already defines: lint, type-check, tests, dependency audit and a production build.
These are not interchangeable. TypeScript can catch an invalid data shape that lint will never see. A production build can find a server/client mistake that development mode tolerated. A dependency audit can identify a known vulnerable package even when the app appears to work.
Our pre-launch command guide explains what each check proves and what it does not.
Ask the agent to explain failures before fixing them:
“Run the repository's launch checks. For each failure, explain the root cause and risk. Propose the smallest safe fix. Do not disable rules or remove tests to make the command pass.”
Layer 2: inspect what the public internet receives
A clean repository does not prove the deployed site is safe, fast or understandable.
Production configuration can change headers. A social preview can point at the wrong image. A cookie tool can fire after the build. A large image can be introduced by content. An API can return a different shape behind the deployed environment.
This layer should check the real URL on desktop and mobile, including:
- navigation and core actions;
- security headers and exposed public data;
- page weight and loading behaviour;
- form labels, focus and error states;
- titles, canonicals, structured data and social cards;
- privacy, pricing and trust consistency;
- console and network failures.
This is the layer PageLens AI is designed to make visible.
Layer 3: give sensitive boundaries deliberate human attention
Some areas deserve more than a generic agent review:
- authentication and account recovery;
- payments and entitlements;
- admin routes;
- uploads and user-generated content;
- personal or regulated data;
- destructive account actions;
- anything that can spend money per request.
For these boundaries, write down the intended behaviour first. Then review both code and live evidence against that contract.
An agent can help enumerate cases, but the team should own the decision about who is allowed to do what.
Review the agent's assumptions, not only its syntax
AI-generated code often fails while looking plausible.
The route exists, but the middleware pattern does not match it. The form submits, but the error message never reaches a screen reader. The query is valid, but it makes five round trips where one would do. The API hides the token, but the server logs it. The code catches an exception, but converts every failure into a success response.
These are confidence failures. The output looks finished, so the builder stops asking questions.
Use a separate adversarial pass:
“Review the last change as if it was written by another team. Find three ways it could be subtly wrong, insecure, inaccessible, slow or expensive even though the happy path works. Show evidence for each concern.”
The separate pass matters because the agent that produced a solution is naturally anchored to its own assumptions.
Give non-coders a fixable queue
A scanner can make this problem worse by dumping technical vocabulary on the user.
The useful output answers four questions:
- What happened?
- Why does it matter?
- Where is the evidence?
- What is the smallest safe next step?
That is why a PageLens finding includes a category, severity, affected page and repair context. The Markdown export lets a coding agent work from the same evidence the founder can see.
The founder does not have to pretend to be a senior engineer. They do need a way to verify that a change improved the live product rather than merely moving the warning.
So, who should review the code?
If you can read the code, review it. If you have a team, use another human for high-risk boundaries. If you cannot read it, do not let that become a reason to ship blind.
Make the repository pass its checks. Test the live URL independently. Treat auth, payments, admin access and personal data as deliberate boundaries. Re-scan after meaningful fixes.
The goal is not to turn every AI builder into a security engineer.
It is to make sure “I did not read the code” does not also mean “nobody checked the release.”
Run a free Ship Check against the live URL before launch.
— Richard