AI-DLC from AWS Labs: Gated Workflows for Claude Code, Codex, Cursor and Kiro

AWS Labs has published a toolkit that wraps a coding agent in a staged, gated workflow: you describe the work, the agent proposes a plan, and nothing moves forward until a human approves it. The repository is awslabs/aidlc-workflows, it is licensed MIT-0, and when we looked it had about 5.2k stars, 950 forks and more than 1,500 commits. It runs inside Claude Code, Kiro, Codex CLI, Cursor, opencode and GitHub Copilot rather than replacing them.

It is the evolution of an idea AWS announced in late 2025, when it open-sourced the first AI-DLC rules for Amazon Q Developer and Kiro. This post explains what the current repo contains, how to try it, how it compares with the steering files you may already use, and what to watch out for.

Quick reference

What problem is AI-DLC trying to solve?

The AWS announcement names three recurring failures of agentic coding tools. First, one-size-fits-all workflows: a simple bug fix does not need the same requirements analysis as a new service. Second, no flexible depth: lightweight work gets over-engineered because the tool applies the same ceremony. Third, over-automation that pushes humans out of review.

AWS's answer is what it calls adaptive workflows. In the blog's words, the process should be "context-aware, scalable, and self-correcting." The agent assesses the request, picks stages, decides how deep each stage should go, and stops at approval gates for a human to confirm. Every human action and approval is recorded.

If you have read our guide to steering Claude Code with CLAUDE.md, skills, hooks, subagents and rules, AI-DLC sits one layer above those surfaces. It uses them as the delivery mechanism and adds a lifecycle on top.

What is in the repository?

The README describes the layout as three parts:

• core/: a hand-authored, harness-neutral methodology and engine, including 93 aidlc-*.ts tools.
• harness/<name>/: thin manifests and integrations for each supported agent.
• plugins/: optional AIDLC plugins, which can add stages.

This split is the main change from the 2025 release, which was written as Amazon Q Rules and Kiro Steering Files. The new design keeps one deterministic engine and translates it per agent. The README says the "same deterministic engine" runs across every supported harness, and that the installer ships a native aidlc command so you do not need Bun or Node.js for a normal install.

The numbers on offer are large: 5 phases and 33 stages "from initialization through operation," 14 agents (11 domain experts, 2 reviewers and an adaptive composer), and 11 workflow profiles for features, bug fixes, infrastructure, security, proofs of concept and enterprise delivery. We have not run all of these, and the counts come from the README, so treat them as the project's own description.

How do you try it?

The README's quick start has three steps.

1. Install. On macOS, Linux or WSL, run the release install.sh with curl. On Windows, run the PowerShell installer from a normal, non-administrator window. The README warns that an elevated shell gets a warning because installing as administrator is less safe.
2. Configure the project. From the project root:

aidlc config --harness claude
aidlc doctor

Replace claude with kiro, kiro-ide, codex, cursor, opencode or copilot. Running aidlc config with no flag starts an interactive setup. aidlc doctor is the first thing to run when something fails.

3. Start a workflow. Open the agent in that project and describe the work:

/aidlc Build a REST API for inventory management

AI-DLC selects a workflow from the request, asks for missing decisions, and stops at approval gates. In Kiro IDE you first choose aidlc in the chat panel's agent picker. In Codex CLI the command is $aidlc.

Version requirements to check

The README gives minimum versions: Kiro IDE 1.1.70 or Kiro CLI 2.24.1 for the v3 engine, Codex CLI 0.145.0, opencode 1.17, GitHub Copilot CLI 1.0.74 or VS Code 1.130. If you are on older builds, upgrade first, because hooks are how the gates are enforced.

Two runners passing a baton, illustrating handoffs between agent stages and human approvals in AI-DLC workflows

What are workflow profiles?

Profiles are how AI-DLC avoids running every task through all 33 stages. The README names Classic and Express alongside focused workflows, and points to a Workflow Profiles guide for choosing between them. The idea matches the original blog's Principle 10, quoted there from the AI-DLC method paper: the method "avoids prescribing opinionated workflows for different development pathways," and the AI recommends a plan for the stated intent.

