AI-XDLC. An AI-driven product design lifecycle with human review at every gate.
About this project
AI-XDLC adapts the staged, verifiable, human-governed lifecycle of AI-DLC to design work. This case study is about the runner I designed and built for it, and what the build taught me about where humans belong in an AI design process. The screens show a fictional wellness-app brief that the runner took from intent to prototype.
Challenge
Every AI design tool I tried optimised for the same moment: prompt in, screens out. That is the least interesting part of design work and the easiest to get wrong. What I wanted was the rest of the process: clarifying intent, grounding in context, generating options, checking them against explicit criteria, and stopping when a decision needed a human. I had the methodology written down as rules. What I did not have was a way to run it that made the gates as visible as the output, and an agent that knows when to stop.
Strategy
Treat the methodology as the product. Twelve stages, three phases, and a rule file for each stage became nodes on a canvas, laid out left to right in phase lanes. A node is locked until the one before it is approved. Every artifact the agent produces pauses at a gate: approve, request changes, pick a direction, or resolve a finding.
The agent runs the loop the methodology prescribes: generate, verify, self-correct, halt or escalate, learn. Design Verification is the hinge. The agent reads its own report as structured findings, revises the target artifact for anything blocking, re-verifies, and gives up after three attempts. Anything that needs editorial, legal, brand, or strategic judgment is escalated to me as a decision with options and a required rationale.
Everything else is grounding: an intent brief, references, a DESIGN.md brand kit whose tokens flow into specs and get injected into prototypes as CSS, and my own answers to the agent's clarifying questions, carried forward as facts. The app is a static site. Claude is called from the browser with my own key, projects live in the browser, and an optional Netlify Blobs sync keeps them across devices.
Results
A working runner that takes a product intent through twelve gated stages to a verified spec, a validation plan, a self-contained HTML prototype, and a set of candidate rules learned from the run. The practical effect is on the calendar. The sequence from brief to verified spec, prototype, and validation plan, which normally spans days of a team's time across drafting, reviews, and handoffs, runs in hours, and the human hours in it are spent at the gates, deciding, rather than producing drafts. Every action, including the autonomous ones, is in an append-only audit log, and every API call is metered so the cost of a self-correction loop is visible in dollars and minutes, not just tokens. The rule files are bundled verbatim into every prompt, so the tool and the method cannot drift apart.
The story
AI-XDLC started as a document: a methodology for letting an agent do design work inside explicit guardrails, with human approval at every step that matters. The document was fine. Nobody, including me, was going to run it by hand. So I built the thing that runs it.
The most interesting design move was making decisions the primary interaction. Most AI tools put the output in the centre and the controls at the edge. Here the canvas shows state, not content: which stage is approved, which is waiting on me, where a revise loop has run. The artifact lives in a panel you open when you want to read it. The thing you cannot avoid is the decision. On the wellness-app run, verification found that the architecture had no navigation mapped to its secondary screens and no state coverage for three of them, fixed both on its own, and then stopped on two questions it would not decide: where the provenance of AI-assisted copy comes from, and how a seven-day trial clock should count. That is the split I wanted. The agent handles the checkable. I handle the judgment.
The second move was turning prose into data the app can act on. The methodology speaks in markdown: clarifying questions in a fixed format, findings with severities, concept sets with a recommendation. The runner asks the agent to append small machine-readable blocks alongside the prose, then parses them into questions I can answer with a click, findings with waive and decide actions, and concept options that spawn a path. The prose stays the artifact; the data drives the interface. The same idea runs through the brand: a DESIGN.md file is both the rulebook the agent reads and the token source the prototype is built from.
The third move was refusing to hide cost and time. Every call is logged with its model, tokens, duration, and reason: generate, self-correction two, re-verify one. The top bar shows the running total. A three-attempt correction loop is honest about what it costs, and that changes how you set the limits. It also surfaced a real behaviour: answer the agent's questions and it will happily ask new ones, some earned by your answer and some because the section exists. Deciding when to stop asking is a design decision too.
What the build proves is smaller than it sounds and more useful. You do not need an orchestration platform to run a governed AI process. You need explicit post-conditions, a place where the agent must stop, and a record of what happened. The hard part was not the API calls. It was deciding which decisions are mine.
What this looks like inside a team
AI-XDLC is a personal experiment, but the operating model it tests is meant for a team. The lifecycle does not change who is accountable for the work. It changes what the work is. Designers stop producing every artifact by hand and start owning the conditions an agent has to meet: what counts as done, which findings block, which decisions stay human.
That moves design leadership to a different place. The rules the agent follows, the accessibility baseline, the trust extension, the brand's DESIGN.md, each stage's post-conditions, are the team's standards in checkable form. Every correction a designer makes in review becomes a candidate rule, so quality compounds across projects instead of resetting with each one. The audit trail and the cost ledger give product, engineering, and legal partners something they rarely get from design: a record of what was decided, by whom, and at what cost.
It also changes what a team can afford to explore. When a full pass takes hours instead of days, and costs a few dollars, developing three concept directions to a verified spec is a routine choice, and human effort concentrates on the decisions that matter. In practice, that means a role that owns:
- Post-conditions and gates. Defines what an agent must satisfy before design work moves forward, and where it must stop.
- Standards as constraints. Encodes brand, accessibility, and trust rules so they are checked on every artifact, not presented in a deck once.
- The human boundary. Decides which decisions stay with people and designs the escalation path that brings them there.
- Visibility. Makes the cost, time, and provenance of AI-assisted work auditable for product, engineering, and legal partners.
- Compounding quality. Turns human corrections into team rules, so each project raises the floor for the next.
Select highlights
- Turned a written methodology into a runnable canvas: twelve stages, three phases, every rule file injected verbatim into the agent's prompts.
- Built the verify, self-correct, escalate loop for real: blocking findings are fixed by the agent within three attempts; judgment calls stop for a human with options and a rationale.
- Made the agent's clarifying questions answerable: questions become decision cards, and answers flow to every later stage as facts.
- Adopted DESIGN.md as the brand input, with a browser-side lint and tokens injected into prototypes as CSS variables and embedded fonts.
- Shipped it as a static app with browser-direct Claude calls, an append-only audit trail, and per-call cost tracking. Source on GitHub.