TL;DR
- AI-DLC itself is solid. Approval gates, audit trails, and picking a profile all feel genuinely good.
- But when your planning input is thin, the ceremony turns poisonous. I kept redoing earlier stages as I went.
- A cheap model plus a heavy lifecycle just doesn't fit. That one's on me.
Reading the docs, I thought "this is it"
Quick summary of AI-DLC from the docs:
AI-DLC wraps AI coding tools in a structured delivery workflow. Harness-neutral core plus thin adapters. The numbers: 5 phases, 33 stages, 14 agents, 11 profiles, 102 audit events. The philosophy is
Small Mob, Broad Agents — a few generalists carrying context around instead of dozens of narrow specialists. I still like that line.Invoking it is easy.
/aidlc build me a REST API , done. (Codex uses $aidlc for some reason. No idea why.)aidlc doctor and the diagnostics export, the spectrum from an 8-stage PoC up to a 33-stage Enterprise run, MIT-0. On paper, nothing to complain about. So I put it straight into a real project. That was the foreshadowing.To try it yourself, the repo is here: awslabs/aidlc-workflows . Installation is a one-liner from the releases page.
Bash
curl -fsSL https://github.com/awslabs/aidlc-workflows/releases/latest/download/install.sh | sh
On Windows grab
install.ps1 instead, then attach a harness from your project root ( aidlc config --harness kiro , for example) and check with aidlc doctor . I used Kiro. This post is about what happened after that.
The field test: AIF exam study materials
The project: niceguy61/learn_aws_aif_c01 — Korean study materials for the AIF-C01. Built with Kiro, and the AI-DLC traces (like the
aidlc/ directory) are still in the repo. If you're curious, go look at the Contents (D1–D5) structure yourself.The setup
- Task: detailed, in-depth study materials for the AIF exam.
- Harness: Kiro. Model access is built in, so provider setup was skipped.
- Models: mostly 5.5 luna and terra to save tokens. Let me say this up front — using AI inside an ADE like Kiro is nothing to be embarrassed about. It's the obvious choice. Trying to optimize tokens is legitimate engineering. What follows isn't "I cheaped out on models," it's "I picked the wrong combination."
At first it really looked like professional work. Questions coming in, approvals at each stage, artifacts piling up. Oh, I thought, this might actually work.
What actually happened
- The further I got, the more I redid earlier work. I didn't know the AIF content that well, and building study materials out of it meant stuff I learned in later stages overturned earlier stages. Remake the content, redo the form. On repeat.
- Pre-implementation questions and sign-offs alone ate 2–3 days. Answering questions and confirming things became the job. The actual work hadn't even started.
- At one point I flipped the entire form. And every time, the workflow wasn't pushing me forward — it was holding me back. Honestly, it got in the way.
- luna/terra plus a heavy lifecycle was a bad match. Gates, reviews, all of it felt designed around an expensive-model assumption. The docs recommend Opus 4.8-class models. I understood that line with my body, not my head.
- Waiting became the job. Obviously a human has to decide at decision points, but while the program sits there stopped, you just keep waiting. Stop watching and you notice late, which slows everything down. Do something else meanwhile? You never know when it'll ask you something, so that's awkward too. The more gates, the more your attention is held hostage.
My take, in short
AI-DLC doesn't help every project. It gets much smoother when the coding side has solid planners, or when you can feed it near-perfect planning materials. It's a tool you can only use properly if you understand the service you're trying to build.
The principles baked into the repo are interesting
Look at the repo README now and you'll find the content principles: the 57 originals (
docs/Refs ) are never modified, moved, or deleted; unconfirmed facts get a needs verification mark instead of being stated flatly; no reproducing exam questions. That's exactly what AI-DLC tells you to do with code. Immutable sources, uncertainty labels, auditable changes. The workflow held me back, but the artifact discipline stuck. If AI-DLC left anything in my habits, it's that. The process was heavy, but at least I kept some discipline out of it.
Why it went that way (things I see now that I didn't then)
What happened is above; this part is what I think about it with some distance.
Methodology amplifies input quality. AI-DLC's gates and audit trail don't guarantee your decisions are right. They guarantee your decisions are recorded. Feed it shaky planning input and it just engraves shaky decisions deeper into more artifacts. Rework gets more expensive with every stage. Looking back, this was Discovery (figuring out what to make), not Delivery (making it). I draped a delivery ceremony over discovery work. Of course it chafed.
Learning-while-building plus heavy ceremony is the worst combo. Study materials mean every early answer is provisional. But Plan Approval bindings, the freeze on direct edits after review — those assume fast sign-offs. In a project full of provisionals, the machinery is just friction. The 2–3 day question bottleneck, the pain of flipping the form — all of it lives here.
I probably picked the wrong profile, too. A full lifecycle (Feature/Enterprise-class) was the wrong call; short PoC/Express iterations would have fit. "Just describe the work and get a recommendation" sounds nice, but judging the recommendation is still the user's job. Beginner guides shouldn't start with "how to turn it on." They should start with "what not to turn on."
Model tier and ceremony weight go together. Run 33 stages plus reviewers plus subagents on a lightweight model and you never collect on the expensive ceremony. Token saving with luna/terra wasn't the mistake — pairing cheap models with the full ceremony was. Pick one: expensive model plus full ceremony, or budget model plus a light profile (Express/PoC).
Gates hold your attention hostage. The hidden cost of human-in-the-loop isn't the minutes spent deciding. It's all the hours spent nearby because you might get called on. Work on something else while the program sits stopped and you notice late; stare at it and the whole block is dead time. With gates attached to 33 stages, the lock-in is tangible. No async escape hatch in the methodology — that's the corner you only see once you've lived in it.
Pros and cons (the version my body learned)
What was good
- The methodology itself is genuinely solid. Audit, gates, profiles,
doctor --export— not toys.
- With good input, it really does accelerate. I believe the ceremony turns into quality when planning is solid.
- The spectrum is real. 8-stage PoC through 33-stage Enterprise. You just have to pick — which is the trap.
What didn't fit
- Thin planning input turns ceremony poisonous. Shaky decisions get engraved into artifacts. Rework gets pricier per stage.
- Don't drape delivery ceremony over discovery work. Learning-while-building (like study materials for a domain you don't know) is fundamentally at odds with Plan Approval.
- The question-and-sign-off bottleneck is real. Mine cost 2–3 days. Leave it out of your schedule and the schedule breaks.
- There's a model assumption. Opus-class recommended. Budget luna/terra-class models plus the full ceremony don't pay off.
- Profile choice is on you. Run a PoC job as a Feature and it just balloons.
Notes for beginners (field-patched edition)
- Ask two questions before adopting. Can you feed near-perfect planning input? Do you understand the domain? If either is no, start with something light like PoC/Express, not the full machine.
- Is this discovery or delivery? Short loops for the former, the lifecycle for the latter.
- Set the model budget first. Expensive model plus full ceremony vs. budget model plus light profile. The middle (budget model plus full ceremony) is the worst. That's the mine I stepped on.
- Put question-and-sign-off time in the schedule. Mine took 2–3 days. Assume the form will flip, and stay in the cheap early stages where flipping is cheap.
- Start profiles small. Express → Bugfix → Feature. Never open with Feature/Enterprise.
- On Kiro, provider setup is skipped — instead, model and token choices hit quality directly. Keep that in mind.
- Don't blindly Approve at gates. What's recorded is a decision, not a correct answer.
- Never refresh with
aidlc configmid-workflow. Finish, then update → doctor → config. Trivial, but breaking it corrupts state.
- Count gate waiting time as schedule. AI-DLC calls a human at every decision point. Drift away while the program sits stopped and you notice late. If you're running a gate-heavy workflow, plan to sit next to it. Can't? Slice stages small so each attention block is short.
So who should use it
- Use it: coding projects with solid planning, teams that need audit and approvals, domains where you trust your input quality.
- Hold off: learning-while-building work, stages where planning is still provisional, budgets that force budget models, schedules with no room to answer questions.
- One line: AI-DLC is "how to run an organization that works with AI." Buy into it when the organization is ready — planning, domain understanding, model budget. For work like AIF materials where you learn as you build, light iterations come before heavy ceremony.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article