The AI code scan is not the control. The remediation receipt is.

Twenty-seven provincial ministries. Roughly 3,400 repositories. Tax records, procurement files, social services case histories - all running on code that predates many of the people now responsible for it. That's the portfolio Alberta's Ministry of Technology and Innovation maintains, and until recently, nobody had a serious plan for reading all 466 million lines of it, let alone fixing what needed fixing.

There's no changelog worth trusting on code that old, no engineer left who remembers every original design call, and no year on the calendar with enough hours in it to review a library that size line by line. That's the room this story actually starts in: not a demo stage, but a mountain of old, sensitive, half-documented government systems that any security team would recognize on sight.

What Alberta actually built

Since 2025, according to a case study Anthropic published on July 6, Alberta has used Claude Code, running on both Opus and Sonnet, to review that portfolio, find vulnerabilities, and fix them. The headline number is the one that travels: a team scanned 466 million lines of code in about 20 hours, with roughly 50 agents working autonomously and in parallel. Alberta's own estimate is that a comparable traditional review would have taken around six and a half years.

That's a real number, and it's worth sitting with for a second. It's also the least interesting part of the story, because a fast scan by itself doesn't fix anything. What makes Alberta's approach a security program instead of a very large pile of suggestions is the two-stage routine underneath the headline: a rules engine flags known patterns first, and only then does Claude review those flags and cite the exact file and line for each one. Anthropic says the combination caught issues that traditional automated scanning tools had missed on their own.

Alberta didn't stop at finding problems. Where a vulnerability needed a fix, Claude Code could generate the patch, write it, and build it. Automated tests were often missing in a codebase this old, so Claude wrote tests first, giving the fix something to answer to besides its own confidence. Where the underlying code was too outdated or too tangled to patch safely, Claude rebuilt it in a more modern, maintainable language instead. That's the same logic behind Alberta's larger cleanup plan: one ministry alone runs 185 legacy applications, and the intent now is to analyze and consolidate them into 16.

None of those patches shipped on their own. Ministry engineers reviewed and approved every one before it went live.

The receipt is the actual control

That last sentence is the whole article, and it's worth being blunt about why.

A scan that runs in 20 hours can also produce a backlog no team can review in 20 hours. Fifty agents finding plausible vulnerabilities in parallel is not automatically fifty vulnerabilities a security team can verify, test, approve, and safely deploy fixes for in the same afternoon. "The AI found it" is not evidence of anything by itself. It's a claim, and claims need something to check them against. What turns an AI-generated finding into a decision a human can actually stand behind is a receipt: exact file and line, the control it maps to, the patch, the test result, the build result, and the name of the person who signed off.

Alberta's structure gets this mostly right by design, not by accident. The rules engine's flags aren't just handed off; Claude's review has to cite a specific location before a finding counts. Specialized agents, built on the Claude Agent SDK, split the work by role. A red-team agent probes the system from the outside and maps how it could actually be exploited. A blue-team agent checks defenses against an international security standard and writes remediation plans that point to exact files. Other agents check code quality and the clarity of public-facing writing. Every application gets checked against roughly 95 security controls on each pass, and the patch itself doesn't ship without a named ministry engineer reviewing it first.

Strip away the vendor framing and what's left is a recognizable shape: evidence, test, approval, in that order, every time. That's the operating pattern worth borrowing, whether or not the tool in question is Claude Code.

What goes wrong without one

Picture the same scan without the receipt discipline. Fifty agents return a thousand findings by lunch. Half of them are real. A third of the patches compile but weren't actually tested against the behavior they're supposed to preserve. Nobody can tell, at a glance, which fixes a human looked at and which ones just look plausible enough that nobody objected. Six months later, an auditor asks which vulnerabilities were patched, on what evidence, by whose approval. The answer lives in scattered chat logs instead of a record built to survive the question. That's exactly the kind of miss that should trigger a hard pause before the pilot expands, not a shrug and a promise to tighten things up next quarter.

That's the failure mode this whole approach is designed to prevent, and it's not particular to government software. It's what happens anywhere a fast, capable tool meets a slow, careful approval process and nobody wrote down where the seam between them is supposed to be. We made a version of this same argument about why an eval should test the receipt of an agent's work, not just its final answer: the score means nothing if you can't see what the agent actually touched. The logic holds even tighter here, since the "work" in question is a security patch touching tax records and case files.

It's also worth being honest about what this case study is and isn't. It's a vendor-published account of a customer's program, genuinely detailed, with specific numbers and a specific engineering shape, but not independently audited, and the public discussion around it so far has been thin. Read it as a well-documented example of an operating pattern, not as proof that every number will replicate exactly elsewhere.

Building the receipt for your own legacy code

You don't need 3,400 repositories or a government-scale rollout to use this pattern. You need one legacy application, a clear boundary for what an AI coding agent is allowed to touch, and a receipt format that survives review. That's the same discipline we've argued for before any AI workflow gets broader access to production systems, and a natural companion to the identity and spend controls we've written about for locking down Claude Code access at the team level.

Start smaller than Alberta did. Pick one repository, ideally one with real security debt and thin documentation, the kind every team already has one of. Before an agent touches it, decide what "found" has to prove: file and line, not just a category. Decide what "fixed" has to prove: a passing test, a successful build, not just a diff that reads well. Decide who has to sign off before a patch ships, and make that a named role, not an assumption. And decide when the application gets checked again, because a scan is a snapshot and security debt reaccumulates the moment nobody's watching.

That last point matters more than it sounds like it should. Alberta isn't treating this as a one-time cleanup; one ministry alone has 185 legacy applications running in production, and the plan is to analyze and consolidate them into 16 reusable applications going forward. A remediation receipt isn't just proof for the fixes already shipped. It's the input to deciding what gets rebuilt, what gets retired, and what gets left alone because nobody can justify the risk of touching it yet. If a scan like this is ever going to be worth the speed it promises, the receipt has to exist before the first patch ships, not reconstructed afterward when someone finally asks who approved it.

If you're carrying a legacy system with more security debt than review capacity, map one legacy system's AI remediation receipt with us. Bring one repository, one review boundary, and one patch-approval path. We'll help turn the scan into a workflow your team can actually stand behind, drawing on the same process automation and responsible AI workflow controls work we bring to any AI system before it reaches production data.