Faster prototypes miss the point: The case for spec-driven design

Software development is going through a structural shift. Agents can turn clear intent into working, tested code, so the bottleneck is no longer writing code but articulating intent, and the spec is the artifact that captures it.

Engineering already has names for this: spec-driven development and the agentic software development lifecycle (ASDLC). The framing is a software factory, where agents are the logistics layer and context is the supply chain feeding each station just in time.

An assembly line of agents does not sound like a home for design craft, and many designers assume there is no seat for them in it. The framing does put most of design's visible output on the side of the work agents now do cheaply.

But design will not earn a better position by default. So far we have mostly met development's new speed by working the way we did five years ago, with AI tools that generate mockups and vibe-code prototypes faster than ever. Faster prototypes miss the point.

The risk is less that designers get replaced and more that they get routed around. When development compresses a build from weeks to days while design still needs weeks to form an opinion, teams stop waiting for the opinion. Concretely, that means the spec gets written without design, and the spec is what gets built.

Design does not get back in by producing more. The work that moves a product forward is judgement applied to accumulated knowledge: which problem is worth solving, what users have already told us, what was tried before and why it fell short. Assembling that knowledge has always been the slow, expensive part, because it lives scattered across tools, decks and people's heads. AI's larger gift to design is the thing it does best: managing knowledge.

Prototyping faster is the least of it. AI's larger gift to design is the thing it does best: managing knowledge

Read that way, the factory offers design a more impactful position than the old process ever did. This piece is about how design integrates with it: as an active author of the spec, on a knowledge base that compounds. I call this merge spec-driven design.

The two leaks that hold design back

The usual design process leaks time and value in two places, and this is the main reason good design is still slow.

Knowledge flows into design too slowly. Picture a designer starting a new feature. The brief is two sentences in a ticket. The reasoning behind it lives in a strategy deck from last spring, a Slack thread, and the head of a product owner booked until Thursday. Related user research exists, somewhere. A previous team tried something similar and dropped it, and nobody wrote down why. So the first weeks go to archaeology.

Sort that coordination work into two piles. One is retrieval dressed up as work: assembling scattered context by hand, re-explaining decisions to whoever missed the meeting, asking experts for facts that could be looked up. This pile exists only because the organisation's knowledge is not queryable. The other is co-creation, the heart of design practice: shaping flows and interfaces through explorative iteration with other people, debating real tradeoffs, generating ideas in dialogue, making calls on strategy or ethics, talking to users. That pile is the job.

Try the same split on your own last month and see which pile is bigger. Whatever the first pile costs, it costs that only because of how the organisation's knowledge is stored, and that is a fixable property rather than a law of nature.

Intent flows out of design too lossily. In most teams the journey to production looks like this: design in Figma, a walkthrough meeting, a developer's interpretation, a review round, corrections, another interpretation, another review. Intent leaks at every step, and everyone involved knows it. The designer pays in review rounds, pixel-policing, and shipped features that miss the point of the design. The artifacts that serve this transfer make the waste visible: walkthrough decks, redline annotations, handover tickets, each written for a single meeting, read once, and dead within a sprint.

Engineering sees the same failure from its side. ASDLC names lossy handoffs as a central defect of traditional development, with insights compressed into decks and tickets that reach an agent as unstructured blobs. It also names the design half of the problem the Figma trap: overreliance on mockups to carry the whole specification. A mockup shows the happy path while hiding the edge cases, error states and data consistency rules where production bugs live. That makes it a suggestion rather than a specification, and screens alone are not a handover.

Both leaks now have names in software research. Margaret-Anne Storey calls them cognitive debt and intent debt. Cognitive debt is the erosion of a team's shared understanding of its own product. Intent debt is the absence of externalised rationale, where decisions get made but the why is never written down where anyone, human or agent, could read it later.

That describes design's situation exactly. Designers pour enormous time into artifacts to align the team and convey intent, yet those artifacts are rarely durable. The understanding they carried evaporates, and the next design starts the whole process over.

Designers pour enormous time into artifacts for alignment and intent, yet those artifacts are rarely durable.

Design remains too slow for agentic teams if the knowledge it depends on doesn't accumulate where agents can reach it, and if its intent doesn't survive the trip from insight to production. The solution is two connected parts.

The Product Knowledge Base (the KB) is the team's shared memory: what the product is for, what has been decided, what we know about users, all of it queryable. The feature spec is the core intent artifact: living documentation inside the KB for each feature, stating what to build, why, and how to verify it. Design draws on the KB and feeds back what it learns, and carries its intent into development through the spec.

The compounding knowledge base

To answer the first leak (slow knowledge retrieval), a team builds a Product Knowledge Base alongside its codebase: the knowledge the team runs on, stored so that agents can fetch what each task needs on demand.

In my experience six components earn their place as core parts of a product KB from a design point of view. The agent instructions file is the front door, telling agents where everything lives and what to read before a task. The product vision is the direction each decision is weighed against, so features cohere into one product instead of each drifting off on its own local logic. Decision logs record what was chosen and why, so calls are not silently reversed or re-argued. Insights collect what the team has learned, from any source: user findings above all, but analytics, support patterns and market reading too, each one reusable so a lesson gets learned once instead of rediscovered. Product-level standards, from the design system to accessibility, are contracts agents build to. Each feature spec carries its own intent and the acceptance criteria that verify it.

