We fed our AI a deliberately broken app. Here's what it fixed first.

Every security tool we tried had the same problem. You point it at a codebase, it thinks for a minute, and then it dumps a wall of findings on you — 3 critical, 12 high, 31 medium, 18 low. Technically accurate. Completely unhelpful at 5pm on a Friday before a release.

So we built the opposite of that. We took a small, deliberately vulnerable Node.js API and asked one question: if you could only fix three things tonight, what would they be?

The findings weren't the hard part

Running Semgrep, Trivy, Gitleaks and Checkov gave us the raw material. That part is solved — good scanners have existed for years. The hard part is judgement. A hardcoded cloud credential and a missing security header are both "findings", but only one of them ends up in a breach post-mortem.

Our AI engineer reads each finding *in context* and scores it the way a senior engineer would:

• Is it reachable from the internet, or buried behind three internal services?
• Does exploiting it need authentication, or can anyone with a browser do it?
• What does it actually expose — a log line, or your entire user table?

What it picked

Out of 64 findings, it flagged three as P0:

• Broken access control (IDOR) on /api/users/:id — no ownership check, so any logged-in user could read anyone's record.
• A hardcoded cloud credential sitting in a config file that had been committed months ago.
• A command-injection path in a reporting endpoint.

Then it did the part that actually saves time: it wrote the fix, we applied it, and it re-verified against a fresh scan. The security score went from 72 to 94, criticals from 3 to 0.

The takeaway

Scanners tell you what's wrong. They don't tell you what to do about it, in what order, or whether your fix actually worked. That gap — between "here are 64 findings" and "here are the three that matter and here's the patch" — is the entire job. It's the job we automated.