AI-DLC's Blind Spot: Where the Intent Comes From

AI-DLC turns an intent into software with real discipline. Nothing in it checks whether the intent was worth building.

Every AI-DLC workflow starts with an Intent: a statement of what needs to be achieved and why. The method, as AWS introduced it, defines it in one sentence. The agent decomposes it into Units, the independent pieces the work gets split into, the Units become code, and a dozen human gates check every step along the way. It is a careful machine. It is also a machine that assumes the first input was right.

That assumption is where most of the pain I saw came from. In the rollout I followed inside a large engineering organization, teams that struggled with AI-DLC almost never struggled with the agent. They struggled because what went in at the top was vague, stale, or aimed at the wrong outcome, and the method processed it faithfully all the way down.

The whitepaper is honest about the division of labor. Humans set the destination. The AI gives the directions. What it does not say is how a team arrives at a destination worth driving to. That is the upstream gap, and this article is about the ritual that closes it.

Errors at the intent multiply

In an AI-DLC workflow, each phase reads the output of the previous one as its context. Requirements are built from the intent. Stories are built from the requirements. Units are built from the stories. Code is built from the Units. That chain is what makes the method traceable. It is also what makes a bad start expensive.

A vague intent does not produce vague code. It produces confident code. The agent fills every gap it finds with the most statistically likely answer, and each later phase treats that answer as settled fact. By the time the mistake surfaces in a code review, it has been encoded in requirements, stories, a domain model, and a few thousand lines of implementation.

The whitepaper calls each human check a loss function: a point where a wrong decision gets pruned before it grows. Follow that logic to its end and the intent is the most valuable loss function in the whole lifecycle, because it is the one with the most downstream work hanging off it. A wrong call at the intent is caught most cheaply at the intent. Every later gate charges more for the same correction.

AI-DLC 2 added Ideation, and most runs skip it

AWS clearly saw the gap. AI-DLC 2 added a whole phase before Inception (the phase where requirements and design get decided), called Ideation, with seven stages: Intent Capture and Framing, Market Research, Feasibility and Constraints, Scope Definition, Team Formation, Rough Mockups, and Approval and Handoff.

Intent Capture is well designed. The product agent asks about the business problem, the customer, the success metrics, the trigger for the initiative, and who has decision authority. Every substantive line in the resulting intent statement carries a tag that says where it came from: your original description, a specific answer you gave, a stored team rule, or an assumption. Assumptions have to be confirmed explicitly, and confirming one keeps the label. It does not promote a guess to a fact. That is exactly the discipline the upstream needs.

Now look at which workflows actually run it.

Which AI-DLC 2 profiles run Ideation

Classic is the profile the engine uses when you name none. In a default run, the intent is whatever you typed after /aidlc.

Workflow profile	Ideation
Feature, Enterprise	All seven stages
MVP	A light version: intent, feasibility, scope, mockups
Proof of concept	Minimal intent capture only
Classic, Express, Bugfix, Refactor, Infrastructure, Security patch, Workshop	Skipped entirely

That makes sense for a bugfix, where the problem is the bug. It makes less sense for the many teams that start with Classic because it is the default and it feels like version 1. In those runs, the intent is the sentence you typed after /aidlc, plus whatever the agent infers from your repository.

And even the full Ideation phase cannot do the hardest part. It structures what someone in the room knows. It does not discover what nobody knows. If the PM is unsure whether the problem is worth solving, seven well-designed stages will produce a beautifully tagged intent for an uncertain problem.

Five questions before the first prompt

The teams that did well had something in place before AI-DLC ever started: an entry document. Some called it a six-pager, after the Amazon habit of narrative memos. The name does not matter. The questions do.

The intent has to answer five questions

• ✓Required:
  What is the problem?Stated as something that hurts today, not as a feature to build.
• ✓Required:
  For whom?A real user or customer group. 'Users' is not an answer.
• ✓Required:
  What result do we expect?What will be different when this ships.
• ✓Required:
  What are the constraints?Deadlines, regulations, systems you cannot touch, budget, and what is explicitly out of scope.
• ✓Required:
  How will we know it worked?A metric that moves, not a deliverable that exists. More on this below.

