# Output isn't design DevFeed: [Output isn't design]() Original publisher: [Read original article]() Published: 2026-04-17T14:23:00Z Content type: opinion Language: en Sources: [Linear]() Topics: [User interface design](), [AI-enhanced product development](), [AI in frontend development](), [human centric design]() Tags: [ai](), [design](), [designing](), [product]() ## AI overview The article argues that design is the work of understanding a problem and fitting a form to its context, not simply producing interfaces or code. AI tools can quickly generate plausible outputs and help with prototyping, but they do not replace the judgment, exploration, and time needed to resolve user needs, technical constraints, and other requirements. ## Source excerpt Design keeps being misunderstood in our industry. New tools keep promising to generate interfaces faster, move words to product instantly, or collapse design directly into code. The assumption behind them is clear: that design is the act of producing. That is the misunderstanding. The hard part of design is rarely generating the form. It is understanding the problem well enough to know what and how something should exist at all. There is use and place for these tools, but tools are not the design process. Christopher Alexander came closer than anyone to naming this clearly. In Notes on the Synthesis of Form, he describes design as the search for a good fit between a form and its context. Context, in his sense, is not a background condition. It is the full set of forces that make a problem what it is: human needs, technical constraints, conflicting requirements, habits, edge cases, and relationships that are easy to miss until you spend time with them. Bad design appears where those forces remain unresolved. Good design appears where those misfits have been worked through carefully. That distinction matters even more now because of how AI encourages you to work. They generate plausible outputs quickly, but they do not necessarily help you understand the underlying problem. In practice, they often do the opposite. They generate outputs, instead first trying to shape the problem or the form to the real conditions of the problem. You can already see the result in products that look polished, ambitious, and impressive at first glance, but begin to unravel the moment you actually use them. They feel brittle, poorly integrated, and full of decisions that were never fully worked through. The form is there. The fit is not. That is also why I still prefer designing visually over prompting. Working visually keeps me close to the problem and is slow enough gives me time to think while I work. Moving things around, testing relationships, and refining structure is not separate fr