The Design vs Code Debate Is Pointing at the Wrong Problem

Towards the end of last year, around November or December, an interesting debate surfaced online around design, code, and AI.

On one side was Ryo Lu, Head of Design at Cursor . On the other was Karri Saarinen, CEO of Linear.

At a glance, it looked like a familiar tools debate. But underneath it was a much deeper conversation about how we build products and what design really means in an AI-driven world.

Ryo's position was direct: design now lives in code. Tools, especially design tools, have shaped how designers work for years, and that hasn't always been helpful. Handoffs break meaning. Translation gets lost. Designing closer to code, or directly in it, removes that gap and leads to better outcomes.

Karri didn't entirely disagree. But he pushed back on something important. Design isn't just execution. It's exploration. It's context. It's the work that happens long before anything is implemented. The issue isn't the tools themselves, it's understanding when a tool should be used and what phase of the work you're actually in.

And honestly, I think both of them are right.

The Part We Often Skip: Exploration vs. Implementation

A lot of confusion in this debate comes from the fact that we treat product development as one continuous motion, when in reality, it has very distinct phases.

There's an exploration phase. This is where research happens. Where you're discovering the problem, defining it, comparing contexts, and trying to understand what actually needs to be solved. It's messy, non-linear, and intentionally open-ended.

Then there's the implementation phase. This is where decisions are refined, feedback is applied, and ideas are translated into something real. Speed, accuracy, and scalability matter much more here.

Problems start when we try to solve exploration problems with implementation tools or expect implementation tools to do the thinking for us.

Why Context Matters in This Debate

Ryo's perspective makes complete sense when you look at where he's coming from.

Cursor is deeply engineering-led. It's built for developers. The team designs and builds in the same environment they ship from. Designing closer to code gives them faster feedback loops and tighter control over what actually goes out.

But not every product or team works like that.

For many teams, especially in early or ambiguous problem spaces, exploring ideas directly in code is restrictive. Code introduces constraints very early, sometimes before the problem is even fully understood. And those constraints can limit how far you're able to explore.

That's the tension Karri was pointing to.

Design isn't just about making something work. It's about arriving at the right solution before you even think about how it's built.

Tools Aren't Competing. They're Optimized for Different Phases

If you step back and look at the ecosystem, this becomes clearer.

Cursor is heavily optimized around implementation and reducing friction between idea and code. Linear is focused on clarity, context, and decision-making before work begins. Figma lives primarily in the space of visual exploration and collaborative thinking.

None of these tools are wrong. They're just solving different problems.

The mistake is assuming one tool or one AI workflow should replace every other part of the process.

The Real Issue Was Never “Handoff”

For years, we framed the problem as “handoff.”

But handoff was never supposed to mean designers disappear after delivery.

The real issue was lost context.

Good product work requires designers to stay involved through implementation, clarifying intent, reviewing decisions, and collaborating when constraints show up. Developers shouldn't have to guess. Designers shouldn't design in isolation.

AI is now helping reduce some of that translation gap. Design-to-code is getting better. Prototyping is faster. Implementation is easier.

That's progress.

But speed doesn't automatically mean correctness.

AI Is Great at Execution, Not Judgment

Most AI tools today are optimized around execution. They help you build faster, prototype quicker, and ship sooner.

But they don't help you decide what should exist in the first place.

You can very easily be fast at building the wrong thing.

AI doesn't understand user nuance, business trade-offs, stakeholder alignment, legal constraints, or product-market fit. It doesn't negotiate priorities or reframe ambiguous problems.

That work still belongs to humans.

And a large part of that responsibility sits with product managers and designers.

Design Was Never Just the Visual

Somewhere along the way, we reduced design to UI.

UI matters. But design has always been about problem-solving.

That's why service designers exist. That's why UX extends beyond screens. That's why teams, workflows, and systems can be designed.

User experience isn't owned by designers alone, but designers are often the ones pushing teams to slow down, ask better questions, and make decisions with intention.

AI doesn't change that.

Where Designers Should Pay Attention Now

If your value as a designer is purely output, replacement becomes a real risk.

But design value has never been about output alone.

It's about contribution: how you frame problems, synthesize information, communicate trade-offs, align stakeholders, and help teams solve the right problems.

AI makes execution cheaper and faster. That means judgment, context, and decision-making matter even more.

So What Does This All Mean?

AI is here to stay. Workflows will change. Collaboration will evolve.

But the fundamentals of design won't disappear.

We'll use different tools. We'll move faster. Some parts of the job will get easier.

What won't change is the need to understand context, solve meaningful problems, and design with intention.

That's where design actually lives.

Not in tools. Not in code alone. But in the thinking that happens before anything is built.