Microsoft Research has demonstrated an agent-assisted workflow that checks whether generated login code follows explicitly agreed requirements. In a November 5, 2026 blog post, the developing team reported using its PDD Kit research prototype to verify the login subsystem of Pet Store, a Rust web application of about 5,000 lines. The demonstration concerns one subsystem, rather than verification of the entire application.
The approach, called Proof-Driven Development, shifts review toward specifying intended behavior. Working inside GitHub Next’s Chopin planning environment, PDD Kit asks developers to resolve ambiguities and records their decisions in a plain-language intent document linked to formal contracts. One consequential question was whether requiring the correct password merely prohibits unauthorized tokens or also requires successful authentication. The approved specification included both directions, while allowing lookup or token-signing failures to produce an internal error.
The team translated the requirements into eight postconditions on the login_flow function. Agents generated implementation code and proofs, which Verus mechanically checked using the Z3 solver. The authors report proofs for five functions: login_flow, login_core, lookup_target, decide_login and issue_token. Under the formal model and its assumptions, the contracts connect the checked password to the same account identified in the token, constrain customer and administrator roles, and specify error outcomes. Email takes precedence when both email and username are supplied; administrator tokens require the administrator lookup path.
The workflow also describes inserting one deliberate code mutation per postcondition into a scratch copy, such as rejecting every login, to check whether Verus rejects the targeted violation. Such checks probe whether a contract rules out unwanted behavior. The report supplies no aggregate mutation-rejection tally. The verified flow was connected to the application’s actual login handler, and the developer reportedly merged the changes after reviewing intent without exhaustive line-by-line review of generated code.
The proof depends on components it does not verify. Database lookups, bcrypt password verification, token signing, the clock, database-error conversion and request unpacking remain behind assumed contracts approved by the developer. The authors report tests using real bcrypt, SQLite and the router. Those tests provide evidence for the inputs exercised, rather than proof of the assumptions. The verification also relies on the Verus, Rust and Z3 toolchain and Verus’s standard library.
The contracts do not guarantee that login finishes, responds quickly, limits attempts, resists timing attacks, avoids out-of-range clock panics or has its roles interpreted correctly by other endpoints. A proof also cannot establish requirements omitted from the specification. This developer-reported blog demonstration does not establish peer review or independent replication, and offers no measured comparison of development speed, review effort, defect rates or security. PDD Kit currently verifies Rust through Verus; its scalability and accessibility beyond this single case remain unmeasured.
Cover illustration generated with AI; conceptual, not research evidence.