Sushant Dinesh

Co-founder & CEO @ Aretta. Verified reasoning for AI: code that's provably correct, not just trusted. Prev: Postdoc/PhD @ EECS, UC Berkeley.

[Sushant Dinesh @dsushant]

1/ A data race lived in SQLite's write-ahead log for 16 years, through 100% MC/DC coverage and a test corpus 590x the size of the library. It survived because the race is rare in time, and testing samples time.

[Sushant Dinesh @dsushant]

@poteto Love seeing this. You named the two hard parts exactly: writing down what you actually intended, and keeping that model in sync as the code changes. We think about the second one every day, because a spec that drifts from the code ends up proving the wrong thing.

[Sushant Dinesh @dsushant]

Strongly agree, and this is the work we think about every day. The hard part for software verification is the formal specifications - which unlike math - aren't widely agreed upon and change from codebase to codebase and with time/development.

So the bottleneck aren't lean proofs, it's formalizing intent and keeping that spec in sync with the code as agents change it. Once we close that loop, we will see the 100x productivity gains.

[Sushant Dinesh @dsushant]

Congrats on SWEBench turning 3. Totally see this happening!

I do believe that to reach 2 (code that wows Linus Torvalds, a superhuman dev) and 4, AI has to generate software that is provably correct with respect to intent. Wowing Linus means we can attest the code is correct, not just slop or overfit to test cases. That is the real bar, measured against thoughtfully written human code that has survived over time. Tests and checks simply can't keep up with growing complexity.

[Sushant Dinesh @dsushant]

Great starting point for getting agents to reason more formally. In our experience, forcing the agent (and yourself) to spell things out formally exposes a lot of bugs on its own. Two things to watch for: 1. Formalizing your intent correctly is hard; still an open problem. 2. You need some way to check that the formal model and the code stay in sync.

Those are the problems we work on every day.

[Sushant Dinesh @dsushant]

@penberg Thanks, Pekka! Very exciting to see our FM techniques making it an impact on your development. Deepening verification this is really important as systems/code gets more complex and harder to reason about.

[Sushant Dinesh @dsushant]

@RosuGrigore @rv_inc This is a great post and matches what we see in practice as well: the process of proofs surfaces bugs.

Curious: do you have any automated ways to detect potentially incorrect specifications? Also, do you have a way to check rust vs. C source conformance?

[Sushant Dinesh @dsushant]

The way to think about this is layering. 1. you describe the high-level properties that are really important to you and, 2. iteratively break them down into lower-level specifications. If you formally model this (e.g., using Lean), you can also check if the decomposition is complete (i.e., am I missing an aspect/lower-level property). If you can own/judge 1. you can use agents to "search" for 2.

And you don't enumerate the corner cases yourself, the decomposition surfaces them.

[Shubham Agarwal @shagarw21]

Excited to share our work on IDS was selected for a #NeurIPS2026 Oral! 🚀

Instead of generating code with agents and praying tests pass, IDS co-evolves code + formal proofs, outperforming SOTA agents to solve several distributed systems specs.

[Sushant Dinesh @dsushant]

@shagarw21 This is really exciting. Great work!

[Sushant Dinesh @dsushant]

So yes: the future of bug finding, and more. The work that's left is on the interface: specs developers can read, models faithful to the code, and proofs that everyone can inspect and understand.

Aristo is open source: https://t.co/ZRJU0XPVgU
Write-ups: https://t.co/JscJHRtuuJ

[Sushant Dinesh @dsushant]

Boris's post is the clearest case yet that formal verification is now a practical tool for working engineers, and Claude is a big reason why.

We run this loop on production engines. Three things get right in order to scale this beyond a one-off run. 🧵

[Boris Cherny @bcherny]

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. This approach is super useful for formally modeling your code and finding bugs that a human probably wouldn't have spotted.

Is formal verification the future of coding (or at least, bug finding)?

[Sushant Dinesh @dsushant]

3. A proof the developer can't understand is dangerous.

A green check with no clear scope is false confidence, worse than no proof. We state every guarantee in plain English, and you can ask what isn't covered. One question found silent data loss in Turso.

https://t.co/aGmt5BH7GA

[Sushant Dinesh @dsushant]

@bcherny One case: Turso merged a fix for a crash bug we'd reported. Re-checking the whole model at the fix commit showed the fix broke a neighboring durability guarantee that no test covered. Our CI bot reopened the issue, and the full fix merged within a day.

https://t.co/sMRtyRbEXs

[Sushant Dinesh @dsushant]

@bcherny Yes! We've been doing this on production engines (Turso, SQLite, hyper). Claude makes the Lean cheap. What stays hard is the last line of your screenshot: keeping the model faithful to the real code, and maintaining models + proof on every commit. That's what we're building.

[Sushant Dinesh @dsushant]

@jorandirkgreef @sachin_singh092 @penberg @tursodatabase Oh, and it also complements the protocol-aware DST efforts you all are pushing on. Great post btw!

[Sushant Dinesh @dsushant]

@jorandirkgreef @sachin_singh092 @penberg Totally agree. That's why you do formal proofs over the implementation/code rather than just the models. This is exactly what we are working on at Aretta with @penberg (@tursodatabase) and a few others. Happy to talk more if this interests you!

[Sushant Dinesh @dsushant]

Forming our next cohort now. If you build in a domain where correctness is critical, one sentence of intent is enough to start: https://t.co/adXV81Cds9

Aristo, the SDK this runs through, is open source: https://t.co/ZRJU0XPVgU

[Sushant Dinesh @dsushant]

1/ A data race lived in SQLite's write-ahead log for 16 years, through 100% MC/DC coverage and a test corpus 590x the size of the library. It survived because the race is rare in time, and testing samples time.

[Sushant Dinesh @dsushant]

5/ The property we checked is not new. It is SQLite's own WAL spec, published all along. The bug was checkable the day it was written, in 2010. Aristo did not exist in 2010. Alas.