Design-Driven Development: Prototypes as Constraints for AI Coding Agents

The PR passed every spec check. The acceptance criteria were green. The agent had followed the ticket line for line. And the first user opened it, froze for three seconds, and clicked the wrong button.

This is the conversation that keeps coming up in AI-enabled delivery orgs, and it is the conversation engineering leaders keep avoiding at every AI-tooling review. The story always starts the same way. The team installed an AI coding agent. The agent shipped fast. The output passed CI, passed the spec, passed code review. Then it touched a real user and the feature did not work, even though every check said it did. The agent had built the right thing by the spec's definition and the wrong thing by the user's.

The instinct is to argue about the agent. Whether Claude Code is good enough. Whether Cursor's context window is the problem. Whether the team should have written better prompts. None of those arguments touch the actual mechanic, because the actual mechanic lives one layer above the agent, in the artefact the agent was given to constrain its output.

AI coding agents do not generate code from nothing. They generate code from a brief. When the brief is a text spec, the agent fills every silent dimension with a plausible default. Layout, sequence, state transitions, the user's task model - none of that sits in the spec, so none of that sits in the agent's constraint set. The agent ships technically correct code that nobody can use, because nobody had defined the interaction surface before the agent started generating it.

This article is about a discipline I call Design-Driven Development. It is the second leg of an upstream stack that sibling pieces in this series have argued: spec-driven development on one side, quality gates on the other. The argument here is that the prototype, not the spec, is the constraint shape an AI agent actually needs at the point of generation. Why that is true mechanically. What alignment dividend the discipline pays before the agent runs. What failure mode it prevents. And what installing it looks like in an engineering org that has already shipped its first wave of AI tooling and is now wondering why delivery still does not feel different.

The spec is the wrong constraint layer for AI agents

A text spec is dense in some dimensions and silent in others. It is dense on what the system does: business rules, data shape, acceptance criteria, the API contract. It is silent on what the system feels like to a user: the spatial arrangement of the controls, the sequence of states, the error surface, the place the eye lands first, the recovery path when something fails. Pre-AI, this asymmetry was tolerable because a human engineer filled the silent dimensions implicitly. They had built the rest of the product. They knew the existing patterns. They had sat next to the designer for two sprints. The spec was a contract written on top of a shared mental model.

An AI coding agent has no shared mental model. It has the spec and whatever it can infer from the existing codebase. When the spec says "the user can filter results by status," the agent infers a filter component. It picks a UI pattern from the most-frequent pattern in the training distribution, or the most-frequent pattern in the codebase, whichever signal is stronger. It picks a default position, a default open-state behavior, a default empty-state. None of these defaults are wrong in any spec-detectable sense. All of them are wrong in the sense that nobody decided them.

Watch what happens at the next layer down. The spec says "show validation errors." The agent picks inline-below-field, because that is the most common pattern in the training data. The user's existing app uses a top-of-form summary, because the product has historically catered to keyboard-driven power users who scan top-to-bottom. The agent's choice is technically correct. It is also operationally wrong for this specific product's users, and the only place that decision was ever recorded was in a Figma file the agent never saw.

Multiply this across every silent dimension of every ticket. Position. Spacing. Sequence. Default state. Empty state. Error state. Loading state. Recovery path. Keyboard navigation. Touch-target sizing. Confirmation patterns. The spec is silent on most of these because no spec writer thinks to write them down. A human engineer absorbed them by osmosis. An AI agent absorbs nothing by osmosis. It absorbs what is in the brief.

This is not a tooling problem. Better prompts do not fix it. Longer context windows do not fix it. The agent does not need more text. It needs a different shape of constraint, one that carries the silent dimensions at the same fidelity as it carries the explicit ones. The artefact that does this is the prototype.

The argument in our sibling piece on spec-driven development was that the spec, written down, is what AI agents need at the what-to-build layer. That argument still holds. The argument here is that the spec is not enough on its own. The spec answers what. The prototype answers how it lands. Both upstream artefacts are required, and the prototype is the one most engineering orgs are still treating as decoration.

The prototype is a higher-bandwidth contract than prose

Bandwidth is the right frame. A prose spec encodes decisions in language, which is a sequential, low-dimensional channel. A prototype encodes decisions in pixels arranged in space and time, which is a parallel, high-dimensional channel. The same decision - "the filter sits to the right of the search bar, opens on click, shows the active filter as a chip below" - takes three lines of prose and four words of pixel labels. The pixel version is also more accurate, because it commits to specifics the prose version glosses over.

