The Agentic SDLC: Software Delivery With Coding Agents

Coding agents have crossed a threshold. They can take a well-specified change, implement it across a codebase, run the tests, fix what fails, and open a pull request. In many organizations that capability is being adopted tool by tool, developer by developer, with no change to the lifecycle around it. The result is predictable: more code, faster, with the same review capacity and the same verification, which means more risk per unit of time.

This whitepaper describes the agentic software development lifecycle: what changes when agents produce most implementation work, and what has to change around them so that throughput becomes an advantage rather than an exposure. It is written for CTOs, VPs of Engineering, platform leads, and engineering managers. It applies FISTA's spec-driven development methodology to the engineering organization itself.

What changes when agents write most of the code?

Three things change at once, and organizations that address only one of them struggle.

1. The unit of work moves from the ticket to the specification. A ticket says what is wanted; a spec says what correct looks like, including constraints, interfaces, prohibited changes, and acceptance criteria. Agents implement specs well and tickets badly.
2. The bottleneck moves from writing to verifying. When implementation is cheap, review and testing become the constraint. If those do not scale, the pipeline backs up or, worse, review becomes a rubber stamp.
3. The risk profile changes. Agents produce plausible code at volume, including plausible security mistakes, plausible misuse of internal APIs, and plausible violations of architectural intent. Defenses designed for human error rates need to be re-tuned.

The traditional lifecycle assumed implementation was expensive and review was cheap relative to it. The agentic lifecycle inverts that assumption.

What does the agentic SDLC look like end to end?

Phase	Traditional SDLC	Agentic SDLC
Intake	Ticket with a description	Spec with acceptance criteria, constraints, and risk class
Design	Engineer decides approach in their head or a doc	Engineer writes interfaces and constraints into the spec; agent proposes a plan for review
Implementation	Engineer writes code	Agent implements; engineer supervises, unblocks, and refines the spec
Verification	Tests written alongside code; CI runs them	Verification gates defined before implementation: tests, static analysis, security scans, evaluation for AI features
Review	Line-by-line human review of every PR	Risk-classed review: intent and architecture for all changes; line-level review for consequential paths
Release	Deploy after approval	Deploy after gates pass; canary and observability tuned for higher change volume
Learning	Retrospectives	Retrospectives plus metrics on spec quality, gate effectiveness, and escaped defects

The lifecycle is a loop from spec to verified change. Every phase has an artifact, and the artifacts are what make the process governable.

How do you write specs that agents can implement?

A good spec for a coding agent is closer to an engineering design brief than to a user story. FISTA's template includes:

• Intent: the outcome in one paragraph, and why it matters.
• Scope and non-scope: files, modules, and behaviors in and out of bounds.
• Interfaces: function signatures, API contracts, data shapes, and error semantics.
• Constraints: performance budgets, dependencies allowed or forbidden, style and architecture rules.
• Prohibited changes: what must not be touched, such as authentication paths, migrations, or public APIs.
• Acceptance criteria: the tests and checks that define done, written before implementation.
• Risk class: which review policy applies.

The discipline is described in detail in spec-driven development with coding agents. The recurring lesson is that spec quality is the strongest predictor of agent output quality; teams that invest in specs get correct changes, and teams that paste tickets into agents get rework.

How does verification replace trust?

In an agentic SDLC, nothing merges because an agent produced it. It merges because it passed verification gates that were defined before the work began.

Gate	What it checks	Notes
Build and tests	Compiles; unit, integration, and contract tests pass	Agents should not be able to weaken tests without review
Static analysis and lint	Style, complexity, forbidden patterns, architectural rules	Encode architecture decisions as rules, not tribal knowledge
Security	Dependency and license checks, secret scanning, SAST, security tests	Treat generated code as untrusted input
Behavioral evaluation	For AI features: golden datasets, regression suites, quality thresholds	Covered in AI regression testing
Spec conformance	Acceptance criteria met; scope respected; prohibited files untouched	Can be partly automated by diff policy

