AI-Generated Code Audit Checklist: A Sample Vibe Check

If you vibe code, you do not need more vague advice. You need a review path that turns "looks fine" into "here is the exact issue, here is the exact file, here is why it matters."

This page is that path.

Below is a practical audit checklist for AI-generated code, plus the kind of evidence a deterministic review tool should surface when something is wrong.

What a real vibe check should prove

A useful AI-code audit should give you all four of these things:

1. Exact location — file path and line number
2. Exact rule — what pattern was violated
3. Why it matters — security, performance, or maintainability impact
4. Repeatability — same code in, same result out

If a tool cannot show evidence, it is asking for trust it has not earned.

Sample findings from a realistic AI-built app

These are the kinds of findings VCX is built to surface.

1. SQL injection in a search endpoint

Severity: Critical
Rule: security.sql.injection
File: src/app/api/users/search/route.ts:42

const query = `
  SELECT id, email
  FROM users
  WHERE email LIKE '%${search}%'`

Why this matters: A search box that interpolates user input directly into SQL can become a data-exfiltration endpoint. This is the exact kind of "it worked in the demo" code AI assistants generate all the time.

What to verify:

• every DB call uses parameters, not interpolation
• ORM escape hatches are still parameterized
• search/filter helpers do not silently concatenate strings

2. N+1 queries in a dashboard list

Severity: Medium
Rule: performance.n-plus-one
File: src/app/dashboard/page.tsx:118

for (const project of projects) {
  project.issues = await db.issue.findMany({
    where: { projectId: project.id },
  })
}

Why this matters: AI often writes clear code before it writes scalable code. A loop that issues one DB query per row looks innocent in local testing, then gets slow the moment real usage lands.

What to verify:

• loops do not hide per-item DB queries
• related data is batched or joined
• dashboards and admin tables are tested with realistic data volume

3. Diverging copy-pasted auth helpers

Severity: Low
Rule: quality.duplicate.logic
File: src/lib/auth/session.ts:12

export function isAdmin(user: User) {
  return user.role === 'admin' || user.role === 'owner'
}

export function canManageBilling(user: User) {
  return user.role === 'owner'
}

Why this matters: This starts as a quality issue and turns into a trust issue. AI-generated code loves duplication. Duplicated auth logic drifts, and drift becomes bugs, confusing policy, or accidental over-permission.

What to verify:

• auth decisions come from one source of truth
• copied helpers were not forked by different prompts
• policy changes update all paths, not just the obvious one

The checklist

Use this when reviewing AI-generated code before production.

1. Input and injection safety

• [ ] No SQL built from string interpolation
• [ ] No shell commands composed from raw input
• [ ] No path traversal through file or route params
• [ ] No unsafe HTML rendering from user content
• [ ] Parsers and deserializers reject malformed input safely

Red flag: "It is internal" is not a security control.

2. Authentication and authorization

• [ ] Sensitive routes check auth server-side
• [ ] Ownership is verified, not just login state
• [ ] Admin-only actions use centralized permission logic
• [ ] Missing session states fail closed
• [ ] Role checks are not duplicated in multiple helpers

Red flag: AI frequently protects the page but forgets the API route.

3. Secrets and environment handling

• [ ] No hardcoded secrets or tokens in source
• [ ] Env vars are only read server-side when required
• [ ] Logs do not leak credentials or personal data
• [ ] Example config values are obviously fake
• [ ] Client bundles do not expose private keys by accident

Red flag: placeholders copied from tutorials survive longer than anyone expects.

4. Dependency and supply-chain risk

• [ ] New packages are maintained and justified
• [ ] Known CVEs are checked before ship
• [ ] Packages with huge install surface are questioned
• [ ] Dependency versions are pinned intentionally
• [ ] The project is not carrying dead packages nobody uses

Red flag: AI will happily suggest abandoned packages if they were popular in training data.

5. Performance and cost traps

• [ ] No N+1 patterns inside loops
• [ ] Expensive work is cached or bounded
• [ ] Large responses paginate
• [ ] Background jobs are actually backgrounded
• [ ] Repeated scans/requests have sane limits

Red flag: "Works on localhost" is not evidence that it scales.

6. Quality and maintainability

• [ ] Duplicate logic is consolidated
• [ ] Giant files are split before they calcify
• [ ] Dead exports and unused branches are removed
• [ ] Error handling is consistent
• [ ] Comments still match what the code now does

Red flag: AI often leaves behind believable but wrong comments.

7. Evidence quality

• [ ] Findings point to exact files and lines
• [ ] The rule category is clear
• [ ] The explanation says why the issue matters
• [ ] The same scan produces the same result
• [ ] Reviewers can verify the finding without faith

Red flag: if a tool gives a scary score without proof, it is marketing, not review.

What to do after the checklist

A good shipping flow for vibe-coded projects looks like this:

1. run a deterministic audit
2. fix critical security issues first
3. kill obvious performance traps next
4. clean duplicated or misleading code before it spreads
5. rerun the audit and confirm the diff is real

That is the whole game: faster confidence, not just faster output.

Why VCX exists

Vibe coding is not the problem. Unverified vibe coding is the problem.

VCX exists to give AI-built projects a deterministic review layer:

• exact rule hits
• exact file evidence
• security, performance, quality, and dependency coverage
• the same result every time you scan the same code

If you want to see whether your repo passes the vibe check, run your own audit.

Start a free VCX audit