Don't Adopt AI-DLC. Steal From It.

The most mature framework for building with agents was designed for someone else. Take what fits your problem. Leave the doctrine on the shelf.

AI-DLC is the best public answer I know to the question every engineering leader is asking right now: how do we build software with AI agents without losing control of what we ship. AWS published the method in 2025. In September 2026 it shipped AI-DLC 2, an engine that installs a 33-stage lifecycle into the coding agent your team already uses.

I would still not tell a team to adopt it.

I have spent the last months inside a large engineering organization where AI-DLC went from a few pilot squads to a training program for the people who will spread it to every team. The method worked where people treated it as material to build with. It struggled where people treated it as a doctrine to comply with. The difference was never the tool. It was the posture.

Adopting a name means adopting someone else’s problems

Picture the meeting. A leader who has read the whitepaper announces that from next quarter the organization does AI-DLC. It sounds decisive. Here is what happens next.

People go and study. They read the paper, watch the conference talks, open the repository, and try to reproduce what they find there. The method describes a 33-stage lifecycle, mob rituals, 14 agents, and a new vocabulary: Intents (what the work must achieve), Units (pieces of the solution that can be built on their own), and Bolts (delivery slices measured in hours). So that is what they try to install. Within a few weeks the team is running ceremonies sized for a problem it does not have, and skipping the one problem it does have, because the paper did not mention it.

AWS and your company are different animals. The method was shaped by a vendor that sells cloud infrastructure to large, often regulated customers, many of them on AWS’s own stack. One of its 14 agents is an AWS platform specialist. Its Enterprise profile runs every stage at the deepest level. That is the right design for its authors. It is a starting point for you, not a destination.

Treat it like a supermarket shelf

A supermarket shelf does not ask you to buy everything on it. You walk past, take what tonight’s dinner needs, and leave the rest for someone with a different recipe. Nobody calls that cherry-picking. It is shopping.

AI-DLC deserves that treatment, because it is a very good shelf. It holds mechanisms that solve real problems with agents, and almost every one of them works on its own, outside the full lifecycle. Taking one does not oblige you to take the others.

The first time I applied this was in a conversation about how to bring the method to a part of the organization that was not ready for it. Instead of importing AI-DLC whole, we split it into its variables: who sits in the mob, how big a task is, which combination of rituals a given team needed. We ended with four or five starting configurations instead of one doctrine. Each team picked the one that matched its maturity. Nobody had to pretend to be a pilot squad.

What to take first

These are the mechanisms that paid off on their own, in roughly the order I would take them.

Take these

• ✓Required:
  Artifacts that persist in the repo.Requirements, decisions, and plans as versioned files the agent reads every session. This is the single most valuable idea in the method, and it works with any tool.
• ✓Required:
  A human gate between steps.The agent produces, a person approves or requests changes, and only then does the next step start. The whitepaper calls each gate a loss function: it catches a wrong decision where it is cheap to reverse.
• ✓Required:
  Let the AI ask the questions.Give the agent the intent and answer what it asks, instead of trying to write the perfect prompt. The questions it asks are the ones a developer would hit halfway through the implementation.
• ✓Required:
  Depth proportional to the work.A bug fix does not need a domain model. AI-DLC 2 encodes this as 11 workflow profiles, from an 8-stage proof of concept to all 33 stages. Steal the principle even if you never install the engine.
• •Optional:
  Slices measured in hours.Bolts instead of two-week sprints. Take it once the team specifies well enough that the agent can deliver a slice without waiting on a meeting.
• •Optional:
  A learning loop.Turn every correction you make into a rule the agent reads next time. AI-DLC 2 does this with a per-stage diary and a confirmation at the gate. A plain file of team rules is a fine start.

What to leave on the shelf, at least for now

The other half of shopping is walking past things.

Leave these, for now

• ✗Anti-pattern:
  All 33 stages on day one.Start with the Classic profile, which is the version 1 ceremony: Inception and Construction, one approval per stage. Add phases when a real problem asks for them.
• ✗Anti-pattern:
  Renaming everything.Calling sprints bolts and epics intents does not change the work. Change the work first. The words can follow, or never.
• ✗Anti-pattern:
  A mob for every task.Mob Elaboration pays when a decision needs several people. A task one engineer can specify alone does not need a room.
• ✗Anti-pattern:
  The agents you have no use for.If you do not run on AWS, the AWS platform agent and the AWS MCP servers are noise. If you have no compliance regime, the compliance agent is ceremony.
• ✗Anti-pattern:
  The expectation of instant delivery.The method makes cycle time worse before it makes it better. Leaders who adopt the label usually adopt the promise too, and then kill the rollout at the bottom of the curve.

Write down what you took and why

The shelf metaphor has one trap: shopping without a list. If every team takes a different handful of mechanisms and nobody writes it down, a year from now you have twenty private dialects of AI-DLC and no way to compare them.

So the guide your organization writes should open with two lists, and every item on both lists should carry its origin.

## What we took from AI-DLC

- Artifacts versioned in the repo, read by the agent every session
  Origin: AWS method, principle "artifacts as context memory"
- Human approval gate after each artifact
  Origin: AWS method; we kept "Approve / Request Changes"
