Wonder has launched an AI design platform that keeps visual design connected to front-end code. Established product teams must decide whether its canvas removes enough rebuilding to earn a place in their existing workflow.

That connection could remove a familiar source of repeat work. In a traditional workflow, engineers have to recreate an approved design in code before connecting it to real data and backend systems. Wonder gives them interface code created during the design process, although developers still need to review it and complete the work that makes the feature function securely and reliably.

AI makes this approach more consequential because interfaces are becoming faster and easier to produce. More options still require people to decide what information deserves attention, how customers should move through a product, and which version is worth building. Replit and Figma are also bringing visual design and working code closer together, so Wonder must show that keeping those decisions on a designer-first canvas creates a meaningful advantage.

The platform most directly affects designers, product leaders, and developers working on established products. Designers and product leaders can guide the visible experience with the product’s real components, while developers retain control over the codebase and the backend systems that make the interface work.

In short, Wonder is betting that human product judgment becomes more valuable when AI can build interfaces quickly. Its case depends on whether the canvas can carry those decisions into code faithfully enough to save developers from reconstructing an interface the team has already approved.

The design-to-code handoff is the step in which engineers translate a separate visual design into the front-end code that users see and interact with.

An AI design-to-code platform lets product teams create and refine visual interfaces while keeping approved design decisions connected to the front-end code developers review.

Wonder launched publicly on April 30, but the company’s origins go back to an earlier attempt to improve how designers hand their work to software engineers.

Before creating Wonder, co-founders Aibek Yegemberdin and Boris Janković built Superflex, a design-to-code platform reportedly used by more than 40,000 developers. Superflex was designed to convert completed designs into code more accurately. As they worked on the platform, however, the founders concluded that improving the conversion did not remove the extra work created by keeping design and code separate.

In the traditional process, a designer first creates a visual model showing how a website or application should look. That design may include the page layout, menus, buttons, colors, text, charts, and other elements a customer will see. The designer then gives that model to engineers, who study it and write the front-end code needed to recreate the interface as part of the working product.

The design gives engineers a picture of the intended result, but it is still a separate file from the interface they build. Engineers have to interpret the design, decide how to reproduce each part in code, and send the result back for review. If the coded version does not match the original design, the team goes through another round of changes.

Wonder was created to remove that rebuilding process.

A person can begin in Wonder by describing the interface they want in ordinary written instructions. The AI creates a visible version on Wonder’s canvas, the on-screen workspace where the interface appears. From there, the user can ask the AI to make additional changes, generate other versions, or adjust elements directly by hand. A finished design from another program is not required before that work begins.

The difference lies in what Wonder creates while the person is making those decisions. The canvas is connected to the front-end code that controls how the interface looks and behaves on the screen. When someone changes the layout, colors, buttons, or other visible elements, Wonder can reflect those choices in the code instead of leaving an engineer to recreate the approved design later.

Wonder does not require every project to begin with a new AI-generated interface, however. Teams can connect the code for an existing product through GitHub and continue designing from what they already have.

Wonder reads that code and brings the product’s existing screens and reusable code components onto the canvas. These components can include buttons, menus, icons, and page sections that the company’s developers have already created. When a designer, product manager, or other person working on the interface asks the AI to change a screen or create something new, Wonder can build with those existing components.

The connection also gives Wonder access to the product’s design tokens, the saved styling rules for its approved colors, fonts, text sizes, and spacing. The components provide the actual pieces used to construct the interface, while the design tokens control how those pieces should look. Together, they help new work follow the same design choices as the rest of the product.

For a product connected through GitHub, Wonder can also return approved canvas changes to the original codebase. It identifies which source files correspond to the changed parts of the interface and prepares a plan showing the code it intends to edit. After the user approves that plan, Wonder opens a pull request in GitHub so the changes can move through the development team’s normal review process. The engineers receive code created through the design work on the canvas, eliminating the need to rebuild the approved interface from a picture.

Wonder calls this “what you see is what you ship”: the layout, buttons, charts, menus, and other visible parts of the approved interface are already represented in front-end code. Developers must still connect those elements to the product’s data and backend systems before the full feature can function. Without those connections, the interface may look complete, but it cannot display live information or perform the actions that depend on those systems.

A dashboard illustrates the division. Wonder can create the navigation, charts, filters, and tables that appear on the screen. Developers have to connect them to the company’s real data and determine what happens when someone clicks a button, changes a filter, or requests information. They also make sure the feature protects sensitive information, loads quickly, responds reliably, and works with the rest of the product.

