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 102-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, including 73 `aidlc-*.ts` tools under `core/tools/`. `harness/<name>/` holds thin, harness-specific manifests and integrations. Packaging generates per-harness distributions, and the README is explicit that you edit `core/` or `harness/<name>/` and never the generated `dist*` output.

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 Claude Code and the shipped Codex configuration default to Amazon Bedrock, GitHub Copilot uses GitHub sign-in or BYOK, Cursor and opencode use their configured provider, and Kiro CLI and Kiro IDE need none 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. `aidlc doctor` is the README's first troubleshooting step, so run it before anything else and expect it to name the problem rather than fix it.

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, and nothing in the README suggests the engine will talk you out of it.

Harness floors are another constraint. The table in the README states Kiro CLI >= 2.6, Codex CLI >= 0.145.0, opencode >= 1.17, 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, and the README does not describe what happens if you configure against a version below the floor.

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 102-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, the approach the search questions associate with AI-DLC, 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, sensors, rules, 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. Classic runs the full staged lifecycle; Express trades stages for speed. 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 README badge and `package.json` both 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-09-20. Releases are frequent and include dated preview builds alongside stable ones: v2.9.0 on 2026-09-15, a preview tagged 20260915.1 the same day, and another preview on 2026-09-14. The preview cadence means there is usually a newer artifact than the one you pinned.

The upgrade surface is documented rather than implied. The Install and Lifecycle guide covers updating, pinning, installing offline, using mirrors and uninstalling. Pinning matters here because the installer pulls `releases/latest` by default, so an unpinned install on a preview-heavy project will move under you. If you develop against the engine rather than just use it, the check path is `bun scripts/package.ts --check`, which the README calls a determinism guard, plus `bun tests/run-tests.ts --ci` for smoke, unit and integration coverage.

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.17, 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