AI Made Code Cheap. Requirements Are the Delivery Bottleneck

The promise of vibe coding was that anyone could describe software and get it. You type a sentence, an agent writes the app, and the twenty-year barrier to building software quietly collapses. That framing got the economics exactly backwards. Implementation got cheap. Describing what "right" looks like well enough that an agent builds it correctly on the first pass did not. A 2025 Fastly survey of 791 professional developers, as analyzed in Hao Wang's SpecBench write-up, found the tools do not level the field: 32 percent of senior developers say more than half their shipped code is AI-generated, versus 13 percent of juniors, and 26 percent of seniors say AI makes them a lot faster, versus 13 percent of juniors ¹. The people who get value are the ones who can specify, evaluate, and steer. For consulting teams that deliver against fixed scope and client expectations, this is the story of 2026: requirements, not implementation, became the critical path.

The bottleneck moved upstream

Microsoft Research's Shuvendu Lahiri names the underlying problem the intent gap, the distance between what a user means and what a program does. The gap has always existed in software. AI makes it worse in two ways: scale without scrutiny, because agents generate code faster than anyone can review it, and plausibility without correctness, because generated code looks right, compiles, and passes a few tests without doing what was asked ². Vibe coding, a term Lahiri traces to Andrej Karpathy, is the purest form: you have intent, never inspect the implementation, and trust the model to bridge the two ².

The delivery consequence shows up long before code review. Augment Code's six-stage analysis of the agent-native SDLC puts it plainly: requirements quality becomes the delivery bottleneck because faster agent implementation exposes planning constraints that human teams previously absorbed later in the lifecycle ³. Think about what that means. Before agents, a vague requirement cost you a week of slow human coding, and the ambiguity surfaced naturally while a developer asked questions. You had slack to absorb a fuzzy spec. Now the agent turns the vague spec into working-looking code in minutes, and the ambiguity does not surface until validation or the client's acceptance test. The slack is gone. The fuzziness got pushed to the end, where it is most expensive.

Specification skill is the multiplier

The Fastly numbers describe the mechanism. Seniors get more out of AI tools because they are better at shaping ambiguity. They know which questions matter before implementation, can anticipate conflicting requirements, reason through trade-offs, and tell a core feature from a nice-to-have. An agent given an underspecified request fills the gaps with its best guess, produces something that works, and delivers something that is not what the user wanted ¹.

There is now a benchmark for this exact failure. SpecBench, from May 2026, evaluates how well coding agents collaborate with users during specification design, by predicting user answers to design-choice questions and producing structured spec sheets. The results are uncomfortable for the "just prompt it" crowd. Gemini CLI gains little from interaction; even told to keep asking until confident, it stops early, and its output can degrade with more rounds. Claude Code and Cursor CLI use their full question budget but ask the wrong things, because more questions do not reliably produce better specs ¹. Agents have become capable solo coders but weak collaborative spec partners. They are eager programmers, not interviewers, and eliciting a precise spec from a vague idea is exactly the skill the tools do not yet have.

The intent-gap paper makes the same point with a two-line example. Ask an agent to "remove duplicates" from a list of integers. Does that mean keep one copy of each element, or drop every element that appears more than once? A human resolves the ambiguity by asking or by domain knowledge. The model resolves it statistically, against training data, with no grounding in your intent, and returns code that looks right for one reading while silently being wrong for the other ². A single unstated assumption, and you have shipped the wrong feature.

The PM and BA role gets a new center of gravity

This reframes project management more than it reframes engineering. If implementation is cheap and specification is expensive, then the highest-leverage person on the team is whoever makes requirements precise, testable, and owned. It is the same reframing we traced for estimation, where velocity stopped forecasting delivery as agents compressed the build phase Estimation After AI. Augment describes a dedicated intent-engineering role emerging, because developers increasingly translate ambiguous business goals into testable specifications for agent execution ³. That is the business analyst's job description, upgraded: writing the artifact that actually drives the build, not one that gets set aside.

The specification becomes the control plane. Augment's framing is that approved specs now direct and constrain downstream execution, so human work centers on requirement quality, ambiguity resolution, and specification ownership ³. Microsoft's guidance for an end-to-end agentic lifecycle describes three layered artifacts that organize the work: requirements capture intent, plans translate it into technical decisions, and task lists break the plan into units agents can implement ³. Note the ordering. Requirements are not a handoff you finish and forget; they are the layer that everything else hangs off, and the layer that has to change first when the client changes their mind.

