AIDLC 10 Principles and Execution Model
1. Why AIDLC
This guide contrasts weekly/monthly development iterations with AIDLC's proposed hour/day iterations. In the AIDLC workflow, AI proposes requirements, task decompositions, code, and tests, and people validate the resulting artifacts at defined checkpoints.
AIDLC (AI-Driven Development Lifecycle) is a methodology proposed by AWS Labs for organizing that collaboration. Its focus is the development workflow: how work is divided, which artifacts carry context, and where review is required.
1.1 SDLC vs AIDLC Comparison
Traditional SDLC AIDLC
━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━
Humans plan and execute AI proposes, humans validate
Weekly/monthly iterations (Sprint) Hour/day iterations (Bolt)
Design techniques are team choice DDD/BDD/TDD built into methodology
Role silos (FE/BE/DevOps) AI transcends role boundaries
Manual requirements analysis AI decomposes Intent into Units
Sequential handoffs Continuous flow + Loss Function validation
1.2 Core Shift: Reversing the Conversation Direction
In AIDLC, a person states the intended outcome and the AI proposes a plan before implementation. The reviewer checks the proposed scope, architecture, dependencies, and risks against the project's business priorities.
For example, an agent may propose authentication, a user API, and profile storage as separate Units. A reviewer can remove an unnecessary interface or change the storage choice before code is generated.
Core concepts of AIDLC are defined in AWS Labs' AI-DLC Method Definition. This document organizes the philosophy and execution model of that methodology as a conceptual guide.
2. AIDLC 10 Principles
🎯 AIDLC Core Principles
Ten Core Principles of AWS AI-DLC Methodology
Reimagine Rather Than Retrofit
Reconstruct from first principles rather than retrofitting AI into existing SDLC/Agile. New methodology aligned with AI's rapid iteration cycle (hour/day granularity)
Reverse the Conversation Direction
AI initiates and leads conversations, with humans as validators. Google Maps analogy — humans set destination, AI suggests routes
Integration of Design Techniques
Integrate DDD, BDD, TDD into methodology core. Built-in elements of AI-DLC, not optional like in Scrum
Align with AI Capability
Adopt AI-Driven paradigm — beyond AI-Assisted, AI leads while humans retain final validation, decision-making, and oversight
Cater to Complex Systems
Target systems with high architectural complexity, multiple trade-offs, scalability and integration requirements. Simple systems better suited for Low-code/No-code
Retain Human Symbiosis
Maintain artifacts essential for human validation and risk management (User Story, Risk Register, etc.). Optimized for real-time use
Facilitate Transition
Maintain familiar terminology relationships for one-day practitioner adaptation. Leverage associative learning (Sprint→Bolt, etc.)
Streamline Responsibilities
AI performs task decomposition and decision-making, enabling developers to transcend specialization silos (frontend/backend/DevOps). Minimal roles principle
Minimize Stages, Maximize Flow
Minimize handoffs and transitions, implement continuous iterative flow. Human validation as Loss Function to catch waste early
No Hard-Wired Workflows
No prescribed workflows per development path (new/refactoring/bug fix). AI proposes context-appropriate Level 1 Plan
2.1 Deep Dive into Core 3 Principles
1. Reverse the Conversation Direction
Traditional Approach:
Developer: "Add API endpoint /users"
AI: "Done"
Developer: "No, it needs authentication"
AI: "Modified"
AIDLC Approach:
Developer: "I need user management functionality" (Intent)
AI: "Analysis shows 3 Units are needed:
1. User Authentication Service (OAuth2 + JWT)
2. User CRUD API (REST + GraphQL)
3. User Profile Storage (DynamoDB)
I propose Domain Design and Logical Design for each Unit..."
Developer: "Remove GraphQL, change to RDS"
AI: "Generating revised plan..."
AI proposes the entire architecture before generating code, and developers validate it by reflecting business context. This is collaboration at the design level, not the code level.
2. Integration of Design Techniques
In Scrum, DDD/BDD/TDD were "optional choices for teams." This guide selects and recommends them as default flavors to apply within AIDLC.
- DDD (Domain-Driven Design) — AI automatically models business logic into Aggregate, Entity, Value Object. Combined with Ontology Engineering to structure domain knowledge.
- BDD (Behavior-Driven Development) — AI generates Given-When-Then scenarios to clarify business behaviors.
- TDD (Test-Driven Development) — AI writes tests first, then generates minimal code to pass tests.
These are not mandated by AIDLC itself; they are the combination of design techniques this guide recommends for consistency in AI code generation.
3. Minimize Stages, Maximize Flow
Traditional SDLC handoffs (Planning → Design → Development → Testing → Deployment) cause knowledge loss and delays at each stage. AIDLC pursues Continuous Flow.
This guide uses Loss Function as an analogy for human review. At each checkpoint, the reviewer compares an AI-generated artifact with requirements and acceptance criteria, identifies errors, and requests corrections before downstream work uses it. The term here describes feedback on an artifact, not a model-training operation.
Intent validation (human) → Unit decomposition validation (human) → Design validation (human) → Code validation (human)
↓ ↓ ↓ ↓
Loss 1 Loss 2 Loss 3 Loss 4
Proceed when the artifact meets the checkpoint's acceptance criteria; otherwise, revise it and review it again. The workflow adapts the stages and review depth to the project context.
3. Intent → Unit → Bolt Execution Model
AIDLC redefines traditional SDLC terminology for the AI era.
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Intent │───▶│ Unit │───▶│ Bolt │
│High-level│ │Independent│ │Fast │
│ Purpose │ │Work Unit │ │Iteration│
│Business │ │(DDD Sub- │ │(Sprint │
│ Goals │ │ domain) │ │Replace) │
└─────────┘ └─────────┘ └─────────┘
│
┌─────┴─────┐
▼ ▼
┌──────────┐ ┌──────────┐
│ Domain │ │ Logical │
│ Design │ │ Design │
│Business │ │NFR+ │
│ Logic │ │Patterns │
└──────────┘ └──────────┘
│ │
└─────┬─────┘
▼
┌──────────────┐
│ Deployment │
│ Unit │
│Container+Helm│
│ +Terraform │
└──────────────┘
AIDLC Core Artifacts
Six Core Artifacts of AI-DLC Methodology and Their SDLC Mapping
Intent
High-level objective to achieve — business goals, features, technical outcomes. Starting point for AI decomposition
Unit
Cohesive independent work unit derived from Intent. Corresponds to DDD Subdomain, enabling parallel development through loose coupling
Bolt
Minimum iteration unit for rapid task implementation within Unit. Hour/day granularity (vs. Sprint's week/month)
Domain Design
Model business logic independently of infrastructure using DDD principles (Aggregate, Entity, Value Object, Domain Event)
Logical Design
Apply NFRs and architecture patterns (CQRS, Circuit Breaker) to Domain Design. Generate ADR (Architecture Decision Record)
Deployment Unit
Packaged executable code (container), configuration (Helm), infrastructure (Terraform/ACK CRD). Functional, security, and NFR testing completed
Artifact Flow
3.1 Intent (Purpose)
AI Redefinition of Epic/Feature
Traditional Epics were "bundles of big User Stories." In AIDLC, Intent is a high-level goal that specifies business purpose.
Example:
Traditional Epic: "Implement user authentication"
→ Vague, unclear scope, includes technical details
AIDLC Intent: "Customers can access the platform using social login
(Google, GitHub) to use a personalized dashboard"
→ Business value clear, AI proposes technical choices
Intent specifies WHAT (what) and WHY (why), delegating HOW (how) to AI.
3.2 Unit (Work Unit)
AI Redefinition of User Story
Traditional User Stories were manually written by humans using the "As a X, I want Y, so that Z" template. In AIDLC, a Unit is an independent work unit where AI automatically decomposes Intent into DDD Subdomains.
Intent → Unit Decomposition Example:
Intent: "Customers can access the platform using social login to use a personalized dashboard"
AI-generated Units:
1. Authentication Service (Core Subdomain)
- OAuth2 integration (Google, GitHub)
- JWT token issuance/verification
- Refresh Token management
2. User Profile Management (Core Subdomain)
- User profile CRUD
- Profile image upload (S3)
- Profile data storage (RDS)
3. Dashboard Service (Supporting Subdomain)
- Per-user widget configuration
- Dashboard layout storage
- Real-time data aggregation
4. IAM Integration (Generic Subdomain)
- AWS Cognito integration
- Permission management
- Audit logs
Each Unit includes:
- Domain Design — DDD Aggregate, Entity, Value Object
- Logical Design — NFR (non-functional requirements), architecture patterns, tech stack
- Deployment Unit — Container, Helm Chart, Terraform module
3.3 Bolt (Iteration)
AI Redefinition of Sprint
Traditional Sprints are fixed-length cycles of one month or less, and an increment is delivered at least once within the Sprint and may be delivered more often (source: Scrum Guide). In AIDLC, a Bolt is a short iteration at hour/day cadence matched to AI's fast execution speed.
Sprint vs Bolt Comparison:
Sprint (Traditional) Bolt (AIDLC)
━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━
Fixed-length cycle of one month or less Flexible hour/day cadence
Planning → Daily → Review AI proposes → Validate → Execute → Validate
Humans decompose tasks AI auto-decomposes tasks
Manual code writing AI code generation + human validation
Increment delivered within Sprint (when Done) Deploy immediately on completion (GitOps)
According to the Method Definition, a Bolt is the smallest iteration in AIDLC: a work cycle that implements a Unit or a set of tasks within a Unit (for example, some of the User Stories that belong to the Unit). A Unit is executed through one or more Bolts, which can run in parallel or sequentially. Operational artifacts such as container images, Helm Charts, and Terraform stacks belong to a separate artifact, the Deployment Unit, not to the Bolt, so there is no 1:1 correspondence rule between Bolts and infrastructure components.
All artifacts (Intent, Unit, Domain Design, Logical Design, Deployment Unit) are stored as Context Memory for AI to reference throughout the lifecycle. Bidirectional traceability between artifacts (Domain Model ↔ User Story ↔ Test Plan) holds when the artifacts are kept in sync with each other, letting AI work with more accurate context.
4. AI-Driven Recursive Workflow
The core of AIDLC is the recursive refinement process where AI proposes plans and humans validate.
Intent (Business Purpose)
│
▼
AI: Generate Level 1 Plan ◀──── Human: Validate · Modify
│
├─▶ Step 1 ──▶ AI: Level 2 Decomposition ◀── Human: Validate
│ ├─▶ Sub-task 1.1 ──▶ AI Execute ◀── Human: Validate
│ └─▶ Sub-task 1.2 ──▶ AI Execute ◀── Human: Validate
│
├─▶ Step 2 ──▶ AI: Level 2 Decomposition ◀── Human: Validate
│ └─▶ ...
└─▶ Step N ──▶ ...
[All Artifacts → Context Memory → Bidirectional Traceability]
4.1 Human Validation as Loss Function
In machine learning, a Loss Function measures the difference between model predictions and actual values to guide learning. Human validation in AIDLC is used as an analogy for a similar role (see the analogy note in §2.1). It denotes feedback on an artifact, not a mathematical computation of distance from a correct answer.
Loss Function Hierarchy:
┌─────────────────────────────────────────────┐
│ Intent Loss │
│ "Is the business purpose clear?" │
│ If Loss is large → Rewrite Intent │
└─────────────────────────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Unit Decomposition Loss │
│ "Is Unit decomposition appropriate? │
│ Any missing/duplicate items?" │
│ If Loss is large → Re-decompose Units │
└─────────────────────────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Design Loss │
│ "Does the DDD model accurately reflect │
│ the domain?" │
│ If Loss is large → Regenerate Design │
└─────────────────────────────────────────────┘
▼
┌─────────────────────────────────────────────┐
│ Code Loss │
│ "Does the generated code accurately │
│ implement the design?" │
│ If Loss is large → Regenerate code │
└─────────────────────────────────────────────┘
If Loss at each stage is small, proceed to the next stage; if Loss is large, re-execute that stage. This reduces downstream error propagation; the review contributes to higher quality but does not prove or guarantee the correctness of the result.
4.2 Adaptive Workflow
AI provides an adaptive workflow that executes only necessary stages based on context.
Workflow by Scenario:
New Feature Development:
Intent → Unit Decomposition → Domain Design → Logical Design → Code Generation → Testing
Bug Fix:
Intent → Existing Code Analysis → Fix Code Generation → Testing
Refactoring:
Intent → Existing Design Analysis → Improved Design → Code Regeneration → Testing
Technical Debt Resolution:
Intent → Identify Debt Areas → Refactoring Plan → Phased Execution
AI doesn't enforce fixed workflows by path, but provides a flexible approach that proposes Level 1 Plans appropriate to context.
5. AIDLC 3-Phase Overview
AIDLC consists of 3 phases: Inception, Construction, Operations.
5.0 Official AWS Labs 3 Phases and engineering-playbook Expansion Mapping
The official AWS Labs repository defines the three phases Inception → Construction → Operations, but Operations is currently a placeholder (only the base stage definition exists; the detailed workflow is to be published later). engineering-playbook fills this gap with its AgenticOps track.
| Official Phase | Official Definition Status (v0.1.7, 2026-04-02) | engineering-playbook Expansion | Key Documents |
|---|---|---|---|
| Inception | Workspace Detection · Reverse Engineering · Requirements Analysis · User Stories · Workflow Planning · Application Design · Units Generation (7 stages) | Intent definition + ontology construction + DDD Strategic Design | 10 Principles · Ontology Engineering · DDD Integration |
| Construction | Functional Design → NFR → Infrastructure → Code Generation → Build & Test (per Unit loop) | Bolt execution + harness engineering + Quality Gate | Harness Engineering · AI Coding Agents · EKS Declarative Automation |
| Operations | Placeholder (only stage definition exists) | AgenticOps track — AI agent-based autonomous operations, observability·prediction·automatic response, ontology Outer Loop feedback | AgenticOps · Observability Stack · Predictive Operations · Autonomous Response |
engineering-playbook interprets the reason the official AIDLC leaves the Operations phase as a placeholder to be that the operations area varies greatly by an organization's observability stack, regulatory environment, and SRE maturity (this is this document's interpretation, not a reason stated by the official repository). The AgenticOps track of engineering-playbook provides a reference implementation that assumes an AWS-based enterprise environment (EKS · CloudWatch · ADOT · Application Signals · MCP).
🔄 AIDLC 3-Phase Framework
Inception → Construction → Operations
Inception
Requirements Definition + Architecture Design
- requirements.md
- design.md
Construction
Code Generation + Testing + Review
- Source Code
- Tests
- IaC
Operations
Deployment + Monitoring + Optimization
- GitOps Deployment
- Observability
- Auto Remediation
🔨 AIDLC Phase Activities
Key activities, AI tools, and outputs for each phase (tool-to-activity mappings are illustrative, not a verified per-tool/version capability claim)
5.1 Inception (Initiation)
Goal: Clarify Intent and decompose into Units
AI Role:
- Analyze Intent and ask questions about unclear parts
- Decompose Intent into DDD Subdomains (Core/Supporting/Generic)
- Generate initial Domain Design for each Unit
Human Role:
- Validate Intent (business purpose clarity)
- Validate Unit decomposition (check for missing/duplicate items)
- Validate Domain Design (reflect domain knowledge)
Deliverables:
- Intent Document
- Unit List (DDD Subdomain)
- Domain Design (Aggregate, Entity, Value Object)
5.2 Construction (Build)
Goal: Implement Units as executable code and infrastructure
AI Role:
- Generate Logical Design (NFR, architecture patterns, tech stack)
- Generate code (TDD: tests first, implementation later)
- Code review (static analysis, security scanning)
- Generate Deployment Unit (Dockerfile, Helm Chart, Terraform)
Human Role:
- Validate Logical Design (NFR compliance)
- Validate code (business logic accuracy)
- Security validation (review sensitive logic)
Deliverables:
- Logical Design Document
- Source Code + Tests
- Deployment Unit (containers, IaC)
5.3 Operations (Operations)
Goal: Post-deployment monitoring, auto-recovery, continuous improvement
AI Role:
- GitOps automated deployment (ArgoCD)
- Real-time monitoring (log, metric, trace analysis)
- Anomaly detection and auto-recovery
- Transform feedback into Intent and pass to Inception
Human Role:
- Deployment approval (production environment)
- Incident response (validate AI suggestions)
- Provide business feedback
Deliverables:
- Observability dashboards (Grafana, CloudWatch)
- Incident reports
- Improvement Intent (next cycle)
6. Reliability Assurance: Ontology × Harness
To improve the reliability of AI-generated code, engineering-playbook introduces a reliability framework with two axes — Ontology and Harness Engineering — as an extension proposed on top of the official AIDLC. This is not a required part of the official AIDLC methodology but an extension this guide proposes, and it aims to improve reliability rather than guarantee it.
Role of the Two Axes:
-
Ontology — A "typed world model" that formalizes domain knowledge. It elevates DDD's Ubiquitous Language into structured schemas that AI can understand. Ontology is not a static schema but a living model that continuously evolves through self-feedback loops.
-
Harness Engineering — A structure that architecturally validates and enforces constraints defined by ontology. "Agents aren't hard, harnesses are" is a key lesson from 2026. Harness validation results promote ontology evolution.
Ontology and Harness do not operate independently. When ontology defines "what to validate," harness implements "how to validate." Harness validation results in turn drive ontology evolution, forming a system that aims to improve reliability incrementally.
7. Adoption Roadmap
AIDLC is adopted in phases to gradually increase organizational maturity.
The durations (2-4 weeks, 1-2 months, etc.) and success metrics (80%+, 30%+, etc.) in each phase below are example values to be tuned per organization, not measured results. Set the actual durations and targets according to team size, existing automation level, and domain constraints.
Phase 1: AI Coding Tool Adoption
└── Start code generation·review with Q Developer/Copilot
(Maturity Level 2)
Phase 2: Spec-Driven Development
└── Systematic requirements → code workflow with AI Agent
Pilot Mob Elaboration ritual
(Maturity Level 3)
Phase 3: Declarative Automation
└── Deployment automation with GitOps
AI/CD pipeline transition
(Maturity Level 3→4)
Phase 4: AI Agent Expansion
└── Autonomous operations with AI Agent
Spread Mob Construction ritual
(Maturity Level 4)
7.1 Phase 1: AI Coding Tool Adoption (2-4 weeks)
Goal: Developers become familiar with AI coding tools
Activities:
- Install Amazon Q Developer or GitHub Copilot
- Practice code auto-completion, function generation, test generation
- Establish AI-generated code validation process
Success Metrics:
- 80%+ of developers use AI coding tools daily
- 30%+ improvement in code writing speed
7.2 Phase 2: Spec-Driven Development (1-2 months)
Goal: Establish workflow where AI analyzes requirements and proposes designs
Activities:
- Practice Intent → Unit decomposition with AI Agent (Q Developer, open-source Agent)
- Introduce Mob Elaboration ritual (weekly, full team participation)
- Build Context Memory (project docs, architecture, codebase)
Success Metrics:
- 50%+ of new features start with AI-proposed designs
- 40%+ reduction in requirements analysis time
7.3 Phase 3: Declarative Automation (2-3 months)
Goal: Automate deployment with GitOps, AI generates infrastructure code
Activities:
- Build GitOps with ArgoCD or Flux
- AI auto-generates Helm Charts, Terraform modules
- AI/CD pipeline transition (CI/CD → AI/CD)
Success Metrics:
- 50%+ reduction in deployment lead time
- 70%+ of infrastructure code is AI-generated
7.4 Phase 4: AI Agent Expansion (3-6 months)
Goal: AI Agents perform operations autonomously
Activities:
- AI Agent for log/metric analysis, anomaly detection, auto-recovery
- Spread Mob Construction ritual (normalize)
- Build Ontology + Harness reliability framework
Success Metrics:
- 60%+ reduction in incident response time
- 40%+ of incidents auto-recovered by AI
8. Next Steps
Now that you understand AIDLC's core concepts and execution model, refer to the following documents:
- Ontology Engineering — Transform domain knowledge into structured schemas AI can understand
- Harness Engineering — Architecturally validate and enforce AI Agent behavior
- DDD Integration — Concrete methods for practicing DDD in AIDLC
References
AIDLC Source
- AWS AI-DLC Method Definition — AIDLC source (Raja SP, AWS)
- AWS AI-Driven Development Life Cycle Blog
- AWS Labs AIDLC Workflows (GitHub)
- Open-Sourcing Adaptive Workflows for AI-DLC — AWS, 2025-11
Design Techniques
- Domain-Driven Design Reference — Eric Evans
- Behavior-Driven Development — Dan North
- Test-Driven Development: By Example — Kent Beck