frontman-ai
/
frontman
The AI agent that lives in your framework/browser
Ship frontend changes from your browser — no code editor needed
Frontman is an open-source AI coding agent that lives in your browser. It hooks into your dev server as middleware and sees the live DOM, component tree, CSS styles, routes, and server logs. Click any element in your running app, describe what you want changed in plain English, and Frontman edits the actual source files with instant hot reload. It supports Next.js, Astro, and Vite (React, Vue, Svelte). Free and open-source — Apache 2.0 (client libraries) / AGPL-3.0 (server). Bring your own API keys (Claude, ChatGPT, or OpenRouter).
Who Is This For?
Frontend developers who want richer context than terminal-based AI tools provide. Frontman reads the rendered page, not just the source files, so it knows what your CSS actually computes to and which component renders which DOM node.
Designers and product managers who want to change copy, adjust…
Browser-aware AI coding tools use runtime context from your running app, not just file context from your repo.
That sounds like a small detail, but it changes the workflow completely.
Most IDE-based tools are great at reading source files and generating code. But when the bug is visual (layout shift, wrong spacing, hydration mismatch, component renders differently than expected), file context is not enough. You need runtime context: rendered DOM, computed styles, route state, and framework boundaries.
Disclosure: I built Frontman, one of the tools in this category. I will call out tradeoffs directly.
What "browser-aware" actually means
A browser-aware tool should do at least three things:
- Understand what is rendered right now (not just what source files say should render)
- Map from clicked element back to source code with usable confidence
- Give the model enough framework/runtime context to make edits that actually survive hot reload
The third point is where most tools diverge.
The three architectures
1) Framework middleware
This approach installs inside the framework dev server as a plugin/integration package.
Because it runs in the framework pipeline, it can access framework-native signals: module graph, route definitions, server/client boundaries, hydration state, and other internals that are hard to infer from outside.
Strengths
- Deepest framework context
- Better element-to-source mapping potential
- Strong fit for click-to-edit workflows
Costs
- Needs dedicated integration per framework
- More maintenance across framework version changes
- Requires installing package(s) in project
Frontman uses this architecture for Next.js, Astro, and Vite (React, Vue, Svelte).
2) Browser proxy
This approach sits between browser and dev server and injects script into responses.
The major upside is stack coverage: one proxy can run across many frameworks without writing framework-specific integrations.
Strengths
- Framework-agnostic starting point
- Fast setup for many projects
- No deep project integration needed
Costs
- Less native framework context
- Element-to-source mapping often relies on heuristics
- Proxying can introduce transport edge cases (HMR websockets, CORS, certs)
Stagewise is the main example in this bucket.
3) MCP bridge
This approach exposes runtime/browser/server data as MCP tools so you can use them from an existing agent workflow.
It is composable by design: keep your current agent, add tools.
Strengths
- Works with existing agent stack
- Good for on-demand inspection and debugging
- Usually low lock-in
Costs
- Pull-based model (snapshot when queried)
- Not always optimized for continuous click-to-edit loops
- Context depth depends heavily on what the bridge exposes
Chrome DevTools MCP and Tidewave are two examples, with very different depth and scope.
Tools in the category right now
Frontman
frontman.sh | Framework middleware | Apache 2.0 (client libs) / AGPL-3.0 (server)
Frontman (https://frontman.sh) is a vertically integrated AI agent that lives inside your framework and is accessible from the browser, letting designers and product managers make visual changes directly on their running application. It connects to your dev server as middleware and sees the live DOM, component tree, CSS styles, routes, and server context.
Supports Next.js, Astro, and Vite (React, Vue, Svelte). BYOK model (Claude, OpenAI, OpenRouter).
Known tradeoff: narrower framework support than framework-agnostic approaches.
Stagewise
stagewise.io | Proxy | AGPL-3.0
Proxy-based browser editing workflow with broad stack compatibility and polished UX. Also supports bridge mode into popular coding agents.
Known tradeoff: framework internals are less native than middleware-first integrations.
Chrome DevTools MCP
MCP bridge | Apache 2.0
Google's MCP server for Chrome DevTools data (DOM, console, network, screenshots). Strong building block for teams already using MCP-native agent workflows.
Known tradeoff: browser-level visibility is useful, but framework-specific semantics are limited.
Tidewave
tidewave.ai | MCP bridge
Deep runtime tooling with strongest fit in Phoenix/Elixir ecosystems. Good example of MCP used for serious runtime introspection.
Known tradeoff: JS framework visual workflow support is not its primary focus today.
Cursor Visual Editor
IDE-integrated visual mode | Proprietary
Fastest path if your team already standardizes on Cursor and wants visual interactions without changing tools.
Known tradeoff: proprietary and tied to Cursor's environment.
Comparison table
| Feature | Frontman | Stagewise | Chrome DevTools MCP | Tidewave | Cursor Visual Editor |
|---|---|---|---|---|---|
| Core architecture | Middleware | Proxy | MCP bridge | MCP bridge | IDE-integrated |
| Runtime browser context | Yes | Yes | Yes | Partial | Yes |
| Framework-native context depth | High | Medium | Low | High (Phoenix) | Unknown |
| Element-to-source mapping | Native-oriented | Heuristic-oriented | Tool-dependent | Tool-dependent | Unknown |
| Works with existing external agent | BYOK | Yes (bridge mode) | Yes | Yes | No |
| Open source | Yes | Yes | Yes | Yes | No |
| Framework-agnostic by default | No | Yes | Yes | No | No |
How to choose
Use this quick decision rule:
- If your main job is visual edits in supported frameworks and you want deep context, middleware-first tools are usually the best fit.
- If your main job is cross-framework coverage with minimal setup, proxy-first tools are usually the best fit.
- If your team already has a strong agent + MCP workflow, bridge-first tools are usually the best fit.
Also: these tools are not full replacements for IDE agents. They are best where runtime UI context matters most.
What to watch this year
I think this category converges around one question:
Can the tool reliably map what you click to the right code change on first attempt?
Everything else (chat UX, model choice, pricing page polish) matters, but that is the core product truth for browser-aware coding tools.
If you are evaluating this category, start with one real bug from your app (not a toy demo), run the same task through two architectures, and compare first-pass accuracy.
That test tells you more than any feature checklist.
Top comments (1)
I wrote this to make the category language clearer, not to claim a winner.
If you are using any browser-aware tooling, I would love one data point: what is your first-pass success rate when mapping a clicked element to the right code change?
That seems like the real signal that separates architecture hype from useful tooling.