How to audit AI-generated code before you ship it: a five-step process for a three-person team

Why AI-generated code needs a different audit

AI-written code fails in a different pattern from code a person wrote. A person who misunderstands a requirement usually leaves evidence: a comment, a question in chat, an odd variable name. An agent produces confident, well-formatted code that compiles, passes the tests it wrote for itself, and may still do the wrong thing.

Two numbers describe the problem, as of October 2026:

• Veracode's 2025 GenAI Code Security Report (published 30 July 2025) tested 80 coding tasks across more than 100 large language models and found that the generated code introduced a security vulnerability in 45% of cases. The models failed to protect against cross-site scripting in 86% of relevant tasks and log injection in 88%, and Java had a failure rate over 70%.
• Stack Overflow's 2025 Developer Survey (49,000+ respondents, published 29 July 2025) found that 80% of developers now use AI tools, but trust in their accuracy fell to 29%. The top frustration, named by 45%, was "AI solutions that are almost right, but not quite", and 66% said they spend more time fixing almost-right AI code.

So the two failure modes to audit for are scope drift (it built something other than what was asked) and silent insecurity (it built what was asked in a way that leaks). A diff review in a pull request catches neither reliably, because the reviewer is reading the code the agent chose to show, against a requirement they half remember.

Step 1: Freeze a requirements baseline

You cannot audit code against a requirement that only exists in a chat transcript. Before the audit, write down what the code was supposed to do, as a numbered list of short declarative statements, and freeze it.

A good baseline line looks like this:

