We fix what scanners can't catch.

The obvious approach doesn't work.

Point a generic security scanner at an AI-built repo and it produces a list. Most of the list is noise: known CVEs that don't apply, missing headers that don't matter, severity ratings that don't reflect blast radius. The actual bugs, the ones AI ships by default, are invisible to it, because they aren't known vulnerabilities. They're new code written by a model.

The hedged-findings problem dominates noise rates: every speculative finding spends human attention to dismiss, and that cost compounds across hundreds of findings. We built our process specifically to avoid this: to surface fewer findings, each of which actually matters.

The four phases of an audit.

Every audit follows the same shape. The discipline matters more than any single tool. It's how we avoid the "scanned and got two hundred findings, none of them matter" problem that wastes founders' time.

1. 01

   Probe the running app

   We start the way an attacker would: curl every API endpoint from a logged-out session, hit webhook URLs with bad signatures, inspect the client bundle for keys. These five-minute checks find roughly half of the critical issues in any AI-built app, before we read a single line of code.

2. 02

   Read the code AI wrote

   AI tools generate code in characteristic patterns. We know what those patterns are: where Lovable wires auth, where Bolt skips signature verification, where Cursor leaves refactor drift. We read for the patterns specific to whichever tool built your app.

3. 03

   Rank by blast radius

   Every finding gets a severity rating based on what a real exploit would actually do: data leak, financial loss, account takeover, denial of service. Findings that look alarming on a scanner but aren't reachable in practice get marked as such. We don't pad the count.

4. 04

   Write the negative tests

   On the Fix Sprint, every fix ships with tests that AI doesn't write: "unauthenticated request returns 401," "forged signature returns 400," "user A can't read user B's rows." These are the tests that catch regressions when the next AI prompt rewrites the same code six months from now.

AI tools write the happy path. We write the unhappy path.

AI tools write what the prompt asked for, and only what the prompt asked for. They almost never write the unhappy path: the negative tests, the rate limits, the "what if an attacker does this" code, the signature checks.

The result is code that demos beautifully and breaks the moment it meets a real user, a real attacker, or a real load curve. That gap shows up consistently across Lovable, Bolt, Cursor, v0, and Replit Agent: different tools, same blind spot. Once you know the shape of the gap, you can find it faster than any automated scanner.

We're not a scanner. We're not a SaaS. We're a small team that reads AI-generated code, names the patterns we find, and ships the fix.

We've shipped enough of this code to know how it breaks.

Two engineers. Twenty-plus years between us, in senior roles across multi-tenant SaaS, retail and point-of-sale systems, payments and banking infrastructure, and developer tooling. We've built things that scaled and things that didn't. Both lessons matter.

We started reading AI-generated codebases the way you'd read any other code: line by line, looking for the failure modes we already know. The patterns turned out to be consistent enough that the work became its own thing. That's what we sell now.

What this approach doesn't cover.

We read for the patterns AI tools ship by default. We don't do adversarial penetration testing of bespoke business logic. We don't cover compliance-style audits (SOC 2, ISO 27001; for those you want a different partner). And we don't catch zero-days in third-party dependencies the way a paid scanner can. If you need any of those, we'll tell you.