AI-Built Apps: How to Audit Code Written by AI Before You Scale It
Veracode tested 100+ models on 80 coding tasks: 45% of the code contained an OWASP Top 10 vulnerability. Here is how to audit an AI-built app before it meets real customers and real data.
By Ivan Pylypchuk, CEO of SoftBlues
Veracode put more than 100 large language models through 80 coding tasks. 45% of the code they produced contained an OWASP Top 10 vulnerability, and the pass rate did not improve as the models got bigger (Veracode, 2025).
That number matters more this year than last, because the internal app your operations lead built over a fortnight is now standing between your customers and your database. Most UK mid-market companies we speak to are past the question of whether to let people build with AI. Something already exists: a quoting tool, a client portal, a reporting dashboard, a rota app. It works. Someone wants to put real customer data through it. The question that needs answering is narrower. Is this thing safe to scale, and how would you know?
An audit of an AI-built application answers that in three parts. What data it touches and who can reach it. Whether a second person could safely change the code. Whether it can survive real traffic, a bad actor, and a Friday afternoon outage. Everything below is the working version of those three questions.
Key facts
Why does AI-written code fail differently?
A junior developer writes code that looks junior. Variable names drift, the structure is naive, the mistakes are visible. An AI assistant writes code that looks senior and goes wrong more quietly.
Three failure modes show up again and again in the applications we look at.
Plausible security. The code has a login. It has input validation. It has a permissions check. Each control is present and each one is shallow. A permissions check that runs in the browser rather than on the server will pass a demo and fail a curious user. Veracode found the models failed to defend against cross-site scripting in 86% of attempts, which is the statistical version of the same problem.
Duplication instead of structure. Ask a model for a similar feature and it will regenerate the logic rather than reuse what already exists. GitClear's data shows duplicated blocks climbing while refactoring falls away. The app is fine on day one. By day ninety a pricing rule lives in six places and someone has updated four of them.
No record of the decision. Human code carries context: a comment, a commit message, a person you can ask. Generated code arrives without the reasoning. Nobody in the building can tell you why the retry limit is three, so nobody dares change it.
Is it a prototype or a production system?
Almost every AI-built internal tool we see is a good prototype being treated as a product. That is not a failure. It is a category error, and it is cheap to correct if you catch it before the scale-up.
| Prototype | Production system | |
|---|---|---|
| Users | A handful of colleagues who know the workarounds | People who will do the unexpected, including outsiders |
| Data | Test data, or a copy | Real personal, financial or client data |
| Failure | Someone reruns it | Someone is blocked, mischarged, or exposed |
| Access control | Everyone is trusted | Roles, least privilege, an audit trail |
| Recovery | Rebuild it | Backups, a restore you have tested, an incident route |
| Ownership | Whoever built it | A named owner with time allocated |
If your app sits in the left column and your plan sits in the right, the audit is the bridge between them.
What should an audit of an AI-built app cover?
We run these in a fixed order, cheapest checks first, because the early findings usually change what is worth doing next.
1. Data and access. What personal or commercial data does it touch, where does that data physically sit, and who can reach it? This is where UK GDPR obligations bite, and it is the check most often skipped because the answer feels obvious to whoever built it.
2. Authentication and authorisation. Ask whether every request is checked on the server, not whether there is a login screen. Client-side permissions are the most common finding we report.
3. Secrets and third-party calls. API keys hard-coded into the front end, or pasted into a config file that ended up on a shared drive. Also worth knowing: which external services is this app quietly sending data to?
4. Injection and input handling. Anything a user types that reaches a database, a shell, a file path or a model prompt. Prompt injection belongs in this check now, if the app calls an LLM.
5. Dependencies and licences. AI assistants recommend packages confidently, including abandoned ones and occasionally ones that do not exist. Check what is installed, whether it is maintained, and whether the licence allows commercial use.
6. Maintainability. Could a second person change this safely? Look for duplicated business logic, missing tests, and the parts of the codebase nobody can explain.
7. Operational readiness. Backups, monitoring, error alerting, a restore you have actually run, and a named human who owns it on a Tuesday afternoon in August.
Keep it, harden it, or rebuild it?
Three honest outcomes. The audit tells you which one you are in, and getting it wrong is expensive in both directions.
| Option | What it means | Best for | Avoid if |
|---|---|---|---|
| Keep as-is, fence it in | Leave the app alone, restrict it to internal users and non-sensitive data | Genuinely internal tools with a small blast radius | It touches customer data or external users |
| Harden in place | Fix the security findings, add tests and monitoring, keep the structure | The architecture is sound and the findings are contained | Business logic is duplicated across the codebase |
| Rebuild the core, keep the design | Reuse the interface and the workflow, rewrite the engine properly | The idea is proven and the code cannot carry the load | Nobody has confirmed people actually use it |
What this looks like in a regulated business
The sequence is familiar. A team builds something useful with an AI assistant. It starts handling real records. Then a client security questionnaire or an insurance renewal asks a question nobody in the room can answer.
We worked through exactly that with a food producer whose internal application had been built largely with AI assistance. The engagement was an audit of an AI-built app followed by a secure rebuild, plus a proper setup for AI-assisted development so the next thing the team built started from a safe baseline rather than a blank prompt. That was an audit and a rebuild rather than a long production track record, but the shape of the findings is representative.
The uncomfortable part is rarely the code. It is discovering that a system three departments now depend on has no owner, no backup, and nobody who can change it.
If you have more than one of these, the fix is structural rather than per-app. Our guide to AI governance for UK mid-market companies covers the policy layer that stops the next one appearing unaudited.
Red flags that mean audit before you scale
Questions to ask whoever built it
Ask these before you commission anything. The answers tell you how deep the audit needs to go.
1. What data does it read and write, and where is that stored? A good answer names the systems and the location. A vague one is itself a finding.
2. Who can log in, and what stops them seeing someone else's records? You are listening for a server-side check, not a hidden menu item.
3. What happens if it goes down on a Friday? You want a named person and a recovery step.
4. What did you have to fix after the AI wrote it? Honest builders have a list, and it tells you where to look first.
5. If you left tomorrow, who could change this? If the answer is nobody, maintainability is your biggest risk, not security.
Frequently asked questions
Does this mean we should stop building with AI assistants? No. DORA's 2025 research found AI amplifies the practice you already have: strong teams get faster, and weak processes ship weak work faster (DORA, 2025). What you need is a review gate before anything touches real data, rather than a ban.
How long does an audit of an AI-built app take? For a single internal application, days rather than weeks. The variable is not code volume. It is how many systems the app connects to and how much of the original reasoning survives.
Can we audit it ourselves? Partly. Dependency, secrets and backup checks are within reach of a competent internal team using standard tooling. Authorisation logic and injection paths reward someone who has broken applications before.
Is AI-generated code worse than junior or offshore code? Different rather than uniformly worse. It is more syntactically correct, less structurally sound, and it fails quietly instead of visibly. Veracode measured 2.74x more vulnerabilities than human-written code in its test set.
What if we built it on a no-code or low-code platform? The same questions apply, minus the dependency review. Access control and data location matter more, because the platform decides where your data lives.
Should we rebuild everything a non-developer made? Rarely. Most of these tools are right about the workflow and wrong about the engineering. Keeping the design and replacing the internals is usually cheaper, and it preserves the adoption you already have.
How do we stop this happening again? Give people a sanctioned way to build, and a checkpoint before production. Our AI proof-of-concept guide sets out the gate we use between "it works" and "it ships".
Where to start
If something built with AI is about to meet real users or real data, audit it first. It is a small piece of work next to a breach notification, and the findings almost always change the plan.
SoftBlues is a registered Anthropic Partner Network member and a Google Cloud Partner. We audit AI-assisted code because we write it. We use it before we sell it. If you want a second pair of eyes on an application before you scale it, or a safe setup for the next one, we will tell you honestly whether it needs an audit, a rebuild, or nothing at all.
See it in production
Systems we have built and run for clients, with the numbers that came out of them.
Related Articles
Build vs Buy AI: What UK Mid-Market Companies Should Build in 2026 (and What They Should Not)
Shadow AI at Work: What UK Companies Should Do About Unapproved AI Tools
