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?
Top comments (2)
Still early days with Pixy, and I’m figuring out a lot of this as I build it. If you try it and something feels weird, annoying, or just doesn’t make sense, tell me. That kind of feedback is genuinely useful right now.
X: x.com/theastroscout
LinkedIn: linkedin.com/in/astroscout/
The visual delta answers what, and drops the thing the agent most needs, which is why.
"Make this container 80px narrower" is unambiguous as an outcome and completely ambiguous as an implementation. Did I want 80px less, or did I want it to line up with the card above it, or did I want it to land on the grid? Those are three different pieces of code: a magic number, a shared constraint, a token step. All three produce a pixel-identical result. They differ only the next time something moves.
So I would not frame the hard problem as capture fidelity. It is capturing intent alongside the delta, and that suggests something concrete. When someone drags an edge and it snaps, the snap is the intent, and it is the most valuable byte in the whole interaction. "Narrowed by 80px" hands the agent a magic number. "Aligned to the container above" lets it write a rule.
On your closing question: what I actually do is describe the change in terms of the system rather than the pixels. Next step down on the spacing scale, not 8px less. Slower to say, and the only phrasing that reliably produces code that survives the change after it.