Formalizing Fermat’s Last Theorem with Large Language Models: From Proof Generation to Engineering Verification

What Does Formalizing a Mathematical Theorem Mean?

Formal mathematics transforms natural-language definitions, propositions, assumptions, inference steps, and conclusions into a machine-checkable logical expression.

Take Fermat’s Last Theorem as an example. The core statement is simple: for integer exponents greater than 2, there are no positive integer solutions to a certain equation. But for a machine to verify it, the following must be made explicit:

1. Whether numbers are natural numbers, integers, or rationals.
2. How conditions like “positive,” “nonzero,” and “greater than 2” are defined.
3. The exact type and rules for exponentiation.
4. Whether variables on both sides of the equation share a consistent scope.
5. Whether number-theoretic results used in the proof have already been formalized.
6. Whether recursion, induction, contradiction, and case analysis conform to the system’s rules.

Formalization is therefore not a sentence-by-sentence translation of a paper into code. It is a software engineering project that reconstructs a verifiable mathematical system: starting from basic definitions, building lemmas, theorems, and dependencies, and eventually producing a closed proof chain.

Why Is Fermat’s Last Theorem So Hard to Formalize?

The difficulty lies not just in the final statement. Modern proofs draw on algebra, number theory, elliptic curves, modular forms, and a vast array of intermediate results. Even when a natural-language proof is complete, formalization still must address several engineering challenges.

1. Long dependency chains

A top-level theorem typically depends on many intermediate propositions, each of which may depend on more basic definitions and already-verified results. If any link is missing, the upper proof cannot be compiled or checked.

This means an automated system cannot simply focus on the final goal. It must maintain a precise dependency graph, for example:

Basic algebraic properties
    ↓
Integer and prime properties
    ↓
Specific number-theoretic lemmas
    ↓
Intermediate structural theorems
    ↓
Core conversion propositions
    ↓
Target theorem

If the model only generates local proof fragments without understanding the dependency structure, it will frequently produce steps that appear reasonable but rely on conclusions that have not yet been established.

2. Natural language hides many implicit assumptions

Human mathematicians routinely omit obvious conditions: a variable belongs to integers, a quantity is nonzero, a function is continuous, or an object was defined earlier. Formal systems do not accept such implicit information. Every premise must be stated explicitly.

For example, in natural language, “for any positive integer n” already carries the type and range. In formal language, the same statement requires explicit variable typing, a positivity condition, and confirmation that subsequent operations apply to that type. A model must have strong context memory and type inference to reduce such errors.

3. Proof strategy requires multi-level planning

Complex theorems rarely succeed through continuous local reasoning. The system must first decide an overall route and then fill in details step by step. Common steps include:

• Transforming the target proposition into an equivalent, more tractable form.
• Classifying cases according to exponent properties.
• Reducing general cases to a few special ones.
• Introducing auxiliary structures or mappings.
• Invoking already verified foundational theorems.
• Proving edge cases and degenerate conditions separately.

This is similar to architectural design in software development. The model must not only “write proofs” but also know when to split a problem, when to reuse existing results, and when to retreat to more basic propositions.

How Should “Completion in About 30 Hours” Be Interpreted?

When a report claims a model completed a large formalization task in a short time, several different metrics must be distinguished.

First, the model may have generated the full formalization script. Second, the script may have been checked and accepted by a verification system. Third, the model may have solved the main hard parts while existing libraries, already-proved theorems, and engineering configurations were prepared in advance. The workload differs greatly across these scenarios.

A serious evaluation should disclose at least the following:

• Whether the process started from an empty environment.
• How many existing mathematics libraries were used.
• Whether the proof was generated entirely by the model.
• Whether any human intervention occurred for route selection or code modifications.
• Whether the verification process is reproducible.
• Whether the reported runtime includes compilation, retrieval, and failed retries.
• Whether the final result covers the complete theorem rather than a special case.
• Whether the proof script can pass verification again in a clean environment.

Therefore, “30 hours” is best understood as an end-to-end experimental cycle, not as a claim that the model independently reproduced centuries of mathematical development. What matters more is whether the model can work persistently on a complex formalization project and effectively handle feedback failures.

Core Capabilities of Models in Formal Proof

1. Proof goal decomposition

The model must split a large goal into multiple subgoals of appropriate granularity. Too-large subgoals make error location difficult; too-small subgoals create redundant work and excessive context.

An ideal decomposition considers both the mathematical structure and the acceptance criteria of the verification system. For instance, splitting “prove a certain property” into four stages—definition expansion, basic arithmetic transformations, condition propagation, and final conclusion—is usually more stable than attempting to generate the entire proof in one pass.

2. Syntax and type repair

A large fraction of failed formal proofs come not from mathematical errors but from type mismatches, variable scope errors, incorrect argument order, or expression forms that do not conform to system requirements. Based on verifier feedback, the model can try to:

