Requirements Are the Bottleneck an SDLC Agent Can't Remove
Compress implementation to nothing and delivery barely moves, because implementation was never the long row in the table. The constraint is upstream, it's organizational, and no tooling touches it.
Make implementation instant and the constraint moves to whatever feeds it. In most organizations that's the supply of well-specified work, and it was a constraint long before agents existed — it was just hidden behind the larger cost of building.
The queue that was always there
Look at where a feature actually spends its time. A rough shape, illustrative but recognizable:
idea → decided worth doing weeks (prioritization, competing work)
decided → specified days (clarification, edge cases, sign-off)
specified → implemented days ← the part that got fast
implemented → reviewed hours
reviewed → deployed hours
Compressing the implementation row toward zero shortens the total by whatever fraction it occupied. The rows above it are unchanged, and they're larger.
→ This is why teams adopt coding agents, measure a genuine speedup on implementation, and don't see proportionate change in delivery. The measurement is real; it's just not measuring the constraint.
Why specification doesn't compress the same way
It requires a decision-maker's attention. Someone with the authority and context to say what should happen has to spend time on it. That person is usually the scarcest resource in the process, and their time isn't freed by faster implementation.
It requires resolving genuine unknowns. Half of specification is discovering that nobody has decided something — what happens to existing records, which customers are affected, whether the old behavior is deprecated or supported. Those aren't writing tasks; they're decisions that need people to make them.
It's serialized on availability. Getting five minutes from the person who knows takes a day. That latency is organizational, and no tooling change touches it.
What can actually be sped up
Being fair: parts of specification are assisted well.
- Drafting from a conversation. An agent turning a discussion into structured acceptance criteria is genuinely faster than doing it by hand.
- Surfacing the questions. "This doesn't say what happens to in-flight orders" — mechanical, valuable, and it front-loads the discovery that otherwise happens mid-implementation.
- Consistency checking against existing behavior. Catching that a proposed rule contradicts something documented elsewhere.
- Generating the edge-case list for a human to rule on, which is recall rather than judgment.
What isn't assisted is the deciding — and that's the part occupying the calendar.
✅ Where the leverage actually is
If specification is the constraint, the useful interventions are organizational rather than technical:
Shorten the decision loop. The single biggest lever. Who can answer a scope question, and how long does it take to reach them? Reducing that from days to hours does more for throughput than any implementation speedup.
Batch the ambiguity. Rather than discovering unknowns one at a time mid-build, have the specification stage produce the full question list up front and resolve it in one pass. This is the thing agents genuinely help with, and it converts many small waits into one.
Push decision authority down. Much of the wait is queueing for someone senior. Where a decision can be safely made closer to the work, it stops being queued.
Write specifications as tests. ⚠️ A specification precise enough for an agent to implement correctly is precise enough to be executable. Teams that make that shift get the specification and the acceptance criteria in one artifact, which removes a translation step and the drift that comes with it.
💡 The uncomfortable diagnostic
Look at your last ten delivered items and mark the calendar time in each phase. If implementation was a minority of elapsed time before adopting agents, it's a smaller minority now — and the speedup you measured is real and mostly irrelevant to delivery.
That's not an argument against the tooling. It's an argument for knowing which constraint you're working on, because effort spent on a non-constraint produces no throughput at all.
The takeaway
Instant implementation moves the constraint upstream to the supply of decided, specified work — a bottleneck that predates agents and is organizational rather than technical. Use agents where they help there: drafting, surfacing questions, enumerating edge cases. Then spend the real effort on shortening the decision loop and pushing authority down, because that's the row of the table that's actually long.