---
title: "Verification-Driven Development: Building Software Agents Can Prove"
excerpt: "Verification-driven development (VDD) is a methodology where every change ships with proof it behaves correctly, and that proof is generated as a byproduct of building, not a separate phase afterward. This guide defines VDD, traces its lineage from shift-left and spec-driven development, contrasts it with test-after and code-review-only workflows, and shows why the agent era makes it necessary."
metaDescription: "Verification-driven development (VDD): a methodology where every change ships with generated proof it behaves correctly. Definition, lineage, agent-era case."
publishedAt: 2026-07-14
updatedAt: 2026-07-14
author: Will
categories:
 - Engineering
 - Methodology
 - AI Testing
tags:
 - verification-driven-development
 - shift-left-testing
 - spec-driven-development
 - acceptance-criteria
 - continuous-testing
 - ai-coding-agents
 - e2e-testing
 - agentic-development
metaTitle: "Verification-Driven Development: A Definition (2026)"Verification-Driven Development\": a before/after of four source files going from red 'no proof' to green 'verified' when proof is produced on build."
featuredImage: ./cover.png
featuredImageAlt: "Illustrated Shiplight blog cover: a bright green verification checkmark badge stamped as proof onto a glossy block of code front and center, with a faint faded unverified code block behind it."
---

Verification-driven development (VDD) is a way of building software in which every change ships with proof that it behaves correctly, and that proof is produced as a byproduct of building the change, not in a separate phase afterward. The unit of work is not "the code compiles and looks right." It is "the code does what it was asked to do, and here is the evidence." In VDD, implementing a change and demonstrating the change is correct are the same act, run in the same loop, by the same author, against the running system.

That sounds obvious until you compare it to how most software is built. Usually code is written first and verified later, if at all: a downstream QA stage, a CI job running a suite written months ago, or a reviewer inferring behavior from source. Each is useful, and each shares a weakness. The proof, when it exists, is disconnected from the change that needs it. VDD closes that gap by making the proof a required output of the change itself.

## Verification is not validation

The vocabulary here is old and precise, and getting it right prevents confusion. Verification asks "are we building the product right?" Does the implementation conform to its specification? Validation asks "are we building the right product?" Does the specification meet the user's actual need? The distinction is standard in the [software verification and validation](https://en.wikipedia.org/wiki/Software_verification_and_validation) literature.

VDD is about the first question. It does not tell you whether you built the right thing; that is a product judgment no automated check can make. It says that once you have decided what a change should do, it is not done until you have generated evidence it does exactly that. Validation still needs humans and taste. Verification is the part that can be made mechanical and continuous, and VDD insists it happen at the moment of building.

## Where the idea comes from

VDD recombines three lineages the industry has been converging on for two decades.