The inventory is not the interesting part. A wiki like Confluence could hold the same documents. What differs is how knowledge gets reached: a wiki is read when someone remembers it exists, while a KB is queried by an agent at the moment a decision needs it. Instruction files and skills tell agents what to consult before a piece of work and what to update after it, so retrieval stops depending on anyone remembering.

For design, the component that benefits the most is research. User findings enter the KB as atomic insights: single findings, tagged and reusable, each linked back to the source that made it true so a finding never loses its context. They accumulate from two directions, research projects and feature work alike. The idea is Daniel Pidcock's atomic research, and spec-driven design gives it a real chance to scale. Connecting scattered findings into generalisable insight is exactly what agents are good at. And once user insight lives in the repository, at the centre of the team's shared memory, user-centricity becomes a default rather than an argument a designer has to win each time.

Put user insight where every agent and teammate will read it, and user-centricity stops being something a designer has to keep arguing for.

In its simplest form all of this is a set of plain text files, kept in the product's own repository beside the code, that humans and agents both read and edit. Markdown, versioned with git.

That is the core idea of spec-driven development: the knowledge lives where the code lives, so it updates in the same commits. The version history then records who wrote each entry and when, at no extra cost.

Spec-driven design turns ambiguity into buildable intent

To answer the second leak (lossy intent transfer), we work on features through a single living feature spec throughout the entire design process. This way, intent reaches development as something an agent can read and check rather than a walkthrough someone has to interpret.

Design's purpose is to make sure the team builds the right thing before engineering builds the thing right. Spec-driven development is usually told from engineering's side, as if the spec arrived ready at planning, leaving the human a thought leader "deciding what matters". But deciding what matters takes generative research with real people, and knowing whether the solution works takes testing with them.

So in reality the spec does not arrive ready. Engineering practice treats an ambiguous spec as a defect. For design, the open questions are the spec while a feature is in discovery and prototyping, and the design process is what turns them into something an agent can implement reliably. Here is how that happens, across five kinds of design work.

Engineering calls an ambiguous spec a defect. For design the open questions are the spec.

Discovery is where the KB's user truth gets built, and everything downstream inherits its quality. The designer spends real time with real users, plans the right studies, and has the findings written up so the whole team can draw on them. This work deposits into the KB as atomic insights rather than into any single spec.

Problem definition turns insight and context into a rich brief. The context that used to take weeks to assemble is now a query: the goal behind the feature, decisions and learnings from earlier work, the technical constraints, and the insights about how people handle the problem today. The spec is born here, carrying the problem being solved, what success looks like, the initial requirements and the open questions with owners.

Craft is the iterative work that turns requirements into design decisions, and prototyping is how those decisions earn their place. Each prototype answers a question the spec has already posed: an unresolved flow, a contested edge case, two directions with no obvious winner. What lands in the spec is the chosen flows and edge cases, plus the directions tried and rejected and why, so nobody re-explores a dead end next year. Whatever the work happens in, a Figma file or a prototype built straight in code, the spec links to it as the canonical source while keeping the decisions and reasoning written out.

Evaluation splits in two, and only one half needs a human. The design review rounds that used to hunt for wrong spacing, missing states and off-system components now run as an agent evaluation against the standards defined as contracts in the KB, and design-system conformance can be settled deterministically, because token and component use is checkable in code. Human reviewers stop spending their attention on contrast ratios. The designer handles meaning: running usability tests, reading what the results say, and making the calls that follow. Findings land in the spec beside the decisions they tested.

Handover stops being a series of meetings and becomes a property of the spec. There is nothing to walk anyone through, because by the time development picks the feature up the document already carries what is needed to build it as intended, and the designer's work here is bringing it to that standard. That does not mean developers meet the feature for the first time in the repository: a spec answers intent debt, and the shared understanding that answers cognitive debt gets built during the work rather than in a meeting at the end.

Intent arrives intact. When intent reaches development as a spec with criteria an agent can check against the running feature, the fix rounds that used to bounce between designer and developer have much less to bounce about.

What the team learns keeps paying. The familiar complaint in user research is that nobody reads the research report. With atomic insights right inside the repo, research keeps giving. An insight from a study run last year turns up in the brief for a feature nobody had thought of yet, so research paid for once keeps working, and it does that whether or not the person who ran it is in the room.

Design becomes the input the factory cannot generate for itself. If design's value was producing screens, agents are a threat, because screens are what they are now cheap at. If it is knowing what users need and judging what is worth building, agents amplify it, because the scarce input in an agentic team is high-quality intent, and that has to come from someone who has spent real time with real users.

My early tests building simple knowledge bases and spec-based handovers in client projects are showing promising gains in both speed and quality, along with stronger collaboration with developers.

My suggestion to any designer is to start small and local: a KB on your own computer, and one spec for the next feature you pick up. If you can, propose building it inside your team’s repo, so the spec you build can be taken into use directly by developers. It takes repository access and a basic understanding of git to move around safely, both learnable with an agent alongside. Explore and iterate what to include in the design spec and judge for yourself what it does to your delivery and to your team collaboration.