AI-DLC Workflows: steering rules that turn coding agents into a staged delivery process

The problem AI-DLC Workflows addresses in an agent session

A coding agent starts each conversation with whatever context fits in the window. On a small change that is fine. On a project that runs for months, the requirements that were agreed in March, the reason a particular table was denormalized, and the test that was written to prove it are all gone by June. The README frames this directly: ad-hoc AI coding loses context as projects grow.

AI-DLC is aimed at teams that already use agents and want the artifacts to survive the session. The README describes five phases and 33 stages running from initialization through operation, 14 agents split into 11 domain experts, 2 reviewers and an adaptive composer, and 11 workflow profiles covering features, bug fixes, infrastructure, security, proofs of concept and enterprise delivery. A 131-event audit trail persists alongside state, team knowledge and learned rules.

The audience is narrower than "anyone using an AI assistant". If your work is a one-file script, the structure is overhead. If your work has a reviewer, a compliance question, or a second engineer who needs to pick it up, the artifacts are the point.

One core, many harnesses: how the steering rules reach your agent

The repository is organized around a split between methodology and runtime. `core/` holds the hand-authored, harness-neutral methodology and engine. `harness/<name>/` holds thin, harness-specific manifests and integrations. Packaging generates per-harness distributions, and package.json describes the generated distributions as living under `dist/<harness>/`.

That layout explains the claim in the title of the README, "one core, many harnesses". The deterministic engine is the same across every supported harness; only the manifest that wires it into a given agent differs. The practical consequence is that a workflow definition is not rewritten per editor, and the harness-specific part stays small enough to audit.

The invocation differs by harness in exactly one visible way. Most harnesses take `/aidlc` as the entry command. Codex CLI takes `$aidlc` instead. Model-provider setup is deliberately left to the harness: the README states that shipped project configuration keeps the provider and model already selected by the user, that `aidlc config providers` can apply Amazon Bedrock settings on supported project surfaces or record manual setup for other harnesses, and that Kiro CLI and Kiro IDE need no provider answer because model access comes with Kiro.

Installing AI-DLC and running a first workflow

The installer is a single shell command on macOS, Linux or WSL. The README states it adds the native `aidlc` command and every harness runtime, and that Bun and Node.js are not required.

curl -fsSL https://github.com/awslabs/aidlc-workflows/releases/latest/download/install.sh | sh

On Windows PowerShell the equivalent is `irm https://github.com/awslabs/aidlc-workflows/releases/latest/download/install.ps1 | iex`. If the shell cannot find `aidlc` afterwards, the README points to the PATH instruction printed by the installer, or to starting a new shell.

There is a second path for machines where a native executable cannot be installed. Install Bun, download `aidlc-copy-runtime-X.Y.Z.tar.gz` from the latest release, and copy the complete `runtime/<harness>/` directory into your project. That route does not use the `aidlc` command at all.

Configuration happens from the project root. Pick the harness you actually use:

cd /path/to/your-project
aidlc config --harness claude
aidlc doctor

Replace `claude` with `kiro`, `kiro-ide`, `codex`, `cursor`, `opencode` or `copilot`. Running `aidlc config` without `--harness` starts the interactive setup when a terminal is available.

With the project configured, open the harness and describe the work in plain language:

/aidlc Build a REST API for inventory management

Codex CLI uses `$aidlc` instead. According to the README, AI-DLC selects a workflow from the request, asks for any missing decisions, and stops at approval gates before moving forward. The first run is therefore a conversation, not a code dump: expect questions before files.

Where AI-DLC gets in the way

The approval gates are the feature and the cost. A workflow that stops for human sign-off before proceeding is the right shape for a change that touches production infrastructure and the wrong shape for a rename. The README's own profile list acknowledges this by separating Express from Classic and from the focused workflows, and it points readers at the Workflow Profiles guide to compare them. Choosing the heavy profile for light work is a real failure mode.

Harness floors are another constraint. The table in the README states Kiro IDE >= 1.1.70 or Kiro CLI >= 2.24.1 for v3, Kiro CLI (V2) >= 2.6, Codex CLI >= 0.145.0, opencode >= 1.18.29, and GitHub Copilot CLI >= 1.0.74 or VS Code >= 1.130. An older CLI is not a degraded experience, it is an unsupported one.

The README also carries a warning worth taking literally: generative AI can make mistakes, and generated output and costs should be reviewed before acting on them. A 131-event audit trail records what happened. It does not make the output correct, and it does not cap what the harness charges you for the reasoning behind it.

How AI-DLC compares to plain spec-driven development

Spec-driven development typically means writing a specification first and letting the agent implement against it. That is a document and a convention. AI-DLC is a runtime: the specification is one artifact inside a staged process that also carries agents, learned rules, team knowledge and approval gates, and the process is enforced by the same engine in every harness.

The closest comparison inside the project's own documentation is the difference between the Classic and Express profiles. That is a real difference in approach rather than a rebrand, and it is the decision a new user actually faces.

Against a bare agent session, the difference is persistence. A Claude Code conversation ends and its reasoning ends with it. AI-DLC writes state, team knowledge and learned rules that the next session reads. If you never need that continuity, a plain agent session is simpler and the extra machinery buys you nothing.

License, maintenance and the cost of staying current

The project is MIT-0, which is the most permissive of the common MIT variants: it drops the attribution requirement. The repository metadata, the LICENSE file and `package.json` all state it. For a team embedding the runtime in a product, that removes the notice-file question, though nothing here is legal advice and your own review still applies.

The repository is not archived, and the last push was on 2026-11-02. Releases are frequent, and the most recent are dated preview builds: v2.11.3-preview.20261102.1 on 2026-11-03, v2.11.3-preview.20261030.1 on 2026-10-31 and v2.11.3-preview.20261029.1 on 2026-10-30. The preview cadence means there is usually a newer artifact than the one you pinned.

The upgrade surface is documented rather than implied. The README links an Install and Lifecycle guide (docs/guide/18-install-and-lifecycle.md) for install options such as `-NoModifyPath` on Windows. Pinning matters here because the installer pulls `releases/latest`, which the README says installs the latest stable release, so an unpinned install moves with each stable release. If you develop against the engine rather than just use it, the check path is `bun run check`, which package.json defines as `bun scripts/package.ts && bun scripts/package.ts --check && bun run typecheck && bun run lint`.

Editorial conclusion

Adopt AI-DLC when the work needs a written trail: regulated features, infrastructure changes, security work, or any project where a reviewer must see why a decision was made. Skip it for one-file scripts and throwaway spikes, where the approval gates cost more than the change. Verify first that your harness meets the stated floor (Codex CLI >= 0.145.0, opencode >= 1.18.29, Copilot CLI >= 1.0.74, Kiro CLI >= 2.6), that `aidlc doctor` reports clean from your project root, and that your team accepts stopping at gates before code lands.

Frequently asked questions

Official sources

1. awslabs/aidlc-workflows on GitHub
2. License: MIT-0
3. Project website
4. README
5. Releases