Nostr notes by Meven Lennon-Bertrand

I think it's practically ok, we have good human measures in ...

2026-07-29T08:13:24Z

In reply to nevent1q…grut
_________________________

I think it's practically ok, we have good human measures in place to avoid such bugs having serious consequences. Of course, on the long run this is a strong motivation to apply serious formal methods to proof assistant kernels, ideally towards full verification!

References: https://github.com/leanprover/lean4/pull/14577 the ...

2026-07-28T13:51:35Z

In reply to nevent1q…8l62
_________________________

References:
https://github.com/leanprover/lean4/pull/14577 the main issue
https://github.com/ammkrn/nanoda_lib/pull/22 the nanoda PR from yesterday that (apparently independently (!!!)) catches the problem on their side
https://leanprover.zulipchat.com/#narrow/channel/270676-lean4/topic/Counterexample.20to.20the.20Lean.20Conjecture.20.28Soundness.20Bug.29/with/613135216 Lean Zulip discussion

This whole Lean kernel bug is almost too on point to be true, it ...

2026-07-28T13:49:06Z

This whole Lean kernel bug is almost too on point to be true, it fits perfectly in the discussions we've had here and elsewhere over the last months/years…

To summarize:
- an AI agent let loose provides a sorry-free proof of the Collatz conjecture
- the proof is detected as actually being a kernel bug
- the bug is related to (nested) inductive types, for which there is no clear theoretical specification: the kernel's code is the reference
- external checkers (lean4lean and nanoda from a week ago) reproduce the bug, because they essentially copied the reference kernel implementation

And so
- AI raises the bar for kernel correctness by a lot
- without a clear type-theoretic understanding of *what is actually implemented*, we're toast
- external checkers help to catch implementation bugs, but without a clear specification they can't catch logic bugs