- Sessions capped at one hour, context cleared at each gate
  Origin: our pilot, after approvals degraded in long sessions

## What we did not take, and why

- Ideation phase: product discovery already runs elsewhere
  Revisit when: a squad without a product partner adopts the method
- AWS platform agent: we run on another cloud
- Full 33-stage route: Classic profile covers our first quarter

The rule I apply to these guides is blunt: if an item has no origin, it does not go in. Every practice either came from the AWS method, from another framework, or from your own pilot. Writing that down is what separates a decision from a rumor, and it tells the next person what they are allowed to change.

AI-DLC 2 just proved the point

Here is the strongest argument for this posture, and it arrived in September 2026.

Teams that adopted version 1 of AI-DLC built on top of it. They had to. Version 1 was a set of rules files, and real teams needed more than that, so they wrote their own layers: extensions that loaded by opt-in, retrospectives that ran at the end of each task, parallel construction across git worktrees, patches injected into the core rules, discipline around clearing context and resuming work. Some of those layers were impressive pieces of engineering.

Then AI-DLC 2 shipped, and a large part of that plumbing became native.

What teams built on version 1, and what AI-DLC 2 shipped

Checked against AI-DLC 2.10.0, the current release on October 1, 2026.

Homegrown on version 1	Native in AI-DLC 2
Custom state tracking and resume after a context reset	A state file per intent, an append-only audit log with 108 event types, and recovery when the agent compresses its context mid-session
Retrospectives that run when a task ends	A learning loop: a diary per stage, candidates confirmed at the gate, rules applied on the next run
Parallel construction with git worktrees	Swarm execution: dependency-ready Units built in parallel worktrees, with batch checkpoints
Patches injected into the core rules	A plugin system that only adds to the core and never edits it
One workflow, trimmed by hand per task	11 workflow profiles plus a composer agent that proposes a custom route

The teams that had adopted version 1 as a doctrine were now maintaining a doctrine plus a pile of workarounds that the vendor had just made obsolete. The teams that had treated it as a shelf lost nothing important, because the plumbing was never the point.

What survived the upgrade was everything that encoded the organization’s own judgment. The rules against vibe coding that a pilot team had learned the hard way. The ritual for shaping a good intent before anyone writes a requirement. The sense of which tasks do not deserve the method at all. None of that shipped in AI-DLC 2, because none of it could. It belongs to the people who learned it.

Own the judgment, rent the plumbing

The lesson generalizes beyond AI-DLC. When you build on a fast-moving framework, split what you write into two piles.

Plumbing: let the vendor own it

1. 01State tracking and resume
2. 02Orchestration of agents and stages
3. 03Parallel execution and worktrees
4. 04Audit logs and traceability checks

Judgment: keep it yours

1. 01Your rules for what the agent must never do
2. 02How your teams shape an intent before the first requirement
3. 03Which work goes through the method and which does not
4. 04What your reviewers check at each gate

If you must extend the framework, do it at its seams. AI-DLC 2 ships a plugin mechanism that can add stages, agents, rules, and checks without editing the core, so your additions survive the next release. I wrote about the same discipline for dependencies in own the seam: a change that lives in the declared extension point gets versioned and survives updates, while a patch scattered across the core gets reapplied by hand after every release, until someone forgets.

When adopting the whole thing is right

Being honest about the exceptions makes the rule stronger.

Adopt AI-DLC close to whole when your organization looks like the customers it was designed for: many teams, regulated work, a need for full traceability from intent to production, and an AWS stack. The Enterprise profile exists for exactly that, and inventing your own version would be waste.

Adopt it close to whole when your teams have no process at all. A complete, documented method beats an improvised one, and the workshop mode exists to teach it.

And even then, adopt it with the adaptations written down. A senior leader I worked with put it well: adopting the whole framework is a fine choice, as long as the changes you make are explicit and deliberate. The failure is never adopting too much. It is adopting without deciding.

FAQ

Isn't taking only parts of AI-DLC just cherry-picking?+

Cherry-picking is taking the easy parts and skipping the hard ones without saying so. This is the opposite: you take the mechanisms that solve a problem you can name, you write down what you left and why, and you revisit the list. The persistent artifacts and the gates, the hardest habits, are the first things on the list.

Will we lose updates if we customize AI-DLC?+

Not if you customize at the seams. AI-DLC 2 has a plugin mechanism that only adds to the core, plus rule files at the organization, team, and project level. Changes made there survive releases. Changes patched into the core files are the ones you lose.

Should we call our process AI-DLC internally?+

Call it whatever helps people find the guide. Just avoid making the name the goal. If people hear the name and go study the AWS paper instead of your two-list document, the name is working against you.

Who decides what to take?+

The people who run the first pilots, with someone who owns the guide. Practices that come from a real pilot carry evidence. Practices that come from a slide carry hope. Write the origin next to each one.

Is this an argument against AI-DLC?+

No. It is an argument for using it well. AI-DLC is the most complete public framework for building with agents, and most of its mechanisms are worth taking. The point is to take them on purpose.

Where to go next

Frameworks age. AI-DLC 2 made a year of homegrown plumbing obsolete in one release, and AI-DLC 3 will do it again. What does not age is what your teams learned about their own work. Take the mechanisms, keep the judgment, and write down which is which.