AI WORLD HQ
Picture asking an AI coding agent (a program that writes and changes software for you) to build a feature. Hours later, it hands back tens of thousands of lines of code. Who checks all of that? Often, nobody reads it line by line, and that's the gap PDD Kit is designed to address.
The problem: reading every line doesn't scale
Most teams today review the plan rather than the code. They describe what they want, go back and forth until the plan and proposed tests look right, and then let the agent build it.
The announcement says the trouble starts after that. An agent can drift from the plan, build something slightly different, and then write tests that pass for its own version. The test suite looks healthy, but the gap between what you asked for and what shipped stays hidden until a bug shows up.
The makers describe two kinds of errors a careful reviewer would usually catch. The code might leave out something necessary, or it might do something plainly wrong. Ordinary tests only check a small slice of what a program can do, so they don't close that gap on their own.
How proof-driven development works
PDD Kit's answer is a method its makers call Proof-Driven Development (PDD). The key idea is that a proof (a mathematical argument showing code behaves as specified) answers a different question than a review. Review asks, "Does this look right?" A proof asks, "Is this right?"
The workflow has two halves:
- Settling intent. The toolkit asks the questions a careful reviewer would ask and records the answers in an intent document. Parts of that intent that can be stated precisely become a formal specification (an exact, machine-readable description of what the code must do). The rest becomes test descriptions.
- Holding the code to it. The announcement says a verifier called Verus checks the code against the formal specification. Verus is a proof language for Rust, a programming language. Where a proof can't reach, such as a third-party library or a user interface, the toolkit uses tests and labels them as evidence rather than proof.
The makers also describe a Trusted Computing Base (the small set of code a proof simply assumes works correctly). PDD Kit makes that boundary visible and asks a person to sign off on each piece. Think of it as a list of what you're taking on trust.
What the makers tested
The announcement describes one experiment. The team used PDD Kit to verify the login logic of a small online store app written in Rust, inside GitHub Next's planning tool, Chopin. According to the makers, Verus helped harden the code and uncovered existing bugs, and the developer reviewed the intent without reading the generated code line by line.
Keep in mind that this is one case the makers chose to share. The announcement doesn't report wider results.
Wrap-up
PDD Kit is the makers' attempt to keep AI coding agents accountable to what a team asked for, using proofs where they work and tests where they don't. The approach is new, and the announcement offers one example rather than broad results. For your next step, read the official announcement yourself and note one question you'd want answered before trusting AI-written code in your own work.