X account: Formal verification will likely play an increasingly important role for the "Antifragile Internet". I personally played around with FV (Lean4) for research in Spr 25. Back then it was a pain to work with, and the leading models (Deepseek/4o) couldn't handle it well. A few things have…

AT A GLANCE

X account @0xfishylosopher believes that model capabilities, advances in automation, and recent security incidents are driving increased attention to formal verification of code, while also highlighting limitations in its coverage and proof assumptions.

Article

Formal verification will likely play an increasingly important role for the "Antifragile Internet".

I personally played around with FV (Lean4) for research in Spr 25. Back then it was a pain to work with, and the leading models (Deepseek/4o) couldn't handle it well. A few things have changed:

(1) The models have gotten really good at FV languages. Lean4 is now the de facto way AI-driven math breakthroughs get done, and the same skills carry over to code.

(2) There's a lot more end-to-end automation. In the @theoremlabs x @AnthropicAI collab, existing fuzz tests are automatically turned into specs, and Claude proves them directly on the compiled RISC-V binary (in Rocq). 239 entry points across 123 open-source libraries, in a few weeks.

(3) The recent security incidents make "verifiable code" much more top-of-mind. FV is finally getting the funding and attention it deserves, rather than being a (historically backwater) area of academia.

Key points

Formal verification will likely play an increasingly important role for the "Antifragile Internet".
I personally played around with FV (Lean4) for research in Spr 25. Back then it was a pain to work with, and the leading models (Deepseek/4o) couldn't handle it well. A few things have changed:
(1) The models have gotten really good at FV languages. Lean4 is now the de facto way AI-driven math breakthroughs get done, and the same skills carry over to code.
(2) There's a lot more end-to-end automation. In the @theoremlabs x @AnthropicAI collab, existing fuzz tests are automatically turned into specs, and Claude proves them directly on the compiled RISC-V binary (in Rocq). 239 entry points across 123 open-source libraries, in a few weeks.
(3) The recent security incidents make "verifiable code" much more top-of-mind. FV is finally getting the funding and attention it deserves, rather than being a (historically backwater) area of academia.
So this is an exciting time for FV-in-code, esp for companies like @theoremlabs building towards verifiable code. But FV is not a panacea where anything verified is "unhackable". 3 caveats:
(1) FV is often retroactive and partial - Much of this is proving properties about existing code after the fact, and only for the paths the tests reach, not the whole library or how other code calls it.
(2) FV has simplified sandboxes - the proofs assume a simple setup (eg. single-threaded, statically linked, RISC-V), and there's still a gap between that and the code actually running in prod.
(3) You have to define the properties properly - notions like "secure" or "safe" or "correct" have to be pinned down mathematically, eg. via test suites, rather than staying high level. When you say something is "safe", what you're really saying is that nothing bad happens for any input in scope.

X account: Formal verification will likely play an increasingly important role for the "Antifragile Internet". I personally played around with FV (Lean4) for research in Spr 25. Back then it was a pain to work with, and the leading models (Deepseek/4o) couldn't handle it well. A few things have…

Article

AI-assisted interpretation

Why it matters to readers

Risks and unknowns

Related Developments