Designing Against the Model

Overview

Context

Our product is conversational and LLM-powered, so the experience is non-deterministic by nature. Static mocks can’t represent the model’s latency, variance, or failure modes, and those are the design. Meanwhile the industry handed every designer a coding agent, with two plausible endings: collapsed handoffs, or inconsistency at machine speed.

Decision

I adopted the AI-native workflow the way I’d ship a feature: as a hypothesis, instrumented and tested. I design verification systems for intelligence analysts, people trained to disbelieve AI until it earns trust, and my own workflow got the same treatment, question by question.

Impact

37 → 6Days, median request-to-production cycle: what took a month now ships in under a week.

3×Codebase growth over the period, and the craft survived: design-system health rose across the codebase.

4Teams beyond mine where design multiplied: the design system now guides anyone's coding agent.

The Challenge

A Mock Promises What It Can’t Verify

For an AI product, the model’s behavior is the experience. A polished Figma flow shows one happy path with placeholder text, and promises an interaction feel it cannot verify: what thirty seconds of generation feels like, what happens when the same question returns different answers, what real data volume does to a layout.

The Setup

Everyone Ships More Now

Over nineteen weeks I merged 115 PRs from my first ever at Primer. That is the least interesting fact in this story, because everyone with a coding agent ships more now. The questions worth testing are whether the output holds up, whether it keeps its craft, whether it still needs a designer.

Question 1

Does Faster Mean Better?

The first PR was three lines on purpose: probe review, CI, and merge before trusting the pipeline with anything consequential. Trust expanded only as evidence did.

0 of 115 shipped changes rolled back

1. Every session ended in verification, not vibes

   A full UX audit, then a thorough code review before pushing, in addition to my own review.

2. The process itself got evaluated on a cadence

   Every few weeks I measured the output (review outcomes, defect patterns) and the process (where sessions stalled, what the agent got wrong), and changed the workflow when the numbers disagreed with it.

3. I only kept what I could evaluate myself

   Backend code was beyond my ability to review to standard, so rather than letting one agent grade another agent’s homework, I handed that work to engineers, and used the boundary to learn: 1:1s and guild sessions on standard engineering practice, and shared skills built with FE and BE engineers so the next non-engineer starts further ahead.

Question 2

Does AI Dull the Craft?

Left unguided, it does. Every agent reaches for the same borrowed conventions, which is why AI-built products converge on the same look: the model’s defaults become the design. The fix wasn’t reviewing harder after the fact. It was moving the design system into the context the agent reads before it writes a line.

01Initial prompting result

02Design refinement

→

The design system applied on its own: on-brand tokens, but generic and uneven. The floor, not the finish.

Rules and guidelines, moved into code and iterated on a cadence: consistent, legible, and unmistakably ours.

4 of 5 health markers improved while the codebase tripled

1. Encoded the judgment layer, not just the component library

   An agent-consumable design system of tokens and components is table stakes now; the real leverage was encoding our design principles and user personas as skills the agent reasons from before it writes a line. Rules still enforce the mechanical standards on every edit and audits verify each change, but principles and personas are what keep the output ours instead of generic.

2. Let the agent own the standard 80% so design owns the 20%

   The agent applies correct components, tokens, spacing, and established patterns automatically, so design attention goes to the 20% that should be novel.

3. Measured the skills and let the measurement correct them

   In-session design iteration dropped 35%, but only structurally forced rules changed agent behavior. Polite prose was ignored, so the skills got stricter, not longer.

4. Spent the velocity surplus on the backlog no team ever funds

   Half of everything I shipped was refinement of existing production UI, the death-by-a-thousand-cuts debt.

Question 3

Does the Agent Replace the Designer?

The opposite happened: demand for design rose. The cleanest evidence is a null result: everyone has the same agent, yet cycle times and output per engineer stayed flat across the team. The tool without design judgment lifted nobody. The agent doesn’t replace the designer; it makes the designer the differential.

79% of all prompting effort went to novel design work

Routine fix6 prompts · 3 hours

One instruction — the element, the property, the value.

↓

Novel feature23+ prompts · days to weeks

Nine in ten sessions opened with a plan or a mock before any code.

↓

1. Plan
2. Mocked directions
3. Decision
4. Refinement ↻

1. Straightforward tasks vanish into a prompt; novel work still needs the full design process

   The session logs show the split. A routine fix is a single design instruction naming the element, the property, and the value (median 6 prompts total, most of that the shipping pipeline), live in about 3 hours. Novel work ran a median of 23 prompts, 9 in 10 of those sessions opening with a plan or a mock before any code, and the deepest explorations ran for weeks. Novel design absorbed 79% of all prompting effort. The agent cleared the routine; it never once skipped the design thinking.

2. Collaboration stopped being a relay

   Work starts wherever momentum is: engineers and PMs begin building and hand to design for refinement, or design pushes code that engineers review. The one rule that survived is alignment up front, on ownership and intent, so a non-linear process doesn’t become overlapping work.

3. Giving the judgment away extended design’s reach and grew the job

   The skills live in a shared repo, packaged by an engineer as a plugin, extended by rules PMs file in; a PM’s first reaction: “I want it. When can I get it?” Routine UI now comes out right no matter who starts it, and the team’s taste sharpened with it: engineers argue their own PRs in design vocabulary. My role moved up the stack, authoring and tuning the system, with the attention once spent on pixel corrections (down from 73% to 47% of my sessions) now going to the judgment no file can hold, formed in front of live behavior and real users.

What’s Next

Still Learning, Still Testing

This workflow was never a destination. Everything here is younger than a year, so the posture is a student’s: keep learning the engineering practices that move my boundaries, keep measuring the output and the process, keep changing whatever the evidence disagrees with.

The next iterations happen with the team. The skills now run in other people’s agents, so tuning them means tuning together: validating that the correction burden drops for other adopters, folding colleagues’ rules back into the shared system, and refining the non-linear ways of working as more disciplines build.

Two claims remain untested: whether the shipped features change end-user behavior, and whether any of this moves revenue. Claims without tests are just marketing, including mine.

Metrics from version-control history, issue tracking, session transcripts, and monthly codebase snapshots across the period.