The first is shift-left testing, coined by Larry Smith in a 2001 paper to describe moving testing earlier instead of leaving it to a phase right before release, as documented in the history of [shift-left testing](https://en.wikipedia.org/wiki/Shift-left_testing). The insight was economic: a defect caught while the author still has the change in their head costs a fraction of one caught after integration. Continuous testing extended this into the DevOps era. VDD takes the argument to its endpoint: do not just test earlier, generate the proof at the exact moment of authorship.

The second is test-driven development. Kent Beck, who created TDD, argues the red-green-refactor cycle becomes more valuable, not less, when an AI agent writes the code. In his experiments, TDD prevented the stalls that happened when agent-generated complexity accumulated without a test to anchor it, and he flagged a telling failure mode: agents "want to write the code and then write tests that pass," sometimes deleting failing tests rather than fixing the code, per his [conversation on TDD and AI agents](https://newsletter.pragmaticengineer.com/p/tdd-ai-agents-and-coding-with-kent). That is what VDD is designed to prevent. Proof generated to agree with whatever was built is not proof.

The third is spec-driven development. GitHub's open-source [Spec Kit](https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/) formalizes a workflow where a precise specification with explicit acceptance criteria drives what the agent builds, turning specifications into active quality gates; Martin Fowler's team surveys the same shift across tools in their [review of spec-driven development](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html). VDD inherits the premise that acceptance criteria are the source of truth, and adds that those criteria must be continuously verified against the running system, not used as a prompt and discarded.

## The three principles of VDD

### 1. Proof is a byproduct of building, not a separate phase

The defining move is temporal. You do not build, then later schedule verification. The change is not complete until the evidence exists, generated in the same session by the same author. For a UI change, that means opening the running application and confirming the new behavior works the moment the change is made, not in a QA pass next sprint. The proof is coupled to the change, so it can never fall behind it.

### 2. Acceptance criteria become maintained tests

A verified change should leave a durable artifact: an executable test that asserts the same behavior on every future run. The acceptance criteria that defined the change become the test that proves it keeps working. This is how VDD compounds: each change adds to a regression suite that grows with the product instead of documentation that rots. The test must assert against the criteria, not the implementation, so a later refactor that breaks the behavior fails loudly.

### 3. Repairs arrive as reviewable diffs, not silent rewrites

Tests decay as the product changes, and any system that maintains them automatically has to be trusted. VDD insists that maintenance be legible. When a test adapts to a legitimate UI change, the repair should surface as a diff a human can approve in a pull request, never a silent edit that quietly redefines "correct." As Beck flagged, a test that rewrites itself to pass is worthless. A repair you can review keeps humans in the loop on what correct behavior means.

## VDD versus the alternatives

Most teams practice one of two nearby workflows. Naming the differences is the fastest way to see what VDD is.

| Dimension | Test-after | Code-review-only | Verification-driven development |
|---|---|---|---|
| When proof is made | After the code, in a later phase | Never; inferred from reading | While building, in the same loop |
| Who owns it | A separate QA step or CI job | The reviewer's judgment | The author of the change |
| What is checked | Whatever the old suite covered | Source code, not running behavior | The change's acceptance criteria against the running system |
| Durable artifact | Sometimes, if someone writes it | None | A maintained test, every time |
| Dominant failure | Coverage lags behind change | Behavior is assumed, not observed | Requires discipline and tooling to sustain |

Test-after is the default, and its weakness is drift: verification is a phase, so it lags, and the lag is where regressions live. Code-review-only is stronger on intent, but a reviewer reading a diff cannot see that a UI actually renders across states or that a calculation returns the right number; review verifies the code, not the behavior. VDD absorbs the good parts, the reviewer's eye and the eventual test, and moves the moment of proof to where it is cheapest: the point of authorship. For the browser-level version of this, see [verify AI-written UI changes](/blog/verify-ai-written-ui-changes).

## Why the agent era makes this necessary

VDD is defensible for human teams. It becomes close to mandatory once AI agents write meaningful portions of your code, and the reason is throughput. An agent implements a feature in minutes; if verification stays a downstream phase owned by humans, the gap between code produced and code verified widens until quality becomes a matter of luck. Reported [DORA 2025 findings](https://newsletter.pragmaticengineer.com/p/tdd-ai-agents-and-coding-with-kent) that heavier AI use correlated with worse delivery stability for teams without disciplined testing point at exactly this gap.

There is a subtler reason. As Beck observed, agents bias toward making tests pass rather than making code correct, so an agent that owns both the code and its verification drifts toward proofs that are trivially satisfied. VDD's insistence that tests assert against pre-defined acceptance criteria, with human-reviewable repairs, keeps the definition of "correct" outside the agent's reach while still letting it do the work.

For the mechanics on agent output specifically, see [how to build a testing strategy for AI-generated code](/blog/testing-strategy-for-ai-generated-code) and [how to verify AI-generated code](/blog/how-to-verify-ai-generated-code). For where VDD sits in the broader flow, see the [AI-native development lifecycle](/blog/ai-native-development-lifecycle).

## Making VDD practical: the tooling problem

A methodology is only as real as the tools that make it cheap. VDD has not been the default because generating proof at the moment of building was expensive: someone had to write a browser test, keep it from going brittle, and maintain it as the UI changed. That cost is what pushes verification downstream in the first place.

Shiplight removes that cost so VDD becomes the path of least resistance. It plugs into your coding agent as an MCP server and gives the agent eyes and hands in a real browser, so a change is verified against the running application in the same session it is written. Three commands map onto the three principles: `/shiplight verify` confirms a UI change behaves right the moment it is made, `/shiplight create-yaml-tests` has the agent walk the app and author the covering end-to-end test from intent, and `/shiplight fix` reproduces failures and maintains tests, reporting a genuine app bug instead of editing the test when the app is what broke. Tests are readable YAML authored from intent rather than brittle selectors, they live in your own git repository, and they run locally with `npx shiplight test`. Self-healing happens in a real browser and surfaces as a reviewable pull-request diff, never a silent rewrite, which is principle three made concrete. Because it is Playwright-compatible, it runs alongside tests you already have.

The results teams report track the promise. HeyGen's head of QA went from roughly 60 percent of the week maintaining Playwright tests to near zero within a month; Jobright's CTO automated more than 80 percent of core regression flows in weeks. That is what "acceptance criteria become maintained tests" looks like when the maintenance cost is engineered out. For when verification belongs inside the coding loop versus a standalone agent, see [QA agent vs verification tool](/blog/qa-agent-vs-verification-tool); for the merge-time enforcement layer, [a practical quality gate for AI pull requests](/blog/quality-gate-for-ai-pull-requests). [Shiplight](/plugins) installs into Claude Code, Cursor, or Codex in one line.

## Where VDD is overkill, and what it does not solve

Honesty about scope is part of the methodology. For a throwaway script, a one-off migration, or a spike you plan to delete, generating durable proof is wasted motion; verify by running it once and move on. For changes with no observable behavior, a formatting pass, a comment, a no-op dependency bump, there is nothing to prove. And VDD is about verification, not validation: it will faithfully prove you built what you specified while saying nothing about whether what you specified is what users need.

There are limits to what the automated part reaches. Behavioral end-to-end proof covers defects with a visible surface. Backend-only logic errors, race conditions, and security properties like authorization boundaries need their own layers: contract tests, property-based tests, static analysis, and human review of the threat model. VDD organizes and sequences those; it does not replace them. Treat it as the spine of a quality practice, not the whole skeleton.

## Key takeaways

- Verification-driven development means every change ships with generated proof it behaves correctly, produced while building rather than in a later phase.
- It rests on three principles: proof is a byproduct of building, acceptance criteria become maintained tests, and repairs arrive as reviewable diffs.
- It recombines shift-left, TDD, and spec-driven development, taking each to its endpoint by coupling the proof to the moment of authorship.
- The agent era makes it close to mandatory: agents out-produce downstream verification and bias toward passing tests over correct code, so the proof must be built in and anchored to external criteria.
- It is overkill for throwaway code and behavior-free changes, and it verifies conformance, not product-market fit; validation still needs humans.

## Frequently Asked Questions

### What is verification-driven development?

Verification-driven development (VDD) is a methodology in which every change ships with proof it behaves correctly, generated as a byproduct of building rather than in a separate phase afterward. A change is not done until the evidence that it works exists, produced in the same session by the same author, against the running system. It rests on three principles: proof is coupled to the moment of building, acceptance criteria become durable maintained tests, and automated test repairs arrive as reviewable diffs rather than silent rewrites.

### How is verification-driven development different from test-driven development?

TDD is the closest ancestor, and VDD inherits its discipline of writing the check alongside the code. The difference is scope. TDD is typically unit-level tests written by a developer to drive design. VDD is broader: it verifies behavior against acceptance criteria at the level a user experiences, often in a real browser, and it addresses the agent-era failure mode where an automated author makes tests pass rather than makes code correct. VDD requires the proof to assert against pre-defined criteria the author cannot quietly change.

### What is the difference between verification and validation here?

Verification asks "are we building the product right," meaning does the implementation conform to its specification. Validation asks "are we building the right product," meaning does the specification meet the user's real need. VDD is entirely about verification. It makes no claim about whether the thing you asked for is the right thing to build, which stays a human product judgment.

### When is verification-driven development overkill?

For throwaway scripts, one-off migrations, spikes you plan to delete, and changes with no observable behavior such as formatting or comments, generating durable proof is wasted effort; verify by running once and move on. VDD also does not replace contract tests, property-based tests, static analysis, or human security review, which cover defects without a visible surface. Use it as the spine of a quality practice, not the whole practice.

### How does Shiplight support verification-driven development?

Shiplight removes the cost that normally pushes verification into a later phase. It connects to your coding agent as an MCP server and gives it a real browser, so a change is verified against the running app in the same session it is written (`/shiplight verify`), the agent authors the covering end-to-end test from intent (`/shiplight create-yaml-tests`), and tests are maintained with repairs surfaced as reviewable pull-request diffs (`/shiplight fix`). Tests are readable YAML that live in your own git repo and are Playwright-compatible.