In practice, you would expect a typo fix to take a short path, while a new service takes requirements, design, construction and test stages with several approvals. We have not benchmarked how well the agent chooses the profile, and that choice is the part of the system most likely to vary by model.

How does this compare with what you already use?

The honest trade-off is overhead. A gated lifecycle slows the first run of any task, and approval gates mean someone has to be present. For solo prototyping, the Express profile or no workflow at all may be the right call. For teams that need an audit trail of who approved what, the 119-event log is the differentiator.

If you run several agents side by side, AgentPlane's local control plane is a different kind of tool, focused on managing sessions rather than methodology, and the two are not in conflict.

Why human gates matter now

There is a reason a gated workflow is arriving as agents get more capable. Research we covered on AI coding agents producing more code, not more software points at review as the bottleneck: output grows faster than anyone's ability to check it. AI-DLC's answer is to move review earlier, to plans and designs, rather than only at the diff. Whether that shifts the bottleneck or just relocates it is an open question, and the README itself warns that generative AI "can make mistakes" and that output and costs should be reviewed.

Risks and limits to know before you adopt it

• Install script trust. The documented install pipes a script from GitHub releases into a shell. That is common, but read it first, or use the manual-copy path from the release tarball. The project also has a security policy and gitleaks configuration in the repo, which is a good sign but not an audit.
• Hooks run commands. The README notes that in Kiro IDE, trusting a folder lets its .kiro hooks run commands on your machine. Only trust folders you wrote or reviewed, and the same care applies to any harness that loads project hooks. If you are running coding agents with real credentials, a runtime control such as AgentBeam, the agent security platform from the explainx.ai team, can block dangerous actions before they happen.
• Model dependence. The README says AI-DLC works best with capable reasoning models and currently recommends Claude Opus 4.8. Expect weaker routing and more drift on smaller models.
• Scale of the repo. With 93 engine tools and 7 adapters, there is a lot of surface area. Pin a version, as the install docs describe, rather than tracking latest in a team setting.
• No independent evaluation yet. We found no third-party benchmark showing that AI-DLC improves delivery speed or defect rates. The AWS claims are about process quality, and they are the vendor's own.

What developers are saying

The Hacker News submission for the repo had 5 points and no comments when we checked, so there is no community verdict to report yet. The README's troubleshooting table already flags the likely friction points, such as Windows PATH problems after install and Codex hooks that need the project to be trusted, and the repo's issue tracker is where early adopters will report more.

Who should try it?

Try it if you lead a team that already uses a coding agent and needs approvals and traceability, you work on brownfield code where requirements analysis matters, or you want a ready-made lifecycle instead of writing one from scratch in rules files.

Skip it for now if you work alone on small projects, you prefer minimal prompting, or you cannot accept a curl-installed tool in your environment. A pared-down alternative is to copy the idea, not the tool: write a short AGENTS.md that requires a plan and your approval before code changes, and see whether that is enough.

A one-hour test is reasonable: install it in a throwaway repository, run /aidlc on a small real task such as adding an endpoint, count how many approval gates appear, and compare time and review effort against your normal agent loop. That tells you more than any README can.

Bottom line

AI-DLC turns a methodology into something you can install: a single engine, seven agent adapters, staged work and an audit log. It is free and permissively licensed, backed by AWS Labs, and refreshingly explicit that humans stay in the loop. It is also young in this form, unproven by outside evaluation, and heavier than a rules file. Try it on a contained project before committing a team to it.

Details reflect the repository README and AWS blog as of October 15, 2026. Star counts, version requirements and stage counts change quickly; check the repo before relying on them.

Related reading

• Steering Claude Code: CLAUDE.md, skills, hooks, subagents and rules
• What are agent skills? The complete guide
• Loop engineering for coding agents with Claude Code
• Claude Code commands: the complete reference
• AgentPlane: a local control plane for Claude Code, Codex and Cursor
• AI coding agents: more code, not more software