September 10, 202614 min read

AI-native SDLC: how the delivery process changes

AI-native Development
SDLC
Spec Driven Development

In an AI-native software development lifecycle (SDLC), a team gives agents work across planning, implementation, release, and operations. The useful change is in how that work connects: agents produce evidence the next stage can use, and people review decisions without having to restart the process at each handoff.

Imagine a coding agent finishes an invoice export before lunch. An engineer still has to explain the requirements to the reviewer, collect test results, prepare a release, and investigate the first production failure. The team has accelerated implementation. Much of the surrounding work still depends on someone remembering what to do next.

Spec Driven Development (SDD) gives that faster implementation clear requirements and a way to verify the result. AI-native SDLC extends the improvement to the surrounding work: deciding what to build, reviewing changes, releasing them, and acting on production feedback. The two approaches can work together to reduce the time and effort of delivering a useful change.

Faster coding leaves the rest of delivery to improve.

Before coding agents implementation takes much of the time

Plan
Design
Build
Test
Deploy
Maintain

With coding agents implementation takes less time

Plan
Design
Build
Test
Deploy
Maintain
Time saved in implementation

SDD · make agent work precise

Define the behavior, plan the change, and verify the result. SDD structures work around the implementation that coding agents accelerate.

AI-native SDLC · improve the whole delivery

Extend agent work to requirements, review, release, and operations. Connect these stages so the remaining handoffs take less effort and time.

Concept adapted from Anthropic's playbook. Widths and heights are illustrative, not measured timings. Maintenance continues after release. SDD spans specification, planning, and verification; faster coding does not mean that work is fully optimized.

What changes beyond AI-assisted coding

In The AI-Native SDLC playbook, Anthropic argues that faster coding exposes delays around the build stage. It proposes six connected stages: plan, design, build, test, deploy, and maintain. Versioned outputs connect the stages, and production findings can initiate new work. People remain accountable for judgment and approvals.

My practical test is whether the team can delegate a handoff along with the task. An agent that writes a spec helps with documentation. A design task that starts from an accepted customer problem, produces a spec, and routes unresolved choices to the right owner changes how the team gets work done.

People coordinate each handoff

Someone gathers context, starts the agent, copies its output, finds a reviewer, and starts the next task.

The team connects agent tasks

An accepted record queues the next task with its inputs. People review decisions and exceptions; configured checks route routine results.

Teams already use CI/CD, automated checks, and production feedback. The additional opportunity is to delegate work that involves interpreting those inputs: synthesizing requests, proposing a design, investigating a failed test, or preparing a diagnosis. Existing delivery controls still provide the boundaries around that work.

An invoice export through the whole lifecycle

Consider a hypothetical SaaS product. Account owners ask support for invoice CSVs; the team wants them to download those files themselves. The first release will support up to 10,000 invoices per export, with strict account isolation. That limit is an example product decision, not a benchmark.

The workflow below is my proposed application of the idea. The snippets show what each stage would leave behind. Later records include fields that the actual tools must populate with results; they do not claim that these checks or deployments have happened.

Invoice export · one change through delivery

Each accepted output supplies the next task.

Planintent.md
Product accepts the problem and scope
Designspec.md + design decision
Product and engineering resolve open decisions
Buildplan.md + code + tests
Engineer accepts the plan; checks run on the diff
Testcheck results + review findings
Failed checks return work to the build stage
Deployrelease record + rollback procedure
Release owner authorizes the rollout
Maintainincident record + next intent
Engineer checks the diagnosis; product prioritizes

Production evidence returns to Plan. Failed checks return to the stage that needs correction.

A proposed workflow for this example. Select a stage to see its artifact, decision, and expected benefit. Checks run throughout the work; these are responsibility boundaries, not six one-pass phases.

1. Plan: turn support requests into a proposal

Manual handoff. A product manager reads export requests, asks support for examples, and writes a ticket for engineering.

With a connected agent. An intake agent reads a permitted, sanitized set of requests, groups the reasons customers need exports, and drafts a proposal with links to those requests. It flags missing evidence instead of inventing demand.

intent.md · proposed customer outcome

Change: invoice-export
Problem: owners ask support for invoice CSVs.
Outcome: owners can export without a ticket.
Evidence: linked, sanitized support requests
Scope: current account; up to 10,000 invoices
Open: required columns and download expiry

Human decision: Product checks the source requests, chooses the outcome, and accepts or rejects the proposal.
What moves the work forward: Acceptance queues a design task with this exact intent revision attached.
Expected benefit: Product starts with a reviewable proposal. Engineering can follow the customer evidence without asking support to reconstruct it.

