Matt Dailey, founder and engineer at Ref, recently shared how he uses AI in product design. He said he is "not a designer" and that he hates "AI slop," so he built a "de-slop" process that puts limits on the model instead of letting it drive the whole workflow. In his setup, humans define constraints, remove things, and supply taste. AI is used for broad exploration and execution.
Start with the system, not the button placement
Dailey said product design should not begin with a question like where a button belongs. It should begin with an understanding of the whole system. Drawing on Christopher Alexander's Notes on the Synthesis of Form, he breaks design into three steps:
- List every design constraint
- Explore multiple solutions that satisfy those constraints
- If a constraint needs to be added or removed, go back to step one
Those constraints can include typography, size, user flow, business logic, and the different states a product must support.
In his view, many teams skip the third step. A user says a feature is hard to use, so the team changes the UI right away. Another user raises a different issue, and another button, prompt, or feature gets added. Dailey calls that pattern "Design Whack-a-Mole."
Generative AI amplifies the urge to keep adding
He argues that generative AI makes that habit worse. Engineers can easily ask an agent to "make X more visible" or "add an entry point for action Y." The model can complete each request quickly, but after enough rounds, the product can end up as an interface assembled from many local optimizations. That can leave more users confused, not fewer.
To avoid that, Ref keeps a separate document that tracks small issues and friction points, or "papercuts," across the product. Obvious errors are fixed right away. Smaller issues are not always addressed immediately and may be grouped into the next redesign instead, so the product is not constantly pulled around by fragmented feedback.
Agents tend to overbuild, so humans need to subtract
Dailey said AI agents show a similar pattern in both UI work and code: they overbuild.
In code, an agent may wrap things in an extra try-catch layer or reimplement a utility that already exists. In UI work, it may keep adding explanatory text, dividers, icons, and other visual elements. The result can look better than what an average engineer might draw alone, he said, but that does not make it good product design.
His method is blunt: inspect elements on the screen one by one and ask, "Do I really need this?" If the answer is no, remove it.
Do not iterate with AI directly inside the production product
Another trap he points to is "Prototype Gravity." Once an engineer has an agent generate a first-pass interface directly in an existing codebase, the code is already there, so the next step usually becomes continued editing of that version rather than renewed exploration. The first solution gains an outsized advantage simply because it exists.
Dailey recommends separating design from implementation. He suggests exploring in environments such as Figma, Cursor Design Mode, Claude Design, or HTML prototypes, and asking AI to generate three to four different options at a time. He spoke especially highly of Figma, calling it one of the best tools currently available for fast design iteration.
The point of that workflow is not whether AI can get the answer right on the first try. It is to take advantage of falling generation costs and use AI as an option generator. Instead of asking for the single best answer, ask for enough answers, then let a person decide which one deserves to move forward.
Use a component library to keep the product coherent
At the implementation stage, Dailey stressed the importance of reusable components. If an agent generates a new button, table, or input field from scratch every time, small details can drift even when the function is the same. Over time, the product can start to look like it was assembled by different designers.
Ref addresses that by maintaining a /showcase page. Agents build and test UI components there first, and only after that are they connected to real product logic. Dailey said this helps separate view from logic and keeps the product aligned around the same visual language.
Completion is not the same as a valid design
Dailey also recommends heavy use of preview deploys. A design that looks reasonable in a mockup may not hold up inside a real product. Data length, different states, user behavior, and backend data can all expose problems in an interface that looked clean at first.
Ref even handles frontend and backend pull requests separately. Backend changes are validated mainly through unit tests and integration tests. Frontend changes are checked through preview deployments so people can open and inspect the actual version directly.
His point is simple: even if an agent completes 100% of the task you gave it, that does not mean the design is correct.
"Steal stuff" is part of AI design too
Dailey's advice to engineers on this point is direct: "Steal stuff."
Most UX problems are not new, he said. Rather than asking AI to imagine a solution from scratch, he recommends studying how other products solved the same problem. He has observed that strong designers often begin a project by collecting large numbers of screenshots and reference examples.
In the AI era, those references gain another function: they can be passed straight into the agent as context.
Taste matters more in the AI era
Dailey closed with a point he considers hard to quantify but central to the whole method: taste.
Many product engineers can tell when a design feels off, he said. The harder part is deciding what to change next. Professional designers tend to answer that question more easily because years of experience have given them a large internal library of usable solutions.
There is no shortcut to building that skill, in his view. It comes from repeated attempts, noticing your own reactions, and reflecting on why a given solution worked or failed.
Ref does not have a full-time designer, and Dailey joked that the team uses an "agricultural threshing" method: throw the design into the middle and have everyone hit it with sticks until the group finally thinks it is good enough.