How does formal verification work?
You write two things: a specification, the property that must always hold, and the implementation. A tool then proves the implementation satisfies the specification. Proof assistants such as Lean check each step of a proof mechanically, so a proof that compiles is correct relative to its specification (Lean, read 12 November 2026). The best-known industrial result is the seL4 microkernel, whose implementation is proved correct against its specification (seL4 proofs, read 12 November 2026). A proof is only as good as the specification it proves.
Formal verification vs testing vs evals: what’s the difference?
| Testing | Evals | Formal verification | |
|---|---|---|---|
| Covers | Chosen cases | Sampled behavior | All inputs, for the stated property |
| Result | Pass or fail per case | A score | A proof or a counterexample |
| Fits | Most code | Model and agent quality | Critical logic, protocols, rules |
| Cost | Low | Medium | Was high, falling with AI |
Use proofs where a single wrong case is unacceptable, and tests and evals everywhere else.
Why does formal verification matter for AI-generated code and agents?
Two shifts meet. Coding agents write more code than people can review line by line, which is the bottleneck behind agentic coding. And models are getting good at writing proofs, which used to be the expensive part. When the machine writes the code and the proof, a checker that cannot be fooled becomes the reviewer. The same idea applies to agent output: AWS offers Automated Reasoning checks in Bedrock Guardrails, which translate a model’s answer into logic and test it against rules written as logic, with a solver, not another model’s judgment, giving the verdict (AWS documentation, read 12 November 2026). It pairs naturally with spec-driven development, since both start from a precise statement of intent, and with deterministic AI controls. A test shows the bugs you looked for; a proof rules out the ones you did not.