The Spec Is the Bottleneck, Not the Model

Our first year of AI automation took us from zero to 33 deployed solutions. The next stretch added ten.

The obvious read is budget, or people, or ideas running out. My data says none of those. Generation capacity was never the ceiling. What slowed the second wave sat on either side of the generating: deciding precisely what a thing had to do, then proving it did. Both are human-paced, and neither gets faster when you upgrade the model.

If your own agent adoption has flattened somewhere past the pilot, that is the first thing worth checking. Short of capacity, or short of specifications? The answer changes what you fund next.

It is also awkward for the story most teams are telling themselves right now, which goes roughly like this: coding agents make specification overhead obsolete, so you prompt, you look, you iterate. I have built four production applications spec-first, plus two indie products on deliberately different spec toolchains, to see whether that story holds. It does not survive contact with anything you have to maintain.

Key takeaways

• The constraint moved off writing code and onto two slower jobs: saying precisely what to build, then proving it was built. Throughput rises when you staff those two jobs, not when you upgrade the model.
• Keep the spec in the repository and review it like code. That is the line between teams shipping agent-built software and teams piling up generated code nobody can maintain.
• Run the regeneration test on one module before scaling the tooling. An afternoon tells you whether you have a specification or just documentation.
• Budget for review load rather than tokens. Approval fatigue arrives first, and it lands on your most senior people.

The bottleneck did not move. It split.

Read the two 2026 Google papers on this side by side and they point in opposite directions. Boonstra’s Spec-Driven Production Grade Development argues that AI removed the code-production bottleneck and pushed the constraint downstream, onto the humans who review, test, and integrate the output. Osmani, Saboo, and Kartakis, in The New SDLC With Vibe Coding, put it upstream: we are no longer waiting on human hands to type boilerplate, we are waiting on human minds to define the boundaries.

They are both right, which is the finding neither states on its own. The bottleneck split in two: specification to the front, verification to the back, and the middle collapsed. Most organisations I have seen respond by staffing neither and then wondering why a 25 to 39% productivity gain, the range industry surveys report, refuses to show up in the delivery numbers. The METR study cited in the same paper found experienced developers taking 19% longer on certain tasks, largely on time spent verifying and correcting output.

This is not an academic problem. As of early 2026, 85% of professional developers regularly use AI coding agents, 51% use them daily, and an estimated 41% of all new code is AI-generated. The volume is already in your repository. The open question is what sits upstream of it.

The regeneration test

Here is the check I run before letting an agent own a module. Delete it. Hand a fresh agent nothing but the spec. See whether what comes back passes the same tests and lands on the same architecture.

I call it the regeneration test, and it has three parts: the spec alone as input, a clean agent with no session memory, and the existing test suite as the judge. If the regenerated version fails, the gap between the two artifacts is exactly what your spec is missing. Write that gap down. Do not rewrite the code.

The test comes straight out of Boonstra’s claim that code is now disposable, that with a solid enough specification the entire codebase can be regenerated repeatedly, even flipped from one language to another in an afternoon. That claim is usually read as a promise. I read it as a falsifiable condition. If you cannot regenerate it, you do not have a specification. You have documentation, which is a description of code that already exists, and it will drift.

The decision rule I would paste into a review doc: run the regeneration test on your highest-churn module first; if closing the gap takes more than one working day of writing, that module is not ready for agent-led work, and the honest move is to keep it under hands-on direction until it is. Skip the check and you ship a codebase that only regenerates in the demo.

The two indie products gave me the cleanest comparison, because I ran them on different methods on purpose. One carries 18-plus formal specs, each written as a requirements, design, and tasks triad with persistent steering documents keeping them consistent. The other runs on plan review and numbered decision records. Different shapes, same property: on both, a module can be regenerated from its written artifacts, and the safety net under the first is a suite of roughly 260 tests.

What has to be in the spec before an agent touches it

