From prompt to product: Why the design step matters

Anyone working with AI-assisted coding assistants today knows the promise: Type a description, and seconds later a working interface appears. Tools like Cursor, Claude Code, or GitHub Copilot deliver increasingly impressive results. Yet what is convincing in an isolated demo quickly reveals a structural gap in real-world projects.

Professional applications do not emerge in a vacuum. They operate within defined color scales, typographic systems, component libraries, and corporate design guidelines. A UI generated straight from a prompt knows nothing about any of this. Technically correct, visually off, and the rework still lands with the team.

The better question, then, is not how AI can generate code faster. It is how AI can support the design process before any code exists at all.

Design Tokens as a Starting Point

The core problem with AI-assisted UI generation is a lack of context. The tool does not know what the existing system looks like.

A practical first step is to bring the design system into a form that AI tools can process. Design Tokens have proven effective here. They describe visual properties such as colors, spacing, and typography in a structured, code-like format, which makes them much closer to development artifacts than to traditional Figma files.

In practice, this step can be accelerated with an LLM. Existing styles, often inconsistently documented, are translated into consistent token structures. The result is not a finished design but a vocabulary, a clearly defined design space within which AI can then deliver consistent results.

Without this step, AI-generated interfaces tend to be generic. With it, consistency becomes possible even in automated generation. That’s enough about abstract concepts, though. The decisive question is how well current tools already support this approach, and where they reach their limits.

What Today's Tools Can Do

Based on these considerations, I evaluated three tools that currently offer AI-assisted design generation: Google Stitch, Figma with its integrated AI features, and Claude Design from Anthropic.

Google Stitch

Of the tools tested, Stitch offers the lowest barrier to entry. A single prompt is enough, and the tool generates a structurally solid first draft. URLs can be provided as visual references, which makes it easier to orient designs around existing products. Figure 1 shows this workflow: on the left, the AI assistant explains its design decisions; in the center, Stitch displays the extracted design system with typography and color palette; on the right, the resulting blog layout in codecentric style. The brand color, the type hierarchy, the grid - all of this Stitch derives from the provided URL. How deep this integration actually goes becomes clear when looking at the technical foundation.

Fig. 1: Stitch canvas with AI chat (left), extracted design system (center), and generated blog layout (right)

Stitch builds on DESIGN.md, a Markdown-based format that describes colors, typography, spacing, and component patterns in a structure readable by AI agents. The file can be extracted from a URL, among other sources, and is usable outside of Stitch as an open-source specification. In practice, however, the integration remains more limited than it first appears: DESIGN.md describes rules and tokens, but Stitch does not produce reusable components from them in the sense of a classic design system. The generated elements remain standalone layers. DESIGN.md thus conceptually takes on the role of design tokens, but stays at the level of rules and visual orientation, without producing real, reusable components. This works well for quick exploration and early prototypes, but not as a permanent building block in a component-based design process.

Figma with AI Features

Figma has the advantage of being the environment where designs are actually maintained and developed further. Figma currently offers two AI-assisted entry points: First Draft generates initial layouts directly on the design canvas from descriptions. It uses Figma's own wireframing and design libraries as a foundation and is suited primarily for quick visual exploration. Figma Make is a separate AI app builder that generates functional, clickable prototypes. The results are not static designs but runnable applications with interactions and navigation. Make prototypes can subsequently be embedded into Figma Design and edited further there.

Full integration, however, requires more preparation than with Stitch. In my test, the workflow looked like this: first, generate a design system in Figma Make, transfer the result into Figma Design and prepare it there as a library, and then use that design as a reference for new projects in Figma Make. Figure 2 shows the result of this process: three separate Figma files, a blog design, a design system, and a structured token collection that need to be created and maintained before AI-assisted generation can deliver consistent results.

Fig. 2: Figma project overview with the three files that had to be prepared for an AI-assisted blog design workflow

Figma's second AI entry point, First Draft, works directly on the design canvas and is suited for quick layout exploration. An important limitation: AI-assisted changes can only be applied to elements that were initially generated by the AI. Once an element has been manually edited, it is no longer part of the AI workflow.

Unlike Stitch, Figma cannot query web addresses as a reference. Anyone who wants to use an existing product as a visual template is limited to manual screenshots or previously created design tokens.