The bandwidth difference is not aesthetic. It is operational. A prototype carries five things prose cannot carry at the same fidelity. Spatial relationships: what sits next to what, what reads first, what the eye returns to. Interaction sequence: what happens first, what happens next, what waits for confirmation. State-by-state behavior: what the screen looks like before, during, and after the action. Error surface: where the error appears, what it says, how the user recovers. And the user's mental model, encoded as the implicit grammar of how the screens flow together.

An AI coding agent reading a prototype gets all five of these as constraint. A prototype is a labeled training example with the answer key attached. The agent does not have to guess the layout, because the layout is the screenshot. It does not have to invent the sequence, because the sequence is the screen-to-screen flow. It does not have to pick an empty-state pattern, because the empty state is rendered. The silent dimensions of the spec are no longer silent. They have been answered by the artefact upstream of the agent.

One temptation is to fix this with better text. "We just need our spec to be more detailed." Teams that go down this road end up with twenty-page specs that nobody reads, which devolve into nine-page specs that still miss the silent dimensions, which collapse back into three-page specs that the next AI agent reinterprets all over again. Prose has a natural ceiling on bandwidth. You cannot prose your way out of a dimensionality problem.

The other temptation is to fix it with better agents. "The next model will figure it out." Possibly, in some narrow sense. But the failure mode here is not the agent's inference quality. It is the absence of the decision in the constraint set at all. No model, however good, generates the decision a human stakeholder needed to make. It generates the most plausible default given the data. A plausible default is not what the product needed; what the product needed was the specific choice the team had made when they thought about the user. That choice has to exist as an artefact the agent can read. The prototype is that artefact.

A note on fidelity. The argument is not that the prototype must be pixel-perfect or production-styled. It is that the prototype must be interaction-true. The agent reads behavior, not polish. A grayscale wireframe that correctly encodes the sequence and the state behavior is a better constraint than a beautifully styled mockup that gets the empty-state wrong. The discipline is about what the prototype must answer, not how pretty it looks. We will return to this in the install playbook.

The alignment dividend lands before the agent runs, not after

The cheapest place to surface a disagreement between business, design, and engineering is on a prototype, before any code has been generated. The most expensive place is in production, after the agent has generated five thousand lines and three downstream tickets have been pulled in on top.

This is not new in software engineering. Every shift-left argument since the 1980s has said the same thing. What is new is that AI coding agents have collapsed the cost of generating code so far that the cost of alignment now dominates the total cost of a feature. Pre-AI, generating the wrong code took two weeks. Realigning afterward took one day on top. Generation dominated. Post-AI, generating the wrong code takes two hours. Realigning afterward still takes one day on top. Alignment now dominates. The bottleneck moved, but most orgs have not moved their discipline with it.

When the prototype is the upstream artefact, business, design, and engineering converge on it before the agent runs. The product manager looks at it and says "this is not the workflow I described." The designer looks at it and says "this is not the brand grammar." The engineer looks at it and says "this state cannot exist given the data we have." All three disagreements surface in minutes, on pixels, with no code yet generated. Resolving them is a redraw, not a refactor. The alignment cost is paid in the cheap currency.

Contrast this with the prose-spec-only flow. The spec gets signed off. The agent generates. The first review notices the layout is wrong, the empty state is wrong, the error pattern violates the product's conventions. None of these are spec violations; they are silent-dimension misalignments. Now the alignment conversation happens in front of generated code that already half-works. The PM is reading code. The designer is reading code. The engineer is defending choices the agent made that no human ever decided. Every conversation costs an order of magnitude more than it would have on a prototype, because every change requires regenerating or hand-editing real implementation.

I have started using a phrase for this: alignment is cheap in pixels and expensive in code. The slogan is doing real work. It tells the team where in the pipeline alignment conversations are supposed to happen. It tells the PM that finalizing the prototype is part of their definition of ready, not the designer's. It tells the engineer that signing off on the prototype is the gate where misreads get caught, not the PR review. It tells the agent, by way of the upstream artefact, exactly what it is being constrained to produce.

A second-order dividend is easy to miss. When alignment happens on the prototype, the conversations are about the user. When alignment happens on generated code, the conversations are about the implementation. The first kind compounds: the team builds a shared model of who the user is and what they need. The second kind doesn't. The team accumulates a backlog of disagreements about specific lines of code that the agent will probably regenerate next sprint anyway. The discipline of upstream alignment is also a discipline of upstream attention. Attention spent on the user pays back across every future feature. Attention spent on the agent's implementation choices does not.

The failure mode this discipline prevents: technically correct, unusable code

The canonical pattern is worth walking through in full, because every engineering leader I describe it to recognizes the shape and most have a recent example.

