A designer I follow recently described how they stopped using Figma. Not because they dislike it—they used it daily for years. But they realized they were spending hours pixel-pushing a picture of a product, only to hand it off and watch it come back slightly different. Every time.
So they switched. Now they open Cursor or Claude Code, describe what they want to build—not what it should look like, but what it should do, how it should feel, who it's for—and shape the product in real-time as it comes to life. No mockup. No handoff. No translation layer.
They call it Direct Design.
And they're right about the diagnosis: the handoff between design and code was always the bottleneck. For thirty years, a designer made a picture of a solution, wrote a spec explaining what they meant, handed it to an engineer who interpreted it, built something close but not quite right, and then everyone went back and forth until it shipped at 80% of the original vision.
Direct Design skips all of that. The person with the vision is the person building the thing. The feedback loop collapses from weeks to minutes. The product gets better because you're experiencing it, not guessing about it.
This is real. This is happening. And it's incomplete.
The Design Handoff Was Never the Only Handoff
Direct Design solves a real problem: the translation loss between a designer's intent and an engineer's implementation. But there's an older, harder handoff sitting upstream of it—one that no amount of designing-in-code can fix.
It's the handoff between user reality and product decisions.
Before anyone designs anything—in Figma or in code—someone has to decide what to build. That decision should come from somewhere: user research, support tickets, behavioral data, friction signals. In practice, it usually comes from a conversation, an intuition, or a feature request that sounded compelling in a meeting.
Direct Design compresses the path from decision to shipped product. But it doesn't improve the decision itself. A designer working directly in code can shape a beautiful, polished experience in hours. They can also shape the wrong experience in hours—just faster and with higher fidelity than before.
Speed to production amplifies whatever you feed it. Feed it clear intent derived from real user friction, and you ship something that matters. Feed it intuition, and you ship a polished guess.
The Vision Problem
The essay that popularized Direct Design makes a revealing claim: the designer needs to "hold the entire product in your head—the user's problem, the interaction model, the edge cases, the business logic, the feel."
That's a staggering amount of context for one person to hold. And it raises the question nobody's asking: where does all that context come from?
In the old model, it came from a team. Researchers surfaced friction. PMs synthesized it into specs. Designers shaped solutions. Engineers stress-tested edge cases. The process was slow and lossy, but it was also a distributed thinking system—each role adding a different kind of rigor.
Direct Design collapses those roles into one. Which means the rigor that used to be distributed now needs to be concentrated. One person holding the user's problem, the interaction model, the edge cases, the business logic, the feel—all in their head, all at once.
That works when the product is small. When you're the founder and the designer and the only person who's talked to users. But products grow. Teams grow. The context that fits in one head today won't fit in one head next quarter.
We've seen this pattern before. A solo builder ships fast because they hold all the context. A second person joins and can't figure out why anything was built the way it was. By week six, the team is reverse-engineering their own product. The context was never externalized—it lived in the vibe.
Direct Design without externalized intent is vibe coding with better taste.
Not Vibe Coding—But Close
The Direct Design essay is careful to distinguish itself from vibe coding. And the distinction is fair: vibe coding is building without thinking. Direct Design is building with deep product thinking, executed directly.
But the structural risk is identical.
Vibe coding fails at the team boundary because prompts are ephemeral—typed once, consumed once, discarded. Direct Design risks the same failure because decisions are ephemeral. Why did the onboarding flow end up with three steps instead of five? What user problem justified the checkout redesign? Which edge cases were considered and which were deferred?
When one person holds all context and makes all decisions in real-time, those decisions don't produce artifacts. They produce code. And code tells you what was built, never why.
The discipline the essay describes—rigorous product thinking, holding complexity, making every decision yourself—is real. The question is whether that discipline produces anything persistent beyond the shipped feature. Because the next person who touches that code, or the agent that needs to extend it, starts from zero.
What Direct Design Actually Needs
Direct Design gets one thing profoundly right: remove the translation layer between intent and reality. Don't make a picture of the thing—make the thing.
But there's a translation layer above design that still exists: the one between user friction and product intent. And that layer needs infrastructure, not just taste.
Friction needs to be captured, not intuited. The best Direct Designers aren't guessing what to build—they have deep user empathy from research, support conversations, and behavioral data. But that knowledge lives in their heads. The infrastructure question is: can anyone else access it? Can an agent? Can the next designer who joins the team?
Decisions need to be structured. "I shaped the onboarding flow and it felt right" isn't reviewable, versionable, or debuggable. An intent spec with objectives, constraints, and success criteria is. The spec doesn't slow down Direct Design—it gives it a foundation that persists after the designer moves on.
Success needs to be defined before building. Direct Design's feedback loop is fast—you experience the product as you build it. But "does this feel right?" is a different question than "did the friction decrease?" The first is taste. The second is verification against intent. You need both.
Taste Needs a Compiler—and a Source
The essay's most powerful line is this: "Taste now has a compiler." Product thinkers can execute their vision directly, without a translation layer.
It's true. And it raises the stakes dramatically.
When execution was slow, bad decisions were filtered by the team. The handoff process was lossy, but it was also a checkpoint—engineers pushed back, PMs questioned scope, designers debated alternatives. The friction of the process was also its safeguard.
When execution is instant, the safeguard disappears. The distance between "I think we should..." and "it's in production" collapses to minutes. There's no room for the conversation that used to catch the wrong assumptions, the missing edge cases, the feature nobody asked for.
Taste is necessary. But taste operating at the speed of AI execution, without structured intent underneath it, is a high-fidelity version of the same problem that vibe coding creates: fast output, fragile foundations.
The compiler is real. The question is what you're compiling from.
If it's one person's intuition, you get beautiful products that can't explain themselves. If it's structured intent—derived from real friction, specified with constraints and success criteria, persistent enough for teams and agents to build against—you get products that are both beautiful and right.
We spent decades trying to teach engineers to think like product people. Turns out it was easier to give product people the ability to ship.
That's the Direct Design insight. It's real, and it matters.
But the logical next step isn't just "designers should learn to code" or "use Cursor instead of Figma." It's this: if the people with product vision can now execute directly, the highest-leverage investment is making sure that vision is grounded in reality, structured enough to persist, and precise enough for anyone—human or agent—to build against.
Direct Design removes the last handoff. The Intent Layer makes sure what you're building is worth the speed.
Don't Just Write Code. Define Intent.
Turn user friction into structured Intent Specs that drive your AI agents.
Get Started for Free