When AI Code Is Bad: A Design-Led Code Review Checklist for Production.

Somewhere between the 500th Figma frame and the 500th "looks good to me," the code review stopped being a technical ritual and became the most important design critique in the building. Here's the uncomfortable part: most of the code being reviewed in 2026 wasn't written by a person. It was generated by an AI agent — and the person reviewing it is very likely a designer who never expected to be in this chair. If that's you, this article is for you. Not to make you an engineer — to make you a reviewer who catches the things that actually sink products.

Let me start with the statistic that should reset your expectations about generated code. Veracode ran 100+ large language models across Java, Python, C#, and JavaScript and found that 45% of AI-generated code samples failed security tests. Not edge cases — 45% of ordinary, task-completion samples. XSS, the vulnerability that lets attackers run code in your users' browsers, failed in 86% of relevant samples. And the models getting bigger didn't fix it; newer and larger models were no more secure than their predecessors. The pattern is clear: the models are excellent at producing plausible code and indifferent to whether it's safe.

The mistake is to read this as "AI code is dangerous, designers shouldn't touch it." The accurate reading is "nobody can ship unreviewed code anymore, and review is a discipline that can be learned." Designers are, frankly, better positioned for it than they realize — because a code review is 80% the same muscle as a design review.

What a design review and a code review have in common

Walk through a design review you've run recently. You checked the happy path, then you checked the states nobody designed: empty, loading, error, offline, permission-denied. You checked whether the interaction was discoverable. You checked whether it scaled — 320px wide, 2000px wide. You checked the details that undermine trust — the misaligned grid, the low-contrast text, the button that looks clickable and isn't.

A code review of an AI-generated change is the same checklist, translated:

• The happy path works. The demo runs. The feature does the thing. (This is what the agent optimizes for, and it's the least interesting part of the review.) The unhappy paths exist. What happens on failure? On empty data? On unauthorized access? The agent ships the happy path; your review gate ships the other 90%. It scales. Not just viewport width — data volume. What happens at a thousand rows? A million? Did the agent write an N+1 query that will melt your database in production? The details that undermine trust. Error messages that actually explain the problem. Buttons that work. No secrets committed. No dead code, no leftover console.logs, no "temporary" hacks.

The vocabulary is different; the craft is the same. You've been training for this review your whole career. You just didn't know the frames were called functions.

The five checks that catch the dangerous stuff

Let me give you the concrete checklist I use. You don't need to know how to write this code — you need to know how to ask the right questions and spot the wrong answers.

One: authorization on every path. This is the single most common failure in generated code, and it's invisible in a demo. Ask: "Show me the middleware, the row-level security policies, or the auth checks on every route this change touches." For every read and write. The 2026 incident reports — from AI-built apps leaking user data to databases exposed by missing row-level security — share one DNA: data that should have been private wasn't protected at the data layer. If the answer to your question is "it's handled elsewhere," go verify it elsewhere. Authorization is not a vibe.

Two: the data you can't see. The agent demonstrates with clean, sanitized data. Real data is messy, incomplete, and sometimes hostile. Ask: "What does this render when the field is empty, null, or malformed?" Check for the crash-instead-of-empty-state pattern, and for places where user input flows into HTML, SQL, or shell commands without escaping — that's your injection surface, and it's where XSS lives.

Three: the error path is a designed surface. The best generated code I've seen treats errors like any other state: intentional. Ask: "What does the user see when this fails?" The answer "the browser's default error page" is a design failure. The answer "a clear message with a recovery action" is a product. You, the designer, are uniquely qualified to grade this answer.

Four: performance at real scale. "It works on my machine with 10 rows" is not a standard. Ask: "How many queries does this page run, and what happens at 10,000 rows?" Watch for the red flags: queries in loops, no pagination, fetching entire tables to count them.

Five: the diff is human-sized. The agent can generate a 2,000-line diff in one shot, and every one of those lines is unreviewed risk. Ask for the change to be broken into reviewable pieces. A diff you can't read is a diff that ships bugs.

How to run a review when you're not the engineer

You don't need to be a senior engineer to run this gate, but you do need a protocol. Here's mine:

• Ask the agent to prove it. Not "does it work?" — "run the tests and paste the output," "show me the RLS policies," "show me the middleware." The agent is your brilliant, fast, occasionally reckless junior, and juniors earn trust by showing their work. Review the review. The agent can review its own code, which is useful and insufficient — it shares the same blind spots. Use it as a first pass, then apply your checklist to the diff. Time-box it. A 15-minute focused review beats a 45-minute distracted one. Run the five checks, make the calls, move on. Escalate the unknowns. When you hit something you genuinely can't assess — and you will — that's not a failure. That's the moment to bring in a human engineer or a stronger tool. Knowing your boundary is a feature, not a bug.

One more thing worth saying about the protocol: the review should happen before the merge, not after the demo. The most expensive review in the world is the one that happens after the feature is already on the staging link, because by then the change has emotional gravity — someone has shown it, someone has approved it, and the review has become a formality. The gate has to be genuinely in the path, not beside it. This is a process-design decision as much as a code decision, and it's the same instinct you use when you insist on testing a flow before the client sees it. Move the gate before the demo and you turn review from a rubber stamp into an actual filter.

Why designers should stop apologizing for this seat

Here's the thing I keep coming back to: the security crisis in generated code is not a reason for designers to stay out of the code review. It's the market proving that nobody can ship unreviewed output — and that the bottleneck is judgment, which is the one thing you've been training your entire career. The agents generate faster than anyone can write; the review is where quality is actually decided; and the review is a design discipline wearing a technical costume.

The designers who treat the review gate as part of their craft are the ones who end up owning the whole path from idea to deployed product. The ones who treat code as someone else's problem are the ones who inherit someone else's bugs. The checklist is above. The muscle is already yours. Sit down, run the five checks, and make the agent prove it.