A ticket says: "The user can filter the results list by status." Acceptance criteria: filter is functional, the filter persists across pagination, the empty state shows a message. The AI agent generates a filter component. It picks a dropdown, because dropdowns are the most common filter pattern in the training data. It places the dropdown above the results list, because that is the most common placement. It uses the labels Active, Inactive, and All, because those are the values in the data model. The PR is opened. The acceptance criteria are green. The code review passes: the code is clean, the tests cover the cases listed in the ticket, the empty state is handled. The feature ships behind a flag for an internal pilot.

The internal pilot exposes the misread. The product is used by operations specialists who work eight-hour shifts triaging incoming items. They do not pick a status once and look at a filtered list. They flip between statuses repeatedly as new items come in and old items are resolved. A dropdown forces three clicks per flip and a re-scan of the page. The previous workflow, without the new filter, had been a tab-strip across the top of the page that they could click without breaking their visual scan. The new filter, technically a filter, is operationally a regression.

The conversation that follows is the one everybody in engineering has had. The PM says "I didn't think to specify tab-strip versus dropdown." The designer says "I would have caught this if I had been shown the prototype." The engineer says "the agent built what the spec said." The CTO looks at the ticket, looks at the PR, looks at the user feedback, and asks the question that defines whether the org is going to learn from this or repeat it: where was this supposed to be decided?

The answer the org needs to install is: on the prototype, before the agent ran. The prototype would have shown a tab-strip or a dropdown. The PM and the designer would have looked at it and one of them would have said "operations specialists won't tolerate three clicks per status flip." The decision would have been recorded as pixels. The agent would have been handed the prototype and would have built the tab-strip, because that is what the constraint said. The ticket would still have shipped. The internal pilot would have validated rather than corrected.

This is the failure mode the discipline prevents. Not bugs. Not non-functional code. Technically correct code that satisfies the spec while violating the user's task model. It is the most expensive kind of failure to detect, because every automated check, including the spec the agent followed, confirms the code works. Only contact with a real user reveals the misread. By that point, the cost of correction includes not just the redraw and the regenerate, but also the political cost of telling a stakeholder their AI-generated feature has to be rebuilt because it was never properly constrained.

Names matter here. The pattern is not "the agent made a mistake." The agent did what it was told. The pattern is underconstraint at the upstream artefact. Calling it underconstraint moves the conversation away from blaming the agent or the engineer or the PM, and toward the operating-model layer where the fix actually lives.

What installing the discipline actually looks like

Installing Design-Driven Development is not adopting a new tool. It is rewiring five decisions in the SDLC. Each one is small. Together they shift where alignment happens.

Who builds the prototype. The default assumption is "the designer." This is wrong for most engineering orgs, because designers are scarce and most tickets are not net-new design work. The right default is: whoever owns the ticket builds the prototype, at the fidelity required. For routine tickets, the PM builds a wireframe in a low-effort tool: Figma with a template, a whiteboard sketch, a Penpot mock, sometimes a marked-up screenshot of the existing screen. For genuinely new patterns, the designer is pulled in, because the design system itself is being extended. The rule is not "designers prototype everything." The rule is "every ticket has a prototype before it has code, at the fidelity its novelty demands."

When in the SDLC it lands. The prototype lands before the spec is finalized, not after. This is the inversion most teams resist, because it feels like extra work. It is not. It is the same work, moved one stage earlier, with the spec written on top of the prototype rather than independent of it. The spec then describes business rules and edge cases the prototype cannot encode, and the two artefacts together form the upstream stack the agent reads. Writing the spec before the prototype produces specs that paper over silent dimensions. Writing the prototype before the spec exposes which decisions need to be made.

What fidelity is required. Interaction-true, not pixel-true. The prototype must answer what the agent cannot infer: layout, sequence, state transitions, empty/error/loading behavior, the user's primary path. It does not need to answer brand polish, micro-animation, or final color tokens. A grayscale wireframe that correctly encodes the sequence is a higher-quality constraint than a fully-styled mockup that gets the empty state wrong. The team should be told this explicitly, because the default professional instinct of designers is to polish, and polish at the prototype stage delays the rest of the pipeline without improving the agent's constraint set.

How it is handed to the agent. The agent reads the prototype as the labeled training example for what to build. In practice, this means: screens are exported as annotated images; interaction states are documented as a state diagram or a labelled flow; the spec sits on top of the prototype as the labeling layer (this button does X, this state transitions on Y). Tools to do this well are improving rapidly: agents that can ingest Figma directly, MCP servers that expose design systems, image-aware models that read wireframes natively. The exact tooling matters less than the discipline of including the prototype in the constraint set the agent generates from. A team that pastes a screenshot into the prompt is doing this. A team that says "see the Figma link in the ticket" and trusts the agent to follow it is not.