Wonder says teams could save days or weeks by giving engineers an approved interface already represented in code, removing the separate step of rebuilding it from a design. Wonder is still measuring the results with its design partners and has not supplied a completed comparison showing how much time teams save.

If AI can already create interfaces quickly, why does removing the handoff between design and engineering become more valuable?

Removing the handoff between design and engineering becomes more valuable as AI makes it easier to produce another interface. Aibek Yegemberdin’s argument is that the difficult part of product development will increasingly be deciding which ideas deserve to become part of the product.

AI can generate a screen within minutes and produce additional versions just as quickly. Each version still requires decisions about what information deserves the most attention, which actions should be easiest to find, and how the experience should guide the person using it. Producing more options does not determine which one best serves the product or its customers.

A company-provided demonstration reviewed by AiNews showed this human judgment in action. Wonder began with a completed desktop affiliate dashboard and asked its AI to create mobile versions. A standard automatic conversion could have produced one mobile layout based on the desktop design. Wonder generated several mobile interpretations side by side, giving the user different approaches to consider.

The mobile versions made different choices about how to arrange the same product. They changed which information appeared first, how the revenue chart was displayed, where the navigation belonged, and how the performance summaries were grouped.

A person still had to compare the alternatives and decide which ideas to keep, revise, or combine. Wonder assigns that work to the human using the canvas. The AI creates the options, while the person directing the product decides which one should move forward.

That division explains why Wonder treats the canvas as the main place where AI-assisted development should happen. Designers, product managers, and other people responsible for the interface can see the alternatives together, judge how each one affects the experience, and continue guiding the AI through written instructions or direct edits.

Wonder also connects those decisions to the product’s existing components and design rules. Each AI-generated version can use the same buttons, menus, fonts, colors, spacing, and other building blocks already established for the product. That shared foundation is intended to keep repeated AI generation coherent, so each new option continues to feel like part of the same product instead of becoming a separate mockup with its own disconnected design choices.

The person comparing the options can then concentrate on the decisions that affect the customer experience: what the screen emphasizes, how information is organized, and which actions should be easiest to complete. The team does not have to spend as much time correcting avoidable differences in colors, typography, spacing, or components before it can evaluate the underlying idea.

Yegemberdin told AiNews that AI has made producing interfaces easier, increasing the value of the human judgment that determines what is worth building. In Wonder’s proposed workflow, design continues throughout development because each new AI-generated option creates another choice about what the product should become.

AJ Smith, a junior partner at Outlander VC, which led Wonder’s pre-seed funding round, describes the human contribution as a “taste layer” that AI generation lacks.

Smith expects user experience to become a larger source of product defensibility—the qualities that help a product retain its advantage when competitors can offer similar features. As AI makes similar features faster to build, he argues that the quality of the experience could become a more important reason one product succeeds over another. Human taste would become the differentiator: the judgment that determines which experience customers will prefer.

But if this is where AI software development is headed, has Wonder found something its competitors have not?

Vibe coding allows someone to describe an application in ordinary language and have an AI agent build much of it. Platforms such as Replit can create working applications, giving people who do not code a way to turn an idea into something they can see, test, and potentially publish.

A relatively simple application may be able to go live through that process. The challenge is when a business needs the application to connect to real company data and backend systems while meeting its standards for security, speed, reliability, and complicated business rules. At that point, “the app runs” and “the app is ready for a business to depend on” become different standards.

Wonder uses some of the same AI-assisted methods, but it is built around a different working relationship. Its main workflow assumes that developers remain responsible for the company’s codebase and the systems behind the product. Designers, product managers, and other people responsible for the customer experience use Wonder to shape the visible interface, while developers review the resulting code and connect it to the rest of the product.

The process begins when a developer connects the company’s GitHub repository to a Wonder file. Wonder reads the product’s source files, reusable components, and established design rules, bringing the relevant screens and interface pieces onto its design canvas. A designer or product leader can then use AI to design the interface and customer experience on the canvas—essentially vibe coding the visible product—while working with the buttons, menus, fonts, colors, and other elements the company already uses.

Once the visual changes are approved, Wonder identifies which source files in the existing product need to be edited and shows the user its proposed plan. After the plan is approved, Wonder opens a pull request containing the new code. The company’s developers can review those changes and merge them into the existing product through their normal GitHub process. Developers then connect the interface to the data and backend systems that make it function.

That division creates a clearer distinction between Wonder and general-purpose vibe-coding platforms:

Replit says, “Help me build this application.”

