Guides · Building with AI
Guides · Building with AI
Review the code an AI wrote the way you would review a stranger's pull request: assume nothing works until you have checked it yourself. The AI is fluent and confident, and neither of those tells you the code is correct, safe, or doing the thing you actually asked for. A review here is not rereading the code to admire it. It is a short, repeatable pass over the places AI reliably gets wrong: auth, data access, error handling, and the one thing it silently skipped.
This is the review chapter of our guide to building an app with AI in 2026, for the point where the code exists and someone has to decide whether it is safe to put in front of users. If the AI's version runs in the demo but keeps breaking in real use, the gaps behind that are in from tutorial to real app. This page is about the pass you make before any of it ships.
Because fluent and correct are not the same thing, and AI is very good at the first one. The code compiles, reads cleanly, and looks like a competent developer wrote it, which is exactly why it is dangerous to wave through. In Veracode's 2025 study of more than 100 models, AI-generated code introduced a security flaw in 45% of tests, and when a secure and an insecure way both existed, the model often took the insecure one.
The model is trained to produce the most plausible next line, not the safest one. It does not know your data, cannot tell when a wrong answer costs money, and will never volunteer what it left out. So the burden sits with you. Treat every generated change as a claim to be verified, not a gift to be merged, and the review is the step that turns "it ran" into "it is safe to ship".
Run the same five checks on every AI-written change, in rough order of how often they bite. Each one is a place to look and a question to ask, not a vague "review the code". Grep is your fastest friend here: it finds the thing the AI quietly did not add.
| Check | Where to look, what to grep for | The question to ask |
|---|---|---|
| Auth on the server | Route handlers and API endpoints; grep for the sign-in or session check | Is this enforced on the server, or only hidden in the UI? |
| Access control | Database queries; grep for the user or tenant id in every read and write | Can account A reach account B's data? |
| Input and errors | External inputs and API calls; grep for catch and for missing ones | What happens on bad input, a timeout, or a failure I did not cause? |
| Secrets and config | Hardcoded strings; grep for key, token, password, http | Is any secret in the code, or readable by the client? |
| Spend and limits | Loops, retries, and calls to paid or AI APIs | What stops this from running forever or spending with no cap? |
Start with who is allowed to do what, because that is where AI-built apps leak most. Broken Access Control is the number one risk in the OWASP Top 10 for 2025, and it is the exact pattern we find again and again in code an AI wrote.
The hole is almost always the same shape. Permissions are handled at the user level, in the browser, with no server-side control, so anyone who opens the network tab can step around them. When you review, do not trust a hidden button or a greyed-out field. Find the server route and confirm it checks both that the user is signed in and that this user owns this record. If the rule that account A cannot read account B lives only in the screen, it does not exist. What each of these holes costs and how it gets closed is in security holes we keep finding in AI-generated apps.
The second thing to check is everything that happens when the happy path does not. AI writes for the input you described and stops there, so the code often has no handling for bad input, a timed-out API, or a job that loops.
The most expensive version of this is an automation with no limit. One app we were called in on ran an unsupervised loop with no spending cap and no stop switch, and rang up an AI bill of over 1,000 dollars in a single day. So when you review AI code that calls a paid API or runs on a schedule, the question is not whether it works once. It is what stops it from running forever. Look for a timeout, a retry limit, input validation, and a hard cap on spend. If any of those is missing, that is your review comment, before the bill is.
The hardest bug in AI code is the gap, the thing missing rather than the lines on the screen, so read every change for what is not there. AI will not tell you it skipped the permission check, the backup, or the edge case, because from where it sits the task looked done.
Read the diff twice. The first pass asks whether the code does what it claims. The second asks what a careful developer would have added that is not here: the input it does not validate, the error it does not catch, the second user it never considered. This is slower than skimming and it is the whole point, because the thing that leaks is almost always the thing nobody asked the AI to add.
Reviewing AI code is one habit: assume nothing works until you have checked it. Confirm sign-in on the server, that one account cannot reach another's data, that failure and spend are capped, and ask of every change what it quietly left out.
We review AI output in two places: before the build, and after. Before an AI builds anything we grill the plan, and after an agent reports that it is done we re-run the check ourselves instead of trusting the receipt.
Two of our open tools do exactly that. Grillin' reads the plan you wrote and tells you whether someone who has never met you could actually follow it, because a vague plan is where bad AI code starts. Smokin' takes an agent that said "done" and re-does the check itself to see whether that was true. You can read every line of both on the projects page. The habit under both is the one this whole article is about: an AI telling you something works is not evidence that it does.
If you would rather have someone go through AI-written code with you before it reaches users, book a production-readiness check and we will tell you honestly what holds and what leaks. We have shipped 15 apps this way, with 2 more in progress, each one pen-tested before it went live, and a small one is usually ready in two to four weeks.
Founder and main developer at Zyntari. Building apps and AI solutions since 2024; before that, 12 years in sales and client-portfolio management and co-founder of two companies. More about the team · LinkedIn