# Can You Prove AI-Written Code Is Correct? Tools Compared

> Source: <https://www.digitalapplied.com/blog/prove-ai-written-code-correct-verification-tools>
> Published: 2026-09-18 00:00:00+00:00

A coding agent will write the function that calculates a refund, checks a permission or parses a file from a customer, and it will write tests for it too. Tests check the inputs somebody thought of. A proof checks every input there is. That difference used to be the concern of hypervisor and cryptography teams, and in the last month it has been offered to everyone: a new language whose compiler refuses code that breaks a written rule, and a report from Amazon on the Rust verifier it uses on the software that isolates its cloud customers from each other.

This post compares four tools a technical founder or lead can put in front of an agent: Bend, Verus, Dafny and Lean. It explains in plain words what a proof is, tables what you write and what each tool proves, says where the effort pays and where it is wasted, and ends with the one-file pattern that makes an agent prove before it commits. Facts about each tool come from its own site or repository and, for Verus, from [Amazon Science's August 31 post](https://www.amazon.science/blog/developing-provably-correct-rust-code-with-verus), all read on September 18, 2026. Every speed figure is the project's own.

1. 01A test samples; a proof quantifies over everything.Amazon's example: a test tries a few arrays on a binary search, a proof shows that for every sorted array and target the result is correct, and that a missing target really is missing.
2. 02Two of the four tools live inside a language you already use.Verus adds specifications and proofs as annotations to ordinary Rust that other compilers ignore. Bend is its own language with Python-like syntax. Dafny and Lean are their own languages too.
3. 03Proof pays on small functions that handle money, access or untrusted input.Pricing, permissions, parsers and invariants over balances are where a wrong answer costs more than a proof. Glue code, UI and prototypes are not.
4. 04The agent pattern is a rules file plus a proof command before commit.Bend ships it as a laws file and a proof step in AGENTS.md; the same shape works with Verus in a CI job. Either turns 'make no mistakes' into something a compiler checks.

## 01 — DefinitionsWhat a proof is, against a test

Amazon's post gives the cleanest example. Suppose your code implements a binary search over a sorted array. A test suite might try a handful of arrays and targets and can miss the corner cases, such as the target being the last element or not present at all. A specification states what must be true: if the function returns an index, the element there matches the target, and if it returns nothing, the target is not in the array. A program verifier then checks that the specification holds for every possible input. The second clause matters, the post notes, because without it an implementation that always returned nothing would satisfy the spec.

Two consequences follow for anyone managing agent-written code. First, the specification is the thing a human has to get right; the proof is mechanical and, increasingly, something the agent can produce. Second, the guarantee has a floor, which Amazon states plainly: it rests on the verifier itself being correct, on the top-level specification saying what you meant, on assumptions about the runtime and standard library, and on the compiler. A proof moves the trust from "the code" to "the spec", which is a much smaller thing to read. Our [reference on kinds of proof in AI research](https://www.digitalapplied.com/blog/ai-research-proof-types-reference) covers the wider vocabulary.

## 02 — The comparisonFour tools *compared*

| Sources: the Bend project site and its GitHub repository; Amazon Science, August 31, 2026; the Dafny project site; lean-lang.org. All read September 18, 2026. Maturity is our description, not a ranking. |  |  |  | 
|---|---|---|---|
| Tool | What you write | What it proves | Maturity and backing | 
|---|---|---|---|
| Bend | Programs in a Python-like syntax with dependent types; rules in a laws file; proofs the agent writes in a proof file. | That the declared laws hold for all inputs, checked by the compiler on every edit. Also compiles to native code and the GPU. | Open source, Apache 2.0. The site says the language is young and to expect bugs; no tagged release existed on GitHub on September 18. | 
| Verus | Ordinary Rust with preconditions, postconditions and proofs written as annotations that the normal Rust compiler ignores. | That functions meet their specifications, that unsafe Rust is actually safe, and that concurrent code holding locks keeps its invariants. | Free and open source, developed by academic and industry researchers. Amazon says it has used it on key primitives of its Nitro Isolation Engine and other critical infrastructure. | 
| Dafny | Programs in Dafny's own verification-aware language with pre- and post-conditions, loop invariants and lemmas; compilers emit other languages. | That implementations meet their recorded specifications, including termination and read/write effects, via a static verifier. | Established open-source project with IDE plugins, a language server, a reference manual and books, per its site. | 
| Lean | Definitions and theorems in Lean, a programming language and proof assistant, with automation tactics. | Any mathematical statement you can state, including properties of programs written in Lean itself. | Open source with a large mathematics community. Anthropic has reported that Claude wrote a complete machine-checked proof of Fermat's Last Theorem in Lean over 11 days. | 

The practical split is between the first two rows and the last two. Bend and Verus are built so that a working programmer, or an agent acting as one, proves properties of application code while writing it. Dafny sits close to them but asks you to adopt its language and compile out. [Lean](https://lean-lang.org/) is a proof assistant first; it is the right tool when the thing to prove is a theorem, and a heavy one when the thing to prove is that a discount never goes negative.

## 03 — BendBend: laws the compiler enforces

Bend describes itself as "a fast language that blocks AI mistakes via proof". Its pitch is aimed squarely at teams whose code is written by agents: you declare rules your application must never break in a file called LAWS.bend, and the compiler demands a mathematical proof that those rules still hold whenever code is edited. The site's demonstration is a small game with one law, that winning is impossible; an agent asked to make the board wrap around introduced a bug that let the player reach the flag, and with the laws file in place the compiler rejected the change until the agent had added a wall and proved the law held. The README's example laws are the kind a business cares about: the sum of all balances must be zero, a sort must return ascending numbers, an array write may never be out of bounds.

Two claims are Bend's own and should be read as such. It says its type checker is a proof checker in the tradition of Lean and Rocq but checks a mid-sized codebase in a second at most, and it publishes a benchmark of 3,200 generic instantiations checked in 0.38 seconds against 19.2 seconds for Lean and over five minutes for Isabelle and Agda, on an Apple M4 Max. It also publishes a game-of-life benchmark in which its single-core time is close to C and its GPU time is 124 times faster than one core. Neither has been reproduced by anyone else that we found. What is not a claim is the project's own caution: the site says Bend is young, to expect bugs, and that it works best on the back end on Linux and macOS. On September 18 the [repository](https://github.com/bendlang/bend) had no tagged release, so we treat Bend as a tool to try, not a product to standardise on.

LAWS.bend is AGENTS.md backed by proof.Bend project site, read September 18, 2026

## 04 — VerusVerus: proofs inside Rust

Verus takes the opposite route to a new language: it lets a Rust developer add specifications and proofs directly in Rust source files, in Rust-like syntax, and reports failures as Rust-style errors at the source line. Ordinary Rust compilers ignore the annotations, so verified code can be consumed by unverified projects through the normal build tool. Amazon, writing on August 31, 2026, says feedback typically arrives in under a second, fast enough for red squiggles in an editor, and that whole projects of thousands of lines verify in the time earlier tools took for single functions. The post makes the point that matters here in one line: that speed helps humans, and it also helps AI agents, which have less proof work to do and can iterate faster.

What Amazon says it has used Verus for is the evidence of maturity. It reports proving the correctness of key primitives in the Nitro Isolation Engine, the software that enforces virtual-machine isolation for its hypervisor, along with other critical infrastructure, and describes two capabilities beyond plain functional correctness: proving that code marked unsafe in Rust still upholds Rust's safety rules, and proving that concurrent code respects an invariant attached to a lock, so that whoever acquires the lock gets a value satisfying it and must prove it still holds on release. For a team whose agent writes Rust, Verus is the tool with the longest production record in this table.

## 05 — The decisionWhere proof pays, and where it does not

Proof is not free. Someone writes the specification, and the agent spends turns on the proof rather than the feature. The routing below is ours, and the test behind every row is the same: would a wrong answer from this function cost more than a specification would?

The pattern that falls out is a small proven core and a large tested shell. That is also the pattern that limits what an agent can do by accident: a proof gate on the core is a check the agent cannot talk its way past, which matters given the rates at which coding agents have been measured gaming ordinary tests in [our census of published reward-hacking rates](https://www.digitalapplied.com/blog/ai-coding-agent-reward-hacking-rates-published-data).

## 06 — The patternGiving an agent a proof step

Bend's installation page is four lines of instructions for an agent, and they are worth quoting because the shape generalises to every tool above. The site tells you to add this to your AGENTS.md:

"When using Bend: run bend guide to learn it; use LAWS.bend to keep important rules; run bend PROOF.bend before committing; parallelize the code whenever possible." The site then suggests asking the agent to write laws for anything that must never break. That is the whole integration: a rules file the human owns, a proof command the agent must run, and a commit that cannot happen until it passes.

The same three parts work with Verus in a Rust codebase: the specifications live in the source, the proof command is the verifier, and a CI job refuses the merge if it fails. Three practical rules make it hold up. Keep the rules file human-owned and reviewed like a contract, because an agent that can edit the laws can weaken them. Run the proof step in the agent's own loop, so it iterates on failures itself rather than handing them back, and give it an isolated working copy for that, as [our post on worktree isolation](https://www.digitalapplied.com/blog/agent-cli-worktree-isolation-parallel-coding-agents) describes. And run it again in CI with the agent absent, so a passing proof is a fact about the repository rather than a claim in a transcript. If you want a proven core carved out of an existing system, with the specifications written with your team, our [development service](https://www.digitalapplied.com/services/web-development) does that work.

## 07 — Next stepMove the trust from the code to the spec

### Write three laws for your most expensive function this week

Pick the function whose wrong answer would cost the most, and write down three things about it that must always be true, in plain sentences. Those are your specification. Whether you then reach for Verus, Bend or Dafny depends on your language and your appetite for a young tool, but the sentences are the hard part and the part no agent should own. Once they exist, a proof step before commit is a day of setup, and it is a check an agent cannot argue with.