Claude wrote 180 million lines of proof code and found bugs years of testing missed

Anthropic's Claude model has produced roughly 180 million lines of mathematical proof code covering 123 open-source libraries in just a few weeks, and along the way it caught hundreds of bugs that conventional testing had missed. The work, carried out by Anthropic's Frontier Red Team together with partner Theorem, applies formal verification — the mathematical proof that software behaves correctly — to real-world code at a scale the field has never seen. For an industry now flooding codebases with AI-generated software, the experiment addresses the question that matters most: can a model not only write code, but prove that the code is safe?

The stakes are straightforward. Formal verification has always worked, but at a price almost nobody could pay. A team of specialists needed 20 person-years to formally verify seL4, a small operating-system kernel, which is why the technique stayed confined to extreme cases such as Airbus avionics software. Ordinary projects relied on testing instead — and testing, by definition, only checks the cases a developer thinks to try.

What did Claude actually do?

Claude did not write new software. It verified existing software, drawing its targets from Google's OSS-Fuzz security project, a long-running fuzzing program (a testing method that feeds programs random or malformed inputs to trigger crashes) that covers widely used open-source libraries.

The pipeline had three stages. Claude translated crash tests into mathematical problems, analyzed the compiled machine code — the low-level instructions a processor actually executes — and produced extensive proofs. An independent verification program called Rocq then checked the proofs automatically. According to Anthropic, the process needs almost no human reviewers.

The researchers describe the result as "fully autonomous" proof generation, with one caveat: the underlying tools and formal foundations were built by humans at Theorem. The automation sits on top of infrastructure people spent years constructing.

Which bugs did the process surface?

The bug findings give the project its practical weight. While generating proofs, Claude ran into hundreds of defects and was permitted to fix them itself. Many, the researchers say, would have slipped past conventional testing because they appear only under very specific conditions — an unusually large input file, or a particular sequence of memory accesses.

Two examples anchor the claim:

• During an effort to verify a widely used PDF reader, the team found as many security bugs in one week as are typically reported for that software in an entire year.
• In another application, Claude caught a logical error that had gone undetected for over a decade.

Even failure produced value, according to Anthropic: when a complete proof ultimately fails, the attempt still surfaces real bugs. A proof that cannot be finished is often a signal that the code itself contains a defect.

What are the limits?

Anthropic is explicit that "formally verified" does not mean "error-free." The proofs hold only under strict conditions:

• A specific processor architecture
• Single-threaded programs
• Inputs under 64 MB

In practice, the verified libraries run on different hardware and in different configurations than the proofs assume. A proof of correctness for one architecture and one execution model says nothing definitive about the others.

The compute cost is also steep. Individual proofs consume up to hundreds of millions of tokens, and Anthropic does not report total project costs. Formal verification at this scale is not cheap; it is simply cheaper than the 20-person-year alternative that preceded it.

There are signs of improvement. A smaller test run showed that proofs are reusable, and newer models are getting more efficient: Anthropic reports that Opus 5.5 solves half the proofs with about 40 percent fewer tokens than Opus 5. Efficiency, in other words, is trending in the right direction while coverage expands.

Why does this matter for AI-generated code?

The economics of software development hinge on trust. If AI can verify its own code, developers can trust AI-generated software more and spend less time reviewing it — savings that apply not just to verification but to the entire coding process. Review time, not generation time, is the bottleneck that limits how much automation the industry can absorb.

The project reframes the debate around AI coding tools. Anthropic's researchers argue the question is shifting from "Can AI program?" to "Can AI prove that the code it writes is safe?" If the answer is yes, the consequences could extend well beyond today's coding assistants, into any domain where software correctness carries safety or financial weight.

That framing carries a caveat of its own. A model that verifies code under defined conditions — one architecture, one thread, bounded inputs — proves less than a blanket safety guarantee. Anthropic acknowledges the gap between the two, and the gap is where most real-world software actually lives.

What comes next?

The roadmap already targets critical infrastructure. Theorem's plans include formal verification work on glibc, OpenSSL, and cURL — three libraries that underpin a substantial share of the internet's software stack. Anthropic expects formal verification with AI to soon become as practical as standard testing.

If that expectation holds, mathematical proof stops being a luxury reserved for avionics and becomes a routine step in ordinary software development. The 180 million lines of proof code are the first evidence that the transition is technically feasible. Whether the token costs fall far enough to make it economical at scale is the open question — and Opus 5.5's 40 percent efficiency gain is the earliest data point suggesting an answer.