Verification-Driven Development: What It Means

What Verification-Driven Development Means

In its current usage, verification-driven development means every change ships with executable evidence that it behaves as intended, generated as part of making the change rather than in a later phase. The proof travels with the diff and reruns on subsequent changes.

That definition is worth stating carefully, because the same three words describe at least two older practices that share almost nothing with it operationally. If you adopt the term without saying which one you mean, two people in the same planning meeting will agree on the label and disagree about the work.

The rest of this page uses the third sense, because it is the one driving current interest and the only one where the tooling question is unsettled. The first two are mature and well documented elsewhere.

Why the Term Came Back

Writing code got dramatically cheaper. Reading it did not, and reviewing it is bounded by the same human attention it always was. When the volume of change rises and the review capacity stays flat, the constraint moves to whatever confirms the change was correct.

That shift is now being argued in the research literature rather than only in vendor material. In Rethinking Software Engineering for Agentic AI Systems, Alenezi analyses verification as a critical quality bottleneck and argues that code is "transitioning from a scarce, carefully crafted artifact to an abundant and increasingly disposable commodity", concluding that the discipline should reorganise around orchestration, rigorous verification of AI-generated outputs, and structured human-AI collaboration. The paper names verification-first lifecycles as an open research challenge.

Read that as a description of where the expensive step now sits rather than as a prediction. If code is abundant and proof is scarce, the scarce thing governs how fast anything ships safely.

How It Differs From TDD, Test-After, and Review-Only

The useful comparison is not against test-driven development, which is where most write-ups start. It is against the two things teams shipping agent-authored code are actually doing today.

• Test-driven development - A human writes a failing unit test first, and the test drives the design of the code that follows. The ordering is the whole point. Verification-driven development is indifferent to ordering and cares only that proof exists for each change, which makes it a weaker claim and an easier one to satisfy at volume. Our guide to test-driven development covers that discipline on its own terms.
• Test-after - Proof is deferred to a later task, and the later task competes with the next feature. What ships is the code; what slips is the evidence. The failure mode is not bad tests but absent ones, accumulating as a debt nobody schedules.
• Review-only - A human reads the diff and approves it. This works when the reviewer can hold the change in their head, and degrades sharply when the author was an agent producing more code than anyone will read carefully. Reading is not executing, and semantic defects survive reading.
• Spec-driven development - Closely related, and the two answer different halves of the same problem. A specification says what should be built; verification says whether it was. Our write-up on spec-driven development covers the generation half, including why a spec an agent can build from needs testable acceptance criteria.

What the Verification Loop Looks Like

Six steps, and the value sits in steps three and six rather than in the authoring.

• State the change as behaviour - Describe what should become true rather than which files to edit. This is the same input a specification provides, and it is what any later assertion has to be checked against.
• Implement - The agent writes the code. Nothing about this step is new, and nothing about it produces confidence on its own.
• Verify in the same session - The agent exercises the running application and confirms the stated behaviour actually occurs. Doing this while the context is still loaded is what distinguishes the practice from testing as a later phase.
• Capture the run as a rerunnable check - A verification that happened once and left no artifact is a demo. The output of this step is a file, not a transcript.
• Ship the check with the diff - The proof travels in the same pull request as the change, so a reviewer sees the claim and its evidence together.
• Rerun on later changes - The check becomes a regression guard, and divergence from the recorded behaviour surfaces as a failure rather than as a surprise in production.

Step three is where the tooling question lives, because an agent that writes code cannot confirm rendered behaviour without something that drives a real browser. Kane CLI is built for exactly that position: a terminal-native browser agent for developers, AI coding agents, and CI pipelines that validates rendered UI in a real Chrome browser from natural-language objectives, closing the gap between the code an agent generated and evidence that it works. Its Test.md format persists those objectives as markdown files, which is what makes step four produce something reviewable rather than a log.

What We Measured: A Green Check on Broken Behaviour

The claim underneath this whole practice is that a check can run cleanly, report success, and prove nothing. That is usually asserted. We ran it.