Wonder says, “Let me make the visual product decisions, then let my developers review the code that puts those decisions into the product.”

Replit is designed to take a user from an idea to a working application inside one platform. Its AI can begin with a written prompt, template, Figma design, screenshot, website, saved design system, or an existing project imported from GitHub or uploaded files.

Replit Design gives the user a visual stage for exploring the idea. The AI generates interactive mockups that can be compared and refined before the user selects one to develop. Replit Agent can then build the chosen direction into a working application inside the same project.

The visual controls remain available as the application develops. Replit’s Visual Editor works on both the original design screens and the live application preview. Simple changes to text, colors, or spacing update the source code directly and do not consume AI credits. More complicated requests go to Replit Agent, which determines what code must change and can use AI credits to complete the work.

Replit therefore serves someone who wants AI to help build the application itself. Wonder serves an established product team that already has developers and an existing codebase. Its goal is to carry the approved interface into that development process so engineers can review the resulting code instead of rebuilding the design from scratch.

Figma Make is a closer comparison because it approaches AI application building from the design side. Figma is already used by teams to create and review visual designs, and Make can turn a written idea or an existing Figma design into a functional prototype, web application, or interactive interface.

A person works in Figma Make through an AI conversation and a live preview of the application. The user can request changes, inspect or edit the generated code, and provide additional designs or images as guidance. Existing code can also be brought into Make for continued development, and completed applications can be published to a public web address.

Figma Make can use production-ready React components, allowing a company to work with the same buttons, forms, menus, and other interface pieces used in its finished product. Figma Code Connect can also link a component in a design file to the matching component in the company’s code repository. Through Figma’s Model Context Protocol (MCP) server, AI coding agents can receive those connections and identify which existing components they should use. MCP is a standard that allows an AI tool to exchange information with another program.

Both platforms allow AI to work with existing designs, production components, and company code. The difference appears in how the design workspace remains connected to the resulting application.

Figma Make centers the work on an AI conversation and a live preview. It can begin with a design created in Figma’s main Design workspace, but that full workspace remains separate from the Make application. A Make interface can be copied into Figma Design as editable layers, although changes made to those layers do not automatically update the application in Make.

Wonder keeps the design canvas at the center so designers and product leaders can essentially vibe code the visible interface while working with the product’s real components. Because those elements remain connected to the existing source files, Wonder can translate the approved visual decisions into proposed code changes. Developers review that code and connect it to the rest of the product instead of rebuilding the interface from a separate design.

Replit and Figma are bringing design and working code closer together, validating Wonder’s premise that the traditional handoff between designers and developers no longer fits AI-driven product development. Wonder has built its workflow specifically for established product teams: designers and product leaders remain in control of the visible interface, while their approved decisions move into the company’s existing codebase. Developers can review and connect that work to the rest of the product without rebuilding the interface from a separate design.

As more platforms connect visual design with working code, why does Wonder believe the design canvas should remain in control?

Wonder believes the design canvas should remain in control because it gives people a visible place to direct the product while AI and developers work with the code underneath it. As AI handles more of the actual building, the canvas allows designers and product leaders to stay involved without requiring them to work inside a coding environment.

Designers and product leaders do more than approve a finished screen. They can ask the AI to generate alternatives, compare them side by side, change individual elements, and continue refining the interface as the product develops. The decisions remain visible on the canvas, where people can judge how the product looks, what information receives attention, and how customers will move through it.

Wonder connects that visual work to AI coding agents through its MCP server, giving compatible agents permission to read and write information on the canvas.

That two-way connection allows work to move between the design and coding sides of the product. A coding agent can pull a Wonder design into code, while changes made through code can be returned to the canvas for visual review. Wonder currently documents support for Claude Code, Codex, Cursor, Claude Desktop, Antigravity, Lovable, and other tools that support MCP.

The connection means designers and developers do not have to abandon their preferred tools to work on the same interface. A designer or product leader can remain on Wonder’s canvas while a developer works with a coding agent. Changes can move between those environments, giving both sides a shared view of what is being built.

Wonder also keeps track of where imported interface elements came from in the company’s code. When a button, menu, or other component is brought onto the canvas, Wonder records its original source file and the version of the code used during the import. That record allows the platform to recognize when the component later changes in GitHub.

If a developer updates the source file, Wonder marks the corresponding canvas element as out of sync. The user can compare the version on the canvas with the latest version in the repository and update it without losing its position or identity in the design. The canvas can therefore remain current as developers continue changing the product outside Wonder.

