An AI SDLC for XP Practitioners

From Design to verified code: How shared artifacts, acceptance criteria, and small increments help teams guide AI coding agents.

Today AI-assisted development leaves decisions in one person’s chat window. That person sees the prompts and the full context then everyone else has to piece together what was done afterward. I haven’t seen a shared surface where product, design, and engineering can all work on the same AI plan and code. But shared artifacts and acceptance criteria can give them a place to review the work together.

One team I work with spent months blending practices from XP and spec-driven development with AI agents. They use separate steps for brainstorming, planning, building, and verification, with more people involved along the way. They also use slicing to break work into backlog items. In my own workflow, I use slicing differently to create behavioral scenarios that feed into the implementation plan.

In The Obsolete Conductor, I argued that product managers need to steer the work rather than orchestrate every handoff. Here’s how I put that into practice. Working with agents still requires shared artifacts and points where an actual human decides because without a decision at the right point, an agent can keep building on an assumption the team would have questioned.

I understand the skepticism that AI development practices can become a collection of shiny tools without better outcomes. Small increments, examples of expected behavior, and frequent feedback were useful long before agents. Like the short feedback loops familiar to XP practitioners, each increment gives us a chance to check the behavior and decide what to do next. I use them to make agent-built work easier to understand and review, and to give the team a better chance of noticing when we’re building the wrong thing.

The five steps below show how I use these practices together, from an idea to accepted code. The teams I work with use many of the same practices, though not always in the same sequence or for the same purpose. The practices are familiar. What changes is how the team uses agents to create feedback mechanisms during implementation and what parts of the process to make visible. You can You can explore how different needs benefit from different adaptive AI workflows.

Choose the flow based on the size, risk, and uncertainty of the work. For a small, clear change, a short definition of done and a verification check may be enough. The fuller set of artifacts is most useful when the work has more uncertainty or risk.

How do you define what an AI coding agent should build?

Before asking an agent to write code, I want us to be clear about what we’re asking for. That starts with the problem, the evidence and beliefs behind it, and questions about the proposed solution. I use brainstorming (superpowers) when an idea has ambiguous requirements, and grill-me (by Matt Pocock) when high-risk decisions or consequential unknowns need more thought.

There are still limits to agent instructions. One way to protect against lost context is to leave a trail of artifacts. This phase produces a design.md file that captures the decisions and what the work should achieve for the user. The file gives product, design, engineering, and the next agent an account of the intended behavior to review. It can also instruct points when AI will need a person’s decision instead of making a risky assumption.

This works for both large and small changes, but an important of this step is a longer Markdown file won’t resolve an assumption that needs to be tested. If we can’t yet explain what someone needs, a prototype may be the better next step. The decision here is whether we understand enough to implement the change or should first build something to learn from.

How do you write acceptance criteria for AI coding agents?

Once the design is clear enough, I have an agent divide it into small pieces of behavior. That differs from splitting work into technical components: implementation details alone don’t describe how someone needs to use or experience the feature.

Acceptance criteria give the team and the agent a shared experiential definition of done. I like Given/When/Then because it describes a starting condition, an action, and an observable result in a form people can discuss from the user’s perspective.

I run a slicing-agent before implementation planning because I find it easier to plan and review one piece of behavior at a time. Each agent can focus on the next increment instead of working through the whole feature.

In June, I rebuilt the discovery suggestions in my personal Wishlist app, replacing placeholder gift ideas with real, linked ones. The work broke into five user outcomes: finding suggestions, explaining why they matched, dismissing poor matches, saving links, and making the flow work on mobile and desktop.

Here’s how the work might have been planned without slicing, alongside the approach I used.

Without slicing:

• The planning-agent creates an implementation plan for the discovery experience as a whole.

• The building-agent works from that larger plan.

• A reviewer would consider several behaviors and their dependencies together.

With slicing:

• The slicing-agent breaks the design into behaviors, including dismissing a poor match.

• It writes scenarios that describe what each behavior needs to do.

• The planning-agent uses those scenarios to plan an increment.

• The building-agent implements and verifies the work against the plan.