What review gate confirms it constrained the agent. This is the part most installs miss. The review gate is not "did the PR pass code review." It is a fifteen-minute walkthrough at PR time where the reviewer pulls up the prototype and the generated UI side by side, and asks: does the implementation match the prototype's interaction model, not just its visual layout? Does the empty state behave as the prototype showed? Does the error pattern match? Does the sequence land in the same order? This is a different review than a code review. It can be done by the PM, the designer, or a peer engineer. It takes fifteen minutes. It catches the misreads the code review will miss because the code review is looking at the code, not the user's experience of the code. Without this gate, the prototype is decoration. With it, the prototype becomes load-bearing.

These five rewirings are the discipline. None of them require a new tool. None of them require hiring a head of design ops. All of them require the engineering executive to decide that the prototype is part of the constraint set the agent reads, and to enforce that decision through definition-of-ready and definition-of-done.

What changes in the operating model when you install this

The implication of all of this is that several roles in the delivery org shift one layer upstream, and the engineering executive gains a measurable gate at a point in the pipeline where they did not previously have one.

The designer shifts from downstream-of-PM to upstream-of-engineering. In the old model, the designer received a spec and produced final visuals, often after the engineer had already started. In the new model, the designer's output is the load-bearing artefact the agent generates from. The designer's time has to move earlier in the cycle, and their work has to be evaluated by whether it constrains the agent well, not by whether it ships polished. This is a real role-level redesign. It requires retraining the designer, the PM who routes work to them, and the engineering manager who staffs the team.

The PM owns the prototype's behavioral spec, not the layout. The PM is not the designer. The PM does not pick colors or grid systems. The PM is responsible for the user-facing behavior the prototype must encode: what the user can do, in what order, with what state transitions, with what recovery paths. The PM either drafts this on the prototype themselves or, for novel patterns, sits with the designer until the prototype answers the behavioral questions. This is also a role-level redesign. Most PMs were trained to write prose specs and now have to think in screens and flows.

Engineering's review window moves from "did this match the spec" to "did this match the prototype's interaction model." This is a smaller shift than it sounds, because most engineering reviews already implicitly check this. The difference is that it becomes an explicit gate, not a tacit one. The reviewer is asked the question and answers it. It takes fifteen minutes. It catches the silent-dimension misreads before they reach the user.

The CTO gains a measurable upstream gate. The metric is simple: percentage of tickets that have a prototype attached at definition-of-ready. Baseline this at whatever the team's current number is, which will be a single-digit percentage in most orgs. Move it to 100 percent over a quarter for tickets that touch a UI surface. Then, separately, measure the percentage of PRs that pass the prototype-walkthrough gate without a revision request. This second number is the leading indicator that the discipline is actually installed, not just declared. A team where the first number is 100 percent and the second is 50 percent is doing prototypes as theatre. A team where both numbers are above 90 percent has installed the discipline.

The combined upstream stack that emerges is the one our sibling articles in this series have built toward. The spec, written down, answers what the system does. The prototype, drawn out, answers how it lands. The agent generates against both. The quality gates downstream catch what the agent gets wrong despite the constraint. None of the three artefacts is sufficient on its own. All three together are what a production-grade AI coding pipeline looks like when delivery has actually been redesigned around AI, rather than AI having been bolted onto delivery that was designed for humans.

The engineering executives I talk to who are still in the "the team is using Copilot, but delivery hasn't changed" phase are almost always missing one of the three. Usually it is this one. The spec discipline is the one engineering leaders reach for first, because it looks the most like what they were already doing. The quality-gates discipline is the one they reach for second, because it sits where their existing CI lives. The prototype discipline is the one they postpone, because it implicates roles outside engineering and because the artefact does not look like code. It is also the one with the highest payoff at the point of generation, because it carries the dimensions the spec cannot.

The org structure question the CTO has to answer is not whether to invest in AI tooling. That decision was already made. The question is whether the prototype belongs in the upstream artefact stack the agent reads. If the answer is yes, then the designer's time, the PM's training, the engineering review process, and the definition-of-ready all have to be redesigned around that yes. If the answer is no, then the team will keep shipping technically correct code that users do not use, and the velocity charts will keep saying everything is fine.

The next AI tooling project is not another tool. It is the first load-bearing prototype on every ticket that touches a screen.

Frequently Asked Questions