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 14, 2026 · Licensed under CC BY-NC-ND 4.0
Why now
Alexander Lipanov
PhD, Applied MathematicsVDD Methodology AuthorFounder & CTO, SOFYCODAI can compress the time it takes to write code several times over, and in my team we see it every day. But writing code was never where the value was. The value is independent verification and expert judgment, and those do not speed up when generation does.
The billable hour is dead. Selling 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 out of 35 years of engineering, research and software development, 25 of them also as an IT entrepreneur building and leading international engineering teams. AI finally made it possible to put the methodology into practice, not only on paper.
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: they 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, reused code fell from 25% to under 10%. Based on 211 million changed lines (GitClear).
+54%
More bugs per developer when an organization's AI adoption is at its highest than at its lowest. Two years of telemetry from 22,000 developers in 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.
What VDD gives you instead
A price per Delivery Unit, built from counted Delivery Bricks and calibrated on your own team's delivery history, with a forecast that sharpens on real throughput.
The Customer, CTO, Product Director, Product Manager and Product Owner read the same price and the same date, and see exactly what they are paying for.
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 checked, 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 it must check it and confirm it before it counts as delivered.
"We value a price that reflects the system's quality, complexity, and reliability rather than one based on code volume or hours spent."
Bricks carry complexity modifiers tied to real risk.
"We value a transparent, explainable basis for price over abstract hours."
Price is calibrated from the organization's own delivery history.
"We value conclusions and estimates grounded in data and statistics rather than arbitrary judgment."
Timelines are a probability range, not a guess: the P50/P85 model is recalculated after every sprint using actual throughput.