That synchronization depends on a component retaining its connection to the original source. An element created only in Wonder, imported without a source reference, or deliberately detached from its source cannot update automatically. Someone would need to reconnect or update that element through another part of the workflow.

Keeping the source connection intact supports Wonder’s larger goal. The canvas is intended to remain a living part of product development rather than a design file that becomes outdated once engineering begins. Designers and product leaders can continue making visual decisions, while developers and AI coding agents work with the implementation and return relevant changes to the canvas.

That approach may appeal most to companies that already have designers, product leaders, developers, and an established codebase. Those teams must decide how much human judgment they want to preserve in the design process and whether Wonder can carry those decisions into code well enough to reduce the time developers spend rebuilding approved interfaces.

As AI development platforms offer more of the same capabilities, what should teams compare before choosing where design, AI, and code come together?

Wonder, Replit, and Figma can all generate an interface, accept existing work, and connect visual changes with code. For product teams choosing among them, the more useful comparison is what enters the platform, where people make decisions, how approved changes reach the codebase, and which work still belongs to developers.

Wonder is designed for companies that want their existing product to remain the starting point. A team can connect its GitHub repository and bring its actual components, design rules, icons, and screens onto the canvas. Replit can also import projects from GitHub, Figma, or uploaded files, while Figma Make can begin with existing designs, pasted code, or production React components.

The platforms also give people different places to review the AI’s work. Wonder keeps those decisions on its design canvas. Replit lets users work with design screens and the live application preview. Figma Make centers the process on an AI conversation and a preview of the application being built.

For an established product team, the path back into the codebase may be especially important. Wonder identifies which source files correspond to the approved canvas changes and presents an export plan before writing any code. The plan shows the affected designs, source files, proposed edits, GitHub branch, and pull request.

Nothing is written to the repository until the user approves that plan. Wonder then creates a new branch, edits the required files, commits the changes, and opens a draft or regular pull request. It does not write directly to the base branch, merge the pull request, approve its own work, force changes into the repository, or alter the company’s settings and secrets.

Those safeguards preserve a role for the development team. Designers and product leaders can make the visual decisions, while developers review the proposed code before it becomes part of the product. Wonder’s pull-request export remains in beta, and the company instructs teams to review every pull request before merging it.

Teams should also examine how well Wonder fits the design and development systems they already use. Figma frames can be copied into Wonder as editable layers, and matching design variables can remain connected when the same names exist in both files. That gives teams a path for bringing existing Figma work onto Wonder’s canvas.

The import does not preserve every part of a Figma design. Images currently arrive as empty frames, while Figma components and their instances become detached from their original component relationships. Some grids, borders, visual effects, textures, and mixed text formatting are unsupported or converted into alternatives that can be represented in web code.

Wonder’s support for design tokens also has limits. It can work with established colors, spacing, dimensions, opacity, and several typography properties, but grouped variables for typography and shadows remain under development. Teams with complex design systems would need to determine whether the parts Wonder currently supports cover the rules their products depend on.

Teams should consider these factors when evaluating how Wonder fits their existing design and development process. Wonder’s central value proposition remains the same: keeping design and code connected so approved interface decisions can move into the existing codebase, reducing the rebuilding work developers would otherwise have to do.

Wonder Pro currently costs $20 per user with monthly billing or $16 per user per month when billed annually. The plan includes $20 in monthly AI tokens, while additional AI usage can increase the cost. Wonder’s MCP server is available on every plan, including the free tier, although teams may separately pay for whichever compatible coding agent they connect to it.

A team evaluating the total cost would need to account for its Wonder plan, any additional Wonder AI tokens, its preferred coding agent, and the developer time required to review the code and connect the interface to the rest of the product.

Wonder’s opportunity comes from giving established product teams a different division of labor. Designers and product leaders can use AI to shape the interface with the company’s real components, while developers retain control over the codebase and the systems that make the product function. The value depends on whether that workflow removes enough rebuilding to save time without disrupting how the team already designs, reviews, and ships software.

Replit and Figma show that the industry is moving toward a closer relationship between visual design and working code. Wonder’s bet is that established product teams will prefer a workflow that keeps human product judgment on the canvas, carries those decisions into the existing codebase, and allows developers to spend less time reconstructing an interface that has already been designed.

Q: What is Wonder, and who is it for?
A: Wonder is an AI design-to-code platform for established product teams. It gives designers and product leaders a visual canvas where they can generate, compare, and edit interfaces while keeping approved design decisions connected to the front-end code developers review.

