Coding assistants were act one. They put a model inside the editor and made individual developers faster at typing. Act two — the one unfolding now — is different in kind, not degree: AI agents drafting real work at every stage of the software development lifecycle, orchestrated together, with humans deciding what advances. Forrester calls this the shift from code assistants to orchestrated SDLC agents, and I think they're right about the direction. But most of the conversation focuses on the wrong thing. Everyone is arguing about how autonomous agents should be. The interesting design problem is the opposite one: the gate.
The local-optimisation trap
Here is the pattern I keep seeing in enterprises. A team adopts an AI coding tool. Coding tasks genuinely speed up — call it 30–40% on the tasks the tool suits. Then leadership asks why overall delivery barely moved, and the honest answer is that coding was never the bottleneck. If planning, design, review, testing, and release are still fully manual, you've accelerated one station on an assembly line and created a bigger queue in front of the next one. Reviewers drown in AI-generated pull requests. QA inherits more change per sprint than it can absorb. The system's throughput is set by its slowest stage, and you just made the fast stage faster.
This is why I've come to believe the unit of AI adoption in engineering should be the lifecycle, not the task. The organisations getting compounding returns are the ones treating the SDLC as a single pipeline in which AI participates at every stage — what Thoughtworks calls preparing for the agentic SDLC — rather than sprinkling tools onto individual roles.
What an agentic lifecycle actually looks like
Strip away vendor language and the shape is consistent. Delivery decomposes into stages — high-level architecture, solution design, implementation, code review, testing, release. Each stage produces an artifact: an architecture document, a design package, a pull request, a review report, test evidence, release evidence. In an agentic SDLC, a specialised agent drafts the artifact for each stage: an architect agent proposes the high-level design, a dev agent implements and opens the PR, a review agent does the first quality-and-security pass, a QA agent generates and runs the tests.
Two properties make this work in a real organisation, and neither is model intelligence.
First: nothing advances without a human sign-off. Every stage boundary is an explicit approval gate. A named person reviews the artifact and either approves it into the next stage or sends it back with direction. The agent does the heavy lifting; the human makes the decision — and is accountable for it.
Second: every artifact is versioned, traceable, and auditable. When an agent drafted the design, a person approved it, and the implementation links back to both, you can answer the question that compliance, security, and incident reviews will inevitably ask: who decided this, based on what?
Why the gate is the point
It's tempting to read approval gates as training wheels — friction to be removed as models improve. I think that misreads what the gate does.
The gate is what makes the system deployable in an enterprise at all. Regulated industries, security review boards, and change-management processes don't have a category for "the model decided." They have a category for "a person approved this artifact at this time for these reasons." Gates translate agentic work into the accountability language organisations already run on.
The gate is also what makes the system improvable. Every rejection at a gate is a labelled failure: this artifact, drafted from this context, was not acceptable, and here's what was wrong. That signal tells you where your agents' context is thin, where your standards are unwritten, and where your prompts encode the wrong assumptions. Autonomy without gates doesn't just risk bad output — it destroys your feedback loop.
And the gate reframes the role question. Engineers in an agentic SDLC spend less time producing artifacts and more time judging them — setting intent, reviewing drafts, and owning decisions. That's not a diminished role. It's the senior half of the job, applied at every stage. The uncomfortable part is that judging well is a skill many teams have under-invested in, because production used to be the constraint.
The other half: agents need something to stand on
There's a quieter prerequisite that determines whether any of this works: what the agents know. A million-line codebase, tribal architecture decisions, and conventions that live in senior engineers' heads are not consumable context for a model. Pointing an agent at raw repositories and hoping is how you get plausible-looking work that violates constraints nobody wrote down.
The organisations doing this seriously are building a curated knowledge layer: distilled, validated, versioned descriptions of systems, decisions, and standards that agents retrieve instead of guessing. I've written separately about why context, not intelligence, is where agents fail — at lifecycle scale, that principle becomes infrastructure.
Where I'd start
If you're leading engineering and this is on your roadmap, my advice is unglamorous:
- Map your lifecycle honestly. Name the stages you actually have, the artifact each produces, and who approves what today. You cannot gate what you haven't defined.
- Pick two adjacent stages, not six. Dev-plus-review is a good first pair: the artifacts are concrete and the feedback loop is fast. Prove the handoff before you scale the pipeline.
- Write down approval criteria. Gates fail when "review" means "vibes." If a human can't articulate what makes the artifact acceptable, an agent can't draft toward it.
- Instrument from day one. Cycle time per stage, rejection rates per gate, rework loops. You'll want evidence, not anecdotes, when you decide what to expand — and feelings aren't findings.
The models will keep getting better; that part is being handled for you. The durable competitive work is designing the system around them — the stages, the artifacts, the knowledge layer, and above all the gates. Autonomy is a capability. Accountability is an architecture. Build the second one.