For dismissing a suggestion, “add a dismiss button” isn’t a complete definition of done. The suggestion also needed to stay dismissed when the person came back. One scenario within the dismiss button feature:

Given I dismiss a suggestion for Ari on desktop web
When I reload Wishlist and return to Discovery for Ari
Then the dismissed suggestion does not reappear.

I use design.md and the slicer’s scenarios together as the input to planning, which then accounts for technicals and tests needed to bring it to life. The design captures user-facing decisions behind the work then the slicer produces a separate Markdown file with verifiable examples of the behavior.

How do you review an AI agent’s implementation plan?

The planning-agent takes the design and the slicer’s scenarios as inputs, examines the repository, and proposes how to implement the next increment. It considers relevant technical constraints plus any design-system guidance available to it and includes completion gates that checked the story’s acceptance criteria as the work progresses.

The result is a planning.md that lays out the implementation phases and how each will be checked against the intended behavior.

I review the plan before asking the agent to execute it. Each phase should identify what will change and how it will be checked. Some phases validate technical work rather than a complete user interaction. A shared plan can also give product, design, and engineering a place to review the scope together.

For the Wishlist example, I’d look for whether the plan preserves a dismissal after reload, scopes it to the right recipient, and explains how to check both. If it doesn’t, the plan needs another pass before building. When I plan the “explaining why they matched” feature I didn’t know what UX I wanted, so I left that design less defined upfront to see what the plan suggests.

A shared artifact gives the team and the next agent a place to find the decisions behind the work. Documentation can go stale when updating it is extra work nobody owns, so our workflow instructs the agent to update the appropriate document as decisions and progress change. People can then inspect those updates, though the team still needs to check that the artifact reflects what was built.

How do AI coding agents build and test in small steps?

With an agreed plan, the building-agent can work through each phase and run the acceptance checks. Those checks give the team feedback at each step, a familiar idea from XP. Engineering remains responsible for reducing risk through controls such as automated tests, CI/CD checks, and access controls.

The building agent stops before implementation when it finds a sequencing problem in the plan

After approval, the agent corrects the sequence and limits the work to the first phase

We give the agent explicit reasons to stop. If it encounters an unanswered question that changes product behavior, needs broader permissions, or discovers that the plan does not fit the repository, it should return for a decision.

Within those boundaries, the agent can make implementation decisions and record them in its notes. One line I use is if the decision would change user-visible behavior from what the team already agreed? If so, the agent stops for a decision, and the change goes back into the design or the criteria.

The agent reports what it built, the checks it ran, and where it recorded progress

The artifacts are Markdown because agents read and edit it well, but it isn’t always a friendly format for people. We render the Markdown as an HTML page when in review and keep the original file as the source of truth. People can open a more readable version without changing the content the agent uses.

Human review can be proportionate to the change. I use designing and slicing to make the work easier to inspect as it progresses, especially when an agent can generate changes faster than I can review them. Smaller phases give me a clearer place to check the behavior and decide whether to continue.

How do you know whether the software solved the problem?

As with XP and other established software development practices, completing the work is only part of the job. Passing acceptance checks shows that the software behaves as expected in the cases we tested. It doesn’t tell us whether we chose the right behavior or solved the problem. After release, watch whether people can complete the intended activity and where they struggle. Use what you learn to revise the design and acceptance criteria before the next change.

What judgment do people keep in AI-assisted development?

This workflow comes from a belief I share with the people I work with: the practices worth keeping help a team agree on what it’s making. Agents can produce code from a plan yet deciding whether the plan addresses the problem still takes critical thinking from the people who understand it and the team responsible for the result.

People remain accountable for the decisions made during development. That’s why I keep artifacts, success criteria, and acceptance checks even when an agent can write code faster than a person can review it. They give people across product, design, and engineering a place to stay in the same conversation as the work.

If you adopt one part of this, start with the acceptance criteria. Before an agent touches the code, write down what done means for the next change, in proportion to its size and risk. Write it in a form a person can read out loud and an agent can test against. Then see whether the plan changes. Mine has, more than once, when a scenario forced a decision we had been avoiding.