Ref founder Matt Dailey publishes a seven-step guide to avoiding AI design slop

Why it matters

AI coding tools make the first plausible interface dangerously cheap. Dailey's method turns design into a reviewed planning problem, reinforcing Ref's larger bet that teams must settle key decisions before agents generate the code.

Matt Dailey (@reactiverobot), founder and CEO of Ref, has laid out a seven-part workflow for using AI to design software without accepting the generic interfaces agents produce by default.

In an essay on Ref's site, Dailey argues that AI works best as a fast producer of alternatives. The engineer still has to define the problem, reject unnecessary elements and decide how the pieces fit together. His method calls for establishing constraints, generating several versions in a design tool, building from reusable components and checking the result against real data in a preview deployment.

Dailey arrived at that process after seven years at Figma, where he worked in infrastructure, built its Growth Engineering function and later joined its Applied AI research group. According to his public career profile, he grew the growth engineering group from one engineer to 24 engineers and three managers or leads. Earlier roles included search and indexing work at Palantir, software engineering at Amazon and a short-lived mobile marketplace called Selbi.

That history gives Dailey an unusual position in the debate over AI-generated design. He is an engineer who spent years inside a defining design-software business, then left to build tools for engineering teams working with coding agents. He is also direct about the limitation: he does not consider himself a designer.

The first draft is the trap

Dailey starts with constraints rather than prompts. He draws the framework from Christopher Alexander's "Notes on the Synthesis of Form": list the requirements, consider multiple solutions and revisit the requirements when a proposed solution exposes a missing constraint.

That final step is where product teams often lose control of the interface. A user struggles with one action, somebody asks an agent to make it more prominent, and the local fix adds another label, line, icon or button. Ref records smaller "papercuts and annoyances" in a shared document instead of immediately patching every complaint into the product.

"The temptation is to spot-fix but that road leads to ruin," Dailey writes.

AI makes those spot fixes cheap enough to become constant. It also tends to solve requests by adding material. Dailey sees the same behavior in generated code, where agents wrap existing logic, add defensive branches and recreate utilities. In an interface, that instinct produces explanatory copy and controls that each seem defensible in isolation while making the complete screen harder to understand.

His correction is deliberately manual: inspect every element and ask whether it needs to exist. The agent supplies output. The human removes the litter.

Keep prototype gravity out of the codebase

Dailey's most consequential recommendation is to avoid designing the first version inside the production codebase. Once an agent has implemented a plausible screen around existing components and application logic, refining that version feels cheaper than exploring a different structure. Dailey calls this "prototype gravity."

His answer is to generate alternatives in a tool built for visual iteration. He still favors Figma, while also naming Cursor Design Mode, Claude Design and HTML prototypes as workable options. The tool matters less than maintaining enough distance from production code to discard the first answer.

That recommendation carries extra weight from a former Figma engineering leader. Dailey is applying the speed of generative systems inside a conventional design loop: explore broadly while changes are cheap, choose a direction and only then accept implementation costs.

Ref also maintains a separate /showcase page where agents can build and adjust interface components before connecting them to the main application. Reusable components give later agent-generated screens a fixed visual vocabulary instead of inviting a fresh interpretation of every button and input.

The final check happens in preview deployments using real data. Dailey says Ref separates frontend and backend pull requests for larger features: automated tests can verify backend behavior, while frontend changes receive human inspection through a shareable preview. An agent can follow the specification precisely and still produce something that fails when actual content, edge cases and workflows replace placeholder data.

Ref is selling the same decision boundary

The essay also explains the product thesis behind Ref. Ref Plans gives engineers a shared document for researching, discussing and approving an implementation before agents write the code. Plans can include diagrams, images, prototypes, comments and approvals, then dispatch tasks to systems including Cursor, Claude Code, Codex and Devin.

Ref's bet is that faster code generation moves the bottleneck into planning and review. When agents can produce several implementations in parallel, teams need a durable record of what they agreed to build and why. Reviewing those choices after thousands of lines have been generated leaves engineers sorting through consequences instead of shaping the approach.

Dailey's design workflow applies that same boundary to interfaces. Constraints and alternatives belong in the plan. Agents can handle production once the consequential choices have been made. Ref's separate Context MCP service follows a related idea by letting coding agents search public and private documentation instead of relying entirely on whatever happened to fit inside a chat window.

Ref began as a solo effort. Dailey wrote when Suvir Copparam joined that he had spent roughly 1.5 years building alone. Copparam had been Dailey's second hire at Figma, and Dailey described bringing him into Ref as an early culture-setting decision.

The design essay shows what that culture is meant to protect as Ref grows. Speed is useful when it produces options. It becomes expensive when every generated option slips into the product and has to be reconciled later.

Dailey closes the workflow with the least automatable instruction: develop taste. Engineers can study existing products, collect screenshots and feed those references to an agent. The final judgment still comes from deciding which examples are worth copying, which generated elements should survive and when an apparently polished screen remains wrong.

That is a practical division of labor for a small engineering team. AI generates the surface area. People decide what deserves to ship.