We have proof automation now

AI may finally make machine-checked code usable — and the comments are already fighting

TLDR: A developer says AI may finally automate the exhausting work of mathematically checking software, which could make ultra-safe code far more practical. Commenters are split between excitement, warnings that AI can still prove the wrong thing, and spicy claims that expert prestige itself could take a hit.

A programmer posted what feels like a big nerd milestone with real-world stakes: using modern AI to help do the painfully tedious “prove this code is correct” work that has kept ultra-safe programming stuck in a tiny expert club. The pitch is simple enough for non-specialists: instead of trusting comments and good intentions, you get a machine to check the rules. The catch, as the author admits, is that this usually takes absurd amounts of time — in one famous case, teams spent far more effort proving than actually building the software.

That’s where the comments light up. One camp is basically yelling, “Yes, this is the future, finally!” They think AI plus proof tools could make super-reliable software cheap enough to matter outside research labs. But the skeptical crowd is not buying the hype without a fight. One commenter warned that even if AI can crank out proofs, it can still quietly drift away from what humans actually meant the software to do — which is a very glamorous way of saying, “Congrats, your robot may have perfectly proven the wrong thing.”

Then came the status-check drama: another commenter was surprised by the article’s “wow, the future is coming” tone and claimed parts of that future are already here at Google and in crypto tools. And the spiciest philosophical take? If AI makes formal verification cheap, one person says the value of elite credentials could crash too. In other words: the code gets certified, and suddenly humans may need to be, too.

Key Points

  • The article presents dependently typed languages such as Rocq and Lean as tools for encoding and machine-checking software invariants.
  • It identifies proof effort as the main barrier to adoption and cites the seL4 project’s report of roughly 10 times more effort spent on proving than on design and implementation.
  • The article describes F* and SMT-based proof discharge as an earlier automation approach that can work for simple cases but can become difficult to manage.
  • It states that proof irrelevance means the existence of a proof is often more important than the proof’s internal structure, though proof engineering and type-checker limits still matter.
  • The author says LLMs may substantially improve proof automation and tested this idea by building a Zstandard decompressor in Lean.

Hottest takes

"might make formal methods cheap enough to be practical" — nextos
"things might drift away from the original specification and intent" — nextos
"the value of credentials that act as shortcut proofs of human competence will decrease, too" — kimjune01
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.