The agentic SDLC: from SRS document to production

The interesting question about AI in software delivery is no longer whether a model can write a function. It can. The question is whether the whole path from "here is what we need" to "it is running in production" can be driven by agents, with a person appearing only at the two points where judgement is actually required.

That path has a name now — the agentic SDLC — and it is buildable today with tools that are generally available. This is how the wiring works, and where it breaks.

The spec is the product

Everything downstream inherits the quality of the specification, and this is the part nobody wants to hear. An agent given a vague requirement does not push back the way a senior engineer does; it produces something confident and plausible that satisfies the letter of what you wrote.

So the SRS stops being a document you write once and file. It becomes the executable contract that the whole pipeline is measured against — the planning agent decomposes it, the test agent derives cases from it, and the QA agent checks the deployed build against it. Written properly, it needs:

• Acceptance criteria per feature, phrased so a test can pass or fail against them. "Fast" is not a criterion; "p95 under 400ms at 200 concurrent users" is.
• Explicit non-goals. Agents will happily build the thing you did not ask for if the spec leaves room.
• The data model, or a clear statement that the agent should propose one for approval.
• What must never happen. Negative requirements are how you stop an agent solving a problem in a way that is technically correct and commercially disastrous.

Stage by stage

Planner agent → ticket queue

The planner reads the SRS and emits tickets: one per shippable unit, each with acceptance criteria copied down from the spec, a dependency order, and an estimate. This is the stage most worth reviewing by hand, because an error here multiplies across everything after it.

Give it a strict output schema. A planner that returns prose produces tickets that vary in shape; one that returns a defined structure produces tickets your automation can act on.

Builder agent → pull request

One agent per ticket, one branch per agent, one pull request at the end. Isolation matters more than it sounds: parallel agents editing a shared working tree produce conflicts no human wants to unpick. Git worktrees or separate checkouts solve this cleanly.

The PR is the interface. Claude Code's GitHub Action and the claude-code-action runner are built for exactly this shape — triggered by a workflow event, operating on a branch, opening a PR with the diff and the reasoning attached.

Review agent

A second agent reviews the first agent's work, and it should not be the same agent in a different costume. Different model, different prompt, different priorities — one optimised to produce a change, one to find fault with it. The subagent pattern exists for this: a reviewer with its own context and its own instructions catches things the author is structurally blind to.

Test agent

Tests derived from the SRS acceptance criteria, not from the implementation. This distinction is the whole game. An agent that writes tests by reading the code it just wrote will produce tests that pass, prove nothing, and give you a green dashboard over a broken feature.

Deploy agent

Staging, then canary, then full rollout, with automatic rollback on an SLO breach. The deploy agent should own the rollback decision — a human deciding whether to roll back at 3am is exactly the job that should not exist. The operations loop is where this gets interesting.

The two gates that stay human

You will read claims that this pipeline runs with no human at all. It does not, and the two exceptions are not arbitrary.

1. Scope sign-off. Deciding what to build is a commercial judgement about customers, priorities and risk appetite. An agent can draft it and should. It cannot own it, because it does not carry the consequences.
2. Release approval to production. Not because the agent is likely to be wrong, but because someone has to be accountable when it is. Regulated environments make this explicit; everywhere else it is still true.

Everything between those two gates — plan, build, review, test, deploy to staging, QA against the spec — genuinely runs unattended. That is the claim worth making, and it is a much larger change than it sounds. It moves a person from doing the work to specifying and accepting it.

What breaks

Four failure modes come up repeatedly, and none are about code quality.

• Volume. Ten agents produce more pull requests than one person can meaningfully review. Without a review agent that genuinely gates, you have moved the bottleneck rather than removed it.
• Silent drift. Agents solve the ticket in front of them. Nothing keeps twelve tickets architecturally coherent unless something explicitly checks that, so make architectural consistency a review criterion.
• Cost. Every stage is an inference call, and a retry loop that runs unattended overnight is a memorable invoice. Cap spend per ticket and alert on it.
• Trust collapse. One bad production incident and the owner starts reviewing every diff by hand, at which point the pipeline is a slower version of the old process. Earn the trust incrementally: staging first, then canary, then full autonomy per service.

Where to start

Not with the whole pipeline. Pick the stage where you currently lose most time and automate that one, keeping every other stage manual. For most teams that is review or testing rather than implementation, which is the opposite of where the excitement is.

1. Write one feature's SRS with testable acceptance criteria. Notice how hard this is; that difficulty is the real work.
2. Automate the review stage. Every PR gets an agent review before a human looks at it.
3. Add the test agent, deriving cases from the criteria rather than the diff.
4. Add the builder for well-specified, low-risk tickets only.
5. Move deploy-to-staging behind the agent. Keep production manual until the staging record is boring.

If you want this wired into an existing codebase rather than a greenfield demo, that is what our AI and LLM integration work covers, and how small a SaaS team can be has the economics.

Frequently asked questions

References

1. Claude Code GitHub Actions — Anthropic
2. anthropics/claude-code-action — GitHub
3. Subagents — Anthropic
4. Events that trigger workflows — GitHub Docs
5. SWE-bench — SWE-bench