Both tools therefore share the same structural blind spot: they generate interfaces, but the results are standalone layers with no connection to real components of the existing system.

Claude Design: A Different Approach

While this article was being written, Anthropic released Claude Design. The tool addresses precisely the gap that Stitch and Figma leave open.

Instead of treating the design system as an afterthought import option, Claude Design makes it the foundation of every project. During onboarding, the tool reads existing information, such as a codebase or available design files, and derives a design system from it, including colors, typography, and component patterns. Figure 3 shows this step: Claude Design analyzed the codecentric website and extracted a complete design system from it, including the brand fonts in use. The chat on the left shows how the tool independently detects and corrects font problems. Where gaps exist in the system, such as missing fonts or incomplete color definitions, Claude Design actively flags them and offers to close them. Every subsequent project can automatically draw on this system.

Fig. 3: Design system onboarding in Claude Design. The tool extracted colors, typography, and layout patterns from the codecentric website and made them available as a cross-project system

This is the decisive conceptual difference to Stitch and Figma: Claude Design does not need to know what design tokens are, because it pulls the information directly from the code. CSS variables, Tailwind configurations, existing component definitions, all of this the tool reads and implicitly assembles into a coherent system. Design tokens as a manual input step become unnecessary, but the concept behind them, namely that visual properties need to be structured and named, remains the prerequisite. Anyone who brings a well-structured codebase benefits immediately. However, you can’t expect to get a consistent system out of thin air when none exists. However, you can’t expect to get a consistent system out of thin air when none exists.

The workflow toward the desired application (in our example, the codecentric blog) then runs iteratively. The foundation is the previously created design system. Claude automatically draws on the extracted colors, fonts, and components. Figure 4 makes this process visible: on the left, Claude works through a structured task list, from project setup through the HTML build to final polish. On the right, the blog design "Aus dem Maschinenraum" emerges in codecentric style. The Tweaks panel allows targeted adjustments to brand mode, card layout, and highlight behavior, without having to regenerate the entire draft.

Fig. 4: Claude Design canvas with iterative workflow (left: task list and chat) and generated blog layout (right). The Tweaks panel allows targeted adjustments to layout and branding

Another difference is the integrated handoff mechanism: once a design is ready for implementation, it can be passed directly to Claude Code as a bundle. The bundle is optimized for Claude Code and accordingly provides strong support for the transition from design to code. For teams that do not work exclusively within the Anthropic ecosystem, there are export options to Canva, as PDF, PPTX, or standalone HTML.

Limitations: Claude Design is still in research preview. In my tests inline comments occasionally disappeared, and larger codebases caused noticeable lags. Moreover, the system integration the tool promises depends heavily on how well the existing codebase and design files are structured. Anyone without a well-maintained design system will get only limited consistency here too. The tool does not solve the underlying problem on its own; it assumes the system already exists.

The Transition from Design to Code

Regardless of the tool, the transition from design to code remains a critical moment.

In practice, this transition works better when the design carries structural information, not just visual. Design tokens, clearly named components, and defined variables help AI tools understand the intent behind a design, not just its appearance.

Equally important is the handoff process, which should be designed explicitly. A prompt like "implement this design" without further information leads to inconsistent results. Referencing the design system, naming specific components, and communicating technical constraints produces significantly better output.

AI-generated frontend code should be treated as a starting point, not a finished product. Review, particularly for accessibility, performance, and consistency with existing code, remains necessary.

Conclusion

The key insight is structural rather than technical: AI in frontend development realizes its potential not through unconstrained generation but through guided exploration within defined systems.

Design tokens are a central concept here, even if they do not always appear explicitly as such. In some systems they have to be provided manually, because the tools have no access to the existing system. In Claude Design they are implicitly embedded in the codebase that the tool reads during onboarding. The format changes; the underlying idea stays the same: visual properties need to be structured and named for AI to deliver consistent results.

The current tool landscape is in motion. Stitch for quick, system-independent exploration; Figma for the collaborative design process, once its AI integration matures further; Claude Design as the conceptually most interesting approach, though one that requires the existing system to already be in a structured state. No single tool solves all requirements today. The relevant question is no longer "Can AI generate an interface?" but "Can AI generate an interface that fits my system?" Anyone looking to answer that question for their own project should not start with the application, but with the design system.