Firstly, I want to say I owe a huge debt of gratitude to Doll for their work on VDD / VSDD. It has been an inspiration and a godsend. You can read their original snippet about VDD here https://gist.github.com/dollspace-gay/45c95ebfb5a3a3bae84d8bebd662cc25
The first time I watched an LLM generate a passing test suite for code it had also written, I realized the benchmark was meaningless. The tests passed, but they only tested what the model decided to test. The failure modes it didn’t anticipate stayed invisible, and some tests were trivial true==true checks.
This is the trust problem with AI-generated code. It’s not that the code is bad. It’s that you can’t tell whether it’s bad without a verification layer the model can’t also write.
What Verification-Driven Development actually is
VDD is a discipline, not a tool. The core rule: the spec comes before the code, the spec is approved by a human before any code runs, and the tests must fail before they can pass. This last part sounds obvious but it’s almost never enforced. That enforcement is the thing that separates a real test from a performance of a test.
In practice this means:
- Write a spec in natural language that a domain expert approves
- Generate failing tests from the spec (red phase must be witnessed, not assumed)
- Generate implementation against those tests
- Pass six binary gates: mutation kill rate ≥85%, complexity within bounds, adversarial spec attack, interface stability check, behavior diff against reference, coverage floor
- Human reviews the merge request with the full gate report attached
The adversarial layer is the one that surprised me most. It takes the approved spec and tries to break it, deleting interfaces, weakening postconditions, merging distinct APIs, then checks whether the tests catch the attack. Decorative specs fail this. Specs that actually constrain behavior pass.
Why this matters more than it did a year ago
Twelve months ago, teams were using LLMs to generate code snippets they’d then review carefully. The review was the trust mechanism. Now teams are using agents to generate entire features across multiple files, and the review is no longer a sufficient trust mechanism. The surface area is too large and the failure modes are too subtle.
IronCarapace is my answer to this. It’s a pipeline, not a linter. The gates are binary. The adversarial review is automated. The human is in the loop at two mandatory checkpoints, spec approval and merge review, but the verification work in between runs without them.
It’s been running in production on my own code for six months. The mutation kill rate gate has caught more real bugs than any other check I’ve ever used.
And if you’re curious about the kind of things this system can do? It has landed full language-to-language ports of entire projects like I2P and pydance converting from Java to Python and from Python to JavaScript. It’s currently building what I believe will be my magnum opus, a self-hosted p2p studio that redefines what we think of when we consider what a ‘browser’ should do versus what we have settled for in the past due to complexity and resource constraints.
IronCarapace kills hallucinations before they start and brings deep rigor into the build process so you end up with software that is robust and works the first time.