Design is a search

Well, I’m glad this generated debate, which is good for the industry, and everyone can see where they stand. I just want to clarify my thoughts here in a more coherent way:

Coding tools are fine, useful, and they definitely help you make the design a reality. A lot of the commentary I’ve seen is about making design quality happen through better implementation, which is great but not really about designing.

I tend to think about design as a search, not a production pipeline. You start with a messy problem. Early on, you do not know the answer. This is why I never fully buy the idea that design is about output. I agree that design is useless without shipping, but the process of designing is not.

The design process, and the suffering part of that process, are valuable.

Constraints
Constraints are not the enemy, but they can arrive early.

Constraints exist in reality: time, budgets, codebases, teams, customers. The mistake is letting those constraints define the space before you have found a direction worth committing to. Then they start shaping your imagination. Early design is about direction. You are trying to find a form that resolves the problem in a way that feels obvious once you see it. That phase benefits from speed, looseness, and tools that let you change your mind without paying a tax for it. Later, constraints become essential. You want reality to push back. You want the medium to answer your questions. That is where prototyping, code, edge cases, performance, and all the sharp corners start improving the work. That is where the craft shows up, and where design-code tools can be useful.

Architecture analog
Architecture is full of constraints, more constraints than software will ever have: materials, gravity, weather, budgets, labor, code, zoning, politics.

Yet it still often starts with sketches. Not because sketching is pure or nostalgic, but because it is a way to separate form from construction long enough to find something worth constructing. A sketch is not a smaller version of the final building. It is a different mode of thinking. It gives you permission to be wrong in interesting ways, and to paint broad strokes. You don’t design houses by iterating from one corner to a full house piece by piece.

I talked to a talented architect who was designing the most modern and sculptural house in a town known for traditional cabins. The ordinance demanded the local style. Starting from the ordinance would have produced something predictable and safe. Instead, the architect started from a new canvas and created a design that respected the landscape, involved the neighbors, built support, and when the plan reached the council, the community backed it. The rule bent. The architecture fit the landscape and the community, even if it didn’t technically fit the ordinance.

If you let constraints define the space too early, you do not just get a worse outcome. You lose outcomes that never get discovered.

Tools
Tools have opinions.

They make certain actions easy and others annoying. Over time, they teach you what is “reasonable” to attempt. Some tools are great for exploration. They help you stay expressive and uncommitted. Others are great for construction. They reward structure, consistency, and correctness. Both are useful. The mistake is collapsing the entire act of design into a medium that is optimized for commitment.

I do not think designers should avoid code. Software is the material. Being ignorant of it leads to fantasy. But there is a difference between understanding the medium and letting the medium control you.

Code is a medium of commitment. Designing inside an existing system means inheriting its past decisions. You gravitate toward what is already supported. You make smaller bets because the cost of a big swing becomes obvious immediately. The result is often work that is elegant inside the current system, but less likely to change the system.

Unification
I understand the desire to unify tools and workflows. Handoffs are lossy. Quality decays in the seams between notes, designs, prototypes, roadmaps, and code. The dream of a coherent universe is compelling. A world where ideas move from chaos to clarity without translation loss. Where designers can build and builders can design.

I see the desire, and it can be good. But unification has a shadow side. It can turn into standardization. If everything is built from the same primitives, you get the same patterns repeated across teams. Tools raise the floor, but they can also lower the ceiling if they quietly define what is worth attempting. If the easiest path is always the most conventional path, convention becomes the product.

Our industry is somehow overly allergic to fragmentation. I’m not sure what it is really about. I actually think it’s a very human thing to have some level of fragmentation: different tools, spaces, environments for different purposes or mindsets.

I might be proven wrong, but I don’t believe in great unification, and I think often it might be driven by a corporate need to dominate many industries, instead of letting many flowers bloom and letting each flower be very good in its own way.

What I actually believe
I am not interested in preserving a romantic separation between “design” and “engineering.” Some designers should code at times. Some engineers have great taste and should design. Some projects thrive when one person can take an idea all the way through.

The thing I want to preserve is a phase of thinking, and not pretend it is not worth our time. Early design needs freedom. Later design needs reality. When those phases get collapsed, you can still ship and fast. But you might also trade the search for the shortest path.

So my belief is simple.

Use whatever tools you want, but be deliberate about what mode you are in. Protect exploration from premature constraint. Invite constraints when you are ready to learn from them. Use code as feedback, not as a cage.

New technology makes it faster to build, but that’s not really what design is about.