Method. Two checks against the same page on the TestMu AI Selenium Playground, in one Chrome session on Browser Cloud. Check A is structural, the kind of assertion a hurried test-after pass produces: the page rendered and the submit control is present. Check B is behavioural: type a message, submit it, and assert the output area shows it. We ran both on the healthy page, then broke the behaviour while leaving the markup byte-identical, and ran both again.

HEALTHY PAGE
  A  structural   PASS     132 ms
  B  behavioural  PASS   2,952 ms

MUTATION: submit handler suppressed (markup unchanged)

BROKEN BEHAVIOUR
  A  structural   PASS      91 ms     <-- still green
  B  behavioural  FAIL   9,755 ms     timeout waiting for output

The structural check stayed green through a regression that made the feature completely non-functional, and it ran faster while broken, 91 ms against 132 ms, because it never touched the behaviour in the first place. A reviewer looking at a passing check would have no signal that submitting the form did nothing.

One detail from building this is worth passing on, because it is a trap for generated checks. Our first behavioural check used a programmatic value-set on the input rather than real keystrokes, and it failed on a perfectly healthy page, because the component only updates on genuine key events. A check written that way is a false negative that looks like a product bug, and an agent producing checks without running them against a working build will ship exactly that.

The mutation was applied deliberately in-page rather than observed in production, and this is one page on one account. What it establishes is narrow and sufficient: presence assertions cannot detect behavioural regressions, so a suite built from them reports health it has not measured.

What Actually Counts as Proof

The measurement above sets the bar. A check earns the word proof when failing it would require the behaviour to be wrong, and nothing else about the system to change.

• Asserts an outcome, not a presence - That an element exists says nothing about what happens when a user uses it. The assertion has to name the state the system should reach.
• Fails for exactly one reason - A check that can go red for a timeout, a missing fixture, or a real defect forces triage before it conveys information, which is most of its value gone.
• Has been observed failing - An assertion nobody has ever seen fail is untested code in the test suite. Break the behaviour once on purpose and confirm the check notices.
• Does not restate the implementation - A generated check that mirrors the code it was generated from passes whenever the code compiles and detects nothing. This is the characteristic failure of proof written by whatever wrote the change.
• Is readable next to the diff - If a reviewer cannot tell from the check what behaviour is being claimed, the check is not participating in review.

Coverage deserves a specific warning here, because it is the metric most often offered as evidence. Coverage records which lines executed, not whether anything was asserted about them, so a suite can execute nearly a whole codebase while checking very little of it. Treat it as a map of what was visited, never as a measure of what was proven.

Where Verification-Driven Development Breaks Down

• The proof is generated by the thing being proved - An agent that misread the requirement writes code and a check that both encode the same misreading, and they agree with each other. This is the structural weakness of the practice and the reason a human gate is not optional.
• Verification is not validation - Proving a feature matches its specification says nothing about whether the specification described the right thing. The practice raises confidence in construction and none at all in the requirement.
• Volume becomes its own problem - A check per change produces a suite that grows as fast as the code does, with the maintenance and flakiness that implies. Our guides to quarantine tests and flaky tests cover managing that growth.
• Nobody reads the evidence - Proof shipped with every diff turns into wallpaper once reviewers learn it is always green. The check earns attention only if it has been seen to fail.
• It is weakest exactly where it is needed most - Concurrency, timing, and state-dependent defects are hard to assert against and hard to reproduce, so the checks an agent writes most confidently cover the behaviour least likely to break.

Conclusion

Take one check an agent generated for you this week and break the behaviour it claims to guard. If it stays green, you have learned more about your suite in five minutes than a coverage report will tell you in a quarter, and you now know which of your checks are decoration.

That is the whole practice compressed into one habit. Proof is not what ran; it is what would have failed. Our measurement showed a structurally valid check passing in 91 milliseconds against a feature that no longer worked at all, and nothing in the pipeline would have flagged it.

For the step where an agent has to confirm rendered behaviour rather than assert markup, the Kane CLI getting started documentation covers running a first verification objective from the terminal, and our walkthrough of verifying vibe-coded builds with Kane CLI shows the loop running end to end on a real project.