Q: How does Wonder connect a design to an existing codebase?
A: A developer connects the product’s GitHub repository to a Wonder file. Wonder reads the source files, reusable interface components, and design rules, then brings the relevant screens and components onto its canvas. After the team approves a visual change, Wonder identifies which source files need to be edited and prepares an export plan. Once the user approves that plan, Wonder creates a branch, edits the files, and opens a GitHub pull request for the development team to review.

Q: Why does Wonder keep the design canvas at the center?
A: Wonder uses the canvas as the place where designers and product leaders direct the customer experience while AI handles more of the implementation. They can generate several interface versions, compare how each one organizes information and actions, and decide which ideas should move forward. Wonder’s bet is that this human product judgment becomes more valuable as AI makes interfaces faster and easier to produce.

Q: Can Wonder build a complete application without developers?
A: Wonder can create the visible interface and represent it in front-end code, but developers still have to connect that interface to company data and backend systems. Developers also remain responsible for security, speed, reliability, business rules, and reviewing the code before it becomes part of the product.

Q: How does Wonder work with GitHub and AI coding agents?
A: Wonder’s MCP server allows compatible AI coding agents to exchange information with its canvas. A coding agent can bring a Wonder design into code, while code changes can return to the canvas for visual review. Wonder also records the source file and code version connected to an imported component. If that source file changes in GitHub, Wonder can mark the canvas component as out of sync so the user can compare and update it. Components without an active connection to their original source cannot update automatically.

Q: How is Wonder different from Replit and Figma Make?
A: Replit is designed to help someone move from an idea to a working application within one platform. Figma Make approaches AI application building from the design side through an AI conversation and live preview. Wonder is designed for established product teams that already have developers and a codebase. It keeps designers and product leaders in control of the visible interface while developers review the resulting code and connect it to the rest of the product.

Q: How much does Wonder cost, and should my product team use it?
A: Wonder Pro costs $20 per user with monthly billing or $16 per user per month when billed annually. The plan includes $20 in monthly AI tokens, and additional AI use can increase the cost. Wonder’s MCP server is available on every plan, including the free tier, although teams may also pay for a compatible coding agent.

Wonder is designed most directly for companies that already have designers, product leaders, developers, and an established codebase. Before adopting it, a team should determine whether Wonder supports the Figma content, design-system features, and development process it relies on. Its pull-request export remains in beta, and Wonder has not supplied a completed comparison showing how much time teams save. The total evaluation should include the Wonder plan, additional AI use, the connected coding agent, and the developer time required to review the code and complete each feature.

Faster interface generation does not remove the need for people to decide what a product should become. Wonder is betting that the design canvas can remain the place where that human judgment happens while AI handles more of the implementation.

Wonder’s most important feature is the connection between its canvas and an existing codebase. Approved visual decisions can use the product’s real components and design rules, map back to the relevant source files, and move into GitHub through a proposed pull request. Developers retain control over reviewing the code and connecting the interface to the systems behind it.

Wonder is most relevant to companies that already have designers, product leaders, developers, and an established codebase. Designers and product leaders can direct the customer experience on the canvas. Developers can review proposed code instead of reconstructing an approved interface from a separate design.

AI allows teams to generate more interface options in less time, but every option still requires choices about what customers should see and how the product should work. Using the company’s existing components can reduce avoidable design corrections before implementation begins. Wonder says removing the rebuilding step could save days or weeks. The company is measuring those gains with design partners to determine how much time the workflow saves in day-to-day product development.

Teams need to decide whether Wonder fits their existing workflow well enough to reduce the time and total cost of moving an approved interface into the product. That requires testing it with their existing codebase, Figma content, design system, coding agents, and review process. Teams should also account for the beta pull-request export, the developer work that remains, and the combined cost of Wonder, additional AI use, connected coding tools, and code review. Comparisons with Replit and Figma should focus on where product decisions happen, how approved changes reach working code, and what each platform requires in tools and developer time to complete that work.

In short, Wonder’s value depends on whether its canvas can translate approved product judgment into reviewable code and genuinely reduce the work between design and engineering.

As visual design and working code converge across platforms, Wonder’s future depends on whether human product judgment can survive the trip from canvas to shipped software.

Editor’s Note: This article was created by Alicia Shapiro, CMO of AiNews.com, with writing support, AEO/GEO/SEO optimization, image concept development, and editorial structuring support from ChatGPT, an AI assistant. All final editorial decisions, perspectives, and publishing choices were made by Alicia Shapiro.