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 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. At the commit I read, its README lists 5 phases, 33 stages and 14 agents. It is a large engine now, not a set of rules.

The Bushido method. thebushidocollective/ai-dlc is a Claude Code plugin with a paper at ai-dlc.dev. 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”. 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 reports that “an agent can call gate-start <slug> followed immediately by approve <slug> 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, 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 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).

The project is also honest about the limit of this. Approval receipts are files in the repository, and the commit provenance reference 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). The second is the ratchet: “During construction, gates are add-only”, so “quality standards can only move forward” (line 302).

The hook, quality-gate.sh, 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 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.” 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: “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, 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, 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 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 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 — 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 — the system around the agents in which this ratchet is one more mechanical guard.
• A 90% 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 — a gate with an exit code in practice, and why it is a gate and not a report.