Someone evaluating Pixy wrote down seven things they'd want to validate before putting it in their workflow. None of the questions were about whether the editor felt nice to use. They were about what happens after you make a change, when your coding agent has to turn that change into code.
That's the useful way to evaluate a visual editor for agents. Moving something 8px to the left is easy. The interesting part is whether your agent knows what moved, where it moved, how far the change should reach, and enough about the context to find the right place in the source. Prompting can describe all of that, but at some point you're playing a guessing game with an agent that wasn't looking at the page with you.
Here are the seven things worth checking in Pixy, including the parts that still have gaps.
The bridge is the product
Most design tools start with a canvas and eventually generate code. Pixy starts with your running site. You make an edit there, Pixy turns it into a structured record, and your coding agent reads that record and writes the source. Your codebase stays the source of truth, and there is nothing to export back into it.
Pixy also doesn't need to know how your codebase produced what you're looking at. A 24px gap you shrink to 16px might come from Tailwind, a CSS module, a styled component, or a prop three levels up. Pixy records which element changed, which property changed, and what the value should be. Your agent already has the repository open, so it works out where that value lives.
If your agent still has to figure out what you changed, you've mostly given it a more expensive prompt.
The quality of that record decides how much guessing is left for the agent. A vague handoff gets you surprisingly close to screenshot prompting with extra paperwork.
How an element gets named
Every record carries a target, and the target determines how far the change should reach. There is no separate scope flag to interpret later.
- A rule
An edit to one of the site's own CSS rules. It reaches exactly as far as that selector reaches, so the agent can make the change once at the component level. - A color
One of the colors the site actually uses. The change applies everywhere that color is used. - A page and a selector
One element on one page. This is the deliberate one-off. - A page and an element ID
Something created in Pixy by drawing or dropping it onto the page. It has no selector in the source yet because it doesn't exist there yet. The record's ID becomes its address and carries the slot in the page flow where you placed it.
"Make this smaller" is a perfectly clear instruction until your agent has to work out what "this" is.
You choose between a rule and a one-off through the block you edit. The CSS tab lists every rule matching your selection, most specific first, and shows how many elements on the page each rule hits. Change a line inside a rule block and the record targets that rule. Change it in element.style at the top and the record targets that element on that page.
The selector is a structural path from body. It uses tag names and :nth-of-type where siblings share a tag, then stops at the first ID it finds. The record also carries a short sample of the element's text, which is often a much better clue when the agent goes looking for it in a template. The full contract is on the pull page, and every API docs page is served as plain text so the agent can read it itself.
The width travels with the change
Each change carries the artboard width where you made it. The diff stores the property, its value before, its value after, and that width. Padding changed at 390 reads as a phone fix. The same property changed at 1440 carries a very different clue about what you intended.
"Fix it on mobile" is how you discover that you and your agent have different ideas about mobile.
When you drag the edge of the frame, your own CSS reflows through its own breakpoints. You can make the mobile fix while looking at the mobile problem instead of later trying to explain which version of "mobile" was in your head.
States are still a gap. The CSS tab shows the rules matching your selection at that moment. A rule guarded by :hover doesn't match until something is hovering, so it isn't in the list, and there is no state switcher yet. Today, you select the element, press C, and write a note. The note travels in the same batch, addressed to the same element, so your agent reads it beside the visual change. It works, but it is still a note rather than an edit.
What survives a re-render
Records attach to targets instead of DOM nodes. The editor reconciles them against the page as it finds it, so a record whose element hasn't appeared yet waits for the next pass. That's how a popup, a late server response, or a page swapped in by the router can still receive its edits. Rule records apply to whatever matches at the time, including markup that just rendered.
The fragile case is a page-and-selector record because a structural path is only as stable as the surrounding structure. Rewrite the markup around it and the record can point at a neighbor. An ID anywhere along the path limits that problem because the path stops there. For component-level changes, editing the rule avoids the positional problem altogether.
The DOM changed while you were looking at it. Very considerate of the DOM.
Edits also survive a reload. Things you tried and then undid don't. If you return a value to what the element already had, Pixy drops both the override and its record, so only the changes you keep reach your agent. Your brief experiment with a 37px border radius stays between you and your browser.
A color change never names an element
Beside the artboard, the Design system panel contains the colors your site actually uses. Pixy reads them from your pages under the active theme and orders them by usage. Open one, choose a shade or type a hex value, and the site changes everywhere that color is used.
The agent receives one record saying that the old color becomes the new one, plus every source line in your CSS that writes the old value. Each source includes the stylesheet path, selector, property, and any @media condition around it. That gives the agent enough context to distinguish something like a dark theme token from its light theme equivalent.
Changing the brand color in 47 places is technically a workflow. So is regret.
If the color comes from a custom property, the record carries that property instead of listing every element currently using it. The agent therefore receives the source of the design token change instead of a pile of individual elements that happen to share the same color.
What leaves the browser
Pixy doesn't capture, copy, screenshot, or store the pages you design on, and nothing on Pixy's side fetches them. That keeps localhost, staging environments, and pages behind a login out of Pixy's reach.
"Nothing leaves the browser" sounds great until the thing you changed also doesn't leave the browser.
The change itself does leave the browser. It's worth being precise about what that means.
- Page context
The page path and title travel with the change. - Target
The record includes the address of the rule, color, selector, or Pixy element that changed. - Edit
The property and its values before and after are included, along with the artboard width. - Element context
A short sample of the element's text is included. If you change a headline behind a login, the old and new headline are both part of the record because those values are the change. - Color sources
For a color change, the record includes the CSS lines that write the old value. - Dropped images
An image you deliberately drop into Pixy uploads because your agent needs the file. - Screenshots and recordings
These never reach Pixy. The browser creates them and puts them in your downloads.
Your agent runs on your machine, under your own account, using whichever provider you use. Pixy doesn't hand your content to an AI provider and doesn't run models of its own. The privacy policy covers the same behavior in the language privacy policies are required to use.
The part you have to test yourself
The seven questions tell you what reaches the agent and where the current gaps are. They cannot tell you how well the loop will work on your codebase because that depends on how your components are written and how well your agent understands the repository.
Eventually you have to stop evaluating the workflow and make it survive your actual codebase.
The useful test is small and annoyingly ordinary. Take a real change you've been meaning to describe in a prompt, make it on the page, then say Check Pixy and inspect what the agent does to the source. If it changes the right thing at the right scope in the right place, you have your answer. If you spend the next five minutes explaining what you actually meant, you also have your answer.
The next time you're about to write a paragraph explaining which button, which breakpoint, which spacing, and which version of "just this one" you mean, open the page and make the change instead.