[Claude Design] Design became code in 6 minutes—What is happening with Claude Design × Claude Code
What the number "6 minutes" signifies
The team at Datadog says, "The design review cycle that used to take a week has been compressed into a single conversation." A representative from Brilliant says, "What took 20 prompts with a competitor's tool was completed in 2 prompts." The team at an unnamed IT asset management tool has documented a case where "a full dashboard, tracking, and reporting system was completed in a single session from the single request of 'I want asset management'."
When you line up these numbers and think about them again, you have to be convinced that something is happening. It's not just that "design has become faster with AI"—it's that the 'translation' that existed between design and implementation has structurally disappeared.
The true nature of a handoff bundle—this is not about passing files
The feature that passes what you created in Claude Design to Claude Code is called a "handoff."
However, if the word "handoff" gives you the image of "passing files," that is incorrect. Clearing up this misunderstanding is the first step to understanding the essence of Claude Design × Claude Code.
The problem with traditional design-to-implementation handoffs
Think back to traditional design-to-implementation handoffs. A designer creates a UI in Figma and passes it to an engineer. What happens at this point?
A Figma file is sent. The engineer opens it and checks the specs. "Is this padding 24px?" "What is this color code?" "What about this hover state?"—a vast amount of information is compressed into visual data. The engineer performs the task of "deciphering" it.
What the designer intended, the context they considered, and the reasons why they chose this layout—in many cases, these are not inside the file. They are in the designer's head.
And when implementation begins, a back-and-forth of confirmations occurs. "What was I supposed to do for this button's hover state?" "Have you thought about how this looks during an error?" "What happens to this mobile view?"—even if you prepare a specification document, unexpected cases always arise.
This is the true nature of translation costs.
The loss of information that occurs when converting visual information into linguistic information. The gap in interpretation that occurs when converting a designer's intent into an implementer's understanding. And the time spent on the "back-and-forth of confirmations" required to resolve that.
If you have ever worked at a startup, you should know the weight of this cost. In a team with five designers and five engineers, a design review for a single feature taking a week—that was the norm.
The technical reality of a handoff bundle
Claude Design's handoff bundle changes this structure from the ground up.
What is inside the bundle is not JPEGs or PDFs. Component definitions, design tokens (values for color, spacing, and typography), copy (text content), interaction annotations, and design system specifications—these are packaged together with the conversation context from the design phase.
Specifically, it means this: if you decide while talking with Claude Design that "this button's hover state should be cyan with a 0.2-second fade transition," that decision is included in the bundle. The design context of "why cyan" and "why 0.2 seconds" is also included as conversation logs.
When Claude Code receives that bundle, it doesn't need to have the question, "What about the hover state?" because the answer is already included.
And there is a most important point.Claude Design, the Producer, and Claude Code, the Consumer, are from the same model family.
What does this mean?
It means that the model that creates the design and the model that writes the code are "speaking the same language." In terms of human language, it is not a case of a Japanese-native designer handing work over to an English-native implementer, but rather a handover between two parties who share the same language. No translation is necessary. The "designer's intent" becomes the "implementer's input" exactly as it is.
Information is not lost. Intent does not disappear. Translation costs do not occur.
"Elimination of translation costs"—I used this phrase in my previous article. Having actually used it this time, the meaning has become concrete. Costs were not "reduced"; they became structurally "unnecessary."
I actually tried it out—From a single prompt to a working UI
I understood the theory. So, what happens in practice? I will write down the experience of trying it myself in order.
Step 1: Design with Claude Design
"I want to create an LP for this series"—That is where I started.
The first thing to do is to load the codebase and design files. From there, Claude Design automatically builds the team's design system. It extracts the countless decisions accumulated within the code—the colors used, font sizes, component roundness settings, and spacing rhythms—as explicit knowledge.
When you actually do it, you have discoveries like, "So that's how our design was set up." It is the moment when the implicit design decisions we have built up without realizing it are visualized.
"This team consistently uses #3B82F6 for the primary color, and the button roundness is standardized to 8px," Claude explains the design system it read from the code. It is an experience of realizing, "The design system for that service was actually inside our own codebase."
Next, I ask it to "provide three directions." For the same requirements, three different visual approaches are lined up. I choose one and convey in an inline comment, "Try this typography with that layout." We refine it through conversation.
The experience here is closer to "talking to a designer" than to the feeling of "operating a design tool." Instead of dragging and placing objects in Figma, instructions are understood through language like, "Make this main copy larger and left-aligned."
One direction is chosen and further polished through conversation. "I want this CTA button to draw more attention," "The information density in this header area is too high"—I make corrections in natural language. Claude interprets that intent and updates the design.
The time it took until the design was finalized was 20 to 30 minutes in this case. The "quality of decision-making" definitely improved—rather than thinking from scratch, it is faster and more accurate to make a judgment when three options are in front of you.
Step 2: Handoff
Once I judge it to be "complete," I execute the handoff.
When you are conscious of the bundle being passed at this time, it feels like you are passing the entire design conversation rather than just passing files. What Claude Code receives is not a finished image, but a structure that includes 'why it is this way'.
Taking the aforementioned example of 'hover state is cyan for 0.2 seconds', the context of the conversation that led to that decision is included in the bundle. Claude Code can start from a state where it not only 'turns the received design into code' but also 'turns it into code while understanding the designer's intent'.
Step 3: Implement with Claude Code
Claude Code generates code based on the received bundle.
What is surprising is that the code is 'calculated backward from the design'. Variable names match the design token names. The component structure corresponds to the granularity defined during the design phase. For example, if you designed it in Claude Design as a 'three-section layout with HeroSection, FeatureGrid, and CallToAction', the code will also come out in the structure of `HeroSection.tsx`, `FeatureGrid.tsx`, and `CallToAction.tsx`.
'Consistently exceeding the output of a junior developer'—I thought this evaluation was accurate not just in terms of quantity, but in terms of consistency. There is no discrepancy between design and implementation. A situation where you write dozens of lines and then think, 'Oh, this component name is different from the design one,' does not occur.
I believe Brilliant's '20 prompts → 2 prompts' compression is due to this high level of consistency. If the back-and-forth of instructions is reduced, the total number of interactions also decreases.
Step 4: Combination with Ultraplan
For simple LPs, it is often completed by Step 3. However, for complex dashboards or multi-functional product pages, Ultraplan demonstrates its true value.
Ultraplan is a new feature of Claude Code added in April 2026. It provides a three-stage flow: drafting an implementation plan in the cloud, checking and adding annotations in the web editor, and executing it locally or remotely once confirmed.
When using Ultraplan, you get a list of 'what to build' before implementation begins. You check it in the web editor and add annotations such as 'I want you to use the existing `Button.tsx` for this component' or 'This API can be a mock'. You eliminate ambiguity before moving to execution.
I believe this 'plan → check → execute' loop is the core structure behind the '1-week design review → 1 conversation' compression achieved by the Datadog team. Because decisions can be lined up and checked all at once, the cost of back-and-forth is drastically reduced.
Harness design is complete—Planner × Generator running in the same ecosystem
The concept of harness design. It is a three-layer structure for making AI operate autonomously.
Planner: Deciding what to build and how to build it
Generator: Actually building it
Evaluator: Verifying the results and running the feedback loop
The challenge is that there is a 'translation cost' between the Planner and the Generator. The problem is that it is difficult to accurately pass the design intent to the Generator. Designing an interface for the Generator to correctly receive the specifications generated by the Planner was one of the difficult points of harness design.
The handoff bundle from Claude Design × Claude Code is a direct answer to that challenge.
Claude Design = Planner（課題を視覚化し、設計意図を形式化する）
Claude Code = Generator（実装し、コードを生成する）
自分（人間） = Evaluator（方向性を判断し、品質を評価し、最終的に承認する）For the first time, the Planner and Generator are connected within the same ecosystem.
What the Playwright case study teaches us
The Playwright automated testing case study introduced on the Anthropic engineering blog helps in understanding this structure.
In this case, the test automation harness is structured as follows.
Planner agent: Analyzes the target feature and creates a test plan
Generator agent: Generates executable test code based on the plan
Healer agent (a variant of an Evaluator): Automatically repairs broken selectors when tests fail
There is one particularly important point in the design of this harness.Separating the 'agent that does the work' from the 'agent that evaluates' eliminates self-evaluation bias—this is the core of harness design.
If you have the Generator also act as the Evaluator, it ends up evaluating what it created itself. Naturally, bias occurs. It becomes easy to be pulled toward the conclusion that 'this is fine.' That is why they are separated.
The fact that Claude Design and Claude Code are 'separate tools' is consistent with this principle. By separating the Planner responsible for design and the Generator responsible for implementation, each role becomes clear. Claude Code can focus on 'faithfully implementing the received bundle.' There is no bias of evaluating the design it created itself.
Claude Agent SDK—The era of building your own harnesses
The Claude Code SDK has been rebranded as 'Claude Agent SDK' (supporting Python & TypeScript).
The name change is not just a rebrand. It indicates an evolution from an 'SDK for operating a specific tool called Claude Code' to a 'framework for assembling agents.'
What the Claude Agent SDK provides is the same toolset that runs Claude Code itself—autonomous file reading, command execution, web searching, and code editing. Using this, you can incorporate a Planner-Generator-Evaluator harness into your own product.
The transition from 'using' to 'building'
Incorporate the compression achieved by the Datadog team—'a one-week design review in a single conversation'—into your own design review process. Design it with Claude Design as the Planner for design generation, the Claude Code SDK as the Evaluator for code review, and Claude Code as the Generator for implementation. Connect them using the Claude Agent SDK.
Alternatively, incorporate it into a startup's prototype development flow. Pass the challenges identified in user interviews to Claude Design to generate multiple UX directions, and pass the version selected and refined by the team to Claude Code via a handoff bundle for implementation. Insert an Evaluator that evaluates the output using automated tests powered by Claude.
Toward the job of 'designing the AI's behavior itself'
The implications for PdMs and engineers are significant.
The task of 'designing the AI's behavior itself' rather than just 'using AI' has entered a range that even non-specialized ML engineers can handle.
Reading the Claude Agent SDK documentation, options such as 'how to set the degree of agent autonomy,' 'at what timing to include human confirmation,' and 'how to design error handling' are explicitly stated. These are no different from design decisions in software engineering. The only difference is that the parts written in code become API calls; the framework of thought remains the same.
The thesis I wrote in the first installment, that 'designing the harness becomes a human job,' has become even more concrete.
Whose job changes and how
Based on my actual experience, I will organize 'what changes and what doesn't.' Not just as a feature introduction, but from the perspective of 'what changes in the context of daily work.'
Changes for PdMs
The biggest change is 'before the request to the designer.'
Conventionally, when a PdM asked a designer to 'add this kind of feature,' they explained it in language. In the form of 'add a button, and when clicked, a modal appears, and inside that...' The designer would receive that and visualize it in Figma.
With Claude Design, PdMs can create those visuals themselves. And not just low-quality drafts like 'something with this image,' but things at a presentable level that conform to the team's design system.
The precision of requests to designers will increase. It becomes a form of 'based on this visual, I want you to polish this part.' A division of labor naturally emerges where the PdM handles the exploration phase and the designer handles the refinement phase.
Also, the 'design of evaluation criteria' I wrote about in the previous article—the flow of defining how the Evaluator judges using visuals—becomes realistic. You can create criteria in the design phase such as 'when finished, compare it with this visual.'
Changes for engineers
The starting point of 'writing from scratch' disappears.
What you receive is a code scaffold. The component structure is decided, variable names correspond to design tokens, and interaction definitions are included. Engineers can focus on the job of adding 'business logic' to that.
This is not to say that the value of engineers will decrease. It means that the time spent thinking about 'what to write' will decrease, and the time spent thinking about 'why to write it that way' will increase. Architectural decisions, performance optimization, and handling edge cases—these are areas that still require human judgment.
The fact that we can now confirm the plan for 'what to build' before implementation, in combination with Ultraplan, is also significant. It reduces rework where 'we built it and the direction was wrong.'
Changes for designers
The time available for "exploration" increases.
Instead of carefully crafting one design in Figma, it becomes natural to quickly try 10 directions with Claude Design, choose the most promising one, and then polish it in Figma—this division of labor is becoming natural.
I believe the anxiety that "Claude Design will take my job" is unfounded for now. What Claude Design cannot do yet—such as the precise component management, detailed version history, and simultaneous team editing found in Figma—remains the professional domain of designers.
Rather, it is more productive to view it as an expansion that allows you to "try more options at an earlier stage."
Changes for startup founders
You can ensure visual quality even in the "pre-hiring a designer" phase.
Pitch decks, landing pages, and product prototypes—you can create these essentials for the seed phase with Claude Design, make them functional with Claude Code, and iterate by showing them to investors and customers.
The conventional wisdom that "you should hire a designer early" may be reconsidered. A strategy of "doing design trial and error with Claude Design + Claude Code, and hiring a designer only after the product has passed the validation phase" has become realistic.
What doesn't change—the value of problem identification has actually increased
I have written about what "changes" so far. However, what "doesn't change" is just as important.
"What to build" remains a human job.
What do you ask Claude Design to do? Which direction do you choose? What is truly necessary for the user? Both the story of compressing the Datadog design review and the story of completing it with two prompts in Brilliant are based on the premise that "the right question was asked."
Let me reaffirm what I wrote in the first installment. As AI becomes capable of handling "writing tasks," the value of "questioning tasks" increases. Increasing the resolution of pain points, identifying problems, and deciding "this is what should be solved"—this ability will remain a core human job even when AI can handle both design and implementation.
Final aesthetic judgment and brand philosophy also do not change.
Even if what Claude Design produces is technically excellent, it is humans who judge "whether this is characteristic of our product" or "whether this tone matches the message to the user." Even if you can automatically generate a design system, humans define "the values that the system should aim for."
Empathy for the user also does not change.
"Why is this user stuck here?" or "Where does the eye go when someone sees this UI for the first time?"—these are not questions that Claude Design can answer. Judging "whether this design communicates effectively" based on words heard in user interviews, observed behaviors, and felt frustrations remains a human job.
Summary—The "inside" of the harness is complete
The domain that AI can handle is steadily moving upstream—this proposition remains unchanged. However, what has changed this time is not just the 'move upstream,' but a structural shift where 'upstream (design) and downstream (implementation) are connected within the same context.'
The handoff bundle was not about 'speeding up translation,' but about 'making translation unnecessary.'
As AI gets better, the 'power to ask' gains value.
Designing harnesses is becoming an essential skill for AI utilization.
Claude Design has extended the 'Planner' phase into the realm of visuals. The act of design has entered the AI ecosystem.
And now, the Planner and Generator are operating within the same ecosystem. The 'inside' of the harness has become a single, continuous flow.
Next is—the transition from 'using' harnesses to 'building' them.
Reference Materials
#ClaudeCode #ClaudeDesign #Anthropic #AIEngineering #AIDevelopment #HarnessDesign #ProductManagement #DesignEngineer #GenerativeAI #AIWorkflow #Startup #AIProduct #FrontendDevelopment #DesignAutomation #AIledDevelopment
いいなと思ったら応援しよう！
サポートありがとうございます！頂いたチップは、より質の高い実務知見を還元するための「AIツール活用費」や「学習用書籍」として大切に活用させていただきます。現場で戦うPdMの視座を共に高めていくための、心強いガソリンになります。