Adapted from Linear's “Design Is More Than Code,” this article examines whether designers should code and argues that focusing only on tools reduces a deeper question: how designers' contributions will evolve under AI. It separates designing the problem from designing the solution and emphasizes defining the right problem before building thoughtfully.
Recent discussion has focused on whether designers should code, whether code is the right medium for design, and whether code reveals design's “truth.” The prevailing view of the source article is that centering the debate only on code and tools is reductive.
Background
The author previously wrote two related pieces—one about design as a search rather than a pipeline, and another about how tools embody opinions that shape what feels reasonable to try. This is the third. He is skeptical of the industry's tendency to present “designing in code” as a universal answer, reduce a complex design process to writing code, and call that progress.
The current debate asks whether designers should code, whether code is the right medium, and whether it can “represent the truth of design.” The author argues that restricting the discussion to tools and code oversimplifies the subject.
The Central Question: How Will Roles Evolve?
The more important question is: How will designers' contribution change under the pressure of AI and new tools?
- Will designers become engineers and be judged by the same standards?
- Will engineers begin holding designers to those standards?
- Will titles such as Head of Engineering and Head of Design remain, or merge into something like Head of Craft?
- Titles themselves do not matter, but these questions reveal what a team actually values and how it believes work should get done.
The practical question is whether pushing designers to design directly in code is a good direction. What will we gain, and what will we lose?
Design Means Different Things
The debate becomes confusing because “design” means different things to different people, depending on:
- The kind of design they practice and how they understand the discipline.
- Their industry and market. Consumer motivations are difficult to predict and often demand rapid experimentation; B2B and enterprise work usually offers more context to design from; some industries demand extreme reliability and clarity.
- Environmental factors such as stakeholders, customers, and company culture.
- The designer's own skills. A visually oriented person may begin with visuals, while a strong coder may introduce code earlier.
- For some people, design simply means putting a button on a screen and moving on.
Software design is a broad field with many tools and methods. Debates framed as “code or no code” often miss the point and instead create division.
The author wants to move the discussion above tools. He does not want tools to dictate design's future, or easier execution to diminish the value of conceptual and divergent thinking. Even engineers who code all day step away from code to draw architecture diagrams, plan systems, and weigh tradeoffs. Code is where software exists, but that does not mean every decision should be made in code.
Part 1: Designing the Problem
The author is not a formally trained designer. He learned through hundreds of projects over twenty years, so he does not claim there is one correct, gatekept way to design. He does believe that design is rarely linear. It moves among levels of abstraction, and while the final output is the goal, spending time on the process improves that output.
His first lesson was to question the problem itself instead of accepting it as a premise. When receiving an assignment, he asks:
- Is this really a problem?
- What happens if we do nothing?
- Who defined this problem?
The most common reason a design project stalls or fails, he found, is that the problem was never made clear. People often disagree about solutions because they are not thinking about the same problem. The eventual solution becomes a compromise among several different problems instead of a clean answer to one central problem. More stakeholders make this worse.
His approach:
- Write down his understanding of the problem and identify all stakeholders.
- When presenting a solution, restate the problem first and watch for objections.
- If anyone disagrees, stop and align on the problem before discussing solutions further.
There will always be stakeholders—colleagues or customers. You need to tell whether feedback means the solution is poor or people's understanding of the problem differs. Sometimes you are solving the wrong problem. The problem is the first part of the equation and the foundation of what you design and build.
The Linear example: The company quickly recognized that customers needed Projects, so “build Projects” went onto the roadmap and everyone agreed. But deeper questions followed: Why do companies organize work into projects? Why not simply complete tasks one by one? What would happen without projects?
Project management is a deep discipline with many approaches. If your vision is a specialized tool for software companies, however, you can narrow the field and ask what those companies truly care about. Put simply, a project is a natural abstraction for managing a company's workflow. It creates accountability, ownership, cross-team coordination, predictability, and visibility.
Studying something so fundamental can seem unnecessary, but understanding a field's history and landscape provides orientation. It reveals which assumptions can be challenged and which conventions are worth retaining. Most importantly, understanding the problem helps determine where to go next and what to optimize or influence. Linear realized that a project might be the most important unit of work: products are made of projects, organizations operate around them, and teams celebrate when they ship. That insight gave the problem a clear direction.
Part 2: Designing the Solution
The author divides solution design into two stages.
1. The Conceptual Stage
This stage finds the overall form a design will take. In an issue tracker, for example, a project could be modeled as:
- A large issue with subtasks.
- A folder or label for issues.
- An independent entity related to issues.
These are concepts that can be explored before anything appears on a screen. The eventual choice depends on your understanding of users and the company, as well as the product vision you want. Each concept exists in a real product and is viable.
Because Linear saw projects as important and fundamentally different from issues, the team made each project an independent entity with its own form. A project should have recognizable form and function, communicating status, decision context, user feedback, priority, schedule, and its relationship to larger plans. Reducing it to a label or a loose collection of issues felt wrong.
The conceptual stage can use prose, pen and paper, a design tool, or code. What matters is giving an idea form, trying different directions, and choosing the one that best serves the problem and product vision. Once you believe in a direction, you can seek broader feedback by building it and testing the concept.
2. The Execution Stage
This is closest to the final result: turning the design concept into something that genuinely works and shaping it into a real form. Code—or working with the material—is essential here. Execution sometimes reveals new information that requires revisiting the problem or concept.
There are different ways to use code at this stage, including sketching with disposable code. This removes some constraints of production code and leaves more room to explore. Although execution may look like the point where design “really” happens, the prior stages have already established context and confidence. You work from that foundation when the material pushes back.
An LLM analogy: Early design work is like constructing the goal, context, and prompt for an agent. Execution is the process of guiding that agent through concrete decisions.
The “time” objection: At this point, someone may ask who has time for all this when a product needs to ship. Why not start building and think along the way? The author argues that this is not about time. The explanation may be long, but the process itself can be fast; you spend only the time the work needs. Without establishing context and goals first, you may iterate in a direction, but it may not be a direction you intentionally chose.
Key Takeaways
This returns to the concern at the beginning: the industry is broadly impatient. If “build the design directly in production” becomes the default, the cultural and organizational forces that encourage teams to consider problems, concepts, and intent will begin to disappear. We start devaluing the “why” behind design in favor of output.
The author's concern is not code or tools themselves, but the decline of thoughtfulness—and with it, the decline of distinctive, carefully designed products. The real question is: As new tools and technologies emerge, how do we keep the habit of thinking deeply alive?
For the author, design has never been about what a button looks like, what it does, or which medium you use. Design is about finding the right problem, the right intent, and the right vision. The feature you design and build today should be a considered step toward that vision.
These notes organize and summarize the source rather than translate it word for word. For the complete original, including images, see:
Discussion
Support the author