The hard constraint underneath all of this is that there is no oracle for specification correctness other than the user. Lahiri's core observation: since no external system can tell you a spec is right, you need ways to assess spec quality through lightweight user interaction and proxy artifacts such as tests ². For a consulting team that is a governance requirement. Every requirement you hand an agent should carry an explicit, checkable way to know it was met, because the agent will not tell you it guessed.

Spec-driven development is how you do it

The practice that matches this reality is spec-driven development, and the reference implementation is GitHub's open-source Spec Kit, released in September 2025. Its argument is that the spec is not a static document but a living, executable artifact that drives implementation, checklists, and task breakdowns. The core insight, from the launch post, is that the specification becomes the source of truth and determines what gets built, because when a spec turns into working code automatically, it decides what "done" means ⁴.

Spec Kit runs four phases with explicit checkpoints, and you do not advance until the current phase is validated. Specify: the agent drafts a detailed spec from your high-level description of what you are building and why, focused on user journeys and success criteria, not technical stacks. Plan: you hand the agent your stack, architecture, and constraints, and it produces a technical plan, which is where company standards, compliance rules, and performance targets get encoded. Tasks: the agent breaks the spec and plan into small, reviewable chunks that can each be implemented and tested in isolation. Implement: the agent works the tasks, and you review focused changes instead of thousand-line dumps ⁴.

The workflow treats agents as literal-minded pair programmers, not search engines. A vague prompt like "add photo sharing to my app" forces the model to guess at thousands of unstated requirements, and some guesses will be wrong, usually discovered deep into implementation. A clear spec, a plan, and focused tasks give the agent what to build, how to build it, and the order to build it in ⁴. This is why it works across stacks: the problem was never the language, it was translating intent into working code.

Three situations make spec-driven development especially valuable for a consulting portfolio. Greenfield work, where a small upfront spec beats letting the agent improvise a generic solution from common patterns. Feature work in an existing system, where a spec forces clarity on how the new code must interact with what is there, so it feels native instead of bolted on. And legacy modernization, where a spec captures the essential business logic of a system whose original intent is long gone, and the agent rebuilds it without inheriting the technical debt ⁴.

Make every requirement checkable

The shift in practice comes down to one discipline: write requirements that can be verified, then verify them. This is the verifiability principle from the intent-formalization research, applied to everyday project work. Since the model has no oracle for correctness other than you, the specification itself must carry the means to test it, whether that is lightweight tests aimed at points of likely ambiguity, or fuller acceptance criteria ².

Requirements tooling has caught up. Jama Software's 2026 survey of AI in requirements management catalogs what works: NLP quality scoring against INCOSE and EARS criteria catches vague terms, passive voice, and missing conditions before anything is baselined, instead of three months later when a test engineer cannot write a pass-or-fail criterion. AI-driven traceability cut review downgrades from 8.7 percent to 1.6 percent and lifted high-confidence trace links from 56.4 percent to 70 percent ⁵.

The reason this is worth the investment is arithmetic. Writing and testing code accounts for only 25 to 35 percent of total time from idea to launch, so shortening the upstream requirements work has an outsized effect on the schedule ⁵. An hour spent making a requirement unambiguous saves days at the end. Jama's guidance is the right default for any consulting team: treat AI outputs as inputs to human review, not as finished artifacts ⁵. The AI drafts and detects; the human owns the judgment call.

The pitfalls are real, and they are the same ones

The risks here are not exotic; they are the old requirements failures, amplified by speed. The CMU study of 807 GitHub repositories found AI briefly accelerates code generation before returning to baseline rates, while static analysis issues rise roughly 30 percent and code complexity rises more than 40 percent ³. DORA's 2025 report found AI adoption can raise throughput while also increasing change failure rates ³. More code, faster, with no better requirements, does not help; it just lets you fail faster at a bigger scale.

The specific trap for consultants is vibe coding on client projects. A client describes a need, an agent produces a plausible build, and everyone is impressed until the acceptance test reveals the gaps. A team that adopted agents without upgrading its specification discipline has simply relocated its risk from implementation to acceptance. The ambiguity that used to be caught by a developer asking a question now survives to integration, exactly the failure Jama warns about ⁵. The fix is not less AI. It is more spec discipline around it, and, when the code does ship, a review pipeline that treats agent output as the risk surface it is, the same gate logic we outlined for AI-generated code in CI/CD AI Writes the Code.

For consulting teams, the deliverable in 2026 is no longer shipped code. It is the right thing, shipped. The project manager's job becomes ensuring the requirements are precise enough that a fast, literal-minded agent cannot misunderstand them, and checkable enough that you can prove they were met. The teams that win this cycle will not be the ones that accept the most AI code the fastest. They will be the ones that can say precisely what "right" means, before a single line is generated.