Verification-Driven Delivery Methodology (VDD) for Software Development in the AI Era.
Not a vibe. A recipe measured, portioned, and verified before it is served
VDD is the pricing, acceptance, and forecasting layer of software delivery. It works with how your team already works: Scrum, Kanban, or an agentic SDLC.
Specification v1.0 · Published October 16, 2026 · Licensed under CC BY-NC-ND 4.0
Published on Zenodo: https://doi.org/10.5281/zenodo.23415760.
Why now
Alexander Lipanov
PhD, Applied MathematicsVDD Methodology AuthorCTO, SOFYCODAI compresses code generation several times over, and we see it every day. But the value was never in writing code. A business pays for a result that works and keeps working.
Speed alone does not deliver that. Code generated fast and checked by no one returns as rework, refactoring, and re-engineering: the same feature paid for twice and delivered late.
VDD cuts that loop. Every user story is priced before work starts, checked by someone who did not build it, and accepted only when verified. VDD lets you catch problems when they are easy to fix, not in production. The business result is the shortest path from requirement to working product, with no budget spent redoing work.
That is why independent verification is not overhead. It is what makes the first delivery the one that lasts.
The billable hour is dead. Selling engineering hours in the AI era is like selling candles in the age of electricity: technically possible, but why, except perhaps for décor and nostalgia.
VDD grew from my 35 years of experience in engineering, research, and software development, 25 of them as an IT entrepreneur. AI finally made it possible to turn an idea into a working methodology, delivered based on verified results.
More writing: alexlipanov.com →
The industry has noticed the problem but not fixed it
90%
Software professionals use AI at work, up 14% over the past year. Adoption alone does not guarantee results: outcomes depend on how an organization evolves its culture, processes, and systems (DORA 2025).
12.3%
Copy-pasted lines rose from 8.3% of changed code in 2021 to 12.3% in 2024, while refactored and reused code fell from 25% to under 10%. Data based on 211 million changed lines (GitClear).
+54%
More bugs per developer when an organization's AI adoption is higher than when it is lower. Two years of telemetry from 22,000 developers across 4,000+ teams (Faros AI).
The usual answer is more process. What's missing is a unit. Verification-Driven Delivery is that unit: not a checklist bolted onto story points and hourly rates, but a pricing model built for what verification actually costs once generation is nearly free.
Existing frameworks weren't built for this job
Reward slowness. The faster AI makes the team, the less it earns.
Built for sprint planning. Relative to one team, meaningless across projects, and unable to price a client relationship. VDD vs. Story Points →
One number for the whole project, set before anyone knows the work. Every change becomes a negotiation, and the risk premium is hidden inside the price.
Key Benefits for Engineering Leaders & Businesses
Independent Verification Gate guarantees that code isn't just fast-generated, but thoroughly tested, compliant, and architecturally sound before it's billed.
Pay for verified outcome units built from counted Delivery Bricks, eliminating arbitrary hourly padding, hidden buffers, and budget surprises.
Replace kickoff guesses with statistical probability ranges recalculated after every sprint using your team’s actual throughput data.
Client, CTO, Product Owner, and Vendor operate on one objective metric. Scope changes are priced as exact deltas before work starts, no contract renegotiations.
What changes when you price a verified outcome
Dimension
With VDD
Hours and story points
Pricing basis
Price per Delivery Unit from counted Bricks, grounded in real team throughput
Relative to one team, meaningless across projects
Who estimates
Counted from the decomposition, the tech lead fixes the list
The judgment of the team doing the work
Review depth
Independent Verification Gate confirms outcome before it's billed
Manual review buried under AI-generated volume, quality erodes
Forecast accuracy
Sharpens continuously from actual throughput data (P50/P85)
Frozen estimate set at kickoff, drifts as work progresses
Scope changes
Re-Bricking: the change is priced as a delta before anyone approves it
Re-negotiated, or silently absorbed
Comparable across teams
Same Brick definitions for every team and vendor
Not comparable
Change stability
Improves: every Unit passes the same verification
Unstable: AI accelerates rework as fast as it accelerates output
VDD Key Concept: Verified Delivery Units and Delivery Bricks
VDD Foundations
Requirements Decomposition
Requirements are captured in a PRD, including the compliance and domain requirements the project actually needs, then broken into user stories and Delivery Bricks before any code is written. AI can draft the decomposition; a tech lead fixes the final list.
AI-Augmented, Human-Verified Development
AI may draft implementation and tests from the decomposed requirements. Nothing counts as delivered until it passes tests derived from the acceptance criteria and is confirmed by an engineer who didn't build it.
Calibrated Price and Forecast
Each Brick category has its own Base Unit Rate, calibrated on revenue from the organization's own verified deliveries. Delivery dates are given as P50 and P85, computed from percentiles of actual weekly throughput and recalculated every sprint.
Quality and Traceability
Every Delivery Unit traces back to the user story that produced it and forward to the code that implements it. Quality checks at function, module and system level, for example against ISO/IEC 5055, are part of verification. Teams can run this with their existing tools or with the Playbook's spreadsheets.
Delivery Unit Concept
Delivery Unit = One Verified User Story = Σ Delivery Bricks
Get Delivery Bricks: Run Requirements Decomposition → Get User Stories
↓
Decompose User Story to Delivery Bricks: 12 categories of Delivery Bricks → Exact Set of Bricks for User Story → Exact Delivery Unit Cost
↓
Code Development
↓
Test Cases Generation
↓
Verification Gate
↓
Verified Delivery Unit
VDD Explained Simply. Controlled Coding vs. Vibe Coding
Imagine trying to cook a dish without ever looking at a recipe relying only on intuition, a rough idea of the result, and improvising as you go: a bit of grilling here, some boiling there, adjusting on the fly. After enough iterations, you will probably end up with something edible. But how much time did you waste getting there, and how many ingredients did you throw away along the way?
That is Vibe Coding: building without a plan. VDD works differently, more like following a recipe. Let us build one, step by step, for a real feature: Customer Registration.
Vibe Coding
Controlled Coding using VDD
Let's build Customer Registration for a web application. To implement it correctly, we need a precise, complete set of steps exactly what the VDD methodology provides.
Ingredients
User model + DB migration (Brick) - 1
Registration endpoint, happy path (Brick) - 1
Email format validation (Brick) - 1
Password validation + hashing (Brick) - 1
Duplicate-email check + error handling (Brick) - 1
Confirmation email integration (Brick) - 1
Registration form, all fields (Brick) - 1
Client-side validation + inline errors (Brick) - 1
API wiring: submit/loading/error states (Brick) - 1
Post-success screen (Brick) - 1
Verification Bricks, one per implementation Brick above - 10
Build overhead (infrastructure) - 3
TOTAL: Customer Registration · 23 Bricks · $23 at an illustrative $1 per Brick
Steps for Cooking
Break the user story into Delivery Bricks (0001–0010). The tech lead fixes the list before any code is written.
Build 0001 through 0010 one at a time. No batching, no skipping ahead on vibes.
Add the 3 build-overhead Bricks: the push-build-deploy cycle that grows with the codebase.
Hand the dish to someone who did not cook it. They run the 10 verification Bricks, one per implementation Brick.
Done. Customer Registration Completed
VDD Manifesto
"We value verified units of work over billed hours."
A Delivery Unit is priced by what it is made of and how it was verified, not by how long someone sat typing.
"We value expert judgment and knowledge more than the speed of code generation."
Every Unit passes through an Independent Verification Gate: an engineer who did not write the code must confirm it before it counts as delivered.
"We value a price that reflects quality, complexity, and reliability over code volume or hours spent."
Delivery Bricks carry complexity modifiers tied to real architecture and business risks.
"We value a transparent, explainable basis for price over arbitrary estimates."
Pricing is calibrated directly from the organization's verified delivery history.
"We value decisions grounded in statistical data over subjective intuition."
Timelines are probability ranges, not promises: P50 and P85 forecasts are recalculated after every sprint using actual team throughput.