Dev ToolsArticle The 1979 objections are collapsing on proof labor and hardening on specifications, exactly where developers now need judgement.
Lenn Voss In May 1979, Richard De Millo, Richard Lipton, and Alan Perlis published "Social Processes and Proofs of Theorems and Programs" in Communications of the ACM, and formal verification never really recovered. Their argument was elegant: mathematics doesn't trust theorems because proofs are formally checked — it trusts them because proofs get read, argued over, taught, and re-derived by a community. Program verifications, by contrast, are unreadable stacks of symbol manipulation that no human will ever socialize. No social process, no confidence, no point.
This week a blog post by Ivan Gavran — a researcher who works on the Quint specification language — re-litigated all six of the paper's arguments from a 2026 vantage point and promptly hit the Hacker News front page. His verdict: AI coding agents have flipped the economics that made the 1979 critique stick. He's half right, and the half he's right about matters a lot. But the half that survives is the paper's deepest point, and it's about to bite harder than ever.
The critics won on economics, not logic #
Here's the part nobody says plainly: De Millo, Lipton, and Perlis were wrong about the mechanism and right about the market. Confidence in a proof doesn't actually require a community of readers — it requires a small trusted checker. Proof assistants like Lean, Coq, and Isabelle replaced the social process with a tiny kernel that mechanically validates every step, which is precisely the substitution the 1979 authors declared impossible. And the empirical record backs the machines. CompCert, the verified C compiler, was fuzzed for years by Csmith alongside GCC and LLVM; the researchers found wrong-code bugs in every conventional compiler they tested and none in CompCert's verified core. seL4 proved functional correctness of an OS microkernel back in 2009. Amazon has been using TLA+ to model-check AWS designs since before its 2015 CACM writeup, catching subtle bugs in S3 and DynamoDB designs that testing missed.
So why did the critique hold for four decades anyway? Cost. seL4's proof took person-decades for roughly 10,000 lines of C. Verification was a luxury good: worth it for a microkernel, a compiler, or a consensus protocol, absurd for your invoicing service. The 1979 paper's real legacy wasn't a refutation — it was permission for the industry to not bother, and for forty-odd years not bothering was the correct engineering call.
What AI actually changes #
The genuinely new development is that proof labor — the thing that made verification a luxury — is exactly the kind of work LLMs are good at. It's tedious, mechanical, and comes with a perfect oracle: the proof checker either accepts or it doesn't, so hallucination costs you compute, never correctness. Gavran points to Igor Konnov using LLM assistance to verify the Ben-Or consensus protocol in Lean; the broader ecosystem tells the same story. AWS's Kani model checker now runs thousands of proof harnesses in CI on the Rust standard library through the verify-rust-std project, and there's a growing research pipeline — vericoding benchmarks at POPL, a NeurIPS workshop on verifiable code generation — treating "agent writes code, prover checks it" as the default loop rather than a curiosity.
There's also a fresh reason to want this. When an agent writes most of your code, reading the diff stops being a meaningful review. You need some artifact that captures intent independently of the implementation, plus a mechanical way to check one against the other. That's just a specification and a verifier wearing modern clothes. The 1979 objection that fully automatic verification was implausible — argument three of six — is the one that's actually collapsing.
The argument that survives is the one that bites #
But notice which objection got sharper. The paper's second argument was that formalizing informal intent is itself an unverified, error-prone act — your spec can be as wrong as your code. The top-voted skepticism on the HN thread is the same point, nearly verbatim: why would the spec be more correct than the implementation? On seL4, bug fixes routinely touched spec and kernel together. And a TLA+ or Quint model that's verified says nothing, by itself, about the Go code you shipped.
Cheap proofs make this worse, not better. When verification was expensive, a "VERIFIED" stamp implied a human had sweated over the spec. When an agent can generate a spec, an implementation, and a proof relating them in one shot, you get a new failure mode I'd call proof laundering: a green checkmark against a property that's vacuous, subtly wrong, or quietly weakened until the proof went through. De Millo, Lipton, and Perlis warned that an automatic verifier's "VERIFIED" teaches you nothing. Fifty years on, that's not a reason to skip verification — it's the design constraint for using it. The social process they said was irreplaceable turns out to be portable: it moves from proofs to specs. Specs are now the artifact humans must read, argue over, and own, because they're the last thing in the loop that can't be delegated.
What to actually do with this #
Concretely, by situation. If you build distributed systems, model-check the design before you code it — TLA+ or Quint, a few hundred lines, the highest-ROI formal method that exists; this has been true since AWS proved it and agents only lower the on-ramp. If you maintain unsafe
Rust or parsers or anything memory-adjacent, put Kani or property-based harnesses in CI now and let LLMs draft the annoying contracts — that workflow is production-real today, not research. If you're tempted to have an agent "formally verify" a business app end to end, don't; the spec would be as long and as wrong as the code, which is argument five of the 1979 paper and it still holds.
And one rule for the new era: review specs with more care than you review code, and keep them small enough that you actually can — a property you can't read in one sitting is a property you're taking on faith. The 1979 paper's authors bet against verification and were right for longer than almost any prediction in computing. What finally beat the argument wasn't better proofs of their wrongness. It was the price of proof going to zero — leaving humans holding the one job the paper correctly said was social all along: deciding what "correct" means.
Sources & further reading #
[The Case Against Formal Verification, 50 Years Later](https://ivan-gavran.github.io/0-social-processes-paper)— ivan-gavran.github.io -
[The Case Against Formal Verification, 50 Years Later - discussion](https://news.ycombinator.com/item?id=49323459)— news.ycombinator.com -
[Social Processes and Proofs of Theorems and Programs](https://gwern.net/doc/math/1979-demillo.pdf)— gwern.net -
[KaPilot: LLM-Assisted Generation of Kani Specifications for Unsafe Rust Verification](https://arxiv.org/html/2607.21957v1)— arxiv.org
[Lenn Voss](https://sourcefeed.dev/u/lennart_voss)· Cloud & Infrastructure Writer
Lenn writes about cloud platforms, Kubernetes internals, and the infrastructure decisions that quietly make or break engineering organizations. Based in Berlin's vibrant tech scene, they have a talent for turning dense platform-engineering topics into prose that people actually finish reading.
Discussion 0 #
No comments yet
Be the first to weigh in.