Intent-Driven Delivery. Two poles dominate how teams talk about… | by Ian Johnson | Jun, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

Intent-Driven Delivery

Ian Johnson

16 min read·<br>Just now

Listen

Share

Two poles dominate how teams talk about AI in their workflow right now. On one end, vibe coding: open a chat, describe the change, accept what comes back, move on. On the other end, spec-driven development: write the formal spec, generate the code from it, treat the spec as the source of truth. Both have a real argument. Both miss the same thing.<br>Vibe coding is fast and unreliable. The work that comes back looks fine and is wrong in ways nobody can name, because nobody wrote down what right was. Spec-driven development is reliable and slow. The spec gets so heavy that writing it becomes the project, and the code ends up locked to the spec rather than to the outcome.<br>Waterfall has the same problems regardless of a human or agent actor.<br>Intent-driven delivery is the middle path. It is not a coding style. It is a delivery model — how a change moves through the whole system, from idea to production, in a way an agent can run and a human can trust. The unit of work is an intent contract : a small, falsifiable spec for one outcome, with named scope, acceptance, and a feature flag. Humans approve at three gates inside the cycle and one more at production. Agents do the middle. The flow is defined by constraints, not vibes and not waterfalls.<br>It answers four questions at once. What do agents do, if not vibe code or generate from a heavy spec? How does work get tracked when the ticket isn’t the unit of work anymore? Who decides a change is safe for users to see? And what’s the shape of a delivery pipeline when both the org and the project have to constrain it? One model covers all four because they’re the same problem in four costumes — the gap between human intent and shipped behavior, with an agent in between.<br>I’ve been running this against a real project for a few months. The skeleton holds. One part is still soft and I’ll say where.<br>Not vibe coding, not spec-driven development<br>The point isn’t which pole is right. They’re answering different questions. Vibe coding asks how fast a change can ship if you trust the agent. Spec-driven development asks how reliable a change can be if you write everything down up front.<br>Neither asks how a customer signal becomes a green deploy without burning out the team.<br>Intent-driven delivery picks a small contract per outcome — much smaller than a full spec — and then trusts the constraints around the contract to do the work the spec would have done in a heavier model. The harness catches what the contract didn’t say. The feature flag absorbs the rollout risk. The three touchpoints place humans where humans add value, and nowhere else.<br>This is closer to agile than to either pole. Small batches, working software, falsifiable acceptance, continuous delivery, retros on what’s slowing the team down. None of that is new. What’s new is that the unit of work is structured enough for an agent to read it, and the flow is constrained enough for the agent to run the middle without a human babysitting. Agile assumed every step had a human in it.<br>Intent-driven delivery keeps the cadence and the values, and lifts the human out of the steps where the human was a bottleneck instead of a contributor.<br>That is also where it splits from spec-driven development. Spec-driven development wants the spec to drive the code generation end-to-end. Intent-driven delivery wants the contract to drive one outcome, then get out of the way. The next contract gets its own spec. The system never accumulates a giant document that has to stay in sync with the code.<br>A delivery model, not a coding style<br>A coding style stops at the editor. A delivery model covers the whole pipe.<br>In this one, the pipe is:<br>1. A signal lands — support ticket, metric, incident, customer request.<br>2. A human turns the signal into a contract.<br>3. An agent reads the contract and does the work.<br>4. The agent posts evidence against the contract’s acceptance.<br>5. A human checks the evidence against the contract.<br>6. The change merges, CI runs on main, the flag stays off until the rollout is ready.<br>Six steps. Three of them involve a human — seed review before step 2, the contract approval at step 2, and the completion review at step 5. Three of them are mechanical. The model is the whole pipe, including the bits that are usually invisible — post-merge CI, the flag, the rollback story. If any of those is missing, the model leaks somewhere and the team eats the cost.<br>The thing to keep in mind: well-defined constraints are what hold the pipe together. The contract constrains what the agent may touch and what done looks like. The harness constrains how the work gets done. The flag constrains when users see it. The CI watch constrains when the contract closes. Pull any one of those out and the...