• Add explicit type annotations.
• Adjust implicit parameters.
• Rewrite equalities into a standard form the system recognizes.
• Add necessary nonzero conditions.
• Split complex expressions into multiple intermediate propositions.
• Select operation theorems consistent with the current type.

This capability resembles compiler error repair, but it relies more heavily on mathematical semantics.

3. Lemma retrieval and reuse

Large formalization libraries already contain many basic results. An efficient model should not prove everything again; it should retrieve reusable lemmas based on the current goal and context.

Lemma retrieval can use names, types, symbol structures, and natural-language descriptions. Practical systems usually combine retrieval with generation: first search for candidate conclusions, then check whether their arguments match, and finally generate the calling code. Without strong retrieval, the model may repeatedly prove what already exists, leading to poor efficiency.

4. Feedback-driven iteration

Formal proof naturally fits a “generate–verify–repair” loop. After each generation, the verifier returns an error location and diagnostic information; the model then modifies the script using the current context.

A typical flow is:

Read current goal
  ↓
Generate local proof
  ↓
Submit to verifier
  ↓
Parse error message
  ↓
Classify as syntax, type, or strategy issue
  ↓
Modify code or replan route
  ↓
Verify again

Correct error classification is essential. Syntax errors can usually be fixed locally; type errors require checking definitions and arguments; strategy errors may mean the whole proof direction must change. If the model cannot distinguish these three, it will repeatedly patch the same wrong place.

Engineering Architecture for a Reliable Formalization System

Making a model work reliably on large proof projects requires more than a chat window. A proper engineering environment is needed.

1. Versioned proof repository

All definitions, lemmas, and proof scripts should be under version control. Each change must record the modification, verification result, and dependency impact, so the model does not overwrite already-correct parts during repeated attempts.

2. Incremental verification

Full-project verification can be expensive. The system should prioritize checking files and dependent modules affected by the current change. Incremental verification shortens feedback cycles and helps the model locate problems faster.

3. Independent trusted kernel

The model can propose proofs, but the final correctness must be confirmed by a small, auditable verification kernel. Model output should never be accepted as trustworthy on its own; only proof objects that pass independent checking have acceptable reliability.

4. Task state management

Complex tasks can take hours or even days. The system must persist:

• Current goal.
• Completed lemmas.
• Unresolved errors.
• Attempted strategies.
• Current file version.
• Verified intermediate results.
• Failure count and rollback points.

Without state management, the model will repeat the same attempts or forget useful context.

How to Evaluate Whether a Model Actually Improves Proof Efficiency

Counting only final success is insufficient. A more comprehensive evaluation system is needed.

Success rate

The ratio of proofs that pass across different difficulty levels, mathematical fields, and formalization styles.

First-pass rate

The ratio of proofs that pass verification on the first try. This metric reflects generation quality but does not replace overall efficiency evaluation.

Average repair rounds

Record the number of verify–repair cycles from first failure to final success. Fewer rounds usually indicate the model uses error feedback more effectively.

Human intervention ratio

Parts where humans choose proof routes, modify key code, or supply mathematical ideas should be counted separately. Only then can we distinguish “model-assisted completion” from “model-autonomous completion.”

Proof maintainability

Short but cryptic proofs are not necessarily better than clear, modular ones. Long-term projects care about readability, reusability, and adaptability to library upgrades.

Practical Recommendations for Developers and Researchers

To use large models for formal mathematics or high-assurance code generation, consider the following:

1. Start with a small verification loop: Begin with simple algebraic propositions to ensure the model can read goals, generate code, and handle errors.
2. Prefer modular goals: Split large theorems into definitions, basic properties, core lemmas, and final composition.
3. Keep human-designed overall routes: Models are good at local expansion and error repair, but the macro strategy of complex projects still needs expert oversight.
4. Limit the scope of automatic changes: Let the model modify only the current failing module, avoiding damage to already-verified content.
5. Record all verification results: Both success and failure samples can improve prompt templates, retrieval strategies, and task scheduling.
6. Insist on independent verification: Any conclusion generated by the model must pass formal checking or another independent validation process.
7. Prioritize reproducibility: The same proof should be rebuildable in a clean environment, not dependent on temporary state or undocumented manual operations.

Conclusion

The involvement of large models in formalizing complex mathematical statements like Fermat’s Last Theorem does not mean machines have replaced mathematicians. It means mathematical research is gradually gaining the automated traits of software engineering: problems are broken into modules, proofs are compiled and verified, errors are fixed through feedback loops, and final results can be reproduced in an independent environment.

In the future, the value of models may lie more in organizing and accelerating proof engineering—including lemma discovery, dependency management, formalization transfer, error diagnosis, and repetitive verification. For developers, the most worthwhile direction is not chasing one-shot complete proof generation but building stable “plan–generate–verify–repair” systems. Only by combining model capabilities with rigorous formal tools, version control, and human review can complex mathematical formalization move from demonstration experiments toward reliable production practice.