# Proofs Got Cheap. Deciding What to Prove Didn't. > Source: > Published: 2026-11-11 23:36:08+00:00 For thirty years formal verification was the correctness technique everyone admired and nobody could afford. The bill just changed. ## 1. Signal's Code Is Now Mathematically Proven. Nobody Had Managed That by Any Method. A research team pointed a multi-agent framework at the Signal protocol and came back with [machine-checked proofs of its security properties](https://deepmind.google/blog/introducing-alphaproof-code/) — not of the design, of the implementation, down to the code on devices. That gap is where real vulnerabilities live, and no one had closed it for a widely deployed protocol before, by any method. The division of labor is the part to study: humans worked with models to translate security goals into formal specifications, and reviewed every one. Agents then generated over six million lines of Lean to discharge the proofs. A second pass of agents audited the result and flagged roughly one percent of the codebase for human eyes, since Lean's checker handles the rest mechanically. Four weeks, against the years this has historically taken. Then they did the thing most AI-assisted results skip: a negative control. They reinserted two real, previously fixed bugs into an isolated copy, and both times the system produced a machine-checked proof that the buggy version was insecure. A verifier that can only say yes is a rubber stamp; this one demonstrably says no. That experiment is worth more than the six million lines. **Why it matters:** - **For ICs:** The skill that just became valuable is not writing proofs, it is writing the specification — stating precisely what your code must never do. That is still yours. - **For leaders:** Verification has moved from a research line item to a scoped engagement for your most dangerous component. You know which one it is. - **For founders:** "Formally verified" is about to appear in competitors' security pages. Ask which properties, against which artifact — design or shipped code — because the answer is usually the former. - Any assurance claim without a negative control is marketing. Ask what the system said about code known to be broken. ## 2. 613,000 Lines of Proof Later, Python Has 418 New Bug Reports A second project went after something messier: CPython itself. Agents [rewrote its functions in Lean line by line](https://broyojo.com/python-formalization/), differential-tested each copy against real Python on tens of thousands of inputs, and only counted a function once a separate agent that didn't write it agreed the work held up. Current standing: 4,071 functions and 18,898 theorems, re-checked on every build. Along the way it filed 418 bug reports against Python, around 55 of which can crash the interpreter or corrupt memory from ordinary Python code. Python has no precise written definition — it means whatever CPython does — and proofs are an effective way to find where the code disagrees with what everyone assumed. The failure mode they hit is the one worth internalizing. The first attempt optimized for breadth: copy every function, prove at least one thing about each. The agents complied, and a later review found fewer than half the proofs held up — in one file, 21%. Not because they were wrong. Because they were true and empty. Their example: proving that if a function returns, the answer is at least zero. A function that always crashes satisfies that perfectly. So every proof now faces one question — could a broken version of this function also pass it? — which is the only interesting question in the discipline. There is a second trap underneath. A checked proof guarantees a statement follows from the Lean model, not that the model matches reality. Their proof that the JSON encoder could build indentation strings at any nesting depth was valid and wrong: the model assumed memory requests always succeed, so it endorsed a case needing sixteen terabytes, where real Python runs out of memory. This is the AI-written test suite that asserts nothing and goes green, wearing a much more impressive badge. **Why it matters:** - **For ICs:** Run the broken-version test on your own AI-generated tests this week: mutate the function and see if anything fails. Most inherited suites won't. - **For leaders:** Coverage measures that assertions ran, not that they discriminate. Agents can manufacture unlimited passing, meaningless assurance — budget review capacity accordingly. - **For founders:** The cheapest credibility in a dependency is a project that publishes what its checks fail to catch. There will be very few. ## 3. The Economics Moved by a Factor of Three Thousand The seL4 microkernel verification famously ran about $362 per line of source. A [survey of the current pipeline](https://charleshuang.me/2026/09/27/theoremsmith/) puts the AI-assisted figure near ten cents. That ratio explains the history of formal methods: at $362 a line you verify microkernels and crypto libraries and nothing else. At a dime, the gate stops being money. It is not free yet. Models remain mediocre at this — agents complete subsets of real Lean repositories at roughly 40% on the benchmark — so the same pipeline is being turned on the models, blanking dependency proofs out of real projects to manufacture frontier-difficulty training tasks. Proofs make a clean reward signal: a checker gives an unambiguous verdict per lemma. Notably, the generator includes an adversarial stage where a model is told about its own verifier and invited to cheat, and every successful hack is treated as a bug in the task. Build your evals that way and you will have better evals. Two honest limitations sit in the write-up, and both are the adoption story: the source projects skew toward mathematics rather than code, and verified codebases get refactored, which means the proofs do too — a maintenance bill nobody has priced, arriving as outage rates climb and AI-generated code gets blamed. **Why it matters:** - **For ICs:** Learn to read a specification before you learn to write one. Agents will do the proving; you will be the one who notices the spec permits the bug. - **For leaders:** Pilot this on one invariant that would end the company if violated — a payment path, an authorization boundary — and treat it as an asset with upkeep, not an audit. - **For founders:** The defensible position is not a verified product. It is a verified property your competitor cannot claim and buyers can check. ## The Verdict: Real or Hype? **AI-generated proofs on real production code → Real.** Signal's implementation is verified and two reintroduced bugs were caught; that is a result, not a demo. **Formal verification in ordinary application code → Real but early.** The proving is solved, the specifying isn't, and nobody has paid the proof-maintenance bill yet. **A green checkmark as evidence your software is correct → Hype.** A proof binds a model to a specification, and agents can generate unlimited true statements that forbid nothing.