Why does Fermat’s Last Theorem still matter?
Fermat’s Last Theorem was already accepted mathematics before Anthropic formalized it. Andrew Wiles and Richard Taylor’s 1995 proof had settled the question, after centuries of failed attempts and a 129-page argument that took months to verify. So why spend 13 million lines of code proving it again?
The answer is not that the theorem needed a new mathematical solution. Its importance is that the proof was translated into Lean 4, where a computer can check every logical step. Anthropic says its Claude agents produced about 13 million lines of Lean code, proved roughly 30,300 intermediate theorems, and used 29,511 of them in the final result. Two independent checkers, comparator and nanoda, accepted the proof.
That changes the practical status of a very complicated argument. Human mathematicians can review ideas and calculations, but long proofs can contain gaps that are difficult to find. Wiles’s original proof famously needed a critical repair after a reviewer exposed a problem. A machine-checked version does not make the mathematics simpler, but it makes the chain of formal deductions far easier to test consistently.
The result also marks a milestone for formal mathematics. Kevin Buzzard, who leads a human FLT formalization project at Imperial College London, said the work completes Freek Wiedijk’s 20-year-old list of 100 formalization challenges. He also stressed that it tells mathematicians essentially nothing new about the theorem itself. Its value lies elsewhere: it shows what automated formalization can now accomplish.
The lasting lesson is simple: formalization is not mainly about finding new answers. It is about making existing answers precise enough for a small trusted checker to verify.
What did Anthropic’s AI actually produce?
Anthropic’s AI did not return a single file containing a short proof. It assembled a large Lean repository that proves Fermat’s Last Theorem through 29,511 theorems, supported by about 533,000 local lemmas and 60,475 Lean modules. The final tree contains about 13 million lines of Lean, or roughly 10.5 million after removing generated boilerplate.
The surprising part is that the result is closer to a compiled software project than a polished mathematical manuscript. Dozens of agents worked for 11 days, consuming about 6 billion output tokens. The internal research model was described as roughly comparable to Claude Fable 5.1. About 7% of the final non-boilerplate lines came from failed earlier attempts, meaning the repository preserves some of the history of the search, not just its successful endpoint.
Anthropic also produced a 390 MB `html/` directory to make the project usable. It contains a page for every theorem, its exact Lean statement, citations, incoming and outgoing dependencies, and expandable graphs. The English explanations are generated automatically, while the Lean statements remain authoritative.
This matters because “13 million lines” does not mean the AI wrote 13 million lines of original mathematics from scratch. The repository includes generated structure, supporting infrastructure, and material from existing projects. Anthropic’s attribution process identified 106 files containing material from the Imperial College London FLT project and `flt-regular`, plus 23 files reproducing Mathlib text.
The practical takeaway is simple: the AI produced a vast, checkable proof artifact, not merely an answer. Its value depends on the compiler, dependencies, attribution, and tools that let humans inspect it.
How can 13 million lines become one trusted theorem?
Thirteen million lines sounds too large for anyone to inspect line by line. That is not how the result earns trust. Lean checks each formal statement with a small trusted core, rather than asking a person to read every generated line.
The proof is divided into declarations: definitions, lemmas, and theorems. Each declaration must type-check before Lean accepts it. Later results can depend on earlier ones, creating a chain that leads to Fermat’s Last Theorem. Anthropic reports 30,300 proved theorems, with 29,500 used in the final proof. Most of the code is therefore supporting mathematics, not repeated copies of the final claim.
The checker relies on three standard axioms: `propext`, `Classical.choice`, and `Quot.sound`. These are explicit foundations, not hidden assumptions added by the AI. The project also builds on Mathlib and adapted files from the Imperial FLT and `flt-regular` projects. The README records 106 adapted files, including 90 from Imperial FLT, plus 23 files reproducing Mathlib text.
The scale still creates an engineering problem. Mathlib version 4.33.0 lists 1,052,234 declarations, while a `nanoda` check produced a 37.8 GB export. Building the project took 5 hours and 32 minutes at 96 jobs, with peak memory of 153 GB. A comparator run took 14 hours and 46 minutes and reached 230 GB.
The key takeaway is simple: trust comes from repeatable checking, not human review of every line. The code can be enormous because the final question is much smaller: does Lean’s trusted kernel accept the complete chain from its stated axioms to the theorem?
Why is Lean’s small axiom base important?
A formal proof is only as trustworthy as the machinery checking it. Lean’s small axiom base matters because it keeps that machinery easier to inspect: fewer foundational assumptions stand between the written proof and the final verification.
That does not make the mathematics simple. Claude’s formalization still produced 13 million lines of Lean code and proved 29,500 intermediate theorems. The point is that all of those steps were expressed in a system whose compiler could check them. A Lean proof does not receive partial credit for sounding convincing. The compiler either verifies it or rejects it.
This creates a useful boundary. Wiles supplied the mathematical breakthrough in 1995, and Claude did not discover Fermat’s Last Theorem or replace that work. Instead, Claude translated the proof into Lean’s strict language, where every dependency had to connect correctly and every required result had to be established in a form the system accepted.
A smaller axiom base also makes the trust question more focused. Readers do not need to trust an enormous collection of informal explanations or accept that a plausible argument probably contains no gaps. They need to examine the formal system and its checking process, then verify that the compiled proof passes. That is a much narrower task than checking 13 million lines by hand.
The practical implication is important for mathematics and for AI evaluation. Formalization is difficult to fake because the output must compile. Fast completion, by itself, proves little. A successful Lean build provides a clear answer to the central question: did the submitted proof satisfy the rules?
The takeaway is simple: Lean’s small foundation does not shorten the proof. It makes the proof’s trust boundary clearer.
What did the Claude agents reuse from human work?
Claude did not start with Fermat’s equation and discover a new proof. The mathematics came from Andrew Wiles’s 1995 proof, which itself built on work by Gerhard Frey, Jean-Pierre Serre, and Ken Ribet. The agents’ task was to express that human argument in Lean 4, a language whose kernel can check every logical step.
That distinction matters. A published proof can say that a result follows from a deep theorem. Lean cannot simply accept that sentence. It needs the theorem stated precisely, all of its assumptions recorded, and a chain of verified steps connecting it to the conclusion. For Fermat’s Last Theorem, that meant formalizing the machinery behind Wiles’s route through elliptic curves, modular forms, and Galois representation theory.
Claude also worked within the existing Lean and Mathlib ecosystem rather than replacing it. Mathlib already contains a large body of formalized mathematics, but this project still grew to more than five times Mathlib’s size. The final proof included roughly 29,500 to 30,300 supporting theorems, including mathematics in areas that had never been formalized before.
So the reused material existed at several levels: the core mathematical strategy from Wiles, earlier results from Frey, Serre, and Ribet, and the established Lean infrastructure and library. Claude supplied the enormous amount of translation and connective work needed to make those ideas machine-checkable.
The important takeaway is that this was not an AI replacement for the mathematicians who created the proof. It was an AI effort to turn their mathematics into a form where a computer could verify every dependency.
How did comparator and nanoda check the result?
The result was not checked by asking another language model whether the proof looked convincing. It was checked by Lean, a proof system that can verify each formal step according to its rules.
The available research does not explain the internal design of tools called Comparator or Nanoda, so it would be inaccurate to claim they independently re-proved the theorem, compared every line, or used a particular checking algorithm. What the research does establish is the role of machine verification: Claude produced a Lean 4 proof, and Lean checked whether the complete formal argument compiled correctly.
That distinction matters. A normal mathematical referee reads an argument and decides whether each step appears valid. For a proof this large, that process could take years. A machine checker instead works from precise definitions and allowed rules. If a step does not follow, the formal proof fails. If the whole Lean project builds successfully, the result has passed the checks encoded in the Lean system and its mathematical libraries.
The scale was substantial. The proof contained more than 13 million lines of code and relied on roughly 29,500 supporting theorems, including mathematics that had not previously been formalized. Lean therefore checked not only the final Fermat’s Last Theorem statement, but also the many results needed to reach it.
Human review still had a role. Kevin Buzzard reviewed the work, building on his earlier Lean formalization efforts. But the central guarantee came from the machine-checkable artifact, not from Claude’s confidence or a reader’s impression.
The takeaway is simple: Comparator and Nanoda should not be credited with checks the sources do not describe. The documented check was Lean compilation and verification of the entire formal proof.
Why does Kevin Buzzard say the proof adds little new mathematics?
The key fact is that Fermat’s Last Theorem was already proved in 1995. Sir Andrew Wiles established the result after more than 350 years of work since Pierre de Fermat first conjectured it. Claude did not find a new argument or replace Wiles’s strategy. It converted that existing proof into Lean 4 code that a computer can check.
That distinction matters because the formal proof is enormous. It contains more than 13 million lines of code and roughly 29,500 supporting theorems. Some of those supporting results cover areas of mathematics that had never been formalized before. But formalizing a theorem is different from discovering one. The work makes the logical structure explicit, defines every object precisely, and supplies every intermediate step in a form Lean’s kernel can verify. It does not, by itself, make Fermat’s Last Theorem a new mathematical result.
Buzzard’s role helps explain the point. He reviewed the final proof, and his own Lean work on Fermat’s Last Theorem helped build the foundation for the project. The achievement is therefore less about changing the mathematics and more about changing how its correctness can be checked.
On paper, a proof can be reviewed by mathematicians over years. In Lean, the finished code can be checked by the Lean kernel, an independent nanoda kernel, and Mathlib’s comparator tool. That provides a different kind of confidence: not a new conclusion, but a machine-verifiable record of the existing one.
The takeaway is simple: Claude formalized Wiles’s proof. It did not re-prove Fermat’s Last Theorem with new mathematics.
What does this reveal about AI autoformalization?
Fermat’s Last Theorem shows that AI autoformalization is no longer just about converting a short proof into computer code. Claude’s result required 13 million lines of Lean and roughly 29,500 intermediate theorems. The original mathematics was already known, but turning it into a form that a machine could check required a huge amount of structured work.
The surprising part is that the model did not handle this as one continuous task. Anthropic used numerous AI agents, each assigned smaller pieces of the proof. Claude worked autonomously for 11 days, while human experts provided occasional high-level instructions. The agents also sometimes lost track of the project’s state and stopped collaborating effectively. Progress improved when they used Prove2Me, a tool built for human mathematical collaboration, to track completed work and choose the next tasks.
That detail matters. Autoformalization is not simply an AI reading a theorem and producing reliable code in one pass. It is a coordination problem as much as a translation problem. The proof had to be broken into layers, connected through intermediate results, and kept consistent across a long-running project.
The result also suggests that formalized mathematics can become useful infrastructure. Buzzard said the work covered algebra, harmonic analysis, geometry, and number theory, and showed that AI-created formalization artefacts were enough to build upon. The proof is more than five times the size of all previous work in Mathlib, which contains about 2 million lines.
The takeaway is clear: AI autoformalization is beginning to scale, but its success depends on memory, coordination, and verification. The machine can produce the code, yet reliable progress still requires a system that keeps many contributors aligned.
Where could machine-checked reasoning help engineering teams?
Engineering teams often rely on reviews to catch mistakes in complex designs. That works, but it depends on people understanding the same details and noticing the same failure modes. Fermat’s Last Theorem shows a different possibility: a system can check a formal argument line by line, without relying on a human referee’s judgment.
The practical lesson is not that every engineering document should become 13 million lines of Lean. Claude’s proof is unusually large, used roughly six billion output tokens, and is likely longer than necessary because it was produced by a machine. Formalization also depends on shared foundations. Anthropic’s proof builds on Mathlib, which was created by hundreds of mathematicians over years, while the Lean FRO maintains the proof assistant infrastructure.
For engineering teams, the useful pattern is narrower. A critical rule, interface, or safety condition could be expressed in a formal language and checked mechanically. A shared library could provide trusted definitions and reusable components. Automated checks could then test whether a new design still satisfies those conditions, rather than asking reviewers to reconstruct every detail from prose.
This would not remove human judgment. People would still decide what the requirements mean, which assumptions are acceptable, and whether the formal statement matches the real system. But once those choices are encoded, the checking itself becomes repeatable. The FLT result was checked against Lean’s standard axioms, and a separate comparator verified that its theorem statement matched Mathlib’s canonical version.
The takeaway is simple: machine-checked reasoning is most valuable where mistakes are expensive and requirements can be stated precisely. Its cost is substantial, but so is the potential reduction in review burden and unnoticed errors.
What should leaders learn before trusting AI-generated proofs?
The first lesson is that generating a proof and verifying a proof are different jobs. Claude’s Fermat’s Last Theorem result was valuable because Lean checked the final logic, not because the model sounded convincing. Human readers can miss one broken link in a long argument. A proof assistant checks each link in the formal system.
That does not make the work effortless or automatic. Claude produced 13 million lines of Lean code, proved 30,300 theorems along the way, and used 29,500 in the final proof. The result was more than five times the size of Mathlib, the main library it built on. A large output is not the same as a clear explanation. It can make review harder unless the system also provides a useful structure for understanding what it has done.
Leaders should also separate the trusted core from the surrounding process. Lean can verify formal logic, but humans still decide how to translate an informal proof into that language, which assumptions to use, and whether the formal statement matches the intended mathematical claim. Claude received occasional high-level direction from Tianyi Peng, including priorities for major steps. That human guidance was part of the process.
The practical lesson is to require machine-checkable results, visible dependencies, and human review of the formalization’s meaning. AI may reduce the years required to evaluate new mathematics, but trust should come from independent checks and clear boundaries, not from the model’s confidence or the size of its output. Formal verification can make knowledge easier to trust, provided leaders treat it as a verification system, not a substitute for judgment.