If you run a design system across multiple product teams, you know the bottleneck. A designer spots a spacing inconsistency, an outdated color token, a component that doesn’t match the latest Figma specs. They file a ticket. An engineer picks it up days later, makes a three-line change, opens a PR. Teams end up bottlenecked on engineering for changes that should take minutes.
Framework-aware AI coding tools exist to short-circuit that loop. You open your running application in the browser, click on the element that needs to change, and describe what you want in plain language: “increase the padding to match our spacing scale,” “swap this to use the secondary button variant,” “this heading should be H2 semibold.” The tool figures out which component file to edit, which design tokens to use, and makes the change — or select multiple elements to fix design drift across your entire app. You see the result live.
The difference between these tools and general-purpose AI coding assistants (Cursor, Copilot, Claude Code) is what they understand. A general-purpose tool reads your source files — a limitation we call the Runtime Context Gap. A framework-aware tool understands your application’s structure—it knows that the button you clicked lives in src/components/ui/Button.tsx, that it’s used in 14 places, that your design system defines --spacing-md as 16px, and that changing the padding here should use that token instead of hardcoding 20px.
Five tools currently exist. They take three different technical approaches, and the approach directly determines what the tool can and can’t do for your team.
Disclosure: I built Frontman, one of the tools in this category. I’ll be transparent about tradeoffs.
Three Approaches, Different Capabilities
The technical details matter less than what each approach means for your workflow. Here’s what you need to know.
Deep Integration (Middleware)
A developer on your team installs a package into the project. Once it’s there, every team member—designers included—gets full component-level awareness in the browser. You click on any element and the tool knows exactly which component it belongs to, which file it lives in, and what design tokens are available. It understands your component hierarchy, your page structure, and where server-rendered content starts and client-side interactivity begins.
What this means for design teams: The tool respects your design system. When you ask it to change a color, it’ll use your existing token (--color-primary-600) instead of hardcoding #2563eb. When you click on a card component, it sees the full component API—props, variants, slots—and can suggest changes that work within your system rather than around it.
The tradeoff: It only works with supported frameworks (currently Next.js, Astro, and Vite-based apps). A developer has to do the initial setup. And because it’s embedded in the build process, bugs in the integration can occasionally disrupt the dev environment.
Frontman uses this approach.
Browser Overlay (Proxy)
No installation in your codebase. A designer runs a single command, and a toolbar appears on top of your running app. You click elements and describe changes, just like the middleware approach.
What this means for design teams: The fastest way to get started. No waiting for engineering to install anything. Works with any web application regardless of what framework it’s built with. If your company has multiple products on different stacks, one tool covers all of them.
The tradeoff: The tool sees what the browser sees—the rendered page—but it can’t see inside your design system’s source structure. It doesn’t know about your component variants, your design tokens, or your spacing scale. When you ask for a change, it’s more likely to produce a one-off style rather than reusing an existing token or variant. For teams maintaining a design system across multiple products, this means more cleanup work to keep things consistent. Source mapping (figuring out which file to edit) also relies on educated guesses rather than direct knowledge, which can break with complex component structures.
Stagewise uses this approach.
Agent Extension (MCP Bridge)
An MCP bridge connects to an AI coding agent your engineering team already uses (Claude Code, Cursor, Codex) and gives it the ability to see browser state—DOM structure, console output, network requests, screenshots. The agent can then answer questions like “what does the current page look like?” or “what error is showing in the console?”
What this means for design teams: Honestly, not much—yet. MCP bridges are designed for developers extending their existing AI coding workflows. There’s no visual click-to-edit interface. You don’t interact with the running app directly. The AI agent has to decide to look at the browser state; it doesn’t react to your clicks. These tools are powerful for engineering workflows but aren’t built for the design-to-code feedback loop.
The tradeoff: Great composability for engineering teams, but currently no path for non-developers to use them directly.
Chrome DevTools MCP (Google) and Tidewave (Phoenix/Rails) use this approach.
The Tools
Frontman
frontman.sh | Deep integration | Apache 2.0 / AGPL-3.0
Next.js, Astro, and Vite (React, Vue, Svelte). Bring your own AI key (Claude, OpenAI, OpenRouter)—no account required, no prompt limits, no per-seat pricing. Understands component hierarchies and design tokens at the source level. Early-stage with rough edges, small community, and incomplete documentation. A developer needs to install it (Getting Started with Frontman covers the process), and it only works with the three supported frameworks.
I built this.
Stagewise
stagewise.io | Browser overlay | AGPL-3.0 | YC-backed
Works with any web application. Two modes: standalone agent (hosted, account required) or bridge mode (connects to Cursor, Copilot, Windsurf, Cline, Roo Code). About 6,500 GitHub stars. Around 10 free interactions per day, EUR 20/month for heavier use. Most people I’ve talked to who’ve tried multiple tools in this category say Stagewise feels the most polished. No bring-your-own-key on the standalone agent—you pay for the AI through their pricing.
Chrome DevTools MCP
MCP bridge | Apache 2.0
Google’s experimental bridge that gives AI agents access to browser state—DOM, console, network, screenshots. Free and open source. Requires an existing AI coding setup (this is a developer tool, not a standalone product). Think of it as infrastructure for engineering teams, not something a designer would use directly.
Tidewave
tidewave.ai | MCP bridge | Created by Jose Valim (Elixir creator)
Built primarily for Phoenix/Elixir backends. Exposes deep server-side state: database queries, stack traces, live process inspection. JS frontend support is thin. Relevant if your engineering team works in Elixir/Phoenix, but not designed for the design-to-code workflow.
Cursor Visual Editor
Built into Cursor IDE | Proprietary
If your engineering team already uses Cursor, this is the lowest-friction option: a visual editing mode inside the IDE where engineers can interact with a preview of the app and request changes visually. No extra install. It’s proprietary and locked to Cursor, and the depth of its framework understanding isn’t well documented. Useful for engineers doing visual work, but designers would need Cursor (a code editor) installed.
Comparison Table
| Feature | Frontman | Stagewise | Chrome MCP | Tidewave | Cursor Visual |
|---|---|---|---|---|---|
| Approach | Deep integration | Browser overlay | Agent extension | Agent extension | IDE built-in |
| Design system awareness | Yes (tokens, variants) | No (rendered DOM only) | No | No | Unknown |
| Click-to-edit | Yes | Yes | No | No | Yes |
| Usable by designers | After dev setup | Yes (standalone) | No | No | No |
| Works with any framework | No (Next/Astro/Vite) | Yes | Yes | No (Phoenix) | No (React/Next) |
| Cost for a team | Free (BYOK) | EUR 20/seat/mo | Free | $10/mo | Cursor subscription |
| Account required | No | Yes | No | Yes | Yes (Cursor) |
| Component source mapping | Exact | Best-effort | No | No | Unknown |
| Open source | Yes | Yes | Yes | Yes | No |
| Setup required | Dev installs package | None | Dev configures MCP | Dev configures MCP | Cursor installed |
Which Approach Fits Your Team
If you’re a designer or PM evaluating these tools, the honest answer depends on two things: what your engineering team uses, and how much design system consistency matters.
Design system consistency is critical. If your team maintains a component library with design tokens, spacing scales, and component variants—and you need AI-assisted changes to respect those patterns—you need a tool with deep integration. Today that means Frontman on Next.js, Astro, or Vite (see Frontman vs. Cursor vs. Claude Code for a deeper comparison). The other approaches will get you faster edits but with more cleanup to keep your system consistent.
Speed and independence matter more. If you want to make quick visual changes across any product without waiting for engineering setup, Stagewise gets you there fastest. Accept that some changes will need design system cleanup, and it’s a good tradeoff for velocity.
Your engineering team wants to extend their existing tools. If the goal is giving developers better browser context in their AI coding workflow (not enabling designer self-service), Chrome DevTools MCP or Tidewave add that capability without changing their setup.
You’re already on Cursor. The Visual Editor is right there. No evaluation needed for the engineering side—but it doesn’t solve the designer-to-code gap since it lives inside a code editor.
None of these tools is a finished product yet. The broader open-source AI coding tools category is early. But the gap they’re filling—the week-long cycle between “I see a spacing issue” and “it’s fixed in production”—is real, and it’s worth understanding your options.