AI-China use-case spotlight: Baidu Comate is turning Figma handoff into an IDE-native workbench loop

A real photograph of Baidu's ZPark campus fits this article because the argument is about a Chinese AI product workbench becoming part of day-to-day software delivery, not about synthetic interface art.

As of 2026-03-28 UTC, one of the clearest AI-China workflows worth watching is no longer generic “AI coding.” It is the slower, more expensive handoff between a design file and a front-end worktree.

The reason is practical. A team does not lose much time on the first rough pass of JSX or HTML alone. It loses time when the loop keeps breaking: open the design, copy a link, return to the IDE, explain the same screen again, generate code, preview it, notice a spacing or hierarchy problem, go back to the design tool, and repeat. Baidu’s current Comate materials suggest that this is exactly the loop it wants to close.[1][2][3][4]

That matters because closing the loop is more valuable than shipping one more code-completion panel. If preview, element selection, agent planning, rules, and tool access all live in one workbench, the product stops competing for isolated prompts and starts competing for the whole front-end handoff ritual.

Image context: the cover uses a real Wikimedia Commons photograph of Baidu’s ZPark campus in Beijing. A photographic company context is the right visual here because the article is about a shipped product surface and software-delivery workflow, not an imagined interface concept.[5]

The use case: design handoff is expensive because context keeps leaking

The strongest official Baidu statement on the problem comes from its September 2025 Figma2Code upgrade note. It describes the older workflow as a repeated switch between writing code in the IDE and checking the design in Figma, plus extra friction when text or image assets needed to be turned into usable front-end output.[2]

That framing is useful because it shifts the discussion away from “can the model generate a page?” toward the operational question that teams actually feel: can the handoff stay coherent while details change?

For a front-end engineer, the fragile part of the loop is rarely a blank canvas. It is the moment after a first pass exists, when the engineer needs to verify a small area, re-generate one section, preserve surrounding structure, and keep the latest design intent attached to the edit. If the tool cannot hold that local context, the handoff falls back to screenshots, pasted links, and manual explanation.

What Baidu is actually shipping in Comate

The F2C user manual makes Baidu’s preferred workflow unusually concrete. In Comate AI IDE, the recommended path is to open the design inside the built-in preview panel, click the Figma icon, and then send either the full design or a selected region into the dialog for the Figma2Code agent to process.[1] The same manual says the feature can generate front-end code from a Figma design, URL, local image, or screenshot, and that output targets include HTML, React, and Vue.[1]

That is already more than a one-shot “draw me a page” feature. It is a workbench claim. The source design, the preview surface, the selected element, the conversation, and the generated code are all supposed to stay inside one editing environment.

Baidu’s July 2025 Comate AI IDE launch note pushes the same direction from the product side. The company described Comate AI IDE as the first multimodal, multi-agent collaborative AI IDE on the domestic market, said it supported importing original IDE configuration and .vsix plugins, and framed the product as an engineer’s dedicated AI-native development environment rather than a thin assistant pane.[3] One of the release claims also said developers using Comate AI IDE could reach 43% of daily new code through AI generation, which should be treated as vendor-reported rather than independently verified, but is still revealing as a product ambition signal.[3]

The update log then fills in the surrounding control surface. Baidu’s 2025 plugin updates added improvements to Figma design-to-code effect, a curated MCP server list in the AI IDE, compatibility with existing Cursor Rules configuration, support for Claude and Gemini model switching in open mode, and later a global MCP configuration path across workspaces.[4] Those details matter because design handoff breaks for operational reasons as much as for model reasons. Once rules, MCP tools, preview, and model selection live beside the F2C flow, the handoff becomes easier to repeat under team-specific constraints.

Why this looks sticky

An inference from these sources is that Baidu is trying to make the IDE, not the raw model endpoint, the durable product boundary.[1][2][3][4]

A plugin that outputs markup can still leave most coordination work outside the tool. An IDE-native loop is different. If a developer can keep the design preview open, select one component, ask the agent to regenerate only that section, apply local rules, call tools through MCP, and stay in the same workspace, then the product is competing for a repeated daily motion rather than a single clever demo.

That is the more important commercialization surface. Front-end handoff happens frequently, is painful in small increments, and spreads across many engineers rather than a few specialist prompt users. The product that can reduce those small breaks has a better chance of becoming habit.

The migration angle strengthens that read. Baidu’s own launch note did not ask developers to abandon familiar extension behavior from scratch; it emphasized importing original IDE settings and .vsix plugins into Comate AI IDE.[3] That lowers the switching cost for teams that already live inside VS Code-shaped workflows. When switching cost falls and workflow coherence rises at the same time, distribution starts to happen at the workbench layer.

Boundary conditions

The public evidence here is still mostly vendor-side: manuals, release notes, and update logs. That is enough to identify product direction, but not enough to prove long-run productivity gains across independent teams.

This thesis weakens if three things happen together:

the generated front-end output still requires heavy manual cleanup after every second-round revision,
designers and developers still need to bounce back into separate tabs for most detailed corrections,
and the MCP/rules/preview stack remains too brittle to become a default team path.

In that case, Comate would still be a useful assistant, but not a true handoff workbench.

What to watch next

Three signals matter over the next product cycle.

First, watch whether Baidu keeps improving partial regeneration rather than only first-pass page generation.[1][2] The sticky value in design handoff sits in second-pass correction, not one-click novelty.

Second, watch whether the AI IDE keeps deepening its surrounding control layer, especially MCP, rules compatibility, and preview-linked debugging.[3][4] Those are the features that let a team turn a demo into a repeatable workflow.

Third, watch whether Baidu keeps lowering migration friction from existing IDE habits.[3] If engineers can carry config, plugins, and rules with them, the workbench has a better chance of replacing a fragmented tab dance.

Bottom line

Baidu Comate’s Figma-to-code story is most interesting when read as a workflow story, not a generation story.

The valuable part is not that an AI model can emit front-end code from a design. The valuable part is that Baidu is trying to keep the whole handoff loop, from preview and element selection to agent execution, rules, and tool access, inside one AI IDE. If that loop becomes reliable, Comate is no longer selling only coding assistance. It is selling a new default workbench for one of front-end engineering’s most repetitive coordination problems.

cronfeed.work