Auditing AI-Generated Code

You described an app, an AI wrote it, and it works. In an afternoon you have something that would have taken a team a week. But somewhere in that speed, a step quietly vanished: the senior review. Nobody read the code the way a principal engineer or designer would — and "it runs" is a much lower bar than "it's ready for users."

Vibe coding is genuinely great. It collapses the distance between idea and working software, and it's not going away. But the same thing that makes it fast — you steer the outcome, not the implementation — means the implementation goes unexamined. The model optimizes for "make the demo work," and the gaps it leaves are exactly the ones that don't show up when you click through the happy path. Those gaps are what an audit is for.

What AI gets right — and where it drifts

Modern models write competent, plausible code. The structure is usually reasonable, the happy path usually works, and the output usually looks the part. That's precisely why the problems are easy to miss: nothing is obviously broken. The drift shows up in the places a model isn't graded on when it generates a demo:

• Accessibility — placeholder-only inputs, missing labels, non-semantic <div> soup, no focus management, contrast that fails WCAG.
• States that aren't the happy path — no empty state, no error state, no loading state, no handling for the input you didn't mention.
• Consistency — three subtly different button styles and four spacing values, because each screen was generated in isolation.
• Performance — unoptimized images, layout shift, blocking work, patterns that jank on a real device.
• Dead and duplicated code — leftover scaffolding and near-identical components that quietly become design debt.

"It runs" is where AI stops. "It's ready for users" is where the review begins.

Why the gaps are dangerous specifically here

With hand-written code, a developer at least saw every line. With generated code, large sections may never have been read by a human at all — so a missing label or an unhandled error isn't an oversight someone made, it's an assumption nobody checked. And because the app looks polished, teams tend to trust it more than they should, shipping straight from "the demo worked" to production. The polish is real; the review still hasn't happened.

How to audit an AI-generated app

Treat the output like a pull request from a very fast, very literal junior: assume competence, verify everything, and read the actual code — not just the running result.

• Audit the generated source, not only the screen. The rendered app hides the missing label and the div soup. The markup shows them. Point an audit at the real HTML, CSS, and JS.
• Use all three lenses. AI drift spans design, code, and conversion at once, so a single-purpose linter misses most of it. Review usability, engineering, and growth together.
• Prioritize by impact. You'll get a list; fix the accessibility and trust-breaking issues first, cosmetic drift later.
• Fix, regenerate, re-audit. The loop is fast — feed the findings back into your prompts or fix directly, then re-run to confirm.
• Keep yourself in the loop. An audit is a fast expert second opinion, not a rubber stamp. You still own the call on what ships.

A pre-launch checklist for vibe-coded apps

Before you point users at an AI-built app, confirm the boring, high-impact basics an audit surfaces in seconds:

• Every form control has a real, associated label.
• Text meets contrast requirements, and the page is usable by keyboard alone.
• Empty, loading, and error states exist and make sense.
• Components are consistent; spacing and color come from a coherent set.
• Images are sized, the layout doesn't shift, and interactions feel immediate.
• The primary action on each screen is obvious.

Frequently asked