AI coding tools are very good at one thing: producing code that runs. Describe a feature, get a working version in minutes, click through it, and it looks finished.
That is the trap. "It runs" is the lowest bar code can clear. The expensive problems show up later: when someone else has to change it, when real users do things the demo never did, or when the first engineer you hire opens the repository and cannot tell why anything is the way it is.
I run Sucre Studios, a small studio that builds fixed-scope MVPs for startups. We use AI tooling throughout our work because it speeds up research, prototyping and coding. But we have one rule: nothing reaches a client as raw model output. An experienced developer reads and tests every line of AI-assisted code and takes responsibility for it.
This is the checklist I use for that review. None of it is exotic. The point is that it gets applied every time, because AI-generated code looks confident whether or not it is right.
1. Read it as if a stranger wrote it
Start with the mindset. AI output is a draft from a fast, tireless junior who has read a lot and understood your project very little. Do not skim it because it compiled. Read it the way you would read a pull request from someone whose judgement you have not yet learned to trust.
If you cannot explain what a block of code does and why it is there, it is not ready. "The model wrote it" is not an explanation, and it will not be an acceptable answer to a customer or a teammate when it breaks.
2. Check that it solves the actual problem
Models answer the question as phrased, which is not always the question you meant. Before looking at style or structure, confirm the behaviour matches the requirement:
- Does it handle the real inputs, including empty, missing, very large and malformed ones?
- Does it do anything you did not ask for? Extra features, extra endpoints and silent fallbacks are common.
- Does it quietly swallow errors so the demo always looks green?
A try/catch that returns a default value on failure is a classic. It makes the happy path look perfect and hides every real bug.
3. Treat every dependency as a decision
AI tools add packages freely. For each new dependency, ask:
- Does this package actually exist, and is it the one intended? Models sometimes invent plausible package names.
- Is it maintained, and is its licence acceptable?
- Is it needed at all, or is it three lines of code you could write yourself?
Every dependency is something you now have to update and trust. Adding one should be a conscious choice, not a side effect.
4. Security is not optional, and the model will not volunteer it
Generated code tends to be written for the demo, not the attacker. Look specifically for:
- Input handling: is user input validated and escaped before it reaches a query, a shell command, a file path or HTML?
- Authentication and authorisation: does every route check who is asking, and whether they are allowed to see that specific record? "Logged in" and "allowed" are different things.
- Secrets: no keys, tokens or passwords in the code, in example files or in commit history.
- Data exposure: do responses return more fields than the client needs?
Treat all AI-generated code as untrusted input until you have reviewed it. That is the same standard you would apply to a snippet pasted from a forum.
5. Look for duplication and drift
Models do not remember your codebase the way a teammate does. Each generation may reinvent a helper that already exists, use a different naming style, or solve the same problem in a new way. Left alone, you end up with three date-formatting functions and no clear convention.
Check new code against what is already there. Reuse the existing helper. Follow the existing structure. A codebase that looks like it was written by one team is far cheaper to change than one that looks like five tools took turns.
6. Make sure it is tested, and test the tests
If the model also wrote the tests, be suspicious. Generated tests often assert whatever the generated code already does, which proves nothing. Ask whether a test would fail if the behaviour were wrong. If you could break the feature and the tests would still pass, they are decoration.
At minimum, run the code yourself with bad input and look at what happens. Several minutes of deliberate poking finds more than a green checkmark does.
7. Check that someone else can maintain it
This is the one teams skip, and it is the one that decides what the code costs over time. Ask:
- Are names meaningful, and do comments explain why, not just what?
- Is there a short note on how to run it, configure it and deploy it?
- Could a new engineer find where a given behaviour lives without asking you?
Code that only works while its author is around is a liability. That matters even more when the "author" is a model that will not remember the project next week.
8. Slow down at the boundaries
Be most careful where the stakes are highest: payments, authentication, data migrations, anything touching personal data, and anything that is hard to undo. These are the places where "mostly right" is not good enough. Review them line by line, and have a second person look.
What this buys you
None of this means avoiding AI. It means using it for what it is good at: research, scaffolding, first drafts and repetitive work, and keeping a human accountable for what ships.
Done consistently, the review is not slow. It is a short, repeatable pass that catches the problems while they are still cheap. The speed AI gives you is real, but it only pays off if the result is something another person can read, change and trust six months from now.
If you are shipping AI-assisted code today, try the checklist on your next pull request and see what it catches. I would be curious which items turn up most often for you.
I'm Lucas Shaw, founder of Sucre Studios, where we build fixed-scope MVPs for startups with AI-accelerated, expert-reviewed development.
Top comments (0)