Claude Design Can Touch the Canvas, but Not the Product

I opened Claude Design expecting it to feel like the visual half of Claude Code. That expectation may have been unfair because Anthropic did not present it as a complete visual development environment, but it was also difficult not to make the comparison. Claude Code can enter a repository, inspect the real application, change files, run tests and leave behind a diff. Claude Design can understand many of the same materials, but the moment the work needs to become real, the authority moves somewhere else.

This is less absolute than it was when Claude Design first appeared. It can now import a design system from a codebase, use existing components, accept direct canvas edits and remain connected to Claude Code through /design-sync. Claude Code can connect back through MCP, bring a design into the repository and export code as a prototype. Anthropic has shortened the distance between the two environments considerably.

But its own documentation still describes the transition from design to software as a handoff to Claude Code. I keep returning to that word because it is doing more work than it seems. The tools can share context. They can exchange artifacts. They may even remain synchronized. Yet one side still proposes what the product might become, while the other side receives the power to alter what the product is.

The old division is still inside the new tool

For years, digital design followed roughly the same structure even as its tools improved. A designer made a representation of the product in Photoshop, Sketch or Figma. Someone else translated that representation into the application. Components, design tokens and developer handoff made the translation more precise, but they did not remove it. Design happened upstream. Production happened downstream. The source of truth was always slightly somewhere else.

The designer proposes. The engineer translates. The product changes somewhere else.

AI seemed capable of dissolving this division because one system could theoretically understand both representations. It could inspect the repository, open the running product, recognise the design system, make a visual change, modify the relevant component and test the result. The visual and operational versions would no longer need to drift apart because they would be different views of the same change.

Claude Design approaches this possibility and then stops at the most consequential moment. It can reconstruct the system as context. It can make a prototype that looks like the system. It can pass that prototype towards a coding agent. But when a visual decision acquires consequences, it leaves the design environment and becomes code.

At first this seems backwards because design appears to be the less dangerous activity. Claude Code can execute commands and rewrite a repository, while Claude Design moves cards and buttons around a canvas. Why should the apparently safer activity receive fewer powers?

The answer is that moving a button is not only moving a button.

The rectangle is not the decision

A button may belong to a shared component used across sixty pages. Changing its position may affect mobile layouts, keyboard navigation, reading order, analytics events, loading states, empty states and visual regression tests. The button is visible, but the decision extends into the system around it. A designer moving the rectangle may intend a local adjustment while the codebase interprets it as a global change to a token or component.

This complexity is a real reason not to let a visual tool silently rewrite production software. It is not a good reason to keep the visual tool disconnected from production. Separation does not remove the consequences. It only hides them until the handoff, when someone discovers that the clean canvas was missing the state nobody documented, the breakpoint that behaves strangely or the component nobody wants to touch.

The design then looks correct because it has been evaluated inside a simplified representation. The product remains difficult because the actual constraints were waiting elsewhere. This is one reason digital design so easily becomes decorative. The tool gives the designer control over surfaces while the product's behaviour, permissions, data and exceptions remain outside the frame.

The first output is not the work

The public reaction to Claude Design makes this distinction unusually visible. Some people are impressed by how quickly it can produce a competent dashboard, presentation or interface. Others describe something that looks strongest in the first generation and weaker after the fifth revision. One Hacker News commenter described the output as competent but not particularly unique. Several replies correctly pointed out that most software does not need to be visually unprecedented. A familiar internal tool may be better than an expressive one.

That defence is fair, but it shifts the question from whether Claude Design can make a good screen to whether it can support design as an ongoing activity. A Reddit commenter defined AI slop as the default obtained with minimal effort being the same default everyone else receives. Another user said they had already specified the architecture, typography and button styles, but still had to keep telling Claude not to colour everything teal. The teal is funny, but the more important criticism was that the system could generate a strong one-shot concept and then begin falling apart as the user added things or tried to revise them.

A professional designer described feeding Claude Design a real startup design system and high-fidelity product states. According to the comment, Claude retained basic typography and colour choices but ignored much of the component system. The resulting work was difficult to repair manually because the structure had become a large hard-coded HTML artifact. It was useful for getting quick stakeholder approval before the designer rebuilt the result properly in Figma.

That workflow is almost too perfect as a criticism. AI was supposed to remove the translation between the prototype and the product. Instead, it produced the prototype faster, helped secure approval and then required the real design to be rebuilt elsewhere. The mockup became cheap without becoming operational.

The usage complaints point in the same direction. One person compared Claude Design to a gym membership that allowed three repetitions per day. The exact limits will change, but the metaphor exposes the product assumption. If the valuable unit is one complete generated artifact, a few expensive outputs may be acceptable. If design is a sequence of small corrections, comparisons, reversals and discoveries, then restricting iteration attacks the activity itself.

The first output is the demo. Iteration under constraint is the work.

Design needs controlled consequences

Claude Code is useful not because code is harmless, but because software development has spent decades building infrastructure around dangerous changes. An agent can work on a branch. Its edits can appear in a diff. Tests can fail. A reviewer can inspect the result. A commit can be reverted. Permissions can limit the filesystem and commands available to it. The environment does not pretend consequences do not exist. It makes them visible and reversible.

Design tools developed a different kind of safety. Frames, layers, components, variants and comments make appearance editable and collaborative, but they do not usually show the operational consequences of a visual decision. The canvas is controlled because it is a representation. The repository is controlled because it has branches, diffs, tests and review. Claude Design currently inherits the first model even though its real potential depends on the second.

The stronger version would not need unrestricted write access. It could make every visual change inside a temporary branch or worktree. Moving an element would show the updated screen and the code diff together. Claude could explain whether it changed one local style, a shared component or a design token. Responsive screenshots, accessibility checks and interaction tests could run automatically. The designer could accept one part, reject another and open a pull request without leaving the visual environment.

This would make design less clean, which may be exactly what makes it more real. The designer would encounter the old permission rule, the awkward component, the analytics requirement and the test that fails when the layout changes. These are often dismissed as implementation details, but they are parts of the product. A design that cannot absorb them is not more strategic. It is incomplete.

There is a familiar habit in the software industry of calling design strategically important while separating it from power. Designers can create journeys, systems, prototypes and visions, but the source of truth remains somewhere else. They can explain what the product should communicate, but they cannot always alter the machinery that determines what the product does.

Claude Design reproduces this hierarchy inside Anthropic's own product line. Design can import the real system, imitate it and remain synchronized with it. Code still receives the authority to act. Maybe this is only a temporary product boundary. Claude Design is still in beta, and Anthropic already has most of the necessary pieces across Claude Design and Claude Code.

But the current boundary reveals an assumption worth noticing. The strange part is not that a design agent cannot freely rewrite production software. It should not. The strange part is that the moment a visual decision gains operational consequences, it stops being treated as design.

AI has made the handoff faster without removing the hierarchy beneath it. Claude Design can touch the canvas. Claude Code still gets to touch the product.

Connected reading

• AI Can Make the Screenshot
• The Prototype Has Become Too Cheap to Trust
• The Design System Under the Design System
• The Coding Assistant Is Becoming the Development System
• The Interface Is Now Part of the Answer

AI authorship note

This revision began with Kris Haamer asking for a new illustrated draft of the original essay. AI supported the editorial rewrite, development of the four visual arguments, SVG implementation and publishing workflow. Kris chose the central argument, the title and the decision to preserve the original essay as version 1 while making the illustrated version current.