The AI-Native SDLC: From Sequential Phases to a Continuous Loop
Agents can turn long delivery handoffs into short feedback loops, helping teams move bounded changes from weeks or months toward days.
On this page 7 sections
A feature can spend three weeks in requirements, two weeks in design, several weeks in development, and another release cycle waiting for testing and deployment. The engineer writing the code may be busy for only part of that time. The rest is spent waiting for decisions, transferring context, and discovering problems after the work has moved to another team.
Now give that engineer an agent that can implement the feature in an afternoon.
The code arrives sooner. The requirements queue, review queue, and release calendar can still leave the customer waiting.
That is the problem with adding AI only to the build phase. The larger opportunity is to change how the whole software development lifecycle works: from a sequence of long phases to a continuous loop in which agents help carry intent, implementation, verification, and production feedback forward.
Anthropic’s AI-native SDLC playbook, by Louis Claxton, describes this shift across planning, design, build, test, deployment, and maintenance. The idea that stands out to me is the connection between those stages. Each stage produces an accepted artifact that the next stage can read and act on.
For a bounded change in a prepared engineering environment, that can bring a weeks-long delivery cycle closer to days. The outcome depends on the quality of the requirements, the environment, the checks, and the decisions around the agent.
Why the traditional lifecycle takes so long
The familiar enterprise workflow looks like this:
Planning → requirements and design → build → test → deploy → operate.
These phases give the organization a way to coordinate specialist teams and record decisions. Product defines the outcome. Architects evaluate the approach. Engineers implement it. QA verifies it. Release and operations teams manage its arrival in production.
In a phase-based organization, each handoff can create its own queue. A requirement waits for clarification. A design waits for approval. A completed feature waits for a test environment. A tested change waits for the release window.
Feedback travels backward through the same structure. If QA discovers that the expected behavior is ambiguous, the question returns to product. If a security review finds a design problem, implementation may have to start again.
The elapsed time grows from both the work and the distance between the people doing it.
Agile teams and continuous delivery have already shortened many of these loops. The sequential model is a description of a common enterprise constraint, not every team’s current practice. Agents extend the opportunity by helping perform work across the stages and preserving context between them.
The phases become a loop
An AI-native lifecycle still needs planning, requirements, design, implementation, testing, and deployment. What changes is how frequently those activities happen and how tightly they connect.
A product owner describes a problem. An agent drafts structured intent and surfaces open questions. An accepted intent becomes a requirements and design proposal. An engineer reviews the approach. Agents implement bounded tasks, run checks, and return evidence. The approved change enters the deployment pipeline. Production behavior informs the next change.
The loop can operate at the level of a small feature or fix, with several passes before the change reaches production.
Testing happens during implementation. Design changes when a prototype reveals a constraint. Production observations become input to planning. A failed check sends the work back to the relevant step while its context is still available.
The activities remain recognizable. Shorter feedback cycles and accepted artifacts connect them. Days to weeks is a possible delivery timescale for bounded changes, rather than a benchmark or a promise for every project.
The circle matters because it represents continuing feedback. An agent can revisit the requirement or implementation when new evidence arrives, rather than leave that evidence waiting for the next planning cycle.
Accepted artifacts connect the work
The playbook uses files such as intent.md, spec.md, and plan.md to make early decisions available to both people and agents. Later stages produce code, tests, review findings, and operational records.
The exact filenames are an implementation choice. The important property is that the next stage receives an explicit, accepted input.
| Activity | What the agent can help produce | What must be established before proceeding |
|---|---|---|
| Planning | Intent, user problem, constraints, open questions | The owner accepts the intended outcome and scope |
| Requirements and design | Acceptance criteria, design options, dependencies | Product and engineering resolve material ambiguity and risk |
| Build | Implementation plan, code, documentation | The change follows the agreed approach and stays within scope |
| Test | Test results, behavioral checks, review findings | Evidence meets the acceptance criteria for the tested revision |
| Deploy | Release record, rollout and rollback preparation | Release policy permits the change to enter the target environment |
| Operate | Diagnosis, incident evidence, proposed follow-up | The owner triages the finding and accepts any new work |
This reduces the repeated reconstruction of context. A testing agent can read the accepted behavior instead of infer it from the implementation. A reviewer can compare the diff with the plan. An operational finding can identify the affected release and the evidence behind the proposed fix.
Version control helps preserve the chain, but a committed file does not automatically become an approved requirement. The workflow needs to distinguish drafts, accepted inputs, and rejected proposals.
For me, that distinction is fundamental. Automated handoff becomes useful when it carries a decision the organization actually made.
Where the time compression comes from
Agents shorten several kinds of work at once.
They can synthesize requirements from supplied material, explore a repository, draft a plan, implement a change, run checks, and respond to specific failures within one working session. A question discovered during implementation can return to the owner with the relevant evidence attached.
They can also support parallel work. Once the interfaces and responsibilities are clear, independent tasks can move forward in isolated workspaces. API implementation, a client integration against an agreed contract, and documentation may proceed together.
Parallelism needs coordination. Two agents editing the same files, or independently deciding what an API should mean, can create more rework than they save. The integration checks and the person reviewing the result still limit useful concurrency.
The third gain comes from earlier feedback. If a defect is caught immediately after an edit, the agent still has the intent and implementation context available. Fixing it days later requires someone to reconstruct both.
These mechanisms can reduce elapsed delivery time enough to move a bounded feature from weeks toward days. Broad migrations, uncertain product problems, external approvals, and changes with substantial operational risk will still require longer.
Making code generation faster is only one part of that improvement. The waiting time around the code must fall too.
A small feature, carried around the loop
Consider an illustrative request: let customers download an invoice from their account page.
In a sequential workflow, the request might move through backlog refinement, requirements, design, backend implementation, frontend implementation, QA, and a scheduled release. Each stage may be reasonable on its own while the combined wait becomes weeks.
In a prepared agent-assisted workflow, the product owner starts with the outcome and constraints: customers can download their own invoices, existing authentication applies, and billing data must remain private.
An agent drafts acceptance criteria and identifies unanswered questions. Can a user download an invoice from another account? What happens when the invoice is unavailable? Does the existing billing service already provide the document?
Once those questions are resolved, an engineering review accepts the design and a small implementation plan. Independent parts can proceed against the agreed interface.
Checks run as the feature takes shape. Authorization tests verify account isolation. Integration tests verify the billing response. A browser check exercises the download and error states. The reviewer sees those results alongside the diff and accepted criteria.
After the release is authorized, the pipeline deploys the change. Monitoring tracks download failures and authorization errors. An unexpected failure produces an evidence-backed investigation and a proposed follow-up that enters the same loop.
A workflow like this may complete in days when the service interfaces, test environment, and release pipeline already work well. It takes longer if those foundations must be built first. The example illustrates the mechanism; it is not a measured result from the playbook.
Human judgment moves to the decisions
Agent assistance changes where people spend their attention.
Product owners still decide which problem deserves solving. Engineers still judge architectural tradeoffs and whether the implementation fits the system. Security and operations owners still determine acceptable risk. Release authority still follows the organization’s policy.
Agents can prepare these decisions by collecting evidence, flagging conflicts, and doing the repeatable work around them. Reviewers need a clear view of scope, behavior, unresolved findings, and the checks that actually ran.
The boundaries belong in the execution system as well as the instructions. Permissions should limit what an agent can access. CI should enforce required checks. Protected branches and deployment controls should enforce review and release policy.
An agent’s statement that it followed a policy is weaker evidence than a check that verifies the required behavior.
This connects with my earlier posts on agent sandboxes and completion contracts. A short delivery loop needs isolated execution and a reliable way to decide whether the requested work is complete.
Start with one loop and measure the result
I would introduce this approach around one bounded workflow with a clear owner, a reproducible environment, and a useful test suite. A small product enhancement or a well-understood defect is a better starting point than a broad transformation.
Capture the intent and acceptance criteria. Make the agent’s plan reviewable. Give it a way to verify its work. Attach the evidence to the change. Connect deployment and production feedback to the same record.
Then measure the whole journey:
- Elapsed delivery time: from accepted intent to production, including queues.
- Time spent waiting: for clarification, review, environments, and release decisions.
- Quality after release: escaped defects, rollbacks, and repeated incidents.
- Human effort and cost: review, corrections, agent execution, and rework.
If build time falls while delivery time stays flat, the next improvement belongs elsewhere in the lifecycle. If review becomes the queue, improve the evidence and review capacity before increasing agent concurrency.
The engineering goal is a shorter path from an accepted idea to working software and useful production feedback. Agents make that path easier to compress when the organization connects the stages around them.
That is how planning, requirements, build, test, deployment, and operations become a continuous loop. Each pass should leave the team with a verified change, clearer evidence, and a better starting point for the next one.