AI-generated code review: what engineers must check before production

Why AI code fails differently

Human mistakes tend to look like mistakes: a messy function, a TODO, an odd name. AI mistakes look like finished work. The code is tidy, commented and plausible, and that makes reviewers relax exactly where they shouldn't.

These are the common failure patterns:

• Locally right, globally wrong. Each function does what the prompt asked, but the system as a whole has three ways of checking permissions and two ways of formatting money.
• The happy path only. The code handles the case the prompt described and quietly ignores the rest: empty lists, timeouts, a webhook arriving twice.
• Outdated or invented APIs. Models mix library versions, call methods that were removed, and sometimes suggest packages that don't exist. An attacker can register such a name and wait for someone to install it.
• Tests that test nothing. Generated tests can end up checking that a mock returns what the mock was told to return. Coverage looks high, and nothing is actually verified.
• Insecure defaults copied from examples: open CORS, debug flags, verbose errors, secrets in config files.

This is not a verdict on AI code as a whole. It means the review has to be aimed at these specific places.

The checklist

Group the review by risk, not by file. These are the areas that should never get only a light pass when users or money are involved.

1. Access and permissions

• Every endpoint checks not only that the user is signed in, but that the object belongs to them. Change the ID in a URL or request: do you see someone else's order?
• Roles are enforced on the server, not only hidden in the interface.
• Admin actions are logged with who did what and when.
• Tokens expire, sessions end on sign-out, password reset links work once.

2. Money and state

• Amounts are stored in minor units or exact decimals, never floating point.
• Payment webhooks are verified by signature and processed idempotently: the same event twice must not pay out twice.
• Operations that change several records run in a transaction or can be safely retried.
• Two users acting on the same thing at once can't both win: the last item in stock, the same deal, the same seat.
• Time zones and dates are explicit, especially for deadlines and billing periods.

3. Input, files and external calls

• All input is validated on the server, including what "can't happen" because the form doesn't allow it.
• Database queries are parameterised; no string-built queries.
• File uploads check type and size and are stored outside the public web root.
• Any feature that fetches a URL supplied by a user can't be pointed at internal services.
• Rate limits exist on sign-in, one-time codes and anything expensive.

4. Dependencies

• Every package exists, is maintained and is the one intended, not a similarly named lookalike.
• Versions are pinned and a lockfile is committed.
• Licences are compatible with how you will use the product.
• Nothing is pulled in for one helper function that the standard library already covers.

5. Integrations

• The code was tested against the real API or its sandbox, not only against the documentation the model remembered.
• Timeouts, retries with backoff and a clear failure state exist for every external call.
• Keys live in environment configuration, not in the repository.

6. Errors, logs and monitoring

• Errors are caught where something can be done about them, and not silently swallowed.
• Logs help diagnose a problem without containing passwords, card data or unnecessary personal data.
• Someone gets alerted when something important fails.

7. Performance

• No query inside a loop over a list (the "N+1" problem).
• Lists are paginated; nothing loads a whole table to show twenty rows.
• Indexes exist for the queries the product actually runs.

8. Tests that mean something

• Tests assert behaviour a user cares about, including failure paths.
• At least the critical flows (sign-up, payment, the main transaction) have end-to-end tests.
• Tests were not generated from the same misunderstanding as the code. If the prompt was wrong, both will agree with each other and both will be wrong.

9. Consistency

• One way of doing each common thing: one permission check, one money format, one error shape.
• Dead code and abandoned experiments are removed.
• Names and structure match the rest of the codebase, so the next engineer can find things.

For security in more depth, the OWASP Application Security Verification Standard is a solid, free reference that a review can be measured against.

How to organise the review

A checklist only works inside a process that makes it cheap to apply. Five habits make it work:

1. Small changes. A change of a few hundred lines can be reviewed properly; one of five thousand gets skimmed. Ask the model for small steps, not a whole feature at once.
2. A human author for every change. The engineer who prompted the code owns it, can explain every line and answers the reviewer's questions. "The AI wrote it" is not an explanation.
3. Machines first. Type checks, linters, a dependency audit, secret scanning and automated tests run before a person looks. Reviewers spend their attention on logic, not on formatting.
4. People on the risky parts. Senior attention goes to the areas above: access, money, integrations and data. The rest gets a lighter pass.
5. A staging environment with realistic data, where QA tests the release as a user would before it goes anywhere near production.

Who checks what

Not every line needs the same attention. Splitting the work is what makes AI-assisted development both fast and safe.

How this maps to the build formats

At EVA-X this split is what separates our three formats. In AI Build, AI generates most of the code and engineering review is light, scoped to integrations and the release, which is why we recommend it for prototypes and internal tools, where a person checks the output. In AI + DEV, engineers own the architecture, the critical logic, the integrations and full QA: the rows marked "line by line" above. In DEV, senior developers write the code end to end and AI is never the final author. Our comparison of AI Build, AI + DEV and DEV covers which format fits which product.

Whichever vendor you work with, ask one question: who is the final author of each part of the code, and who reviews what? A clear answer is a good sign. "Our developers use AI" is not an answer.

What you can check without reading code

You don't need to be an engineer to catch a lot of what a weak review misses. When a module arrives for acceptance:

• Read the delivery note. It should say what was done and how to check it. If it doesn't, ask.
• Try the failure paths. Submit empty and absurd values. Double-click "Pay". Go back in the browser in the middle of checkout. Turn off the network on your phone halfway through a form.
• Swap roles. Sign in as a regular user and open a link that belongs to an admin page or to another user's record.
• Do it twice at once. Open the same record in two tabs or on two devices and change it in both.
• Check the boring parts. Password reset, email confirmation, sign-out on all devices, account deletion.

You have time for this: our contracts give you 7 days to review each module, and you either accept it or send it back with a list of fixes. Our guide to acceptance criteria goes further.

Red flags in AI-heavy delivery

• No tests, or tests that only exercise mocks.
• Huge commits with thousands of lines and a one-word message.
• Packages nobody on the team can explain.
• Demos that only ever show the happy path.
• No logs, no error tracking, no way to see what happened when something fails.
• Different patterns for the same problem in different parts of the code.

A note on ownership

Code written with AI raises a legal question that ordinary code doesn't: parts of it may not be protected by copyright at all. That doesn't stop you from owning and using the product, but it is worth seeing how your contract handles it. Under EVA-X terms, the rights pass to you once the contract is paid in full, and for AI-generated parts that aren't protected, the studio transfers whatever rights it has and makes no claims to them. More in who owns the code.

If you're planning a product with AI features or AI-assisted development, see our AI app development page, or describe your product on the estimate to see the modules, the recommended format and a price; the team reviews it with you before the contract fixes it.