In addition to what others added below you might be interested in this postmortem <a href="https:&#x2F;&#x2F;leodemoura.github.io&#x2F;blog&#x2F;2026-8-24-postmortem-for-the-kernel-soundness-bug-hunt&#x2F;" rel="nofollow">https:&#x2F;&#x2F;leodemoura.github.io&#x2F;blog&#x2F;2026-8-24-postmortem-for-t...</a>

You can’t, so you keep the kernel small. The Lean tactics language is rich, so users can autogenerate proofs for the truly trivial bits, but the core language is checkable in dependent type theory.Kernel bugs, like compiler bugs, exist. As of now, a prover is considered good if it has no known bugs that would thwart a mathematician working in good faith. It’s not considered responsible yet for being impervious to adverse users, but that may change in the age of Ai.

You can only do so in another framework that might itself have bugs.Lean is called that because the hope is the part that has to be correct by inspection (&quot;the kernel&quot;) is small or &quot;lean&quot;.The kernel does have bugs sometimes.

You haven&#x27;t thought that through. The regress obviously isn&#x27;t infinite, and it bottoms out in things that are immediately true by inspection. And seriously, how likely is it that you have stumbled upon a fundamental problem with the whole notion of automated proof that no one in the field has thought of?<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=RxV4PQcJ1fw" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=RxV4PQcJ1fw</a> (&quot;The Proof in the Code: How Lean Is Quietly Rewriting Trust in Math&quot;)

Serious question: how do you prove that the Lean interpreter itself (not to mention the toolchain built around it) is error-free? Isn&#x27;t this turtles all the way down to some degree?

Kevin might not care, but I care more about building the foundation for future proofs and human understanding than I do about this particular result.

I believe Lean supports a signature search mechanism. E.g. Haskell has Hoogle, Lean has Loogle. So in many ways it&#x27;s actually easier to search for &quot;library&quot; code than in most languages, because the type tells you everything you need to know and you don&#x27;t need to care about the implementation.

My anecdotal experience is that while LLMs are quite good at closing theorems given an LSP to inspect the proof-tree, they suffer from similar kind of problems with proofs as they do with bigger codebases in any language -- finding reusable parts that can be built into libraries (that&#x27;s lemmas in Lean 4 sense). However, Buzzard has many times said that he wouldn&#x27;t care how big the proof is and how ugly it would be, as long as there would be a proof.

I wonder if any piece of the lean code is in a shape which means it could be contributed to one of the existing Lean libraries.My experience is that it takes a lot of human input to make Fable write code nice enough for a formalisation library others can work on. But since this is certainly a lot of prerequisites formalised as well, it would be nice if not all of the effort was wasted on one capstone proof!
(Repost of a earlier comment, but I feel it fits better here)

This is a very impressive result. Bravo to that team.

Front-page discussion: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=49568506">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=49568506</a>

Now we have what Fermat tried to write in the margin: aa2d8b34692b16c70f699536de0d8e75b9a3e9ef

Fermat's Last Theorem in Lean 4