Both approaches move beyond coding assistants. Their practical value depends on how organisations manage context, enforce controls and retain ownership.
An engineering team generates a feature in an afternoon. Security reviews it the following week. An integration assumption surfaces during testing. Operations asks who approved the recovery approach.
Implementation has accelerated. The decisions around it still take time.
In AI Will Not Fix a Broken Delivery Model, I explored why organisations need to redesign delivery around AI. AWS’s AI-Driven Development Life Cycle and Anthropic’s AI-native SDLC playbook offer two practical approaches to that redesign.
I see value in both. The comparison becomes useful when we examine how each connects business intent, engineering execution and human accountability.
AWS starts with how the team makes decisions
AWS introduced AI-DLC around Inception, Construction and Operations. AI proposes plans, seeks clarification and generates work. People validate the direction and make critical decisions.
Mob Elaboration and Mob Construction bring the team together around requirements and implementation, with context retained in the repository. AWS’s AI-DLC methodology
For enterprise leaders, that collaborative model deserves attention.
A customer onboarding change can involve product, identity, security, integration and operations. Each function understands a different consequence. An agent needs those perspectives before its plausible solution becomes an approved one.
The benefit I would look for is earlier resolution of conflicting assumptions.
AWS also makes the workflow adaptive. Teams can adjust the stages and depth to the task rather than imposing the same analysis on every change. AWS’s adaptive workflow guidance
That principle needs protecting during adoption. A straightforward defect should not acquire a collection of generated documents simply because the framework can produce them.
Anthropic makes the connections between stages explicit
Anthropic retains six familiar stages: Plan, Design, Build, Test, Deploy and Maintain.
The practical shift is how work connects across them. Versioned intent, specifications, plans, code, tests and review findings provide inputs to subsequent activities. Repository instructions and skills carry institutional knowledge; hooks enforce defined checks. Evaluations assess agent behaviour, while production findings feed back into planning. Human judgement remains necessary, particularly for critical and regulated changes. The plays are modular rather than a mandatory linear sequence. Anthropic’s AI-native SDLC playbook
The implication interests me more than the filenames.
A requirement normally passes through conversations, tickets, documents and interpretation. Each transition creates an opportunity to lose context.
When people and agents work from the same approved artefact, the organisation has a clearer basis for checking whether implementation still reflects the original decision.
But an accessible file can still contain an ambiguous requirement. Someone must resolve that ambiguity.
The approaches overlap more than the labels suggest
My reading is that AWS places greater emphasis on collaborative decision-making and adaptive orchestration. Anthropic makes the connections between artefacts, agent instructions and execution controls particularly concrete.
This is a comparison of emphasis, not exclusive capabilities.
Even the stage counts need care. AWS’s original method describes three phases; its current open-source implementation describes five and supports multiple coding environments. AI-DLC implementation guide
I would assess either approach against the organisation’s delivery problems before choosing a framework.
Executable controls still need owners
The supplied commentary makes a useful distinction between skills that guide behaviour and hooks that enforce checks. It goes too far when it suggests that hooks make compliance certain.
A hook can block a defined action within the boundary it controls. It cannot establish that the rule is complete, the configuration is correct or every relevant path passes through it.
Consider customer data. A check might prevent credentials entering a code change while missing sensitive information written to application logs.
The check worked. The organisation’s control coverage was incomplete.
Each automated control needs an owner, a defined scope, evidence that it works and a response when it fails. Those responsibilities become more consequential as agents gain authority.
Review must follow the risk
I would also resist treating plan approval as sufficient assurance for the resulting code.
A sound plan can produce a flawed implementation. Tests can encode the same misunderstanding as the code. An automated reviewer can miss a business constraint that nobody supplied.
Reviewing the plan helps settle direction early. Release assurance still requires evidence about what was built.
For a bounded internal change, automated checks and targeted human review may be proportionate. Changes to identity, payments, customer data or production permissions warrant closer scrutiny.
The organisation should define those boundaries before increasing autonomy.
Production feedback is established practice
The supplied article suggests traditional SDLC lacked a production feedback loop. DevOps and SRE already connect incidents, monitoring and operational learning to engineering work.
The useful development here is making that connection more executable: preserving diagnostic context, initiating corrective work and limiting agents to authorised actions.
I would judge that capability by how reliably it recognises when to stop and escalate.
Start with one complete delivery path
For a first implementation, I would combine the strongest practices from both approaches.
Bring the relevant people together to validate the outcome and constraints. Record the approved context where agents can use it. Connect implementation to meaningful checks. Define approval boundaries and recovery authority.
Then measure the complete path: delivery time, review queues, rework, escaped defects and operational effort.
A faster build is useful. Whether the organisation can release, operate and support that change with confidence determines how much delivery it should delegate next.
Is your organisation ready to delegate more of software delivery to AI?
I work with technology leaders to clarify delivery ownership, strengthen architecture governance and define where AI agents can act safely.
If you’re evaluating AWS AI-DLC, Anthropic’s AI-native SDLC or your own approach, let’s discuss what fits your organisation and where to start.