AWS Labs released AI-DLC (AI-Driven Development Life Cycle) as an open-source workflow orchestration system for coding agents. Instead of embedding instructions in prompts, it uses file-based steering rules that load conditionally across a three-phase workflow. The system supports six platforms (Kiro, Amazon Q, Cursor, Cline, Claude Code, GitHub Copilot) and has accumulated 2,665 stars in its first weeks.
The core insight: production coding agents need structured checkpoints and context management that survives across sessions. AI-DLC solves this with a folder architecture that separates core rules from detailed instructions, plus a generated reference folder that persists agent state.
The File-Based Steering Model
AI-DLC splits rules into two directories:
aws-aidlc-rules/: Core workflow logic, always loadedaws-aidlc-rule-details/: Detailed instructions, loaded on demand
This separation addresses context window limits. The agent starts with lightweight rules that define the workflow structure. When it enters a specific phase (planning, building, verifying), it loads only the detailed rules for that phase.
Why this matters: Monolithic prompt files force agents to process irrelevant instructions throughout execution. Conditional loading keeps the active context focused. If the agent is planning architecture, it does not need verification rules in memory.
The system also generates an aidlc-docs/ folder at project initialization. This folder holds:
- Project context summaries
- Architecture decisions
- Phase completion artifacts
Agents reference this folder across sessions. If you stop work mid-build and resume tomorrow, the agent reads aidlc-docs/ to recover state without re-analyzing the entire codebase.
Three-Phase Workflow Structure
AI-DLC enforces a linear progression:
- Plan: Agent analyzes requirements, proposes architecture, generates design docs
- Build: Agent implements code based on approved plan
- Verify: Agent runs tests, checks quality gates, validates against plan
Each phase ends with a human checkpoint. The agent cannot proceed to Build until you approve the Plan. It cannot mark work complete until Verify passes.
Quality Gates Between Phases
The workflow includes explicit transition rules:
| Phase Transition | Required Artifacts | Failure Mode |
|---|---|---|
| Plan → Build | Approved design doc in aidlc-docs/, architecture diagram | Agent proceeds with unclear requirements, generates misaligned code |
| Build → Verify | Implementation complete, unit tests written | Incomplete features slip through, technical debt accumulates |
| Verify → Complete | All tests pass, security scan clean, documentation updated | Broken code reaches production, missing docs block adoption |
These gates prevent cascading failures. If the agent skips planning and jumps to code, you catch it at the first checkpoint. If tests fail during Verify, the agent loops back to Build with specific failure context.
Kiro Steering Files and Workspace Configuration
For platforms that support it (notably Kiro), AI-DLC uses steering files to configure agent behavior at the workspace level. A steering file is a YAML or Markdown document that defines:
- Available tools and their usage policies
- File access boundaries
- Approval requirements for destructive actions
- Custom workflow extensions
Example steering file structure:
# .kiro/steering.yml
workflow: ai-dlc
phases:
plan:
rules: aws-aidlc-rules/plan-core.md
details: aws-aidlc-rule-details/plan-detailed.md
checkpoint: human-approval
build:
rules: aws-aidlc-rules/build-core.md
details: aws-aidlc-rule-details/build-detailed.md
tools:
- file-write
- terminal-execute
checkpoint: test-pass
verify:
rules: aws-aidlc-rules/verify-core.md
details: aws-aidlc-rule-details/verify-detailed.md
tools:
- test-runner
- security-scanner
checkpoint: human-reviewThis configuration lives in version control. When a new developer clones the repo and starts their agent, it automatically adopts the team’s workflow rules.
Context Management Across Sessions
The aidlc-docs/ folder acts as a persistent memory layer. After the Plan phase, the agent writes:
aidlc-docs/architecture.md: High-level design decisionsaidlc-docs/implementation-plan.md: Step-by-step build tasksaidlc-docs/context.md: Project background and constraints
During Build, the agent references these files instead of re-inferring intent from code. If you ask it to add a feature, it checks architecture.md to ensure the new code aligns with existing patterns.
During Verify, the agent compares implementation against implementation-plan.md. It flags deviations: “Step 3 called for retry logic, but I don’t see exponential backoff in the current code.”
This approach reduces hallucination. The agent has a written record of what it planned, so it cannot later claim it “intended” something different.
Multi-Platform Support Strategy
AI-DLC works across six platforms because it avoids platform-specific APIs. The rules are plain Markdown files. The agent reads them as instructions, not executable code.
Platform-specific setup varies:
- Kiro: Uses native steering file support
- Amazon Q: Loads rules via workspace configuration
- Cursor: References rules in
.cursorrulesfile - Cline: Includes rules in system prompt
- Claude Code: Loads rules as project context
- GitHub Copilot: References rules in
.github/copilot-instructions.md
The core workflow logic stays identical. Only the loading mechanism changes.
Failure Modes and Observability Gaps
AI-DLC improves on ad-hoc prompting, but it introduces new failure modes:
Rule drift: If developers edit aws-aidlc-rules/ locally without syncing changes, teams end up with inconsistent workflows. The system does not include a rule validation tool.
Checkpoint bypass: Nothing prevents an agent from ignoring checkpoints if the platform does not enforce them. Kiro has built-in approval gates, but Cursor and Cline rely on the agent’s instruction-following ability.
Context bloat: The aidlc-docs/ folder grows over time. After 50 features, the agent may struggle to parse a 10,000-line architecture.md. The system does not include context pruning or summarization.
Observability: You cannot see which rules the agent loaded or when it transitioned phases unless you manually inspect logs. There is no trace export or workflow visualization.
Technical Verdict
Adopt AI-DLC if your team uses multiple agent platforms and needs consistent checkpoints across developers. The file-based steering model solves the prompt engineering problem: instead of maintaining fragile instruction chains, you version-control workflow rules that load conditionally. The three-phase structure with human gates prevents the most common autonomous coding failures (skipped tests, misaligned implementations, missing docs). This works best for teams building internal coding agents or standardizing workflows across projects where context persistence matters (multi-week builds, complex domains).
Skip it if you require real-time observability, sub-second latency, or audit logs for compliance tracking. The conditional rule loading is clever for context management but adds overhead. More critically, you cannot trace agent decisions back to specific rules or visualize workflow state. Platforms without native approval gates (Cursor, Cline) rely on instruction-following, which means checkpoint bypasses are possible. If your workflow is exploratory rather than linear, the three-phase structure will feel restrictive.
For teams deploying this in production, add logging and file access boundaries. The lack of platform lock-in means you can experiment with different agents without rewriting rules, but you will need to build your own observability layer to understand what the agent is doing and why.