Can AI formalize mathematics without humans reading every proof? AutoIP shifts the review burden to statements
An unreviewed three-country project used Claude agents to build a 35,562-line Lean library for inverse-problem theory. Lean checked every proof, while deterministic tests exposed one textbook theorem whose hypothesis was far narrower than it appeared—but fewer than half the stated theorems had direct author review.
The short version
- What happened
- AutoIP contains 523 library files and 152 test files, totalling 22,312 lines of Lean library code and 13,250 test lines, with 51 formally stated theorems and 503 non-vacuity obligations.
- Who it affects
- Mathematicians may spend less time reading generated proof steps, but more time specifying definitions and attesting that formal statements preserve intended meaning.
- What remains unproven
- The manuscript is an unreviewed work in progress and reports one project in established linear inverse-problem theory.
Keep in mind
The manuscript is an unreviewed work in progress and reports one project in established linear inverse-problem theory.
Only 25 of 51 Lean-stated theorems and 22 constructed definitions had direct author review at the reported snapshot.
The workflow changed during development, so improvements across review rounds cannot be attributed separately to restructuring or newer models.
No controlled human baseline reports total review time, compute, token use, failure rate or cost per accepted statement.
One detected textbook-exposition problem does not estimate the prevalence of errors in mathematics or prove that every non-vacuity test is sufficient.
Source analysis · 3 linked sources. Primary analysed source date: 4 November 2026.
Read the full report · 10 min The evidence, methods, implications and limitations
The finding: proof checking became cheap, but meaning remained the human bottleneck
A new unreviewed project argues that AI agents can write a substantial body of formal mathematics without requiring people to read every proof line. AutoIP translates classical linear regularization theory—the mathematics used to recover information from noisy or incomplete measurements—into Lean 4. The proof assistant checks every formal step against shared foundations. The authors' proposed human task is narrower: compare each formal theorem or definition with its natural-language counterpart and confirm that the encoded statement says what the mathematician intended.
That division of labour is consequential because a perfect proof of the wrong formal statement is still the wrong result. AutoIP therefore does not claim that Lean or an AI agent understands the intended mathematics. It moves trust from thousands of generated proof steps into three places: the Lean kernel, the formal definitions and the human attestation that each formal statement matches its blueprint. The paper reports useful engineering evidence for this workflow, but it is a work in progress, has not been peer reviewed and has only partial direct author review.[1][2][3]
What is inside the library
The reported snapshot contains 51 definitions, including 14 cited from Mathlib, 15 predicates and 22 constructions. It lists 73 theorems: 22 cited from Mathlib and 51 stated in Lean. The broader result inventory includes 83 lemmas, 16 corollaries and five propositions. Across 523 library files and 152 test files, the project counts 22,312 lines of library code and 13,250 lines of tests. It also generates 503 non-vacuity obligations designed to show that hypotheses can hold and can fail in non-trivial settings.
The mathematical scope includes the Moore–Penrose inverse, source conditions, parameter-choice rules, convergence rates, optimality, spectral regularization, Tikhonov and Landweber methods, discretization, perturbed operators and balancing principles. These methods matter in imaging, sensing and other inverse problems where measurements do not directly reveal the object of interest. Yet the library covers established linear theory chosen partly because relevant functional analysis already exists in Mathlib. It does not demonstrate that the same process can reliably formalize novel nonlinear, statistical or machine-learning theory.[2][3]
The distinction that matters
Where trust sits in AutoIP
Different checks answer different questions; no single layer establishes all of them.
Blueprint
Authors state the intended mathematics
Natural-language target
Specification
Reviewer compares formal and informal statements
Meaning attestation
Proof
AI agents generate Lean code
Machine-readable derivation
Kernel and tests
Lean checks proof; tests probe non-vacuity
Formal correctness, not intent
How agents wrote and reviewed the code
The authors wrote a LaTeX blueprint whose nodes define the informal statements and dependencies. Claude Opus 5, and later Opus 5.5, wrote the Lean code. GPT-5.6 Sol and Claude agents also reviewed code and statement correspondence. Deterministic checks enforced the file organization, rejected new axioms and removed unused code. Each node records whether an author or agent judged the formal statement to match the informal one, and hashes make that approval expire when the statement or its dependencies change. Changing a proof alone does not invalidate a statement review.
This was not a preregistered comparison between human and AI formalizers. The workflow evolved after the first pass produced problems. In one early review, GPT-5.6 Sol raised about 300 code-quality objections; Claude Opus 5 acted on slightly more than half and rejected the rest. A separate Claude session then raised more than 450 new objections to already revised code written by the same model. After the team reorganized work into smaller, delimited nodes and changed model generation, three review rounds spanning 205 to 229 nodes found one mismatch in total. Restructuring and model change cannot be separated as causes.[2]
The denominator shows why ‘fully verified’ would overstate the result
Lean verifies that the submitted proofs type-check, but the project reports direct author review for 22 constructed definitions and 25 of the 51 theorems stated in Lean. All roughly 200 nodes had agent attestations, while only a subset had human attestations. The human-reviewed definitions include every construction of a new object, which targets an important risk, but the incomplete theorem coverage means the library should not be described as wholly human-validated. Open code helps outsiders inspect it; openness is not the same as completed expert review.
The authors estimate that one premium Claude seat over three months would have been sufficient for the development, although the work used several authors' plans, and one ChatGPT Plus subscription covered the GPT-5.6 Sol reviews. Those are retrospective subscription observations, not a controlled cost comparison with mathematicians. The paper does not report total tokens, wall-clock agent time, human review hours, failed generations or the labour needed to design and repair the workflow. It therefore supports feasibility, not a general claim that formalization is cheap in every field.[2]
Non-vacuity tests found a real problem in established exposition
For each specification, a deterministic program generated obligations requiring an example where the hypotheses hold and another where they fail. Agents then proved those obligations. This matters because a contradictory premise lets Lean prove a theorem that says nothing, while a premise that can hold only in a degenerate case may make a result far less general than readers assume. The paper reports 503 such obligations and describes one convergence theorem whose hypothesis, when applied to common parameter rules, effectively forced trivial operators or spaces.
The theorem itself was true, but the authors found that its advertised use was much narrower than the surrounding textbook and lecture-note prose suggested. After non-trivial witnesses were required, the suspect obligation remained stuck on a zero operator; an agent review explained the restriction, and the theorem was removed. The convergence results that had cited it could still be proved by other routes. This is evidence that formalization plus targeted tests can expose a gap in exposition. It is one documented case, not an estimate of error prevalence in textbooks.[2]
Formal correctness does not validate the original argument
AutoIP's generated proofs sometimes bypassed the informal proof route. Lean could therefore certify the intended conclusion even when a cited step in the prose did not support it. That distinction is subtle and essential. Statement alignment tells a reviewer that the formal theorem matches the intended theorem. Kernel checking tells them that some formal proof establishes it. Neither fact proves that the original natural-language proof was sound, historically faithful or pedagogically useful.
Definitions introduce another risk. Lean functions are total, so a function that is meaningful only on part of a domain may return a conventional 'junk value' elsewhere. An early dimension statement used a dimension function that returns zero on infinite-dimensional spaces, making the encoded result weaker than the informal lemma. AutoIP responded by defining functions on natural domains and adding hypotheses that rule out junk values. This illustrates why formalization needs domain experts who can read types and definitions, even when agents handle the proof construction.[2]
What changes for mathematicians and scientific software teams
For mathematicians, the proposed workflow could redirect scarce review time from low-level proof steps toward statement design, definitions and the connection between results. A domain expert would still need enough Lean literacy to recognize what a formal specification says, but not necessarily the skill to construct every proof. For students and researchers, an open formal library could make dependencies explicit and reveal when assumptions in neighbouring results do not fit together. Credit, responsibility and correction processes will need to distinguish blueprint authors, agent-generated code and human attestations.
Scientific software teams face a related lesson: passing automated tests does not establish that a requirement was specified correctly. A checker can enforce consistency with encoded rules while missing a flawed target, an omitted population or a meaningless edge case. AutoIP's use of hashes, expiring attestations and non-vacuity tests is relevant beyond mathematics because it links each approval to the exact object reviewed. The practical idea is promising; the evidence remains one self-reported project in one mathematical domain.[1][2][3]
What would change the assessment
Confidence would rise after independent mathematicians complete the outstanding statement reviews, reproduce the library from the blueprint and audit the examples the paper says were corrected. A versioned public record should show which nodes have human attestation, which were rejected and how changes propagate. Comparisons with human-led formalization could measure author and reviewer time, compute, defects, repair cycles and the usefulness of the resulting interfaces. Peer review should also examine whether the mathematical characterization of the textbook gap is accepted by specialists.
The case for generalization would strengthen if the workflow succeeded on unfamiliar, recent and disputed mathematics rather than settled linear theory close to existing Mathlib foundations. It would weaken if outside reviewers found silent statement drift, if proofs depended on unintended axioms or if experts could not keep pace with generated libraries. For now, AutoIP demonstrates a concrete architecture for agent-written, kernel-checked mathematics and a valuable warning: as proof generation becomes cheaper, the hardest review question may be whether people asked the machine to prove the right thing.[1][2][3]