AI-DLC, episode 1: when requirements arrive by word of mouth, AI accelerates misalignment

One sentence handed to an agent

An operations manager sums up the need in one sentence: “We need a portal where everyone can follow the field interventions.” The team opens a coding agent, pastes the sentence, and the agent gets straight to work.

In barely an hour, it produces a portal that works. Along the way, and on its own initiative, it has also made a series of trade-offs nobody asked for: every user sees every intervention; emergencies are sorted simply by order of arrival; nothing is kept in a history; the application needs a permanent connection; the technology chosen is not the team's; and tests are left for later.

The code is not bad. The problem lies elsewhere: nobody asked the agent to ask its questions before writing. The team saves an hour, then spends several days unpicking architecture and business choices that were made on its behalf.

This scenario is imagined, and deliberately simplified. Yet it is the starting point of season 1 of our series: a spoken request, raw and unedited, and the method that stops the agent from deciding in place of the business.

The problem: an agent that asks no questions

Scoping requirements is not a difficulty born with AI. As early as 2014, a study by the Project Management Institute found that when a project fails to meet its goals, inaccurate requirements management is the primary cause almost one time in two (47%).

What AI changes is the speed at which this flaw takes effect. A requirement misunderstood by a team used to surface over the weeks; an agent turns it into code within hours. With AI, a poorly scoped requirement no longer just slows the project down: it accelerates misalignment, and the gap with the real need is discovered later, in review or in production.

DORA's research (Google Cloud), published in September 2025, points the same way. A focus on the end user amplifies the positive effect of AI on team performance; without it, AI adoption can actually harm performance. Teams then risk, in DORA's words, moving quickly in the wrong direction.

Most teams already guide their agent with an instructions file: choice of language, naming conventions, an obligation to write tests. These are style preferences. They do not tell the agent when it is allowed to write code, which questions to ask first, or which documents to have approved before starting.

AI-DLC in brief

AI-DLC (AI-Driven Development Life Cycle) is a development method published by AWS in July 2025. It rests on one principle: AI writes the plans, asks the questions and carries out the work; humans arbitrate and make the critical decisions, because only they know the business context. What it changes compared with the classic cycle, bolts instead of sprints and three phases, Inception, Construction and Operations, is covered in our episode 0. This episode focuses on what the method concretely requires of the agent.

What changes compared with an agent left to itself

• The order: no code before the requirements have been analysed and approved.
• The questions: the agent writes them in a file, with answer options, instead of making assumptions.
• The documents: each stage produces a document in the project repository, on which the next stage builds.
• The approvals: the agent stops at the end of each stage and waits for explicit human agreement before going on.
• The record: every decision is timestamped in an audit log, kept with the code.

Tooling that enforces the process

The official tooling, released as open source by AWS and at version 2.11.1 in October 2026, adds two phases ahead of the method's three: an automatic initialisation, which prepares the working folder and detects whether the project starts from scratch or takes over existing code, and an ideation phase, which writes down the intent before deriving requirements from it. In all, 33 stages, which eleven predefined plans combine according to the type of work: from fixing a bug in 5 stages to a project in a regulated context in 29.

Case study: a project in the energy sector

Our case study* takes place in the energy sector, at a company that works on the electricity grid every day: connections, maintenance, emergency repairs. It is a sector under pressure. In France, the main electricity distribution system operator plans 5.5 billion euros of investment in 2027 (in 2021 euros), then more than 5 billion a year until 2032, compared with 4.4 billion in 2022, mainly to connect renewable energy and charging points.

Behind these figures are connections to schedule, faults to repair after a storm or a flood, and qualified technicians to send to the right place at the right time. Each intervention must also be justifiable after the fact: who decided it, who carried it out, in what order, and why. In an essential sector, traceability and cybersecurity requirements are heading towards more stringency, with the transposition of the NIS2 directive, adopted by the French Senate and still awaiting debate in the National Assembly at the time of writing.

The season 1 project

Season 1 follows the construction, from scratch, of an intervention tracking portal for this company. The work is carried out for real, stage by stage, and measured.

The request, as it is handed to us

The project starts with a few sentences from the operations manager, with no specification and no mock-up:

Replace interventions with deliveries, files or claims, and technicians with drivers, advisers or experts: the request stays the same. Scattered tools, teams lacking information, customers chasing for updates, and the wish for a shared view.