• R-07 A signed-out visitor who opens /app/* is redirected to /sign-in and returned to the original URL after signing in.
• R-12 An invoice can only be marked paid by a workspace owner or admin.
• R-15 Webhook payloads from Stripe are rejected unless the signature verifies.

A bad one looks like "handle auth properly". If you cannot say whether a line is met or not by looking at the running product, rewrite it until you can.

For a feature built over a week with Cursor or Claude Code, the baseline is usually 15 to 40 lines. Pull them from the PRD, the issue descriptions and the prompts you gave the agent. Then stop editing it: the point of a requirements baseline is that it is a fixed reference, so that the next step is a comparison, not a negotiation.

In Atrix, the Develop run turns a brief into a requirements list, and you freeze it as the baseline for the product. If you do not use Atrix, a numbered Markdown file committed to the repository does the same job. What matters is that it is written down, numbered and dated.

Step 2: Diff what was built against the baseline

Now go line by line through the baseline and mark each requirement as one of three things:

Do this with the running product open, not just the code. Agents are good at writing a function named requireAdmin and then not calling it on one route.

Three things to look for specifically:

1. Tests that were changed to pass. Search the diff for modified assertions, deleted test cases and new skip or only markers. In our experience this is the single most common way an agent closes a failing task.
2. Requirements the agent reinterpreted. "Redirect after sign-in" becomes "redirect to the dashboard"; "owner or admin" becomes "any signed-in member". The code is clean, and wrong.
3. Extra behaviour nobody asked for. Agents add features. Each one is unreviewed surface area. Either add it to the baseline and review it, or remove it.

This is the part Atrix automates. The requirements audit in Atrix AI compares the frozen baseline against what the team has planned and built in the workspace, and reports coverage and drift per requirement. Be clear about its limit: it audits requirements, not source code. It does not read your repository, run static analysis or find vulnerabilities. It answers "did we build what we said we would build?", which is step 2, and nothing in steps 3 to 5.

Step 3: Run static analysis over the whole repository

Static application security testing (SAST) is the cheapest step and the one teams skip. Run it over the whole repository, not just the diff, because an agent's change can make previously safe code reachable in a new way.

As of October 2026, three tools cover most small teams:

Prices are from each vendor's pricing page in October 2026 and change often.

Run the scan in CI so that it happens on every pull request, and triage the first run by hand. Expect a lot of noise the first time; the point is to get to a clean baseline so that the next agent-written change shows only new findings.

What SAST will catch in AI-written code: injection (SQL, command, log), missing output encoding, hard-coded secrets, insecure randomness, known-vulnerable dependencies. What it will not catch: a missing authorisation check on one route, a webhook handler that trusts an unsigned payload, a price computed on the client. Those are step 4.

Step 4: Review auth and payment paths by hand

A person reads these, start to finish, with the baseline open:

1. Every route that changes data. For each one, find the line that checks who the caller is and what they are allowed to do. If you cannot find the line, it is not there.
2. Session and token handling. Where the session is created, how long it lives, how it is invalidated on sign-out and password change.
3. Webhooks and callbacks. Signature verification before any parsing. Idempotency on retries.
4. Money. Where prices, totals and discounts are computed. Anything computed in the browser and trusted by the server is a finding.
5. Secrets and configuration. Grep the diff for API keys, connection strings and tokens. Agents paste example keys into code more often than people do.

Budget two to four hours for a feature-sized change. The reviewer should not be the person who prompted the agent, for the same reason a writer should not proofread their own draft.

If you use the GitHub integration, the issues you open from this review link back to the requirement and the pull request, so that "R-12 partial: admins can mark paid, owners cannot" is a tracked item with an owner, not a comment that scrolls away.

Step 5: Write the findings down and fix in order

Record each finding as an issue with four fields: the requirement it maps to, severity, the file and line, and the fix. Severity is simple at this scale:

• Critical: unauthenticated or cross-tenant access to data, or money computed incorrectly. Fix before shipping.
• High: a security flaw that needs a signed-in user to exploit. Fix in the same sprint.
• Medium: a missing edge case that users will hit. Schedule.
• Low: style, dead code, duplicated logic. Batch.

Put the critical and high items into the current cycle, and run the audit again when they close. A second pass is quick because the baseline and the scan already exist; the only new work is re-reading the lines that changed.

Tooling that makes this easier with Cursor and Claude Code

The audit gets cheaper when the agent has the baseline in front of it while it works. Three things we do:

• Give the agent the baseline, not just the prompt. With the Cursor integration or the Claude integration, the agent can read the requirements page and the issues through Atrix's MCP server, so the numbered list it builds against is the same one you will audit against.
• Ask for the mapping in the pull request. A rule in the agent's instructions, "list which requirement IDs this change implements", turns step 2 from a hunt into a check.
• Make the agent run SAST before it opens the PR. Semgrep runs locally in seconds. If the agent sees the findings, it fixes most of them itself.

None of this replaces steps 3 and 4. It shortens them.

For a three-person team, the first full audit of a feature built with agents takes about a day. The second takes half that, because the baseline process and the scanner are already in place.

FAQ

What is the difference between a requirements audit and a code audit?

A requirements audit checks whether what was built matches the list of what was supposed to be built: coverage and drift per requirement. A code audit checks whether the code itself is correct, secure and maintainable: static analysis, dependency review, human reading of sensitive paths. You need both for AI-generated code, and they are steps 2 and 3 to 4 above. Atrix AI does the first; the second is SAST plus a person. The agency side of Atrix, Atrix Digital, does human code audits as a service.

Can an AI tool audit AI-generated code?

Partly. SAST tools, some of which now use models for triage, catch pattern-level flaws well. A second model reviewing the first model's output catches some logic errors, but it shares the first model's blind spots on authorisation and business rules. As of October 2026 we treat AI review as a pre-filter for the human review in step 4, not a replacement.

How do I audit a vibe-coded app I did not build?

Start with step 1 anyway: write down what the app is supposed to do from the product itself, screen by screen, and number the list. Then run SAST over the whole repository, and read every route that changes data or money. Expect the baseline to take longer than for code you built, because the requirements were never written down.

How often should we audit?

Per feature, before it reaches paying users, and again when critical and high findings close. For a team shipping weekly, that is a short audit every week and a full one every cycle.

Which SAST tool should a small team pick?

Semgrep's Free Edition covers up to 10 contributors and 10 private repositories as of October 2026, runs locally and in CI, and is the easiest to start with. If your code is on GitHub and you already pay for Code Security, CodeQL's pull request integration is the lowest-friction option. Pick one and run it on every pull request; which one matters less than running it.

Next step

Write your baseline first. The requirements audit in Atrix AI runs against it on every plan, and our earlier post on code audits with AI covers when a small team needs a full audit and when a light one is enough.

Sources

Veracode 2025 GenAI Code Security Report press release, 30 July 2025. Stack Overflow 2025 Developer Survey results, 29 July 2025. Prices checked in October 2026 on Semgrep pricing, GitHub Advanced Security, GitHub billing docs and Snyk plans.