--- title: "AI-DLC: the only gates that count are the ones code enforces" description: "AI-DLC names two methods, one from AWS and one a Claude Code plugin. In both, the gates written as prose lost to the agent. What each does well, and how to enforce 'gates may only get tighter' in CI." date: 2026-10-24 canonical: https://pabloalbaladejo.com/blog/ai-dlc-gates-only-count-when-code-enforces-them --- # AI-DLC: the only gates that count are the ones code enforces AI-DLC is a name for a development life cycle in which an AI agent does most of the work. Gates decide when it may move on. It matters because two very different projects use the name. Both teach the same lesson in their own files: a gate written in prose loses to the agent. Below I compare the two and show where each one's prose gates failed. I also say what each does well, and how I enforce the one idea worth taking from them. ## One name, two methods **The AWS method.** Raja SP described it on the [AWS DevOps Blog](https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/) in July 2025. The core loop is in one sentence: the AI "creates a plan, asks clarifying questions to seek context, and implements solutions only after receiving human validation". The implementation is [awslabs/aidlc-workflows](https://github.com/awslabs/aidlc-workflows). At the commit I read, its README lists [5 phases, 33 stages and 14 agents](https://github.com/awslabs/aidlc-workflows/blob/bf4628d999868c7d3635142db01f8e15d41b9deb/README.md#L119-L120). It is a large engine now, not a set of rules. **The Bushido method.** [thebushidocollective/ai-dlc](https://github.com/thebushidocollective/ai-dlc) is a Claude Code plugin with a [paper at ai-dlc.dev](https://ai-dlc.dev/paper). Its idea is different. The agent should run on its own, held back by "quality gates that block, not checklists to check". The gates are shell commands in the frontmatter of an `intent.md` file, and a hook runs them every time the agent tries to stop. The two share words, but not their meaning. In the AWS post, a Bolt replaces the sprint: a work cycle "measured in hours or days". In the Bushido README, a Bolt is ["a single iteration/session bounded by `/clear` cycles"](https://github.com/thebushidocollective/ai-dlc/blob/ac19ff6cb783c19ee7169295d7475cb471ad8146/README.md#L47). If you read a post about "AI-DLC", check which one it means first. ## AWS learned in public that a prose gate is a suggestion The first AWS releases put the gates in prose: rules files that told the agent to wait for the user. Agents did not always wait. **Issue #366 shows the hole.** The `approve` command existed, but it checked nothing. The stage files told the agent to produce output, and no code made it. [Issue #366](https://github.com/awslabs/aidlc-workflows/issues/366) reports that "an agent can call `gate-start ` followed immediately by `approve ` for every stage", without producing any code or documents. Its conclusion: "The state machine transitions are purely ceremonial." **Issue #55 shows a smaller version.** In [issue #55](https://github.com/awslabs/aidlc-workflows/issues/55), the reporter saw agents "fabricate timestamps entirely" in the audit log. The v2 answer was to move the gate out of the prompt and into a hook. The header of [`aidlc-plan-approval-guard.ts`](https://github.com/awslabs/aidlc-workflows/blob/bf4628d999868c7d3635142db01f8e15d41b9deb/core/hooks/aidlc-plan-approval-guard.ts#L4-L14) says why, and I find it the most honest file in the repository: > A field report showed prose losing that contest: a conductor generated the code first and backfilled the plan beside code-summary.md, making the plan an output instead of the input. The hook now refuses to dispatch the developer agent, or to write project files, until the approval evidence is current. A second hook records each real human message, so that "a gate that is put to you needs a real message from you to approve it" ([phases and stages guide](https://github.com/awslabs/aidlc-workflows/blob/bf4628d999868c7d3635142db01f8e15d41b9deb/docs/guide/04-phases-and-stages.md#L89)). The project is also honest about the limit of this. Approval receipts are files in the repository, and the [commit provenance reference](https://github.com/awslabs/aidlc-workflows/blob/bf4628d999868c7d3635142db01f8e15d41b9deb/docs/reference/20-commit-provenance.md#L18) says so: "anyone who can write to the repository can write a receipt". A hook proves that steps happened in order. It does not prove who did them. ## Bushido's ratchet is the same lesson from the other side The Bushido paper makes two strong claims about its gates. The first: "The agent cannot stop [...] until all gates pass" ([paper, line 281](https://github.com/thebushidocollective/ai-dlc/blob/ac19ff6cb783c19ee7169295d7475cb471ad8146/website/content/papers/ai-dlc-2026.md#L281)). The second is the **ratchet**: "During construction, gates are add-only", so "quality standards can only move forward" ([line 302](https://github.com/thebushidocollective/ai-dlc/blob/ac19ff6cb783c19ee7169295d7475cb471ad8146/website/content/papers/ai-dlc-2026.md#L302)). The hook, [`quality-gate.sh`](https://github.com/thebushidocollective/ai-dlc/blob/ac19ff6cb783c19ee7169295d7475cb471ad8146/plugin/hooks/quality-gate.sh#L21-L32), is real code with real exit codes. But the code does less than the paper says, and its own comments admit it: - **The second stop skips every gate.** When a Stop hook blocks, Claude Code retries with `stop_hook_active` set. The hook exits early on that retry. The comment says it directly: "ALL quality gates are bypassed on the second stop attempt." The authors explain why. Without it, nested subagents would loop forever. - **The ratchet is not in the hook.** The hook reads the current `intent.md` on every stop. It keeps no copy of the original gates and compares against nothing. As I read it, an agent that deletes a failing gate from the file and then stops will pass. - **The check lives in a prompt.** Removal is caught by the reviewer hat. [Step 7](https://github.com/thebushidocollective/ai-dlc/blob/ac19ff6cb783c19ee7169295d7475cb471ad8146/plugin/hats/reviewer.md#L122-L129) tells the reviewer to `git show` the old `intent.md` and flag any removed gate. That is a good instruction. It is still an instruction to a model. Again, the authors wrote this down themselves. A design note in the repository says: ["The ratchet effect is a convention enforced by process, not by the hook."](https://github.com/thebushidocollective/ai-dlc/blob/ac19ff6cb783c19ee7169295d7475cb471ad8146/.ai-dlc/harness-enforced-quality-gates/unit-02-elaborate-integration.md#L134) So the ratchet, one of the paper's two strong claims about gates, is the one the hook does not enforce. ## What each project gets right Each one gets something important right. **AWS has the right layering, and says it in one line.** The same hook header states the rule: "determinism belongs in tools and hooks, knowledge in agents, judgement with humans". That is the best short summary of agent harness design I have seen in a repository. The project also fixed its gates in public, in issues anyone can read. **A practitioner liked the gates too.** Seonwoo Kim ran the AWS workflows on a real project and [wrote it up](https://builder.aws.com/content/3Jf8J3oSE6d92kkduSWNrmcAmAg/i-ran-aws-ai-dlc-workflows-on-a-real-project): "AI-DLC itself is solid. Approval gates, audit trails, and picking a profile all feel genuinely good." **Bushido puts the gates next to the spec, as data.** The gates are commands in frontmatter, and a hook runs them, not the model. Intent gates and unit gates are merged in code, so a unit can add gates but not replace them. And "gates may only get tighter" is the right rule. It just needs a different place to live. ## What nobody has measured Neither project publishes an outcome eval. I looked, and I found nothing that measures whether the method gives better software than working without it. The AWS numbers that exist are written or relayed by AWS. The critics are small samples, but they are specific: - **Ceremony cost.** In the same Builder Center post: "Pre-implementation questions and sign-offs alone ate 2–3 days." And the line I find most useful: the gates "don't guarantee your decisions are *right*. They guarantee your decisions are *recorded*." - **Context cost.** [Issue #105](https://github.com/awslabs/aidlc-workflows/issues/105), an RFC in the AWS repository, counted about 12,000 tokens loaded at the start of every v1 workflow. It proposed cutting that to about 3,000. - **No evals.** In the [Hacker News thread](https://news.ycombinator.com/item?id=50100387), a reader asked whether there are evaluations of whether it works. Another answered: "The answer to that is no." One commenter who had trialled it wrote: "My assessment has been just use the native harness." Another wrote that their organization runs something similar, and that its evals showed "speed and token use improved when it was removed". The same commenter still sees value in consistency. These are comments, not studies, and none of these evals is published. ## Borrow the rule, and enforce it against the base branch I do not take the method. I take the rule "gates may only get tighter", and I put it where an agent cannot reach it. The Bushido hole shows the design question. **Where does the baseline come from?** If the check reads the gate list from the file the change can edit, the change can delete the gate and the check will agree. The baseline has to come from somewhere the change cannot rewrite. In a pull request, that place already exists: the base branch. [Kaiord pull request #1520](https://github.com/pablo-albaladejo/kaiord/pull/1520) applies this to coverage floors, and it is merged. Kaiord's coverage floors were plain numbers in config files, and lowering one was a one-line diff that every gate accepted. The new script, `scripts/check-coverage-floors-ratchet.mjs`, reads each floor at the merge base with `origin/main` using `git show`. It fails when a floor is lowered or removed. Raising one, or adding one, passes. When it fails, the message is the rule itself: "A coverage floor may rise, never fall." The PR lists one limit, and I add a second: - **It reads literals.** It cannot see a coverage step that someone disabled in the workflow file. - **The guard is code in the same repository.** A change can edit the guard too. AWS's provenance note makes the same point about receipts. What the guard changes is visibility: weakening a gate now means editing a guard, in a diff a reviewer will see. It stops being a quiet one-line change to a number. Kaiord already had code gates of this kind on `main`. For example, [`check-no-unconditional-skip.mjs`](https://github.com/pablo-albaladejo/kaiord/blob/c4ba5c570815a8f0cad0ffd73c83513bdf564851/scripts/check-no-unconditional-skip.mjs#L1-L10) rejects a test that is skipped with no condition. The coverage ratchet follows the same pattern: a rule an agent could ignore becomes a failing check. ## A checklist you can copy - For every gate in your agent workflow, ask one question: is this a command with an exit code, or a sentence in a prompt? Count only the first kind. - Read your hooks for early exits. A retry guard or a missing dependency can turn a blocking gate into a silent pass. - Compare gates with the base branch, in CI, not with the file in the change. - Fail closed when the baseline cannot be found. A shallow clone must be an error, not a pass. - Let a gate rise freely. Make lowering it a visible, reviewed change. - Keep timestamps, approvals and audit rows out of model output. Have a hook or a tool write them. - Do not adopt a method because it has a name. Borrow the mechanisms that its own issues show working, and measure them on your own repository. Both AI-DLC projects teach the same thing, one by fixing it and one by admitting it. A gate is only as strong as the code that runs it. ## Related writing - [A gate is only as real as its run](https://pabloalbaladejo.com/blog/a-gate-is-only-as-real-as-its-run) — the check before this one: proof that a gate executed and could block, with three Kaiord gates that did not, and a fourth found in review. - [Shipping production software with AI agents](https://pabloalbaladejo.com/blog/shipping-production-software-with-ai-agents) — the system around the agents in which this ratchet is one more mechanical guard. - [A 90% pass rate is not a gate](https://pabloalbaladejo.com/blog/a-pass-rate-is-not-a-gate) — the other half of a real gate: a threshold that says what breaks when you miss it. - [Evaluating LLM outputs in production](https://pabloalbaladejo.com/blog/evaluating-llm-outputs-in-production) — a gate with an exit code in practice, and why it is a gate and not a report. ## FAQ ### What is AI-DLC? AI-DLC (AI-Driven Development Life Cycle) is the name of two different methods. The first is from AWS: Raja SP described it on the AWS DevOps Blog in July 2025, and its implementation is the awslabs/aidlc-workflows repository. The AI writes a plan, asks questions, and only builds after a human approves. The second is a Claude Code plugin from The Bushido Collective that lets the agent run on its own behind quality gates. They share words such as Intent, Unit and Bolt, but those words do not mean the same thing in each. ### Did AI-DLC's prose approval gates work? Not reliably, and both projects show it in their own files. In the AWS repository, issue #366 reports that an agent could start and approve every stage without producing any output. The state machine was 'purely ceremonial'. The v2 plan-approval hook says in its header that 'prose' lost: the agent wrote the code first and the plan after. In the Bushido plugin, the rule that gates may only be added is a reviewer prompt, not a check in the hook. ### Is there evidence that AI-DLC improves outcomes? I found no published outcome eval for either method. The AWS numbers come from AWS itself. A practitioner on AWS Builder Center reported that questions and sign-offs took two to three days before any work began. In the Hacker News thread on the repository, one commenter answered the question about evaluations with 'The answer to that is no'. That is a commenter, not a maintainer. ### How do you enforce that quality gates only get tighter? Compare the gates in the change with the gates on the base branch, in CI, and fail when one is lowered or removed. The baseline must come from a place the change cannot edit, such as the merge base with main. A gate list read from the same file the change can edit is not a ratchet, because the change can delete the gate. Kaiord pull request #1520, now merged, does this for coverage floors. ## Sources - [AWS aidlc-workflows v2, plan-approval hook header: 'A field report showed prose losing that contest'](https://github.com/awslabs/aidlc-workflows/blob/bf4628d999868c7d3635142db01f8e15d41b9deb/core/hooks/aidlc-plan-approval-guard.ts#L4-L14) - [AWS aidlc-workflows issue #366: an agent can approve every stage with no output; 'purely ceremonial'](https://github.com/awslabs/aidlc-workflows/issues/366) - [Bushido AI-DLC quality-gate.sh: the Stop hook, and the comment that all gates are skipped on the second stop](https://github.com/thebushidocollective/ai-dlc/blob/ac19ff6cb783c19ee7169295d7475cb471ad8146/plugin/hooks/quality-gate.sh#L21-L32) - [Bushido AI-DLC reviewer hat, step 7: the ratchet check is an instruction to a reviewer](https://github.com/thebushidocollective/ai-dlc/blob/ac19ff6cb783c19ee7169295d7475cb471ad8146/plugin/hats/reviewer.md#L122-L129) - [Seonwoo Kim, 'I Ran AWS AI-DLC Workflows on a Real Project', AWS Builder Center, 22 Sep 2026](https://builder.aws.com/content/3Jf8J3oSE6d92kkduSWNrmcAmAg/i-ran-aws-ai-dlc-workflows-on-a-real-project) - [Kaiord pull request #1520 (merged): coverage floors checked against the merge base with main](https://github.com/pablo-albaladejo/kaiord/pull/1520)