You Don't Need to Know Lean. Your Coding Agent Does.
An Anthropic engineer who admits he doesn't know Lean or TLA+ used Claude Opus 5.5 to formally verify the Claude Agent SDK — and walked away with 16 PRs of real race-condition fixes.
Formal Verification Didn't Need a PhD. It Needed Two Prompts.
Boris Cherny runs Claude Code at Anthropic. He also says, in public, that he doesn't really know Lean or TLA+. That didn't stop him from pointing Claude Opus 5.5 at the Claude Agent SDK, asking it to build a formal model, and walking away with 16 pull requests fixing real bugs and race conditions — out of a couple of short prompts. At Kuaray, we've spent two years telling clients that formal methods are the highest-leverage, lowest-adoption tool in software engineering, mostly because almost nobody on a normal team can write a TLA+ spec. That excuse just expired.
What Actually Happened
Opus 5.5 shipped September 22nd — 40% cheaper per task than Opus 5, 66.4% on Terminal-Bench 4.0, and reportedly capable of chewing through a 680,000-line codebase migration in under a day. That volume is the real story, because it's also the problem: no human review process scales to agent-generated code at that rate. Formal verification is the one technique built for exactly this — exhaustive, not sampled — and until last week it required specialists your org doesn't have.
Cherny's experiment collapsed that requirement. He didn't write the Lean model. The model wrote itself, from a codebase Cherny knows well but couldn't formally specify. The bugs it found weren't lint warnings — they were concurrency and state-management issues, the kind that pass code review for months and then take down production on a Friday.
The Pushback You Should Actually Listen To
Not everyone's buying the "formal verification" framing, and they're right to push. One sharp critique making the rounds: what Cherny actually did was bug finding, not verification in the rigorous sense — there's no proof that the Lean model faithfully represents the real SDK's behavior, so a clean result doesn't mean the code is correct, just that this particular model didn't find a counterexample. That distinction matters more than the headline number.
Here's the honest read: it's still a Lean/TLA+ model catching real, reproducible concurrency bugs that your existing test suite and code review missed, for the cost of two prompts. Call it "structured, adversarial bug hunting with a formal flavor" if you want to be precise. Either way, it beats what most teams are doing today, which is nothing.
This Is Already Becoming a Product Category
Within days, an open-source Claude Code skill pack (proof-skills) packaged this exact workflow — model, find counterexample, reproduce as a failing test, fix, re-verify — into four reusable skills. Their own benchmark: 98% bug-fix effectiveness on buggy fixtures with the skills, versus 54% without. Whether or not that number survives independent scrutiny, the direction is clear: this stops being a demo and starts being tooling within a quarter, not a year.
What We're Telling Engineering Leaders This Week
- Pick your worst concurrency offender and run the experiment. The service where you've had two "we still don't fully understand what caused that" incidents is your pilot. Not a greenfield toy project.
- Treat every "verified" claim as a bug report, not a proof, until someone checks the model matches reality. Feed counterexamples back as regression tests — that part is unambiguously real value regardless of the semantic argument above.
- Don't build this in-house yet. Watch the tooling category form for another month before you staff a "formal methods team." It's moving too fast to justify the headcount today.
- Update your AI-code SDLC policy now, not after the incident. If agents are shipping 680,000-line migrations, "a human read the diff" was never going to be your safety net.
Schedule a Technical Architecture Review with our Strategists — and bring your gnarliest concurrency bug.