writing
Three AI-Native Software Delivery Methods Compared
Anthropic, AWS, and OpenAI describe different layers of AI-native software delivery: artifact handoffs, lifecycle governance, and the agent harness.
AI-native software delivery does not have one agreed method.
Anthropic, AWS, and OpenAI describe three useful approaches. They overlap, and they focus on different layers:
- Anthropic connects lifecycle stages through committed artifacts.
- AWS provides a broader delivery and governance framework.
- OpenAI focuses on the repository and tool environment that lets coding agents work reliably.
The practical answer is not to pick one vendor’s vocabulary. Use the smallest combination that preserves intent, makes evidence executable, and keeps human accountability at the consequential boundaries.
Anthropic: make every handoff an artifact
Anthropic’s AI-native SDLC playbook keeps six recognizable responsibilities: Plan, Design, Build, Test, Deploy, and Maintain. The main change is how work moves between them.
Each stage writes an artifact that the next stage can read. An idea becomes intent.md. The accepted intent becomes spec.md. The approved specification becomes plan.md. Implementation produces code and tests. The pull request preserves review findings. A production incident can become a new intent and start the loop again.
This creates a shared interface between people and agents. The product owner can correct the intent. An engineer can challenge the plan before code changes. A reviewer can compare the final diff with the accepted specification. Git records who changed and approved each artifact.
The method is deliberately modular. Teams can adopt individual plays and keep humans focused on the gates that require judgment. Anthropic’s security guidance for its AI-native SDLC adds an important qualification: higher velocity requires risk-tiered automation, hard identity and access boundaries, deterministic and agentic review, logged approvals, and human review for critical code.
The strength of this approach is continuity. It gives an agent enough durable state to continue the work without relying on one long chat. Its risk is ceremony. A small reversible change does not need four documents. The artifact chain earns its cost when ambiguity, duration, coordination, or consequence makes handoff quality important.
AWS: govern the complete delivery lifecycle
AWS’s AI-Driven Development Life Cycle addresses a larger problem. It is a structured method for moving from customer intent through implementation and operation with AI participating across the lifecycle.
The open-source AI-DLC Workflows organize work across Inception, Construction, and Operations. The phase and stage model covers discovery, requirements, design, implementation, testing, deployment, and operational learning.
Two concepts make the method especially useful for complex work:
- A Unit is an independently implementable component or service.
- A Bolt is one Construction pass for a Unit or a small dependency-linked group.
The first Bolt should create a walking skeleton that exercises the architecture end to end. Later Bolts can follow dependency, value, risk, and learning priorities. AWS also makes scope and workflow depth explicit, so a focused change does not automatically inherit the same process as a large system.
This is stronger than a file naming convention. It provides lifecycle governance, decomposition, traceability, and evidence for environments where several teams, services, controls, or approval owners are involved.
The tradeoff is weight. A full enterprise method can slow down work when the real need is one bounded repository change. The method should scale with consequence and irreversibility, not with project prestige.
OpenAI: engineer the harness around the agent
OpenAI’s harness engineering starts from another observation: an agent is only as effective as the environment in which it works.
Repository knowledge must be discoverable. Tests, linters, type checkers, and build commands must provide fast feedback. Work should be isolated and reviewable. Repeated review feedback should become durable instructions or deterministic checks. The harness gives the model context, tools, observable results, and a clear definition of done.
OpenAI’s guidance for long-horizon Codex tasks makes the operating loop concrete: plan, edit, run tools, observe, repair, update status, and repeat. Durable project memory keeps the work coherent through a specification, milestone plan, execution instructions, and a current status record.
The custom code review rules show how the harness learns. Consequential repository-specific invariants belong in scoped AGENTS.md rules. Mechanical checks remain in CI. A rule should include both the risk and the safe path, and it should be tested against violations, valid exceptions, and unrelated changes.
Harness engineering is less a lifecycle methodology than an execution foundation. It explains why the same model performs differently across repositories. A vague codebase with slow tests and hidden conventions will produce weaker agent work than a repository with clear boundaries and immediate feedback.
How the methods fit together
| Method | Primary layer | Best fit | Main risk |
|---|---|---|---|
| Anthropic AI-native SDLC | Artifact handoffs between stages | One product or repository that needs durable continuity and reviewable approval | Creating documents that do not improve a decision |
| AWS AI-DLC | Lifecycle governance and decomposition | Complex enterprise delivery with multiple components, controls, or teams | Applying the full method to small reversible work |
| OpenAI harness engineering | Agent execution environment and feedback loops | Any repository where coding agents must operate reliably over time | Treating instructions as enforcement instead of adding tests and boundaries |
I would combine them in three layers:
- Use AWS to decide the delivery depth, decomposition, and governance that the outcome requires.
- Use Anthropic’s artifact handshake where intent, specification, plan, and evidence must survive across people or agent sessions.
- Use harness engineering to make the repository executable: clear instructions, bounded tools, fast verification, observable failures, and feedback encoded close to the code.
Then define authority once. Deterministic controls should enforce stable invariants. Agents should handle reviewable exploration and implementation. Humans should retain product judgment, material risk acceptance, and irreversible release decisions.
A small working example
I used the lighter artifact pattern in the 7DayFocus AI Delivery Lab. Each material change keeps accepted intent, specification, plan, implementation, tests, review findings, and evidence beside the code.
The runtime demonstrates the same principle at a different boundary. A model may propose task moves and priority changes. The application parses and validates the complete proposal, shows the exact diff, checks that state has not changed, and applies one atomic transition only after explicit approval.
The repository does not claim to implement Anthropic’s internal process or the full AWS AI-DLC. It makes one useful pattern inspectable: agents can move quickly when intent and evidence are durable, deterministic boundaries remain outside the model, and humans approve the decisions that matter.