The questions hidden in the request

For an operations manager, everything has been said. For an agent, almost nothing is defined yet. Take the words of the request one by one: each hides at least one question the agent must get an answer to before writing a single line of code.

An experienced team would guess some of the answers. An agent will pick one interpretation and build it quickly and cleanly, without warning.

Four families of questions, for any project

These questions are not specific to this case. We recommend putting every request through four families of questions before handing it to an agent:

1. Who: who uses the tool, with what rights, who sees what, and who has access to sensitive data?

2. What comes first: which rule decides what goes first, and who sets it?

3. What record: what must be kept, for how long, for whom, and what will serve as evidence in an audit or a dispute?

4. Under what conditions: what must the tool do when conditions deteriorate, with no connection, or when two people change the same data?

An unanswered question is not a blocker. It is a decision that belongs to the business, before the agent makes it in its place.

Our approach: making the requirement verifiable

Our conviction fits in one sentence: with AI, the value of a project is decided before the code. The job is not to write a better prompt for the agent, but to turn a requirement expressed out loud into a verifiable requirement, one the agent can deliver and the team can check.

Raising scoping maturity, one level at a time

Our maturity framework describes this path in five levels for the “Scoping and requirements” stage. Each adds only its own increment and assumes the previous one is in place:

1. Absent: the requirement is expressed out loud, with no template. This is where our project starts.

2. Initiated: every request takes the same form, thanks to shared Epic, Feature and Story templates.

3. Structured: a “Ready to Dev” check verifies that a request is complete before it enters development.

4. Industrialised: time spent upstream is measured, and every request sent back to the business is sent back for a recorded reason.

5. Piloted: the agent spots an incomplete request on its own and sends it back to the business with its questions; the decision stays human.

We recommend not skipping a level. An agent able to scope on its own adds nothing if requests have no common form; it only speeds up the disorder.

Three principles we recommend

1. The intent remains the reference: the original request is kept with the code, and every requirement, every test and every change must be traceable back to it.

2. AI proposes, humans decide: the agent writes the plan and asks the questions; the business and the team decide. An unanswered question stays open; it is not filled in by an assumption from the agent.

3. One requirement, one verifiable criterion: a requirement without an acceptance criterion does not pass the “Ready to Dev” check. That criterion is then used to derive the tests from the expected behaviour, not from the code produced.

These principles assume the business is available. If the operations manager can only answer the agent's questions once a fortnight, the short loop of AI-DLC becomes a two-week cycle again.

The collective elaboration session

The business, the team and the agent sit in front of the same screen. The agent reads the intent, proposes a first set of requirements and asks its questions. The team answers, corrects and decides. The agent therefore does not work alone: its questions are put in front of the business and the team, and no line of code is written until the answers have been settled. AWS calls this session Mob Elaboration: the whole team validates the AI's questions and proposals there.

In practice: AI-DLC in a project

A method is only worth the way it fits into a team's daily work. Here, step by step, is how we set it up on 28 October 2026 for this project, with Claude Code as the coding agent. The screenshots come from our own machine; the blue highlights are ours.

1. Install Claude Code

Claude Code installs with a single command, through Homebrew on a Mac or through Anthropic's official install script. The AI-DLC tooling also relies on Bun, a JavaScript runtime, in version 1.3.8 or later.

brew install --cask claude-code

2. Get AI-DLC without running an unknown script

The documentation suggests installing through a script that is downloaded and run straight away. We recommend another route, a few minutes slower: download the archive published on the official repository, check its checksum, review what it adds, then copy into the project the folder intended for Claude Code.

shasum -a 256 aidlc-copy-runtime-2.11.1.tar.gz
tar -xzf aidlc-copy-runtime-2.11.1.tar.gz
cp -R runtime/claude/. ~/projets/cas-energie/

This review shows what the tooling really does. It attaches itself to 16 of the agent's hooks, and its settings file pre-authorises around a hundred of the tool's commands as well as changes to every file in the project. Nothing malicious, but a tool that takes up a lot of room, and one you need to know before adopting it.

3. Prepare the project

The project lives in its own git repository, on a dedicated branch, with only data created for the occasion. Before the first launch, we add local settings, which are not versioned:

• Offline: the tool does not look for updates on the internet on its own and does not measure its usage.
• Its own files protected: the agent cannot change the tooling's rules and scripts.
• No web search, no external server: the agent works with what the repository contains.
• Secrets out of git: .env files are excluded from version control from the start.

When Claude Code is first launched in the folder, the tooling sets itself up. The /hooks command lists the hooks it installs:

4. Check the installation

The tooling comes with its own diagnostic, which we run before any request with the /aidlc --doctor command:

We keep Claude Code in its manual mode, where the agent asks before acting. The commands and file writes that the tooling pre-authorises still go through without a question: that is the price of its automation, and one more reason to review its settings.

5. Start with /aidlc, then version

The work starts with a single command, followed by the request copied word for word, shortened here:

/aidlc Portail de suivi d'interventions. Demande du responsable d'exploitation : « Aujourd'hui, on suit nos interventions […] »

The agent prepares its working folder, detects that the project starts from scratch, then proposes a plan before acting:

That plan stopped before operations, whereas our season runs all the way to production. Of the eleven plans available, we chose the “enterprise” plan: 29 stages, designed for a regulated context, with full traceability. It requires a human to approve every plan and every summary.

First stage: capturing the intent. The agent does not write code: it writes its questions in a file, then asks how the team wants to answer them.

Its twelve questions come back to the words of the request: what makes an emergency, why keep a record of everything, the conditions without a network, the customers concerned. On top of these come the success indicators, what the first version will not do, and who decides the scope. We have not answered them yet: those answers belong to the elaboration session.

Everything the agent produces, the progress status, the questions and the audit log, is a file in the repository. We commit it to git, like the code: six months from now, we will still know why a decision was made, and by whom.

Company rules, applied to every project

The tooling lets a team add its own standards: conventions, security requirements, compliance rules. We recommend writing down there the requirements that apply to every project in a regulated sector, so that the agent applies them without anyone having to remind it.

Our recommendations for getting started

What we take from the official documentation, to apply from the very first project:

• Answer precisely: a vague answer produces a vague requirement. “One account per technician, deactivated when they leave, and read-only access for customers” is worth more than “rights management”.
• Do not skip stages: user stories become the acceptance criteria, then the tests. Skipping them leaves a gap that is paid for later.
• Version the documents produced: they are not drafts, but the project's living documentation.
• Write your rules once: the company's security and compliance requirements should become rules the agent applies to every project.
• Keep the business in the loop: without quick answers from the business, the method loses its main advantage.

Conclusion

A request of a few sentences. Four words that each hide a decision. And an agent that, left alone, would have made all of them without asking anyone.

AI-DLC does not make the agent more cautious. It forces it to stop, ask its questions and wait for a human decision, then it keeps a record of each one in the repository, with the code. That discipline is what makes the difference between an agent that speeds up the project and an agent that speeds up misalignment.

In the next episode

The request is set out, the tooling is in place, and the agent is waiting for our answers to its twelve scoping questions. In episode 2, we answer them in a session with the business, and we publish the session as it unfolds, up to the first requirements.

One question interests us more than any other: of these twelve questions, and of those that will follow before the first line of code, how many had the team not anticipated?

We will publish:

• The questions and our answers: the agent's questions as they are, and the decisions made in the session.
• What remains open: the decisions postponed for lack of an answer from the business.
• What comes out of it: the approved requirements and user stories, with screenshots.
• The first measurements: the time between the spoken request and an approved requirements plan, and the number of requirements with a verifiable criterion.

Our approach to AI-DLC is described on our dedicated page.

Related readIs there still a place for agile in the age of AI-DLC?AI agents can now produce in a few hours what a team used to deliver in a two-week sprint. AWS has turned this into a method, AI-DLC, which replaces the sprint with the "bolt", a cycle lasting a few hours or a few days. Some conclude that agile should be thrown out. We think the opposite: AI-DLC retires the rituals of agile, not its values, and AI makes those values more necessary than ever. This article opens a series in which we will put that claim to the test on a project built for the purpose, with measurements to back it up.Read the article

* Methodological note: the company, the project and the data are created for the occasion, based on the real issues of the energy sector, and do not resemble any existing company. The execution, the measurements and the failures are real, including when they do not work in our favour. The project remains simpler than a client project, which we will point out in every episode.