Verification-Driven Development

In one sentence

Verification-driven development is a methodology where every change ships with automatically-generated proof that it behaves correctly, produced as a byproduct of building rather than as a separate QA phase bolted on afterward.

Why it matters now

For most of software history, verification was a stage you reached later: write the code, then test it, then review it, then maybe run it through QA. Each handoff added latency, and each was optional under deadline pressure. That order held up when a person wrote every line and carried the intent in their head while doing it.

AI coding agents broke the order. When an agent authors dozens of changes a week, the human reviewer no longer has the context the author had, and "we will test it later" becomes "it merged untested." AI-generated code fails differently, too. It is frequently syntactically correct but semantically flawed, passing a compile and a glance while quietly diverging from intent. Verification-driven development responds by moving proof to the front and making it non-optional: a change is not done until the proof that it works exists.

How it differs from test-after and review-only

Test-after treats verification as a step that follows building. You finish the feature, then you go write tests for it, if there is time. The proof lags the change and often never arrives, which is how test debt accumulates.

Review-only leans on a human reading the diff. Review catches design problems and obvious mistakes, but a reviewer cannot execute the change in their head. Reading that a form submits correctly is not the same as watching it submit. When the author was an agent, review-only is especially thin, because the reviewer is reconstructing intent from code they did not write.

Verification-driven development differs on one axis: the proof is a byproduct of building, not a later task. As the agent implements a change, it also produces the executable evidence that the change behaves correctly, in the same working session, against the intent that drove the change. There is no separate phase to skip.

The loop

1. The change is described in terms of intended behavior, ideally as a spec the agent works from.
2. The coding agent implements it.
3. In the same session, the agent verifies the behavior by exercising the real application, not by asserting on its own diff.
4. The verification is captured as a durable, re-runnable test written from intent.
5. That test travels with the change into the pull request, so the reviewer sees proof, not a promise.
6. On later changes, the same test re-runs, and any divergence surfaces as a reviewable diff rather than a silent break.

The output of the loop is not just a passing check today. It is a stable regression test that keeps proving the behavior tomorrow.

Shiplight as the enabling tooling

Verification-driven development needs tooling that lets the coding agent verify and author tests without leaving its workflow. Shiplight provides exactly that. It installs into the agent as an MCP server plus skills with a one-line setup for Claude Code, Cursor, Codex, VS Code, and 40-plus agents, giving the agent eyes and hands in a real browser.

Three commands carry the loop. /shiplight verify confirms a UI change looks and behaves right after an edit. /shiplight create-yaml-tests has the agent walk the app and author E2E tests from intent. /shiplight fix reproduces a failure, root-causes it, and maintains the test, and if the application itself is broken it reports the bug instead of quietly rewriting the test to pass. The tests are readable YAML, they live in your own git repository rather than a vendor cloud, and they run locally with npx shiplight test. Self-healing happens in a real browser and surfaces as a reviewable PR diff, not a silent rewrite, which is what keeps the proof trustworthy.

The results teams report track the methodology's promise. HeyGen's Head of QA went from spending roughly 60 percent of the time maintaining Playwright tests to near zero within a month, and teams commonly stand up first suites of around 300 tests in the first week.

Where verification-driven development fits

It is the operating discipline underneath several narrower practices. PR-time verification is where the generated proof gets checked, at the moment a change is proposed. The verification agent is the actor that produces the proof. And AI-native testing describes the test layer that makes authoring proof cheap enough to do on every change. Verification-driven development is the name for insisting that all of it happens by default, on every change, as part of building rather than after it.