What mathematicians should know about the Lean Theorem Prover: questions of reliability and AI

[This is a guest post by Thomas Hales. This blog post was initially written in a different file format and converted using AI. — T.] Mathematicians have been weighing in on what they value about mathematics. For me, what matters is the consistency of math and its unparalleled reliability in support of science and civilization. Formalization of Math A formal proof is a mathematical proof that has been exhaustively checked at the level of the foundations of math and the fundamental rules of logic. In theory, this might be done by hand, but because of the number of steps involved, this is generally done by computer, using software that is designed for the task. Examples of theorems that have been formalized include the four-color theorem, the Feit-Thompson (odd-order) theorem, the Kepler conjecture, sphere eversion, the sphere packing problem in 8 and 24 dimensions, Navier-Stokes forced blowup, and Fermat’s Last Theorem. The last three formalization projects have been completed this year and have brought widespread awareness of the potential of formalization. Software systems for formalization are variously called proof assistants, theorem provers, or interactive theorem provers. For the purpose of this post, these terms are used interchangeably. Many proof assistants have been developed over the years: Automath, HOL Light, Isabelle, Coq (renamed Rocq last year), Metamath, Mizar, and Lean. Freek Wiedijk edited a book “The Seventeen Provers of the World” that compares some of these proof assistants, giving a proof of the irrationality of the square root of 2 in each of them. Among mathematicians, the Lean theorem prover is the most popular, and this post will focus on Lean. Lean was developed and introduced by Leo de Moura in 2013, while at Microsoft. To our great benefit, de Moura persuaded Microsoft to make the software open-source. Kevin Hartnett’s book on the history of Lean, “The Proof in the Code”, states that Jeremy Avigad (the director of Carnegie Mellon’s new NSF institute ICARM) was the first user of Lean. He ran a Lean seminar in 2015 that I attended. In 2017, one of Jeremy’s graduate students, Mario Carneiro, working with Johannes Hölzl, took existing parts of Lean’s core library and started a separate Lean mathematical library, called mathlib. This library of formalized mathematics is now massive, containing nearly 300,000 theorems, over 100,000 definitions, 2.5 million lines of code, with over 700 contributors. Any definition or theorem in mathlib can be used to prove further theorems. For example, if a proof uses the Cauchy-Schwarz inequality, the result can be cited from the library rather than reproving it. Autoformalization is a practical reality In the past, researchers had to transcribe paper proofs into formal proofs by human labor. For example, the formal proof of the Kepler conjecture on sphere packings in three dimensions took about 20 human work-years to complete and consists of about 500,000 lines of proof scripts. For years, it has been a dream for many of us working in formalization to find ways to bring increased automation to the process. Autoformalization is the realization of that dream. Autoformalization is the formalization of mathematics by AI. AI reads the paper (say a pdf or tex file) and outputs the formal proof in Lean or some other proof assistant. Autoformalization has become a practical reality in 2026. Starting in late spring and summer of 2025, researchers were becoming increasingly bullish about autoformalization. Here are some milestones. Sep 2025, Math Inc. produced a quasi-autoformalization of the prime number theorem. The process was merely “quasi”, because humans had to intervene to give further guidance whenever the AI got stuck. Jan 2026, J. Urban posted an arXiv preprint “130k lines of formal topology in two weeks” that gave the autoformalization of large parts of Munkres’s topology textbook in a proof assistant based on set theory. Mar 2026. Approximately a week after announcing the completed formalization in 8 dimensions, Math Inc. announced an autoformalization of the sphere-packing problem in 24 dimensions, following the proof by Viazovska and her collaborators. This project generated about 500K SLOC (source lines of code) that golfing (or code pruning) later reduced to about 200K lines. May 2026, a group at Meta/Facebook Research autoformalized a large part of 26 mathematical textbooks in a project called ATLAS. From there, numerous theorems have been autoformalized. Particularly noteworthy is the autoformalization of Fermat’s Last Theorem, announced by Anthropic on September 4. This project generated 13 million lines of Lean in 11 days. The announcement of Navier-Stokes blowup with forcing on September 8 by OpenAI was accompanied by an autoformalization of the theorem in Lean. Looking forward, Urban stated in January, “We believe that (auto)formalization may become quite easy and ubiquitous in 2026, regardless of which proof assistant is used.” Autoformalization projects have been completed in various proof assistants using various LLMs, but we focus on Lean. “For [Jesse] Han, it represents even more: the beginning of a revolutionary transformation in mathematics, where extremely large-scale formalizations are commonplace” (IEEE Spectrum). Jared Lichtman announced the launch of MAP (the Mathematics Autoformalization Project) on Sept 8, 2026, which aims to translate “all known math into formal code”. He asks us to imagine the next one trillion lines of code. Is Lean reliable? Type theory. Lean is based on type theory; in fact, a particular dialect of type theory called CIC, the calculus of inductive constructions. This post is not intended to be a tutorial on type theory, and I will be brief. Russell’s famous paradox in 1901 (the set of all sets that are not an element of themselves….) led to a crisis in the foundations of math. Two solutions were proposed later that decade. (1) Zermelo’s axioms of set theory that disallow the creation of unsafe sets; (2) type theory that makes it a syntax error to create Russell-paradox-like entities. Type theory was introduced by Russell himself in 1903 in his book Principles of Mathematics, and it became part of the foundational system of Russell and Whitehead’s Principia. For mathematicians who are accustomed to set theory, B. Werner’s paper (1997) “Sets in Types, Types in Sets” gives some reassurance that whatever they have done in set theory can be translated into type theory, and whatever gets done in type theory can be translated back into set theory. More precisely, the paper shows that ZFC set theory can be encoded into CIC, and that a particular dialect of CIC can be encoded back into ZFC (augmented with a hierarchy of inaccessible cardinals). At the risk of simplifying matters to a ridiculous degree, we might say that “types are like disjoint sets”; each element in type theory “is an element of” exactly one type. The type of the natural number 2 is the natural number type; the type of e, the base of the natural logarithm, is the real number type, and so forth. The type of natural numbers is disjoint from the type of real numbers, and an explicit coercion (sending 2 to 2.0) is constructed from the type of natural numbers to the type of real numbers. When I give talks, I sometimes draw a picture of sets as a Venn diagram with nonempty intersections and a picture of types as bricks stacked against one another without intersection. Lean’s design One part of the Lean system is a general-purpose programming language (appropriately called the Lean programming language). Ordinary computer programs, such as a program to sort a list, can be written in this language, then compiled and run. The Lean system also provides a mathematical language, in which definitions can be written, theorems can be stated, and proof scripts can be written. The programming language and mathematical language are not independent entities. Rather, it is a single language that does both. Program code can be mixed with theorems about the correctness of the algorithms; mathematical proofs can be generated using programs. The proof scripts in Lean are parsed and go through a process called elaboration (a sort of compilation process for mathematics), then the proofs are checked by the Lean kernel. It is the kernel’s responsibility to check and verify the output of elaboration. The Lean kernel is several thousand lines of C++ code. The kernel is carefully engineered but extremely complex. We mentioned mathlib above, which consists of about 2.5M SLOC, written in the Lean language. The library has been elaborated, then checked by the kernel. If there is an unconditional false proof anywhere in these 2.5 million lines of code, it is the fault of the kernel or runtime for failing to reject a false proof. Any defect in the underlying type theory is a serious kernel defect, if it is implemented in code. Lean proofs should never be believed until they have been checked by the kernel. Additionally, a proof in Lean should not be accepted until a human audit is performed to ensure statement fidelity. Is the verified theorem what we think it is? Do the definitions in Lean correspond to what we think they should be? This task is generally massively easier than checking the proof itself. For instance, for Navier-Stokes, a human should check that the statement in Lean corresponds with Fefferman’s statement of the Millennium Prize Problem, and specifically that concepts such as the field of real numbers, partial derivatives, and measure are correctly defined in Lean. The comparator tool in Lean assists with this task. The tool can also perform additional checks, such as inspection for possible unauthorized axioms. Summer of Soundness Bugs