I’ve been working on a project called Pixy. The idea came from a pretty simple problem: coding agents are great at making changes, but explaining visual changes to them can still be annoying.
If I want a section to be narrower, a heading moved slightly, or the spacing changed at a particular breakpoint, I have to describe all of that in a prompt. For more complicated changes, I might take a screenshot, mark it up, and then explain what I meant anyway.
With Pixy, you can just make the change visually.
Your website becomes the canvas
You add one script tag to your website and Pixy adds a visual editing layer on top of it. You can select elements on the actual page and change things like spacing, size, position, typography, and layout.
It feels similar to using a website builder, except there isn’t a separate version of the website sitting inside Pixy. You’re working with your real site, so there’s nothing to redraw or keep in sync with a design file.
The main difference, though, is what happens after you make those changes.
Passing the changes to a coding agent
Pixy keeps track of the visual changes you make and can pass that information to a coding agent.
Instead of writing a prompt like “make this container 80px narrower, increase the gap between these elements, and use a smaller heading on mobile,” you can make those changes directly on the page and let the agent read them.
The agent can then work in the actual codebase and figure out how those changes should be implemented.
This separation is important to me. I don’t want Pixy to generate or own the application code. Your codebase stays the source of truth. Pixy is just the interface you use to show the agent what you want.
It also means there’s no export step. You don’t have to recreate the design somewhere else, send screenshots to the agent, or write a long prompt describing something that is much easier to show visually.
Working with other people
I also wanted the same interface to work when more than one person is involved.
Pixy has multiplayer built in, so several people can be on the same website and work through changes together. There are also video meetings built into it, which means you can open the site with someone, talk through what needs changing, and make those changes while you’re discussing them.
This is especially useful for reviews. Instead of having a call open in one app, the website in another, comments somewhere else, and then translating all of that into instructions for an agent, the discussion and the visual changes can happen in the same place.
Why I’m building it
AI has made writing and changing code much faster, but communicating what we want is still a bottleneck.
For many programming tasks, text is exactly the right interface. For visual work, I’m not convinced it always is. If I can show an agent exactly how I want a page to look, that seems more useful than spending five minutes trying to describe it.
That’s what I’m trying to do with Pixy: give humans a visual interface for communicating with coding agents, while leaving the actual implementation to the agent and the codebase.
It’s still a recent project, so I’m curious how other people are handling this today. If you use coding agents for frontend work, how do you usually communicate visual changes?