None of this is new. It is product thinking, and good product people have always done it. What changed is the cost of skipping it. When a team of humans built from a vague ticket, the vagueness got resolved slowly, through a hundred small conversations. When an agent builds from a vague intent, it resolves the vagueness instantly, by itself, and writes the result down as if someone had decided it.

This is also where Spec-Driven Development earns its place as the step before AI-DLC. A team that has practiced writing a spec, with the why, the what, and the explicit negative scope, already knows how to answer these five questions. A team that has not will find the questions harder than the code.

Let the size of the problem decide how much the AI does

One of the best ideas I saw in the rollout came from the people using the upstream tooling, not the people building it. A product manager and a designer who tested it early asked for a triage step before anything else: classify the problem first, then decide how much the agent is allowed to do.

The triage does not change how many questions the agent asks. It changes what the agent is permitted to generate on its own.

Complexity triage before the intent

The classification is a gate, not a verdict. If the agent calls it low and the problem crosses three teams, override it before you continue.

Complexity	What the agent does	What the human does
Low	Runs the discovery end to end and delivers a draft intent.	Reads it and approves or corrects.
Medium	Guides section by section, with a check after each one.	Answers and approves each section before the next.
High, many stakeholders	Facilitates only. It organizes the conversation and never generates structure on its own.	Owns every decision. The agent takes notes.

The anti-pattern here is the shortcut in the other direction. The agent classifies the problem as high complexity, someone overrides it to get a full autonomous draft faster, and the draft comes out with holes the size of the stakeholders nobody consulted. Those holes enter the lifecycle as a vague intent, and you already know what happens next.

Give the agent a curated index, not the whole wiki

Every company has a wiki full of documents. Some are current. Many are not. An agent with access to all of it cannot tell the difference, and it will happily build your intent on a decision the company reversed two years ago.

I watched it happen live. During a demo of an upstream discovery agent, it pulled a document from 2022 into the context of a current project. The product manager running the demo knew the domain, spotted it, and corrected it. Someone with less context would have approved it, because it looked exactly like a relevant document.

The fix the team used is unglamorous and it works: a curated index per area of the wiki, maintained by hand, listing the sources the agent is allowed to treat as trustworthy. The agent reads the index first and only follows links from it. Building the index is boring work. It is also the precondition for trusting anything the agent writes upstream, for the same reason a good AGENTS.md matters downstream: the agent is only as good as the context you choose to give it.

A success criterion is an outcome, never an artifact

This was the single most common mistake I saw the agent make, and the one most likely to slip past a tired reviewer.

In one live session, a product manager was shaping the intent for an internal backoffice that would replace a paid vendor tool. The agent drafted the success criteria and wrote, in substance, that success meant the documentation being complete. She stopped and pushed back. The documentation was the deliverable of this step. The success of the feature was cutting the vendor cost and answering a move a competitor had made. A document existing is not a business result.

They were right, and the agent accepted the correction. But notice how plausible the wrong version was. “Documentation complete” and “epic created” are things a team produces, so they look like progress. They measure activity. An intent whose success criterion is an artifact will produce a lifecycle optimized for producing that artifact.

Artifact criteria (reject these)

1. 01Documentation is complete
2. 02The epic is created in the tracker
3. 03The API is deployed
4. 04The screens match the mockups

Outcome criteria (ask for these)

1. 01The vendor contract can be cancelled
2. 02Checkout abandonment drops on mobile
3. 03Support tickets about refunds go down
4. 04Onboarding takes one day instead of five

The same session showed two smaller lessons. First, the agent infers work from keywords. The PM had mentioned the competitor in passing, so the agent started a competitive benchmark nobody needed. State what is out of scope explicitly, or the agent will invent scope from your vocabulary. Second, when that benchmark search failed on a network error, the agent said it would not make up data. That is a good sign. If yours fabricates a market analysis when a source is unreachable, you have a bigger problem than the intent.

Completeness beats format

Upstream tooling tends to produce a tidy summary document, and the natural assumption is that the summary is the input downstream. One team learned otherwise. The summary their upstream process generated had cut context that the original ticket contained, and they spent real time putting it back during Inception.

