Two short prompts. Sixteen pull requests fixing bugs and race conditions. Boris Cherny, who created Claude Code, posted on September 22 that he used Claude Opus 5.5 to formally verify the Claude Agent SDK with Lean, the theorem-proving language mathematicians use to write machine-checked proofs. He said he does not know Lean well. He does not know TLA+ well either.

That last part is the story, not the bug count. Formal methods have existed since the 1970s and have stayed inside a narrow band of teams: aerospace, hardware, and a handful of infrastructure groups at Amazon and Microsoft that use TLA+ to model distributed systems before writing a line of code, according to the language’s own site. The reason was never that formal verification did not work. It was that writing a Lean proof or a TLA+ spec requires thinking in predicate logic and state invariants, a skill almost no application engineer has time to build. Cherny did not build it either. He had Claude build the model for him.

What the post actually claims

His X post reads: “I used Opus 5.5 to formally verify the Claude Agent SDK using Lean. A couple short prompts = 16 PRs fixing various bugs and race conditions. Video attached. TLA+ also works well. I sometimes combine Lean and TLA+ to look for issues around data flow, concurrency, and state mgmt. I don’t know either language well, but Claude is excellent at both.”

One reply in the thread names the shift precisely. Shreyans Bhansali wrote that he had avoided formal methods mostly because of the learning curve, and agents kind of delete that excuse. That is the actual claim worth testing at your own company, separate from the specific SDK Cherny happened to be working on.

The Claude Agent SDK is the same engine that runs Claude Code, packaged as a library so any team can build agents on top of it. It has queues, retries, and shared state across concurrent sessions, which is exactly the class of system where a race condition hides for months until a customer trips over it in production.

The objection worth taking seriously

Mustapha Derzi, a VP of application development with more than 30 years in the field, asked the sharpest question under Cherny’s post: when Claude writes both the Lean model and the proof, what catches the case where the model quietly diverges from what the code actually does? The bug lives in the gap between the two.

Maksim Al Dandan answered with the precision the thread needed. A proof is only about the model, not the code. The spec becomes the artifact you review by hand, and the real advantage is that the spec is far smaller than the full codebase. But that does not remove the review work. It relocates it.

This is the part that gets skipped by anyone treating this as a magic bug-finder. If Claude hands your team 16 PRs generated from a Lean model that Claude also wrote, somebody still has to read that model and confirm it captures the real rules of the system, not a simplified version of them. Cheaper than reading every concurrent code path by hand, looking for the same race condition. Not free.

Where it pays off, and where it doesn’t

This is where I take it out of the LinkedIn thread and into how we actually scope agentic engineering work.

Model in Lean or TLA+ when the system has real concurrency: job queues, locks, retries, more than one process writing the same piece of state. Model it for state machines where the transitions matter, like an approval workflow or a billing pipeline. Model it for integrations between systems where a payment order can duplicate or vanish if two services disagree about which event happened first. A unit test checks one path at a time. A formal model searches for counterexamples across every path the state machine allows.

Skip it for a standard CRUD app. Skip it for a script that runs once and gets thrown away. And skip it if nobody on your team is actually going to read the spec Claude produces, because at that point you have only moved where the bug hides, not whether it exists.

What changed this week is not that formal verification became infallible. It is that the cost of writing the first model dropped low enough to try in a sprint instead of a quarter. If your system has a state machine or a concurrency path that has already bitten you once, that’s the candidate. Start there, not across the whole codebase.

We already fold concurrency and state review into our software audit, and this is one more tool in that kit, not a replacement for the judgment of whoever runs it. It’s the same pattern we documented in code review when AI already writes 41% of the code: the work does not disappear, it changes shape. And it fits what we’ve been tracking in the four loops that replaced prompt engineering: every time an agent makes one technical step cheaper, the step that stays expensive is the one a human has to sign off on with judgment.

Let’s find where your system needs a formal model, not another test