# AI-Generated Code Audit and Hardening for Fast-Moving Teams

DreamLabs is an AI-powered app development agency in California — a fractional product team for mobile and web apps, from strategy to launch.

Your repository was written mostly by Claude Code, Cursor, or Copilot, and it works. We read it the way a security reviewer or an acquirer would, prove what we find, and fix what matters — in weeks, at a fraction of a rebuild.

## Frequently asked questions

### How is this different from a penetration test?

A pentest probes the running system from the outside and tells you what an attacker can reach today. An audit reads the code, the configuration, and the infrastructure, which surfaces the things a pentest structurally cannot: the authorization check that exists on one endpoint and not its sibling, the permission rule that happens to be unreachable, the migration that never ran in production, the dependency with a known advisory. They are complementary, and if you need both we will say so.

### We used Cursor and Claude Code, not a no-code builder. Does this still apply?

That is exactly who this is for. Agent-written repositories are real engineering artifacts with real velocity behind them, and the failure modes are specific rather than catastrophic: duplication instead of abstraction, tests that assert the implementation, validation in the wrong layer, and a hundred small confident decisions nobody reviewed at the speed they arrived. The code is usually far better than a builder's output. It has just never been read end to end by someone whose job was to read it.

### Will you tell us to rewrite everything?

Almost never, and we would rather say so upfront than have you brace for it. Most audits end with a prioritized fix list measured in days and weeks. A rebuild recommendation has to earn itself with arithmetic — what maintaining this costs per quarter versus what replacing it costs once — and if the numbers do not support it, we will tell you the codebase is fine and take the smaller engagement.

### Can we keep shipping while the audit runs?

Yes. We work read-only against a commit, and your team keeps merging. If something significant lands mid-audit we fold it in. The only thing we ask for is a short conversation with whoever knows the system best, because thirty minutes of context usually saves a day of inference.

### How long does it take and what does it cost?

Most audits run one to two weeks depending on the size of the codebase, and are priced well below a rebuild — the point is to find out what you are dealing with before committing to anything larger. Fixing what we find is scoped separately, after you have the report, so you are never buying remediation for problems that turned out not to exist.

## Where AI-written codebases quietly break

This is a different situation from a no-code or app-builder migration, and it deserves saying plainly: you have engineers, you have a repository, and the code is real. You shipped faster than you could have any other way because AI wrote most of it. That was the right call, and it is how our own team works every day.

The problem is what AI-written code is good at. It produces work that runs, reads idiomatically, and looks reviewed. What it does poorly compounds quietly: it repeats itself instead of abstracting, invents a second way to do something the codebase already does, writes tests that assert the implementation rather than the behavior, validates input on the client where a user can walk around it, handles the path the prompt described and no other, and is confidently wrong in a register that reads as correct. None of that surfaces in code review when the reviewer is moving as fast as the generator — and the faster your team ships, the less anyone has read the whole thing.

The trigger is almost always external. An enterprise customer sends a security questionnaire. An investor's technical diligence asks who wrote this and how you know it is safe. A new engineer takes three weeks to become productive in a codebase that has four ways to fetch a user. Or there is an incident, and nobody in the room can say with confidence what else is affected. Any of those is the moment to have someone read the whole thing with fresh eyes, before the answer matters more than it does today.

## The full read, not a spot check

An audit that samples a few files tells you how the code looks. We read the repository, the infrastructure, and the running product, because the gap between them is where the real findings live.

- **Security.** Authorization enforced on the server rather than in the interface, object-level access (can user A load user B's record by changing an ID), secrets and keys reaching the client, input validation, webhook verification, injection surfaces, and dependency and supply-chain risk.
- **Data.** Schema constraints, indexes, foreign keys, migration history, whether backups exist and whether a restore has ever been rehearsed, plus how personal data is stored, logged, and retained.
- **Correctness.** The tests that exist versus the tests that matter — assertions that only restate the implementation prove nothing — alongside error handling, retries, and what happens on the failure paths nobody prompted for.
- **Architecture.** Duplication, module boundaries, how many ways the codebase does the same thing, dead paths still shipping to users, and framework features being reimplemented by hand.
- **Operations.** Separate environments, CI/CD, observability, alerting, rollback, and whether anyone could diagnose a 3am incident from what is written down.
- **Performance and cost.** N+1 queries, unbounded reads, missing pagination and caching, and the AI-era one nobody budgets for: model-call patterns and token spend inside your own product.
- **The human layer.** Whether a competent engineer who has never seen this repository can be productive in it, which is the single best proxy for what it will cost you to maintain.

## A report you can act on this week

The deliverable is a written report, not a scanner dump: every finding with its reproduction, its severity, its blast radius, and an estimate of what fixing it costs — prioritized into this week, this quarter, and never. It is written so an engineer can act on it and a non-engineer can understand what is at stake, because the person who commissioned it is often not the person who will fix it.

From there the fixes are yours to make or ours to ship. This is deliberately a smaller engagement than a migration, and for a codebase that is fundamentally sound it is usually the right one. If the audit finds otherwise, you will have the evidence to make that call properly instead of guessing.

## The audit, step by step

### Read the Whole Thing

Not a sample. Senior engineers go through the repository, the infrastructure configuration, and the running product side by side, because generated code frequently claims behavior the deployment does not have. We work read-only and out of your way, so your team keeps shipping through the audit rather than pausing for it.

### Threat-Model and Verify

Findings get tested, not asserted. Every security issue we report comes with a reproduction — the request, the account, the steps — so nobody has to take our word for it and nobody wastes a sprint chasing something theoretical. This is also the stage that separates the genuinely dangerous from the merely untidy, which is most of what a checklist-driven audit gets wrong.

### Report and Prioritize

You get a written report with each finding scored by severity, blast radius, and effort to fix, split into what to fix this week, what belongs in this quarter, and what is fine to leave alone forever. It is written to be read by both an engineer and whoever asked the question that started this — a customer's security team, a board, a founder.

### Fix It, or Hand It Over

Some teams take the report and do the work themselves, which is a completely legitimate outcome and one we scope for. Others want the criticals closed by the people who found them, which we do in a short focused engagement. And occasionally the honest answer is that hardening is not enough and the foundation needs rebuilding — in which case we show you the arithmetic rather than just asserting it.

## Links

- Full page: https://www.dreamlabs.pro/services/ai-generated-code-audit
- Offerings & pricing: https://www.dreamlabs.pro/offerings
- Contact: https://www.dreamlabs.pro/contact