2. Design: resolve behavior before building

Manual handoff. An engineer translates the ticket into behavior and asks about roles, limits, and error handling as implementation proceeds.

With a connected agent. A design agent reads the accepted intent and existing authorization code. It drafts acceptance criteria and proposes a design using the current export path. It asks the team to settle expiry and CSV fields before producing a build task.

spec.md · agreed behavior

Change: invoice-export
Input: accepted intent revision
Allow: account owners only
Isolation: current account invoices only
Limit: 10,000 invoices; larger requests rejected
Download: authenticated; expires in 15 minutes
Columns: invoice ID, date, currency, gross total

Human decision: Product confirms the fields and limits. Engineering approves the authorization and expiry design, or requests changes.
What moves the work forward: The approved spec and design decision become inputs to implementation planning.
Expected benefit: The team catches disputed behavior while it can still change a few lines of specification, before code and tests depend on it.

3. Build: implement with enough context to continue

Manual handoff. An engineer starts an agent session, explains the repository, and repeats that context when work moves to another session.

With a connected agent. The build agent loads the spec, repository instructions, and test commands. It proposes a file-level plan, implements an accepted slice on a branch, and records what passed and what remains. A later session reads that record before continuing.

plan.md · implementation and progress

Change: invoice-export
Input: approved spec revision
1. Add export request and download routes.
2. Apply account-owner checks to both routes.
3. Add CSV action and limit error to the UI.
4. Test isolation, expiry, and the row limit.
Handoff: commit, checks run, remaining work

Human decision: An engineer accepts the approach and resolves departures from the spec. The agent cannot approve its own scope expansion.
What moves the work forward: The candidate commit triggers verification against the same spec revision.
Expected benefit: The next session can resume from recorded progress. The reviewer gets a bounded diff with a reason for each change.

4. Test: return failures to the agent with evidence

Manual handoff. A reviewer discovers a missing permission check, describes the failure, and waits for an engineer to restart the agent.

With a connected agent. The agent runs the test suite and exercises the export in a browser. CI reruns protected checks against the candidate commit. A failing result returns the reproduction steps to the build task; the agent repairs within scope and submits another candidate.

Verification record · required evidence

Candidate: exact commit under review
Required checks:
- Non-owner request and download are denied.
- Another account's file cannot be downloaded.
- Expired links fail; oversized requests fail.
- An owner downloads the agreed CSV columns.
Attach: tool results, run IDs, open findings

Human decision: The reviewer checks account isolation and gaps in coverage. Missing evidence blocks progress; the agent cannot turn a failed requirement into a pass by weakening it.
What moves the work forward: Passing checks and the required review make the candidate eligible for release.
Expected benefit: Reviewers spend less time relaying reproducible failures. They can inspect check results and focus on assumptions the tests may share with the code.

5. Deploy: ship the version that passed review

Manual handoff. Someone assembles release notes, checks which commit passed, and asks operations how to disable the feature if it fails.

With a connected agent. The agent prepares release notes and a rollout proposal from the reviewed diff. The pipeline checks the candidate's approvals and test results. After release authorization, it deploys that version and records the environment and smoke-check results.

Release record · deployment evidence

Change: invoice-export
Candidate: reviewed commit + build identifier
Required: passing checks and release approval
Rollout: enable for the internal test account
Smoke check: request and download an export
Rollback: disable invoice_export feature flag
Record: deployment ID, result, approver

Human decision: The release owner accepts the rollout and stop conditions. Production credentials and pipeline permissions enforce that decision outside the prompt.
What moves the work forward: A successful rollout registers the deployed version with the monitoring task.
Expected benefit: Operations can identify what shipped and how to stop it. The team avoids rebuilding release context from chat messages.

6. Maintain: use production failures to start the next change

Manual handoff. An alert waits for a person to collect logs, identify the release, and translate the investigation into a new development task.

With a connected agent. Suppose exports within the supported limit time out on larger accounts. An alert invokes a diagnostic agent with bounded read access. It gathers traces, links the deployed version, and proposes a background-job export as a hypothesis for review.

Incident record → next intent.md

Change: invoice-export-follow-up
Observed: supported exports time out
Evidence: trace links + deployed build ID
Hypothesis: request duration exceeds timeout
Proposed: evaluate background export jobs
Unknown: query cost or request-path limit?
Next: engineer validates; product prioritizes

Human decision: An engineer validates the cause and handles any immediate incident response. Product decides whether the proposed redesign enters the backlog.
What moves the work forward: An accepted follow-up starts another design pass and adds the failure to regression coverage.
Expected benefit: The next task arrives with an investigation attached. The team can address a recurring failure without losing the evidence between operations and development.

