Claude Formalized Fermat’s Last Theorem: Why 13 Million Lines of Verified Mathematics Matter

The important thing about Claude’s 13-million-line Fermat’s Last Theorem project is not that an AI “solved” a famous problem in 11 days. Andrew Wiles and Richard Taylor’s work had already established the theorem decades ago; the breakthrough here is that a multi-agent Claude system translated an end-to-end proof into Lean code that a small trusted checker can verify.

For software engineers, that makes this less of a math-news curiosity and more of a sharp example of where LLM systems become genuinely useful: pair generation with a hard verifier, decompose a huge goal into dependencies, preserve state across agents, and make every intermediate artifact reusable. Thirteen million lines sound absurd until you realize that formal verification is deliberately hostile to hand-waving.

First, separate discovery from verification

Fermat’s Last Theorem says that there are no positive integers a, b, c, and n greater than 2 for which aⁿ + bⁿ = cⁿ. The human proof is famously deep: it connects a hypothetical counterexample to elliptic curves, modular forms, and a contradiction. It is not the sort of result where someone reads 129 pages, nods, and can honestly say every dependency is now beyond doubt.

That’s what Lean changes. Lean is a proof assistant: you state definitions, axioms, lemmas, and proof steps in a formal language, and its kernel checks whether each step follows from the allowed rules. An informal mathematical proof routinely skips “obvious” transformations and inherits decades of background results. A formal proof must name and type-check the actual path from assumptions to result.

Claude did not replace the intellectual history behind the theorem, and it did not make the proof human-readable in the way a good textbook does. It produced a different kind of artifact: an executable proof. That distinction matters when reading the headline. “Verified” is the big word, not “Fermat” and not “Claude.”

Why it took 13 million lines

The line count is not 13 million lines of novel mathematical insight. It is the expanded dependency graph needed to express advanced mathematics in a machine-checkable environment: definitions, coercions between number systems, library interfaces, lemmas that make implicit reasoning explicit, theorem statements, and the glue that connects them.

This is familiar territory if you’ve worked with production code. A compact product requirement can expand into schemas, migrations, authorization rules, test fixtures, observability, retries, failure handling, deployment definitions, and documentation. The implementation is longer not because every line is genius, but because real systems have interfaces and edge cases.

Formal math takes that principle to an extreme. The computer does not accept a proof because the author has a prestigious name, because the idea seems right, or because an expert can fill in the omitted middle. It accepts only a derivation that compiles under its logical rules. That strictness is why the artifact is valuable.

The engineering lesson is the harness, not the chatbot

Anthropic’s account makes clear that this was not a single prompt followed by a magical answer. Dozens of agents worked against a structured plan using Prove2Me, a collaboration system designed for formalization. The system tracked theorem statements as a directed acyclic graph, so agents could identify prerequisites, work in parallel, and reuse completed results instead of repeatedly rediscovering context.

That is exactly the missing layer in many “agentic” coding demos. A model can write a plausible function from a ticket. It struggles much more with a sprawling task where it must remember what is done, choose the next dependency, avoid conflicting changes, validate assumptions, and recover from partial failures. Bigger context windows help, but a durable external representation of project state helps more.

The useful pattern is straightforward:

1. Turn the objective into small claims or tasks with explicit inputs, outputs, and dependencies.
2. Give agents a shared source of truth: a task graph, issue tracker, typed interface, or proof plan—not merely a chat transcript.
3. Make every claimed result pass a cheap, deterministic verifier whenever possible: a compiler, type checker, test suite, linter, model checker, or proof kernel.
4. Persist validated intermediate artifacts so later agents build on facts rather than generated summaries.
5. Treat failed attempts as data. They can expose missing abstractions, bad task boundaries, or tests that need to be added.

What “verification” buys you with LLM output

LLMs are unusually good at producing locally convincing text. That is helpful for drafting code, but dangerous when correctness depends on a long chain of reasoning. A test suite catches some errors, a compiler catches another class, and a proof assistant catches a still stronger class: whether the formal claim logically follows from the formal assumptions.

This does not mean Lean makes all questions easy. You still have to formalize the right specification. You still have to decide whether the axioms and imported libraries are appropriate. And a formally verified implementation can faithfully satisfy a bad requirement. The verifier narrows the trust boundary; it doesn’t eliminate product judgment, security review, or domain expertise.

But narrowing the trust boundary is already an enormous win. Instead of asking, “Do we trust this entire model trajectory and every intermediate explanation?” you can ask, “Do we trust this relatively small checker, the specification, and the dependencies it accepts?” That shift is the same reason compilers, reproducible builds, and cryptographic signatures have outsized value in software engineering.

Where developers can apply this now

Most teams do not need Lean, and most codebases cannot be proven correct end to end. You can still take the Fermat project as a design prompt. Find the part of your workflow where a generated answer can be checked mechanically, then move agent effort upstream of that gate.

For example, have an agent generate a database migration but require it to run against a disposable production-shaped schema and verify forward and rollback behavior. Have it propose a refactor but accept it only after compilation, focused tests, static analysis, and a public API diff. Have it create infrastructure changes but evaluate them with policy-as-code and a plan review. The LLM supplies search and synthesis; deterministic tooling supplies the veto.

The next useful question for an AI feature is therefore not “Which model writes the cleverest answer?” It is “What will prove—or at least strongly check—that the answer is allowed to ship?” Claude’s FLT formalization matters because it demonstrates a compelling answer at extreme scale: when generation is attached to a rigorous verification loop and a well-designed collaborative harness, output stops being just persuasive text and starts becoming infrastructure other people can build on.