Design is More Than Code—But Where Do You Design the Problem?

You can't merge a pull request without a passing build. You can't deploy without the pipeline. But you can ship a feature nobody can explain six weeks later—and nothing in your toolchain will stop you.

Linear's Karri Saarinen calls this over-indexing on execution: the industry has collapsed the nuanced work of designing the problem into the tactical act of designing the solution. We ship faster than ever while understanding less than ever about what we're shipping.

He's right. And it's worse than he describes—because it isn't a choice teams make. It's a choice the toolchain makes for them. Every tool in the modern stack accelerates execution. Nothing enforces the thinking that should precede it.

The Asymmetry

Look at how much infrastructure exists for the execution side of product development:

• Linear structures work into projects, cycles, and priorities.
• GitHub versions every change, enforces review gates, and tracks history.
• Vercel deploys on every merge. CI/CD pipelines catch regressions automatically.
• Cursor and Claude Code generate working code from natural language in seconds.

The rigor here isn't cultural—it's structural. The gates aren't optional, so the discipline isn't either. Infrastructure forces it, even on teams that would never maintain it voluntarily.

Now look at the intent side—the work of figuring out what to build and why:

• A Google Doc, half-finished, last edited three weeks ago.
• A FigJam board covered in sticky notes from a brainstorm nobody summarized.
• A Slack thread where the PM, designer, and tech lead reached a conclusion that was never recorded anywhere.
• A Jira ticket that says "Improve checkout UX."

There's no structure here. No versioning. No review gate. No equivalent of "you can't merge without a PR" for "you can't build without a defined problem." The entire front end of product development runs on culture, goodwill, and the hope that someone in the room is paying attention.

When execution was slow, this asymmetry was tolerable. Defining the problem might take a week, but building the solution took months. There was time for the messy thinking to settle into shared understanding through conversations, standups, and code reviews.

AI has removed that buffer. When execution is instant, there's no settling period. The gap between "someone had an idea" and "the code is in production" can be measured in hours. And every hour of that gap that should have been spent on problem definition gets compressed into a prompt.

What Gets Lost

Karri identifies the cost clearly: teams start optimizing solutions before verifying problems. But the downstream effects are more specific than that, and worth naming.

You lose the "why." When a feature ships without a structured problem definition, nobody can explain why it exists six weeks later. The rationale lived in the conversation that preceded the prompt. The conversation wasn't recorded. The prompt was discarded. The code is the only artifact—and code tells you what was built, never why.

You lose the edge cases. Problem definition is where edge cases surface. When you skip it, edge cases get discovered in production—by users, not by the team. An AI agent asked to "add a checkout flow" will build the happy path beautifully. It won't add rate limiting, handle expired sessions, or account for the payment provider's webhook failures—because those constraints weren't in the prompt, and they only emerge when you design the problem before designing the solution.

You lose alignment—and the ability to verify. A PM, a designer, and an engineer each carry a different mental model of "improve checkout UX." Without an artifact that forces them to reconcile, each optimizes for their own reading: the designer ships a beautiful flow, the engineer ships performance, the PM wanted conversion. All three ship something. None ship the same thing. And because nobody specified what success looked like, nobody can say afterward whether it worked—so the team finds a metric trending the right way and declares victory while the friction that started the whole thing sits untouched.

Culture Alone Won't Fix This

The instinct is to solve this culturally. Write better docs. Hold more design reviews. Encourage teams to think before they build. Karri gestures this way—keep "consideration" alive as a value.

I agree with the value. I'm skeptical of the mechanism.

Culture is what you practice when nobody's enforcing it.

And cultural disciplines erode under pressure. When the CEO wants a feature by Friday, when a competitor just shipped something similar, when the AI can have a working prototype in twenty minutes—"let's spend two days defining the problem" feels like a luxury.

This is exactly the dynamic that played out with code quality. For years, the industry said "write tests" and "do code review" and relied on culture to make it happen. It didn't work—not because people disagreed, but because deadlines always won. What worked was infrastructure: CI/CD pipelines that refuse to merge untested code. The discipline became structural, and suddenly everyone had test coverage.

Problem definition needs the same structural enforcement. Not because teams don't value it, but because without infrastructure, it's the first thing that gets cut when execution is fast and deadlines are real.

What Infrastructure for Intent Looks Like

If the execution side of development has Linear, GitHub, and Vercel, what does the intent side need?

It starts with evidence, not opinion. The input to a product decision shouldn't be "what does the PM think we should build?" It should be "what friction are users actually hitting?" Support tickets, research transcripts, behavioral data—this is the raw material. Intent that traces back to evidence is judgment. Intent that traces back to a hunch is a confident guess. The spec should be anchored to the friction that motivated it, not to someone's intuition.

A structured artifact, not a contract. Problem definition today lives in prose—Google Docs, Notion pages, Confluence wikis. Prose is flexible, which makes it great for exploring and terrible for enforcing: you can write a "spec" with no constraints, no edge cases, no definition of success, and nothing flags it. But the fix isn't to swing the other way and compile intent into a rigid contract. Intent is judgment under evidence—it has to stay legible to a human reviewer and precise enough for an agent to build against. Structured, not frozen.

Versioning and history. Code is versioned. Designs are versioned. Intent is... overwritten in a Google Doc with no changelog. Revisit a decision three months later and you can git blame the code but never the why. Intent needs the same temporal discipline that code has: versions, diffs, and a record of how understanding evolved.

A review gate. The most powerful piece of infrastructure in modern development is the pull request. Not because it catches bugs—code review is mediocre at that—but because it forces a pause. Someone has to look at the change before it ships. Intent needs an equivalent gate: no handoff to execution until the decision has been reviewed against explicit criteria. Not a rubber stamp. A structural checkpoint.

The Machine for Designing the Problem

Karri is right that design is more than code. But framing it as a mindset problem underestimates how structural the issue is.

The industry didn't get disciplined about execution because thought leaders wrote essays about the value of testing. It got disciplined because the toolchain made rigor the default. CI/CD didn't ask teams to value quality—it made quality a gate that couldn't be bypassed.

Intent needs the same thing. Not more essays about the importance of thinking. Infrastructure that makes intent grounded in evidence, structured, versioned, and reviewable—a first-class artifact in the workflow, not a Slack thread someone hopes to remember.

Linear gave us the machine for building the solution. We're building the machine for designing the problem. That's what an intent layer is for.