Will we ever see a soundness bug in the lean kernel again?<p>To a software developer the question seems insane. There were bugs in the past, of course there will be more.<p>When we see those bugs, what will it mean for AI lean proofs? Can we trust them?<p>This whole thing boils down to trust.<p>We can trust human verifications highly because of community and reputation and human proof-of-work. Humans sometimes lie about math results but it's rare because of this. They make mistakes and those mistakes are discovered by communities who are themselves largely trustworthy because of this.<p>LLMs don't care about reputation. They hallucinate and fabricate often. In harnesses they literally try to cheat and bend rules, which is a disaster for knowledge that is encoded in rules. So we have to rely on proof checkers.<p>The problem is, how trustworthy are proof checkers? Are there bugs? And is the underlying theory itself free of paradoxes and unknowables and mathematical "bugs" that can be exploited? Imagine a human mathematician hell bent on deceiving other mathematicians - would we trust their breakthroughs, even with a verifier?<p>Because of these properties, the final backstop has to be humans, and rooted in the community and proof-of-work based human trust system. At the moment people are trusting the tools too much.<p>Prediction: bugs will be found by humans using AI tools that call into question the Navier-Stokes proof.
You might be interested in the con leche project. A subset of the Lean theorem prover which was sufficient to prove the entire contents of Lean mathlib has been proven consistent.
It seems like very important work and was discussed in the article with some caveats.<p>Maybe I am being too skeptical about something I don't understand very well, but I'm not completely convinced it means no more kernel bugs will be found.<p>What does it mean for con leche if further lean kernel bugs are found? What if the bugs affect con leche's correctness itself?
The existence of an undiscovered soundness bug doesn't make everything proven in Lean illicit. The proof would have to exploit the bug. People build houses on sound foundations even though the tectonic situation under them might not be sound.<p>> Because of these properties, the final backstop has to be humans...<p>The post has clearly stated that the work on Lean's underlying metatheory is not done, and requires more work. It's not inconceivable that computer formal verification could reach the trustworthiness of math itself.
> The existence of an undiscovered soundness bug doesn't make everything proven in Lean illicit. The proof would have to exploit the bug.<p>Yes, correct. The proofs would have to be checked to make sure they don't exploit the bug.<p>> computer formal verification could reach the trustworthiness of math itself.<p>Yes, it could. I don't think that is currently the case.
> The problem is, how trustworthy are proof checkers? Are there bugs? And is the underlying theory itself free of paradoxes and unknowables and mathematical "bugs" that can be exploited? Imagine a human mathematician hell bent on deceiving other mathematicians - would we trust their breakthroughs, even with a verifier?<p>---<p>> Autumn of verified Lean kernels<p>Have you read this section (and immediately following sections) in the article? It seems that it partly addresses your thoughts. Perhaps you should comment replying to it.
> Autumn of verified Lean kernels<p>Above my pay grade, but it sounds like some kind of super cool self-hosted recursive lean-checker-in-lean.<p>I notice there are a bunch of caveats in that part of the article. If you were an LLM strongly RL'ed to give humans the result they're asking for, using recursion bugs to satisfy the goal would probably be something you would try.<p>I'm by no means an expert but I do think the old adage "great claims require great evidence" still applies, and a healthy dose of scepticism and epistemic humility is warranted.
> Coq (renamed Rocq last year)<p>This is lamentable.
The article already mentions the paper, <i>Sets in Types, Types in Sets</i> by Benjamin Werner which maps between Set/Type theories.<p>Another related and more approachable paper on the evolution of Type Theory and its relation to Set/Category theories is <i>Types, Sets and Categories</i> by John Bell.<p>Finally also see, <i>Typed Lambda Calculus / Calculus of Constructions</i> by Helmut Brandl for an excellent book-length but concise overview of CoC/CIC.<p>IMO, the above is required reading to understand theorem provers and proof assistants. In particular, Brandl's work is a must-read.
> Autoformalization has become a practical reality in 2026<p>Uh, _maybe_. I've been translating papers into lean for the last week and the correlation between the formalized result and the papers is extremely poor. The cycle seems to be "have a go at the paper, it's a bit hard, prove something different, proclaim success". It's still faster than doing it all by hand but paper in -> lean out in no way ensures a correspondence between the two.
> <i>prove something different</i><p>I'm not sure but do you mean "<i>prove the final end result using a [¿slightly?] different path</i>"?
Think of it this way. A math paper is pseudocode that has never been run. A Lean formalization is a running program. (It really is.)<p>In the process of formalizing, you find bugs, you find gaps, you find ways to fill those in. Maybe you rewrite part of the proof. Maybe you didn't quite wind up with the same result. Perhaps your theorem has some new conditions or something.<p>Was the original paper true? Maybe. But that isn't what you verified. What you verified is almost surely true though. So you take the win, and move on.
No, prove something else could mean proving something very trivial thus making the proof meaningless on its own.<p>IE a proof can be true, rigorous, and not at all what was asked for.
When independent reviewers compared the paper's text to the generated Lean formalization, they found that whenever the AI hit a wall, it quietly altered the statement like bumping a bound requiring 4 orders of derivatives up to 5 orders, or shifting sign indices (+1 vs -1) so the proof checker would accept the code.<p>The Lean kernel did its job verifying that the compiled code was logically consistent, but the code wasn't proving what the English paper claimed.
[flagged]
[flagged]
[dead]