Why the artifacts matter

An artifact is a durable output of the work: a document, commit, test result, review, or deployment record. Its value comes from what someone can do with it. A reviewer needs to see which requirement a test covers. A diagnostic agent needs to know which build produced a trace. The next implementation session needs to know what remains unfinished.

Anthropic's work on long-running agent harnesses describes using progress records and git history to help new sessions recover context, alongside incremental implementation and end-to-end testing. That addresses a practical failure: a fresh session should not have to guess what the previous session completed.

For the export workflow, I would link records through a change identifier and the exact input revisions. Each handoff would name its owner, status, evidence, and unresolved questions. A new implementation commit would need fresh checks; a passing result for yesterday's commit would not authorize today's release.

What makes the process run

I would begin with one connection: an accepted export spec queues a planning task on a branch. The task receives the spec revision, repository context, allowed tools, and a definition of done. The engineer reviews the plan before the build agent continues. That is enough to test whether the handoff saves coordination work.

As the team adds connections, the workflow needs explicit rules for passing, failing, and escalating. Passing verification can make a commit eligible for release; a failed test sends evidence back for repair. An unresolved security decision goes to an engineer. Retries need a limit, and a duplicate event should not create another release or another copy of the same task.

Claude Code's hooks documentation describes running configured actions at lifecycle events, including checks that can block tool calls. Hooks can handle local automation; CI permissions, branch protection, and deployment controls must enforce the wider release policy. Instructions in a prompt cannot substitute for those controls.

The Terraform module factory shows a smaller piece of this approach: a coding agent can run a command that checks platform standards and returns concrete failures. The team maintains the checks so the agent has a dependable way to judge its work.

Where Spec Driven Development fits

SDD makes a specification an active input to development. The team records intended behavior and constraints, plans against them, and verifies the implementation. For the export, that means deciding who may request and download a file, which invoices it contains, and how limits and expiry work.

GitHub Spec Kit organizes work around project principles, a specification, a plan, tasks, implementation, and convergence checks. Kiro uses requirements or bug analysis, design, and tasks. Both illustrate how teams can make intent concrete enough for an agent to implement and check.

Scroll the table sideways to compare both approaches.

How specification-led work fits within an AI-native delivery process
Dimension	Spec Driven Development	AI-native SDLC
Primary concern	Make intended behavior explicit and use it to guide implementation and verification.	Give agents bounded work across delivery, with usable outputs, checks, and ownership between stages.
Invoice export example	Specify which roles may export, which invoices they can access, and how the team will test that behavior.	Connect customer requests to that spec, then connect implementation, release evidence, and production failures to the next task.
A sign it is working	The team resolves ambiguous behavior before implementation and can trace tests back to requirements.	People spend less time relaying context and restarting work, while delivery quality stays within agreed limits.

These are overlapping concerns. SDD can include production requirements, bug fixes, and iterative changes; it does not require a frozen spec or a waterfall process. AI-native delivery can use SDD throughout. The distinction is that a spec alone does not assign an incident, configure a trigger, or decide who may release the implementation.

How to tell whether the process improved

The benefits beside each stage are hypotheses to test. For the export, I would expect less context reconstruction, fewer manual restarts after routine failures, and a clearer route from a production problem to a reviewed fix. More generated documents would not establish any of those gains.

Coordination effort: count manual restarts and the time people spend gathering inputs or copying results between tools.
Delivery time: measure from accepted customer need to usable release, including time waiting for review and approvals.
Quality and cost: track rework, failed releases, escaped defects, agent runtime, and model cost alongside throughput.
Customer outcome: check whether owners complete exports and whether export-related support requests decline, accounting for usage volume.

An agent can write a detailed spec for a feature customers do not need. It can repeat an incorrect assumption in both code and tests. A faster loop makes those errors travel faster too. People still need to inspect customer evidence, challenge risky assumptions, and revise the checks when failures reveal a gap.

Start with one complete change

Trace the current path. Follow a recent feature from request to production. Find where people wait or reconstruct context.
Agree the records and decisions. Choose where intent, requirements, check results, and release evidence belong. Name who accepts each transition.
Connect one repeated handoff. Give the agent bounded access and usable inputs. Define the failure route before enabling automatic continuation.
Compare the whole delivery. Use similar changes to check effort, lead time, failures, and customer outcomes before expanding the workflow.

Keep the amount of specification and review proportional to the change. A copy correction needs less ceremony than account permissions. The goal is to let a team deliver a well-defined change with less coordination work, enough evidence to review it, and a reliable way to act on what happens after release.