Every time I've asked a coding agent to change something on a screen, the conversation goes the same way. I paste a screenshot. I try to describe which button I mean. The agent guesses, edits a file, and I wait to see if it guessed right. Half the time it didn't, and we do it again.
A few weeks ago I ran into a project called Lavish Editor, built by Kun Chen (@kunchenguid on GitHub). It solves this exact problem for a narrower case: static HTML files an agent has already generated. Lavish opens the file in a real browser, lets you click the exact element you mean, type what you want changed, and sends that straight to the agent with the file and line already resolved. No more "the button in the header, you know the one."
Lavish is built as what its creator calls an AXI, an Agent eXperience Interface, documented at axi.md. The idea is simple to state and surprisingly deep once you sit with it: instead of designing a CLI for a human to type into, you design the operator experience for an autonomous agent that only ever touches your tool through shell commands. That changes almost everything about how the tool should behave. Output gets encoded in a token-efficient format instead of raw JSON. The CLI long-polls for feedback instead of forcing the agent to guess when to check back. Every response ends with a concrete next step instead of a wall of text the agent has to parse on its own. It's a real, opinionated set of standards, and reading through them changed how I think about building CLIs at all.
What stuck with me most about Lavish, though, wasn't the AXI part on its own. It was the interaction loop underneath it: click an element, describe what you want, the agent applies the fix, you see the change, repeat. That loop works beautifully for a static file sitting on disk. But most of what I actually build isn't static. It's a live dev server, mid-development, with state, routing, and hot reload already running. I wanted that same loop, but for the app I already had open in my browser right now, not for a file the agent hands me afterward.
So I built Reactive Editor.
What it actually does
Reactive Editor is a CLI, published on npm as reactive-axi. Point it at a project directory and it detects your framework, spawns your project's own dev server behind a local reverse proxy, and opens your app in a browser with a review shell wrapped around it. Click any element on the page, write a note describing what you want changed, and send it. Your coding agent, polling on the other end, receives the note along with the exact source file, line, and component the click resolved to. It makes the change, saves the file, and you watch it hot-reload in the same browser tab, on the same running app, with the same state it had a second ago.
No screenshots. No describing a button by its color and rough position. No agent guessing at a file it's never seen you looking at.
The problem underneath it
Giving an agent feedback on a live UI today usually means one of two things: a screenshot, which loses everything about how the app actually behaves, or a paragraph of description, which is slow and easy to get wrong. Both push the burden of translation onto you. You already know exactly which element you mean and exactly what should change about it. The gap is that the agent has no way to see what you're seeing or know where that element came from in the source tree.
Reactive Editor closes that gap directly. The click itself is the pointer. Resolving it to a real source location, not a guess, is the part that took the most work to get right.
What it supports today
Reactive Editor works across React, Vue, and Svelte, and the precision of that resolution depends on what each framework's own tooling actually exposes:
React (Vite, Next.js Pages and App Router, TanStack Start, Create React App): resolves to the exact file, line, and column, verified across React 16 through 19.
Svelte: resolves to the exact file, line, and column too, genuinely zero-config, using metadata Svelte's own compiler already emits in dev mode.
Vue: resolves to the exact file and component name. Vue's templates don't carry per-element line metadata the way React's JSX or Svelte's compiler output does, so when an exact line isn't available, Reactive Editor says so plainly instead of guessing one.
That last point matters more than it might look at first glance. A tool that occasionally reports a wrong line is worse than one that admits it doesn't know. Reactive Editor never fabricates a location it can't back up.
A few other things worth knowing
Queue before you send. Click several elements, write a note on each, and review the whole batch before sending it to the agent as one delivery instead of firing off notes one at a time.
Local-first. Your app, your dev server, and your feedback loop stay on your machine. Nothing is proxied through a third party to make this work.
An Agent Skill ships with it. Install it once with npx skills add adeeshsharma/reactive-axi --skill reactive-editor and your agent learns the open, poll, apply, poll loop on its own, including how to handle the honest fallback cases above.
Hot reload survives the proxy. Framework fast-refresh keeps working through the reverse proxy, so a fix lands in the browser the same way it would if you'd edited the file yourself.
Try it
npm install -g reactive-axi
reactive-axi <path-to-your-app>
Or skip the install entirely and let your agent run it on demand with npx -y reactive-axi. The source, the full command reference, and a demo are on GitHub at github.com/adeeshsharma/reactive-axi.
If you've felt the same friction describing a live app to an agent that I have, I'd like to know whether this closes the gap for you too. Issues, feedback, and pull requests are all welcome on the repo.
