Digital Engineering/AI Product Assurance/AI Code Audit
AI Code Audit: find out what is actually in your codebase
A diagnosis, not a sales process. We read the software you built with AI and hand you a written register of what is wrong with it, every item classified, located and costed in plain language.
You probably do not know whether you have a problem
Most people who land on this page are not certain anything is wrong. That is the honest starting position, and it is why the audit exists.
The software runs. Customers are using it. Nothing has caught fire. But something nags: a feature that took a morning last month and half a week this month, a bug that came back after it was fixed, a customer question about where their data sits that you answered vaguely and have not stopped thinking about since.
This is the ordinary condition of software built quickly with AI assistance, and it is not a sign you did anything foolish. The tools work. What they do not do is hold the whole system in mind across sessions, argue with you about a data model, or notice that a decision made in week two contradicts one made in week seven. Nobody held that thread, because until recently whoever wrote the code also held it.
The result is software that is locally sensible everywhere and globally uneven. Some parts are fine. Some are load-bearing and fragile. From your seat the two look identical, because both work today.
An audit resolves that. It replaces a feeling with an inventory: which parts are solid, which will hurt you and roughly when, and which of the things worrying you were never problems at all.
What the audit covers
The audit is assessed against The Noseberry Product Assurance Framework, the same six dimensions used on every engagement in this service line, so a second audit next year measures precisely what this one did. The evidence behind each dimension is published rather than held privately.
Read the assessment methodologyCode Health
Duplication, complexity concentration, dead paths and naming consistency are measured, then the parts they flag are read. We look particularly for the same problem solved several ways in different corners, the signature of generated code and the best predictor of what your next six months of changes will cost. Test coverage is judged on whether the tests would catch a real regression, not on the percentage.
Application Security
Authentication and authorisation traced route by route rather than sampled. Input handling, file uploads, secrets in the repository and in configuration, and how third-party keys are scoped. Assessed against OWASP ASVS and the OWASP Top 10, with secure-SDLC practice referenced to NIST SSDF. We identify gaps relevant to these standards. We do not certify compliance against them. Where more depth is needed, the AI Application Security Audit goes further.
Product Architecture
The data model as it stands against the product you now sell. Module boundaries, ownership of records, what happens when two parts of the system both believe they are authoritative, and integrations where someone else’s failure becomes your outage.
Scalability & Performance
Query shapes against realistic volumes rather than seed data, N+1 patterns, missing indexes, unbounded result sets, background jobs, and the point at which the current design stops being adequate.
Cloud & Delivery
How the software gets from a laptop to production, whether anyone else could repeat that, environment separation, configuration handling, what is monitored, and what a failed release costs you in time.
Engineering Governance
What is written down, what exists only in one person’s head, how changes are reviewed, and where AI tooling sits in that process.
Each dimension carries one of these three statuses, traced to specific findings underneath it. A status you can interrogate beats a number you cannot.
Numeric scoring is held until the methodology page is published in full. We would rather ship a defensible status than an impressive-looking number nobody can check.
Who books an audit
Founders who built the product themselves.
You used Claude, Cursor, Lovable or Replit, you have real customers, and no experienced engineer has ever looked at what you made. You want a second opinion before making an expensive decision on a hunch.
Small teams about to grow.
You are hiring your first or third engineer, and would rather know what you are handing them than watch them find it in week two and form conclusions in private.
Non-technical owners of technical assets.
Someone built it and left, or a contractor delivered it and the relationship ended. You are now responsible for something you cannot read.
Technical leaders wanting an outside read.
Your team has shipped fast with AI assistance and you suspect review has not kept pace. An audit gives you evidence rather than opinion.
Anyone facing a question they cannot answer.
A security questionnaire, an investor’s technical adviser, a co-founder asking whether the platform will hold.
When it is worth doing, and when it is not
The best time is before a decision, not after a disaster. An audit is cheap next to almost anything you might do afterwards, and it is most valuable when a real choice is in front of you.
Book one when
- You are about to spend serious money on the codebase: a rebuild, a first engineering hire, or a large feature that assumes the foundation holds. All three are easier to commit to with an inventory in hand.
- The same category of bug keeps returning, which usually means fixes have hit symptoms rather than whatever generates them.
- A customer or investor has started asking how the software is built and you have been answering from memory.
- The person who understood the system has gone.
- The pace has changed. Software that gets steadily harder to modify is telling you something specific, and the earlier you read it the cheaper it is to act on.
When it is not
- The product is a fortnight old, has no users and changes shape weekly, so an audit measures something that will not exist next month.
- You already know what is wrong and simply want it fixed. You do not need a diagnosis, so go to Vibe Code Cleanup.
- The product has no customers and your budget stretches to one thing, so spend it on finding customers. We will say so on the call.
How the audit runs
A short call and an NDA
before anything is shared
Thirty to forty-five minutes on what the product does commercially, what has gone wrong before, who built it and with what, and what decision is waiting on the answer. The NDA is signed here, not later. We confirm which repositories are in scope and put everything else out of scope, in writing.
Tooling pass
first 48 hours
Static analysis, dependency and licence resolution, secrets detection across full commit history rather than the current head, and a read of your infrastructure configuration. Rule sets are tuned to your stack first; at defaults they generate hundreds of low-value hits that bury the four findings that matter.
Reading the system
days two to six
Engineers work through the code the way someone inheriting it would: following a request from entry to database and back, reconstructing the data model on paper, chasing authorisation through every route, looking for places where two parts of the system hold contradictory assumptions. This is where the findings that change decisions come from.
Classification and costing
days six to eight
Each finding gets a class, a file-and-line location, a sentence on what it costs you if untouched, and a rough estimate in engineer-days. Findings roll up into the six dimension statuses, so nothing is asserted without evidence beneath it.
Delivery and walkthrough
days eight to ten
You receive the report and register, then a live session with whoever needs to understand it. Bring your engineers to argue with us; that hour is usually the most valuable part of it.
Two weeks end to end is typical. Anything Critical reaches you the day we find it. You will not wait until delivery to hear about an exposed credential. Access is revoked once the walkthrough is done.
What you receive
A written audit report
covering all six framework dimensions, each with a status and the evidence behind it, written so an engineer respects it and a non-technical owner can act on it.
A findings register as a working spreadsheet
not a PDF appendix, with every issue classified Critical, High, Medium or Optimisation and carrying a location, a business-impact sentence and an effort estimate, usable as a backlog by whoever does the work.
A reconstructed architecture and data model diagram
describing the system as it actually is rather than as intended, which for most AI-built products is the first time anyone has written that down.
A dependency and licence inventory
covering what is in your product, where each package came from, which versions carry known vulnerabilities, and which licences create an obligation before an acquirer notices it.
A prioritised action list
ordered by risk and dependency, so the first fortnight of work, by anyone and not necessarily us, removes the largest share of exposure.
A recorded walkthrough
so a future hire, an investor or your own developers can absorb the full picture without another meeting.
A written answer to your original question
whatever it was, whether the platform holds for two more years, whether to rebuild, or whether it is safe to hire against, answered explicitly rather than left implicit in a list of issues.
How findings are classified
Every finding carries one of four classes. A class is a recommendation about timing, not a judgement about taste.
Classification
What it means
Expected response
Something is exposed right now: data, money, availability or a legal obligation.
Address before the next release.
Will cause real damage under conditions you should expect this year: growth, a new customer, a departure.
Schedule this quarter.
Costs you continuously in engineering time and slows every change near it.
Planned work, sequenced sensibly.
Worth doing, with no urgency attached.
Do it while you are in that code anyway.
Every class is paired with a plain-language impact line. “Duplicate validation logic across three controllers” is not something anyone can prioritise; “a user can change their own subscription tier through the API because the check exists only in the web form” is. If a finding cannot be written the second way, we question whether it belongs in the register.
What it costs
Fixed-scope audit
from $2,500
For a single-product codebase. A price agreed before work begins, not an estimate that moves.
Included at that price
The scoping call and NDA, the full tooling pass, engineering review across all six dimensions, the classified findings register, the architecture and data model reconstruction, the dependency and licence inventory, the prioritised action list, the report, and the walkthrough with its recording. Nothing on that list is charged separately, including a follow-up question a fortnight later.
What counts as a single-product codebase
One repository, or a repository plus a thin companion such as a marketing site or a small worker, holding one product. Up to roughly 75,000 lines of first-party code. A conventional stack, a web application, a database and a handful of integrations, on mainstream cloud hosting. Most products built in six to eighteen months by one to four people sit inside this.
What puts an engagement above the entry price
Several repositories under one product, or a monorepo above the size threshold. A regulated domain such as health or financial services, anything where a data-protection regime shapes the assessment and findings need mapping to a control framework. A mobile application plus a backend, which is two codebases with a contract between them. A legacy migration in flight, where two systems run in parallel and the interesting problems live in the seam. Self-managed infrastructure that has to be assessed rather than read.
How the larger tier is quoted
After the scoping call we send a fixed price and a written scope, usually within two working days. Larger audits typically land between $4,000 and $12,000. We quote a number, not a day rate, so if the work runs longer than we judged, that is our problem rather than yours.
How we handle your source code
You are considering handing your product to people you have spoken to once. Here is the arrangement, so you can check it against your own comfort level first.
Access is read-only and time-boxed
A repository invitation with read permission, or a supplied archive if your policy prefers. Where infrastructure is in scope, a read-only console role restricted to the agreed environments. Nothing in an audit requires the ability to write, merge, deploy or configure.
Live systems and customer records stay out of it
We do not ask for production database credentials, admin logins or exports of user data, and you should treat any such request as a mistake worth challenging. Where the audit examines how personal data moves, we work from schema, field classification and code paths.
Named people only
The engineers assigned to your audit are named in the engagement note before access is granted. Nobody outside that list gets access, and every credential is withdrawn once the walkthrough is complete.
The paperwork comes first
An NDA is executed before the scoping call goes further. If your organisation prefers its own agreement, send it. We sign client paper regularly and it delays nothing.
Where it runs, and what survives
Analysis happens on our infrastructure by default, or inside your environment with only findings leaving it if your security team asks. When the audit closes we keep the report and register; your source code is deleted, with retention terms written into the engagement note.
Before you pay us, run a free scanner
Genuinely, do that first. Point a free tool at your repository this afternoon. GitHub’s own dependency and secret scanning costs nothing on most plans, and several credible free tiers exist beyond it. That is real value for nothing, and if it finds a leaked key you have had a very good day. But a scan is only half the work.
What a scanner finds
- Outdated and vulnerable packages
- Credentials sitting in your commit history
- Known vulnerability patterns
What only an audit finds
- Whether your permission model actually makes sense, not just whether individual lines match known-bad patterns
- A free-tier customer who can reach a paid endpoint by guessing a URL, because nothing there is malformed, it is missing a rule nobody wrote
- An orders table and an invoices table that disagree about what a cancellation means
- A webhook handler that will process the same payment twice under a retry
- The fastest-growing table in your database with no archival plan, becoming an operational problem next spring
A scanner checks whether code is well-formed. An audit checks whether it is right. If your budget covers only the scanner, run the scanner. It beats nothing, and this offer will still be here later.
What happens after the report
Nothing, unless you decide otherwise. The audit is a closed engagement with a defined deliverable and no automatic next step.
Plenty of clients take the register elsewhere.
To their own developers, to the agency that built the product, or to a contractor hired against the action list. That is a legitimate outcome, and it is why the register is a working spreadsheet rather than a locked document. A findings register only we could act on would be a worse deliverable.
Some ask us to do the work.
If you want that, Vibe Code Cleanup picks up from the register with a Retain / Refactor / Replace decision per component, and Production Readiness & Hardening covers the operational side. Both are quoted separately afterwards, with no expectation created by having bought an audit.
And if it is fine, we tell you.
Some audits conclude that the software is in reasonable shape, the risks are minor and the sensible next move is to keep building. We write that down plainly and you go back to work. It happens often enough to be a real possible answer rather than a polite disclaimer.
Why Noseberry for this
We are not upselling you.
The audit is priced as a standalone product and is the majority of what we sell in this service line. Findings are not written to manufacture a remediation quote, and the effort estimates are there so you can price the work with anyone.
Reviewers who have operated production systems.
Everyone assessing your code has shipped, broken and repaired live software with customers on it. That is what separates a finding that matters from one that is merely true.
We build with the same tools you did.
Our engineers use AI assistance daily on client work under governed conditions: an approved model and tooling list, security-explicit prompting, scanning before human review, and stop conditions so an agent escalates instead of improvising.
The method is published.
The methodology sets out what evidence supports each dimension, so you can disagree with a conclusion and argue it against a written standard rather than our authority.
We will talk you out of it.
If the scoping call suggests an audit will not earn its cost yet, we say so before you pay. It costs a sale and it is still the right answer.
Evidence
We would rather show you a redacted findings register on a call than publish case studies we cannot yet evidence. We will walk you through anonymised registers from comparable engagements and introduce you to a reference client before you commit.
Frequently asked questions
Our fixed-scope AI Code Audit starts at $2,500 for a single-product codebase: broadly one repository, up to around 75,000 lines, on a conventional stack. That covers the tooling pass, engineering review across all six dimensions, the classified findings register, the architecture reconstruction, the dependency and licence inventory, the report and a walkthrough. Larger engagements, such as multiple repositories, a large monorepo, a regulated domain, mobile plus backend, or a migration in progress, are quoted after a scoping call and typically land between $4,000 and $12,000, fixed before work starts.
An audit is diagnosis; a cleanup is treatment. The audit reads your codebase and produces a classified register of what is wrong, what it costs you, and in what order to address it. Nothing in your code changes. A cleanup is the engineering work that follows: a Retain / Refactor / Replace decision applied to each component and executed while the product stays live. They are separate purchases because they are separate decisions, and plenty of people who buy the first never buy the second.
No, and a good proportion of audit clients do not. The register is deliberately built to be handed to somebody else: file locations, business impact, effort estimates in engineer-days, and an action list ordered by risk. Your own developers can work from it, and so can any agency you brief. We would rather deliver a portable document and be judged on it than lock the value behind a follow-on engagement. If you do want us to do the work, it is quoted separately after you have read the findings.
Two weeks from the scoping call to the walkthrough is typical for a single-product codebase: the tooling pass runs in the first 48 hours, engineers read the system through the middle of the engagement, and classification and reporting close it out. Larger or multi-repository systems run three to four weeks, and we tell you which before you commit. You will not wait until the end to hear anything: the register is shared as it develops, and anything Critical reaches you the day it is found.
Read-only repository access and about forty-five minutes of your time. Three things help beyond that: a sentence on what the product does commercially, a list of anything that has broken before, and a note of which parts you built first. We do not need documentation, a tidy repository or anything cleaned up in advance: an accurate view of the current state is the whole point, and preparing for the audit would defeat it. Nothing is needed from your team during the review.
Yes, and these are among the most common codebases we see. Platform-generated applications share a recognisable set of traits: consistent scaffolding, security controls applied unevenly across routes added at different times, generous permissions on managed backends, and business logic sitting where it suited the generator rather than the product. We assess exported or connected repositories exactly as we would any other. If your product still runs entirely inside a hosted platform, say so on the call and we will confirm what can be reviewed.
It gives you the evidence to make that call, and we state a recommendation explicitly. Rebuilds are usually the wrong answer: they discard working business logic and every undocumented lesson embedded in it, and they take far longer than anyone estimates. They are occasionally right, particularly when the data model no longer matches the product you now sell. Because the audit assesses component by component, the honest answer is normally that most parts are worth keeping and a small number are worth replacing.
Then the report says so and you spend the rest of your budget building. This is a real outcome, not a courtesy: products built carefully in one framework by someone with prior engineering exposure often come through with a handful of Medium findings and nothing urgent. We do not inflate a register to justify an invoice, because the register is what our reputation rests on. If the scoping call suggests the audit will not earn its cost, we say so then and you keep the money.
An NDA is executed before scoping. Access is read-only, granted only to engineers named in the engagement note, and revoked once the walkthrough is done. We never ask for production database credentials, customer records or admin access to live systems. Analysis runs on our infrastructure by default, or inside your own environment with only findings exported if your security team requires it. When the engagement closes your source code is deleted, and the retention terms sit in the engagement note rather than in a promise.
Yes, the report is yours and many clients use it that way. A dated findings register with an action plan attached is a stronger position in front of an enterprise buyer or a technical due diligence process than a claim of having no problems, because it shows the team knows its own product. If you want a version pitched at a non-technical audience, we will write one. We share nothing ourselves without your written instruction.
Find out what you own
Send a repository link and a paragraph about what is bothering you. Within two working days you get a fixed price, a written scope and a straight view on whether an audit is worth your money right now.
Related resources
Go deeper with our thinking
From Spreadsheets to a Scalable Platform – building Canada’s Most Tenant- First Coliving System
Read case study
How to Build a SaaS Product
Read guide
The MVP Development Guide
Read guide
Building a Digital Engineering Roadmap That Aligns With Business Goals
Read article
Engineering IoT Products: Key Challenges and Best Practices
Read articleNot sure where you stand?
Take a free two-minute readiness scorecard built for your industry.