The contents are less negotiable than they look. Boonstra’s list is the full technical design, database schemas, API contracts, pinned library versions, the background reasoning behind the what, and scenarios that include the edge cases. Behavior-driven specifications using the Given / When / Then structure do the heavy lifting, because they force the model to think in state, action, and outcome rather than guessing at intent.

Format turns out to carry real weight. The SkCC study by Ouyang and colleagues, reported in the same paper, found LLM agents so sensitive to instruction formatting that generic, unoptimized Markdown produced performance drops of up to 40%. For configuration nested more than three levels deep, YAML hit 51.9% parsing accuracy against 43.1% for JSON and 33.8% for XML. Narrative in Markdown, structure in YAML. A five-minute change that recovers accuracy you are currently paying for in review cycles.

The organisational half matters more than the syntax. The spec lives in a specs/ folder checked into version control, indexed by the agent, read by humans. The New SDLC paper is blunt with engineering leaders here: rule files, system prompts, eval suites, and skill libraries should be reviewed in pull requests, versioned with the project, and owned by named engineers.

That whole layer has a name in the paper. The harness is everything wrapped around the model, the instructions and tools and sandboxes and guardrails and observability, and the authors are direct about whose problem it is: that surface area belongs to your team, not to the model provider. Without named ownership the harness drifts, and agent behaviour stops being reproducible across the team. Which makes this the same discipline shift I wrote about in scaling AI from experiment to infrastructure, one layer lower in the stack, and the reason the specs for probabilistic software look different from the ones you wrote for deterministic systems.

The bill arrives as review load

Skip the upstream work and you get more artifacts, faster, with no filter. Boonstra names the three failure categories precisely: merge conflicts from multiple developers landing in the same file within the hour, review gridlock as a large pull request becomes a nest of dependent sub-requests, and context fragmentation, where an agent quotes an outdated snapshot of a file and generates code calling a function that no longer exists.

Then the human cost. Quantum Workplace research reported by CNBC found frequent AI users 45% more likely to experience high burnout than non-users. The mechanism Boonstra describes is approval fatigue: a constant stream of micro-approvals until developers start clicking approve reflexively and the team quietly stops checking the machine’s work in order to keep pace with it. His own team found the limit when an agent in auto-approve mode clicked a new button, connected to a deprecated service with no safeguards, and sent fifty colleagues emails full of hallucinated content.

When the agent does something wrong, check the harness before you blame the model. On the Terminal Bench 2.0 benchmark, one team moved a coding agent from outside the top 30 into the top 5 by changing the harness alone, with no model change. A separate LangChain study raised a score by 13.7 points by adjusting only the system prompt, tools, and middleware around a fixed model. Most agent failures, examined honestly, are configuration failures.

Start with one module, not a mandate

The temptation at leadership level is to announce spec-driven development as policy. That produces compliance documents nobody regenerates from.

The narrower version is the one my own repositories can evidence. Take the module with the highest churn and the clearest test coverage. Write the spec until it passes the regeneration test. Put it under version control with a named owner. Then measure the change in review hours rather than lines generated, because review hours are where the constraint now lives.

Osmani’s book puts the ceiling honestly: AI reliably covers around 70% of a feature, and the last 30%, the edge cases and the architecture and the maintainability, still needs serious human expertise. The papers a year later call it the 80% problem. The drift between those numbers is the point: the share the machine handles keeps rising, and the residue keeps getting harder and more senior. Your advantage sits in how precisely you can describe the job before it starts, and how fast you can tell whether it got done. That is the work of agentic engineering rather than ticket-taking.

So pick the module this week. Run the regeneration test on it, log the review hours on either side, and bring that number to your next planning cycle. It will settle the tooling debate faster than another vendor demo.

References

• Boonstra, L. (2026). Spec-Driven Production Grade Development in the Age of Vibe Coding: The Blueprint for Scalable Workflows and Team Evolution. Google, May 2026.
• Osmani, A., Saboo, S., & Kartakis, S. (2026). The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering. Google, May 2026.
• Osmani, A. (2025). Beyond Vibe Coding: From Coder to AI-Era Developer. O’Reilly Media. ISBN 979-8-341-63475-6.