- Microsoft Research describes PDD Kit, a tool that uses mathematical proofs to check agent-written code against a plain-language intent that the team reviews and approves.
- In Microsoft's demo, people review the spec and sign off on each assumption the proof leans on, instead of reading the code. The demo covers only login logic.
- Leaders should ask where agents write their code, which parts need proofs, and who signs off on the assumptions behind each one.
The review that no longer scales
When an agent writes tens of thousands of lines in one sitting, nobody reads them all. Microsoft Research says reading every line of the pull request "doesn’t scale to this new way of work." Most teams invest in a plan and in tests instead.
Microsoft names the weakness in that approach. The agent can drift from the plan. It then writes tests that pass for its own version of the code, not the version the team intended. Coverage looks healthy, and the gap stays hidden until a bug report arrives.
The lesson here is that agents change what is scarce. Producing code is no longer the bottleneck in Microsoft's telling. Deciding what you are willing to take on trust is.
What PDD Kit does
Microsoft calls its approach Proof-Driven Development. The toolkit, PDD Kit, runs inside Chopin, GitHub Next's shared planning environment, where a team and agents work in one document.
The team starts by reviewing what it wants in plain language. The tool puts questions to them, much as a careful human reviewer would, and files the answers in a document Microsoft calls an "intent artifact". Anything that can be stated mathematically becomes a formal specification. What cannot is turned into informal specifications that drive tests.
The coding agent then writes the proofs, and a checker called Verus confirms every step. Microsoft says nobody needs to read the proof. If Verus accepts it, the proof holds. Instead, people read the spec, which Microsoft says takes only a few minutes to learn. It also says no formal methods background is needed.
A worked example: the login
Microsoft built a demo store called Pet Store, about 5,000 lines of Rust. The backend uses Axum and SQLite. The storefront is a Leptos app compiled to WebAssembly. The team verified only the login logic. Microsoft says a flaw there can expose a customer's account or an admin's controls, so proof effort pays off there first.
The developer's request was two sentences. Before writing anything, PDD Kit asked a question that looks pedantic. Should a wrong password be refused, and should the right password be accepted? A login that refuses everyone satisfies the first half perfectly. Microsoft says an agent left alone would pick one reading without telling you. Here the developer chose both.
The developer also widened the scope. The first draft proved the core decision and left the handler around it trusted and tested. The developer asked for the handler's glue code to be proved too, because a refactor can quietly swap two lines there. The result was an async function called login_flow with eight conditions attached.
One of those conditions ties the password check and the token to the same account. Microsoft describes a bug it would catch. A login checks the password against Bob's account but issues a token for Alice's. Each step looks fine alone. Microsoft calls this "the kind of wiring bug a test suite rarely thinks to look for."
Where the proof stops
A proof cannot cover everything. The SQL query runs in a library Verus cannot check. The password hashing and the clock sit outside the proof as well. For each of these, PDD Kit writes an assumed contract, usually as a small wrapper function. The developer accepted six such pieces one by one.
Each assumption gets a test. The entries read "planned" until the test runs. Then they record the command's result and the commit it ran against. For the clock, the assumed contract says a token's expiry is exactly 24 hours, or 86,400 seconds, after the clock reading.
The plan also lists what nobody is promising. It makes no promise that the login call ever completes, or that an out-of-range clock will not cause a panic. It says nothing about the timing or rate of attempts, or about how other endpoints read the role.
What to ask your teams
This is a Microsoft Research demonstration on one function inside a 5,000-line app. Microsoft says the same process can verify the whole app, but the login is the only part it walks through. Treat it as a design to evaluate, not a result your own systems will match.
The design still points to useful questions. Which parts of our agent-written code would hurt most if wrong: login, payments, permissions? Do our reviews record what we trust, such as the database, the cryptography library and the clock? Or does that list live in one engineer's head?
Ask also who checks the tests when the same agent wrote the code and the tests. Finally, ask who signs off on the spec. Microsoft says its tool does not approve new trust or wider scope on its own, and a person must.
A proof is only as honest as the list of things it trusts.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Microsoft Research.
