Claude Design Can Touch the Canvas, but Not the Product

Claude Design seems much less useful than it could be for a simple reason. It can touch the canvas, but it cannot quite touch the product.

This statement already needs a qualification because Claude Design has changed since Anthropic introduced it in April. It is no longer merely a sealed generator that receives a prompt and exports a visual artifact. Claude Design can import a design system from a codebase, use existing components, accept direct edits on the canvas and remain connected to Claude Code through /design-sync. Claude Code can connect to Claude Design through MCP, bring designs into a repository and export code back as a live prototype.

The two products are not completely separate anymore.

But Anthropic still describes the important transition in revealing language. When a design is ready to become software, it is handed off to Claude Code.

That sentence contains the old software industry inside a new AI product.

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

For years, this was the normal structure of digital design. A designer made a representation of the product in Photoshop, Sketch or Figma. A developer then recreated that representation in the actual application. The tools improved, components became more systematic and handoff became more detailed, but the basic division remained. Design happened upstream. Production happened downstream. One side was allowed to describe what should exist. The other side was allowed to make it exist.

AI seemed capable of dissolving this boundary. The same system could inspect the repository, understand the design system, observe the running application, propose a change, implement it, test it and revise it when the result did not work. There was no obvious technical reason for the visual and operational versions of the product to remain different objects.

Claude Design comes unusually close to this possibility and then stops.

It can read the codebase as context. It can use components extracted from the codebase. It can produce an interactive prototype that resembles the product. It can even stay synchronized with a coding agent. Yet the authority to modify the real system remains associated with a product called Claude Code.

This is strange because design appears, at first, to be the lower-risk activity. Claude Code reads repositories, edits files, executes commands, runs tests and creates pull requests. Claude Design rearranges interfaces and presentations. If Anthropic is willing to let an agent operate on software, why is the visual design environment treated as the place where consequences should stop?

The obvious answer is that moving a button is not actually a small change.

The button may belong to a component used on sixty pages. Moving it may change the mobile layout, the focus order, the accessible name, the loading state, the analytics event, the empty state or the position of something else that only appears when a user's name is unusually long. A visual decision is attached to code, data, behaviour and organisational rules that are invisible when the object is treated as a rectangle.

But this is an argument for connecting design to the product, not for separating it.

Keeping design inside a cleaner environment does not remove the consequences. It postpones them. The prototype can look correct while the production system continues to contain all the old components, undocumented states, responsive exceptions and awkward dependencies that made the design problem difficult in the first place.

The online reaction to Claude Design is full of this tension. Some users are genuinely impressed by how quickly it can turn a specification into a convincing interface or presentation. Others describe a competent but generic result, a system that looks more capable in the first generation than it feels after the fifth revision.

One Hacker News commenter wrote that Claude Design could produce a competent interface with little effort, but little that felt truly unique. Several people replied that this was exactly what they wanted. Most software does not need to be strange or unprecedented. An internal hospital tool may benefit from being familiar, obvious and visually boring.

That defence is reasonable, but it also shifts the question. Claude Design may be good at raising the floor of interface production. That is not the same as making the work of design more powerful.

Another commenter argued that the remaining difficulty is fitting the interface around domain knowledge, unusual users, existing conventions and real use cases. The generated surface may be competent while the product reasoning remains unresolved. This is where the distinction between making a plausible screen and designing a product becomes important.

A Reddit discussion produced a sharper definition of AI slop: the default obtained with minimal effort is the same default everyone else receives. One user said they had already defined the architecture, button styles, fonts and other design rules, yet still had to repeatedly tell Claude to stop colouring everything teal. Another described the system as strong at producing one-shot concepts for familiar patterns such as dashboards and chat interfaces, but said it fell apart when the user started adding and revising things.

That last criticism matters more than the colour.

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

A professional designer using Claude Design for a startup described feeding it a full Figma system and high-fidelity product states. According to the comment, Claude retained basic typography and colours but ignored much of the component system. The generated work was difficult to repair manually because it was represented as a rigid, monolithic HTML structure. The designer found it useful for quickly obtaining stakeholder approval before rebuilding the work properly in Figma.

This is almost a perfect reconstruction of the workflow AI was supposed to remove.

Generate something convincing. Get approval. Rebuild the real thing somewhere else.

The tool has accelerated the mockup while preserving the handoff.

There is another contradiction in the usage model. Design is iterative by definition, but early users complained that a few rounds could consume a large portion of their available usage. One person compared it to buying a gym membership and being allowed only three repetitions per day. Anthropic has since moved Claude Design into the shared Claude usage pool, but its own documentation still warns that complex projects and many iterations consume more usage.

This is not only a pricing complaint. It reveals an assumption about what the valuable unit of design is. If the expensive moment is generating the first complete artifact, then the product is organised around output. If the valuable work happens through dozens of small corrections, comparisons, reversals and discoveries, then the product has to support sustained manipulation.

Claude Code became useful partly because software development already has infrastructure for controlled consequences. A coding agent can work in a branch. Its changes can be shown as a diff. Tests can fail. A pull request can be reviewed. A commit can be reverted. Permissions can limit which files and commands are available.

Design tools developed a different kind of control. They control appearance through frames, layers, components, variants and comments. They are excellent at preserving an editable representation of the intended interface. They are much weaker at showing what changing that representation does to the operating system of the product.

Perhaps Claude Design is not handcuffed because design is more dangerous than code. Perhaps it is handcuffed because design has not been given the same operational infrastructure.

The stronger version of Claude Design would not need unrestricted write access. It could operate on a temporary branch or worktree. A user could move an element on the canvas and see both the visual result and the code diff. Claude could explain whether it changed a local style, a shared component or a design token. It could run responsive screenshots, accessibility checks and interaction tests. The designer could accept one change, reject another and open a pull request without changing modes.

The visual interface would become a way of operating on the product rather than describing a hypothetical version of it.

This would also force design to become less clean.

The designer would encounter the component nobody wants to touch, the state that was never documented, the old permission rule, the analytics requirement and the test that fails when the layout changes. These may look like implementation details from the canvas, but they are part of what the product is. A design that ignores them is not more conceptual. It is simply incomplete.

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

Claude Design reproduces this hierarchy inside Anthropic's product line. Design can import the real system, imitate it and send work towards it. Code receives the authority to act.

Maybe this is only a temporary organisational boundary. Claude Design began as an Anthropic Labs research preview and is now in beta. The current connection with Claude Code already makes the original separation less severe. Anthropic may eventually combine the canvas, repository, browser, tests and branch into a single environment.

But the current product still reveals something about how the industry understands design.

The strange part is not that Claude Design cannot freely rewrite production software. It should not. The strange part is that the moment a visual decision gains operational consequences, it leaves the design product and becomes code.

AI has made the handoff faster without removing the assumption underneath 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 essay began with Kris Haamer noticing that Claude Design felt much less useful because it ran separately from the product and lacked direct authority to change it. AI supported the current product research, review of public reactions, drafting, editing and implementation. Kris identified the central contradiction, rejected an unclear first title, selected the title Claude Design Can Touch the Canvas, but Not the Product, and approved the article for publication.