Claude and formal verification: what was proven for 123 libraries

The weakest point of vibe coding often appears after a beautiful demo. The page opens, the button works, the assistant writes "done." But how can you understand if the program will withstand unusual data? Anthropic's fresh work gives reason to talk about a different level of verification — and about what should be demanded from AI even in a small project.

What exactly Anthropic announced

On October 22, 2026, Anthropic reported on joint work with Theorem: Claude built formal proofs for 239 entry points in 123 open-source libraries. The proofs concern defined properties of the compiled code; they are verified by the Rocq kernel. This is a result from a team of authors that the editorial team did not reproduce independently.

The main experiment has clear boundaries: single-threaded static programs for RISC-V/Linux, a fixed memory budget, and input data smaller than 64 MB. The conclusion depends on the specification, the execution model, and the verifier. It does not mean that all 123 libraries have become free of any errors on all platforms. Original source and study limitations →

Start with a rule that can be broken

Imagine an educational game with an equipment shop. The hero has 50 coins, and a sword costs 40. The first purchase goes through, leaving 10. This is one successful example. But what happens after a double click, a negative quantity of items, or loading an old save?

For such a project, it is useful to write down specific rules: the balance does not become negative; each confirmed purchase adds exactly one item; reopening the window does not repeat the deduction. This is our hypothetical task definition, not an Anthropic experiment result.

The words "the game works" hide many different requirements. The rule about coins doesn't check control usability, accessibility for the visually impaired, or progress saving after a restart. When requirements are named separately, it is easier to see gaps in the report.

How to read an agent's response about checks

Ask for four things: what was checked, on what data, what was actually obtained, and where the check ends. The phrase "no errors found" without these details provides little information. A list of tests is also no substitute for actually running them.

For a small game, you can start with a scenario table in a plain text file. Next to each rule, write a normal case, an edge case, and an attempt at an incorrect action. When you change the shop, return specifically to these scenarios. For a website, an analogous rule might be "the user can only edit their own entry."

Ready-to-use AI task

This editorial template helps request an itemized check. It does not run a formal verification tool by itself.

Check a specific property of my project: [formulate the rule]. 1. Specify which files and scenarios relate to this rule. 2. Name the assumptions without which the conclusion is invalid. 3. Suggest an example that could violate the rule. 4. Perform an available check and show the actual result. 5. Separately list what remains unchecked. If these are standard tests, call them that. Do not call the explanation a formal proof. Do not change the rule just for the sake of a successful check.

For beginners and developers

If you are just starting, take one important action: a purchase, a save, or a publication. Ask to explain what could go wrong, and together check six specific cases. It is better to understand one such action than to receive an incomprehensible twenty-page report.

If you work professionally, add the code version, environment, and reproduction command to every conclusion. After changing dependencies or an algorithm, the old result needs a review. Separately check whether the agent weakened the condition it was supposed to prove.

For your own browser game, start with a mini-course on making a game with AI. And if the website already exists, this will help: a practical breakdown of code checking by agents. The most useful question to ask an assistant after "done" is: "Show me the observations you used to reach this conclusion."

More from this collection

• Project Swap: AI can bargain, but does it understand what you want?
• Why AI forgets important things: JAM and memory for a specific task