The Handoff That Breaks Every Autonomous SDLC Pipeline

Chain agents across the development lifecycle — specify, design, implement, test, review — and one handoff fails more consistently than the rest. It's the first one: intent to specification.

Everything downstream executes faithfully on whatever comes out of it, which means an error there is amplified by every subsequent stage rather than caught by one.

Why this specific boundary

The input to stage one is a person's intent, which exists partly as a description and largely as unstated context: what they're actually trying to achieve, which constraints are firm, which parts they haven't thought about, what they'd say if asked the right question.

The output is a written specification — a lossy encoding of that intent, and lossy in a systematic way. The parts hardest to articulate are the parts most likely to be dropped, and those are frequently the parts that determine whether the result is right.

Every later stage then treats the specification as ground truth, because from their position it is. → An implementation agent has no way to know the spec captured the wrong thing. It will build exactly what was written, well, with tests confirming it does what was written.

What makes it worse than a human handoff

A person receiving a vague spec does three things an agent typically doesn't:

They notice it's vague. Years of pattern-matching on underspecified requests produces a feeling that something is missing.

They ask. Often informally — a message, a hallway question — that resolves the ambiguity in seconds and leaves no artifact.

They fill gaps from context. Not always correctly, but from a model of what the requester probably meant, built from having worked with them.

An agent given the same spec proceeds. It has no accumulated sense of what's normally missing, no cheap channel to ask, and no model of the requester. It produces a confident implementation of an under-specified thing.

⚠️ And because the downstream stages verify against the spec rather than against the intent, the pipeline's own quality checks all pass. Tests confirm the wrong behavior. Review, if it checks the diff against the ticket, confirms compliance with the wrong requirement.

Fixing the boundary rather than the stages

Make specification an interactive stage, not a transformation. The agent's first job is to produce questions, not a spec. What's ambiguous, what it's assuming, what would change the implementation. Three good questions answered by the requester is worth more than any amount of downstream capability.

Require the spec to state its assumptions explicitly.

specification: exclude shipping from the total when status is cancelled
assumed:       applies to partial cancellations too
assumed:       existing cancelled orders are not retroactively corrected
unclear:       whether tax follows shipping — implemented as: tax also excluded

The unclear line is the valuable one. It converts a silent guess into a visible one that a person can correct in seconds.

Have a human approve the spec, not just the code. ✅ Reviewing a specification takes a minute and catches the errors that cost hours downstream. Reviewing only the final diff means catching the same errors after five stages of faithful work built on them.

Attach the original intent to every downstream stage. Not just the spec — the original request, verbatim. Then the implementation and review stages can notice a mismatch between what was asked and what was specified. This is cheap and it's the only mechanism that catches a bad spec after the fact.

🔍 Detecting it in an existing pipeline

Sample completed work and ask the original requester one question: did this do what you wanted?

Not "is it correct" — correct against the spec is what everything already measures. The failures concentrate in work that was correct and not what was wanted, and that gap is invisible to every automated check in the pipeline by construction.

If that number is bad, the fix isn't a better implementation agent.

The takeaway

The intent-to-specification handoff is where SDLC pipelines lose, because it's the only stage whose input isn't a written artifact and whose errors are invisible to everything downstream. Make it interactive — questions before specification — require assumptions and ambiguities to be stated, put a human gate on the spec rather than only on the code, and carry the original request through every stage so a mismatch can still be caught. Everything after that boundary is faithfully executing whatever survived it.