The lesson they wrote down: AI-DLC does not need a specific format as input. It needs the most complete information available. If the original ticket has more detail than the summary, give it the ticket. Give it both. Record which documents you passed in, so the next person knows what the agent knew. A summary is written to communicate a decision to people. It is not written to preserve every constraint an agent will need.

Convincing is not the same as correct

A product lead in the rollout explained the risk of AI-generated discovery with an analogy I keep repeating. When you get an email from your bank, you look at it carefully. Is the link right? Is the logo crooked? A generated six-pager is the opposite case. It looks so much like a real one that you stop being careful. And then you actually read it and realize there is nothing in it.

The better the format, the less people read. That is why the intent needs a named human with domain knowledge to sign it before anything downstream starts. In the sessions I watched, senior people interrogated every claim the agent made and took longer. Less experienced people accepted the first draft and moved on. For a team without that experience, pair them: one person drives the session, another person who knows the domain approves the result.

The upstream ritual before AI-DLC starts

Input

A problem someone thinks is worth solving

↓

1. TRIAGEClassify the problem

   Low, medium, or high complexity decides how much the agent may generate on its own.

   ↓
2. SOURCESPoint the agent at curated sources

   An index of trusted documents, not the whole wiki. Attach the most complete material you have.

   ↓
3. FIVEAnswer the five questions

   Problem, for whom, expected result, constraints with explicit out-of-scope, and an outcome metric.

   ↓
4. SIGNA domain owner signs the intent

   Someone who would catch a stale rule or an artifact disguised as a success criterion.

↓

Output

An intent worth decomposing. Now Inception has something real to work on.

The intent is the first half of a spec

If you have read anything else I write, you can see where this goes. The intent is the top layer of a spec: the why and the what, before the how. In the Spec-Driven Development workflow I use, that layer is the product requirements document, and it gets approved before a single design decision is made. How to write a spec covers the format in detail.

AI-DLC 2 gets closer to that with Ideation, and the source tags on every claim are a good idea. But a phase you can skip is not a habit, and the default workflow skips it. The habit has to live in the team. If your people cannot answer the five questions on their own, the method will answer them for you, and it will answer with the average of everything it has read.

FAQ

What is an Intent in AI-DLC?+

An Intent is the starting input of an AI-DLC workflow: a high-level statement of what needs to be achieved and why, whether it is a business goal, a feature, or a technical outcome. The AI decomposes it into Units of work. In AI-DLC 2, each Intent also gets its own folder in the repository where every artifact, decision, and audit record for that piece of work is kept.

What is the difference between an Intent and a Unit?+

The Intent is the why: one statement of purpose. A Unit is a piece of the how: a self-contained part of the solution, derived from the Intent, that can be built and deployed on its own. One Intent usually produces several Units.

Does AI-DLC need a PRD or a six-pager?+

The method does not require a specific document. It needs the most complete information available about the problem, in whatever format your team uses.

In practice, teams that arrived with a structured entry document answering problem, users, result, constraints, and success metric had far fewer reworks than teams that typed one sentence after the command.

Does the Ideation phase run on every AI-DLC 2 workflow?+

No. Feature and Enterprise run all seven Ideation stages, MVP runs a light version, and Proof of concept runs a minimal intent capture. Classic, which is the default when you do not name a profile, skips Ideation entirely, as do Express, Bugfix, Refactor, Infrastructure, Security patch, and Workshop.

How long should an intent be?+

As long as it takes to answer the five questions honestly. For a small task, one paragraph. For a cross-team initiative, a few pages. Length is not the test. The test is whether someone with no context could tell what problem you are solving, for whom, and how you will know it worked.

What is the most common mistake in an AI-generated intent?+

A success criterion that is an artifact instead of an outcome: 'documentation complete' or 'epic created' instead of a business metric that moves. The second most common is stale information pulled from an uncurated wiki.

Where to go next

AI-DLC is excellent at turning a good intent into good software, and indifferent to whether the intent was good. That part is still yours. Triage the problem, curate the sources, answer the five questions, and make someone who knows the domain sign before the machine starts.