Two rules keep gates honest. First, agents may not modify the gates for the change they are implementing; test edits and policy changes go through separate, human-reviewed specs. Second, gate failures are data: a spec that repeatedly produces failing changes is a bad spec, and the fix is upstream.

Security deserves special mention. Generated code inherits the vulnerabilities of its training distribution and the agent's misunderstandings of your internal APIs. The AI-generated code security checklist lists the controls; the principle is that the verification pipeline, not the reviewer's eyes, is the primary defense.

How should human review change?

Line-by-line review of every generated change does not scale, and pretending it does is how review becomes theater. The agentic SDLC uses risk-classed review:

Risk class	Examples	Review policy
Low	Docs, tests for existing behavior, isolated internal refactors	Gates only; sampled human review
Medium	Feature code behind flags, internal API changes	Intent and architecture review; spot-check implementation
High	Auth, payments, data migrations, public APIs, infrastructure	Full line-level review by a named owner; two approvals
Critical	Security controls, cryptography, compliance logic	Human-written or human-paired; agents assist only

Reviewers spend their time on what humans are uniquely good at: judging whether the change does what the spec intended, whether the spec was right, and whether the architecture is drifting. The change in reviewer role is one of the largest cultural shifts, and it should be taught, not assumed. Guidance on safe adoption is in how to adopt AI coding agents safely.

What governance does the agentic SDLC need?

Governance answers three questions: what agents may do, what they may touch, and how you know. FISTA recommends a written policy covering:

• Permitted tools and models, with an approval path for new ones.
• Access boundaries: repositories, environments, secrets, and production systems agents may reach, enforced through scoped identities rather than trust.
• Data handling: what code and data may be sent to which model providers, aligned with your privacy and IP obligations.
• Review policy by risk class, as above.
• Audit: which changes were agent-generated, from which spec, verified by which gates, reviewed by whom.
• Incident handling for defects and security events traced to generated code.

A policy template is in AI coding agent governance policy. The organizational framing sits inside the broader AI governance framework.

What should you measure?

Measure delivery outcomes, not agent activity.

Measure	Why it matters
Lead time for changes	The headline throughput gain, from spec to production
Deployment frequency	Whether verification and release scale with implementation
Change failure rate	The risk signal; must not rise as volume rises
Defect escape rate	Whether gates catch what review used to catch
First-pass gate success	Spec quality and agent reliability combined
Review time per risk class	Whether reviewers are spending effort where it matters
Time to restore	Operational resilience under higher change volume

Acceptance rate and lines of code generated measure usage; they say nothing about value and reward volume. Report these measures per codebase and per risk class, because an aggregate can hide a single high-risk service whose change failure rate is climbing while everything else improves. The measurement approach is expanded in measuring AI developer productivity.

What are the common failure modes?

1. Tool adoption without lifecycle change. Individuals use agents; the pipeline is unchanged; review backs up; quality slips.
2. Specs that are really tickets. The agent guesses, the reviewer catches some guesses, and the rest ship.
3. Agents editing their own gates. Tests are "fixed" to pass; coverage drops silently.
4. Uniform review policy. Either everything gets line-level review and the team burns out, or nothing does and risk climbs.
5. Measuring activity. Leadership celebrates acceptance rates while change failure rate rises.
6. No access boundaries. An agent with production credentials and a misunderstood instruction is an incident.

How does FISTA Solutions install the agentic SDLC?

FISTA Solutions builds software with the agentic SDLC internally and installs it inside client engineering organizations through forward deployed engineers and AI enablement engagements: the spec template, the verification gates, the review policy, the governance document, and the metrics, applied to your real codebases with your engineers. Where teams need additional capacity that already works this way, staff augmentation supplies it. FISTA's record of 150+ projects across 12+ countries rests on the same principle as this whitepaper: specify, verify, then ship.

If your engineering organization is adopting coding agents faster than its lifecycle is changing, talk to FISTA on WhatsApp about a scoped assessment, or read AI coding agents for enterprise teams next.