Code audits with AI: what to check and when you need one

Two questions, not one

An audit answers two different questions, and most tools only ask one.

1. Did we build what we agreed? The product has requirements, written down somewhere. Are they all implemented? Did any quietly change? Did something get dropped without anyone deciding to drop it?
2. Is it safe to put in front of customers? Can one account see another's data? Are there secrets in the repository? Does a payment retry charge twice?

The second question gets most of the attention, because security failures are expensive and public. The first is skipped more often, and for a small product it is usually where the surprises are: the feature a customer was promised that never got built, or the requirement that was reworded after sign-off so the build "passes."

What the first question needs

You cannot check a build against requirements that do not exist, or against requirements nobody can test. So the first half of an audit depends on work done much earlier:

• Requirements with keys, such as REQ-014, that never change, so work can be traced back to them.
• Acceptance criteria for each one: how someone would check it on the running product.
• A frozen version of what was agreed. If the requirements can be edited after sign-off, an audit against "the requirements" is an audit against whatever they say today.

With those in place, the checks are straightforward. Every Must requirement has finished work against it. Each acceptance check passes on the live product. Requirements that changed after sign-off are flagged with the old and new wording. Requirements that were dropped are recorded as decisions, not deleted.

What the second question needs

For a small web or mobile product, a practical security and reliability pass covers six areas:

• Access control. Every route that touches private data checks the session. Admin actions check a role, not just that someone is signed in. Changing an ID in a URL cannot reach another account's records. Most serious findings in small products are here.
• Secrets. No keys or tokens in the repository or its history. No server secret exposed to the browser through a public environment variable. Leaked credentials rotated.
• Dependencies. Known advisories checked against a real advisory database, such as npm audit or OSV, with the advisory IDs recorded.
• Input handling. Parameterised queries, no dynamic code execution on user input, escaped output, validated uploads, restricted server-side fetches of user-supplied URLs.
• Money paths. Payment handlers are idempotent, webhook signatures are verified, amounts are computed on the server, and credits or refunds cannot be spent twice under concurrent requests.
• Operations. Errors reach monitoring someone reads, backups exist and a restore has been tried, migrations are applied before the code that needs them.

And one more check that is easy to forget: it is live. An audit of something nobody outside the team can reach is not finished.

Where AI helps

AI is genuinely useful in an audit, in specific places:

• Reading a large codebase quickly and pointing at where to look: every route handler, every place a price is computed, every call that fetches a URL.
• Triage. Ranking a long list of findings by what costs money or exposes data first.
• Writing reproduction steps and suggested fixes for a finding that has already been established.
• Explaining a finding to the person who has to fix it, in terms of their code.

Where AI gets in the way

The failure mode is an audit made of a model's opinions. A model asked "is this code secure?" will produce a confident list, some of it right, some of it plausible and wrong, and all of it formatted the same way. A finding you cannot verify is worse than no finding: it costs time to chase, and it teaches the team to ignore the report.

So the rules for an AI-assisted audit are simple:

• Evidence or it did not happen. Every finding has a location (file and line, or a route), evidence that shows the problem, and steps to reproduce it. No evidence, no finding.
• Findings come from checks, not vibes. Dependency advisories come from an advisory database, not from memory. Access-control findings come from actually changing an ID and seeing what happens.
• Stable identity. Give each finding a fingerprint so that re-running the audit tells you what was fixed, rather than producing a new wall of text.
• A verdict, not a mood. The audit passes when there are no open critical or high findings and the product is live. Otherwise it is another iteration.

When you need one

A small team does not need a continuous audit programme. It needs an audit at the moments when the answer matters:

• Before a public launch or an app store submission. The last cheap moment to find an access-control hole.
• When outside work comes back. A contractor, a studio or a coding agent has built something against your requirements. This is exactly when "did we get what we agreed" needs an answer.
• Before due diligence, or when you take over someone else's codebase.
• After large changes to authentication, payments or data access.

If you are between those moments, a lighter habit works: keep requirements keyed, reference the keys in commits and pull requests, and re-check the money paths whenever they change.

Where Atrix AI fits, and where it does not

To be clear about scope: Atrix AI does not scan or analyse your code. The security and reliability checks above are yours to run, by hand, with the tools named, or with a reviewer you trust. What Atrix AI does is the part of an audit a workspace can answer honestly, and the bookkeeping around the rest.

The first question: did we build what we agreed? In Atrix AI you accept your requirements and freeze them as a numbered baseline, which keeps the exact wording of each requirement, and the PRD and source documents, as they stood. The requirements audit then shows, for each requirement in the baseline, whether work exists, is in progress or is done, and flags requirements whose wording changed or that were dropped after the freeze, as well as frozen documents edited since. A requirement in a baseline cannot be deleted, only marked Won't, so nothing disappears quietly. Every state is computed from your records, not from a model's opinion.

Traceability. Requirements carry permanent keys. When you hand a build to a coding agent, the handover bundle from Develop mode includes the documents and the keys, and asks for the keys in commits and pull requests, so an auditor can trace work back to what it was for. The AI agent drafts the requirements and plans the work; people decide what is agreed.

Tracking findings. Each finding from your audit can be logged as an issue with a priority, in the same project as the requirements it affects, and accepted requirements with no work against them can be broken into issues. The audit's second half happens outside Atrix; its results do not have to live in a spreadsheet.

For the checks themselves, use the free code audit checklist. It includes a findings log with severity, location, evidence, reproduction and a suggested fix for each row.

The short version

A useful code audit checks the build against agreed, testable requirements, then checks that it is safe and live. AI makes the reading, ranking and explaining faster. It should never be the source of a finding on its own. Start with requirements that can be checked, and the rest of the audit gets much easier.