Change your app's UI without describing it

You shipped a dashboard. This week's design work is six small things. The Create project button belongs in the header. The sidebar is too wide. The page heading should be 26px instead of 32px. The cards need more space and less rounding. On a phone, they should stack into one column.

None of that is hard to build. Describing it is.

"Move the button into the header" needs to say which header and where inside it. "Make the sidebar narrower" needs a width. Changing 32px to 26px needs another sentence, because the same rule is used on five other screens. Four of the six changes are one CSS value each, and writing the instruction takes longer than making the change.

Edit the running app

Open your project on Pixy, press Copy instructions, and paste them into your coding agent. It asks where you want Pixy, installs the tag, takes its own key, and teaches itself the rest. If you would rather not touch the site at all, install the Chrome extension instead.

Then press ⌘⇧E and the page in front of you becomes editable.

It is still your running app. The project rows came from the server, your own permissions are the ones in force, and the trial badge is there because this account is on a trial. The menu you left open stays open. Nothing is copied onto a canvas or rebuilt somewhere else, so the states you can't mock up are available to edit too. Pixy works on the rendered page, whether it came from Next.js or anything else.

Make the six changes

1. Move Create project
   Drag the button into the header. Pixy records the container it landed in and the element it now comes before, so your agent moves it in the template instead of inferring a position from a screenshot.
2. Narrow the sidebar
   Grab its right edge and pull. The change is attached to that sidebar on that page, and nothing else changes width with it.
3. Resize the heading
   Open the CSS tab, find the rule setting the heading size, and change 32px to 26px. The other five screens follow because they use the same rule.
4. Increase the card gap
   Change the gap on the grid rule. One value updates the spacing between every card.
5. Reduce the corner radius
   Change the radius in the same rule. Pixy records the property, its previous value, and its new value.
6. Stack the cards on mobile
   Pull the frame to 390px and set the grid to one column. If the change can't be made directly, select the cards and press C to leave a note. Both go into the same batch and stay attached to the same cards.

That is the design pass, start to finish.

The CSS rule sets the scope

Changing one card and changing every card look identical on screen. In the code they are different changes.

Pixy gets the scope from 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 one hits. Change a value inside a rule and the change is addressed to that rule. Every match updates, and your agent makes the corresponding change once in the code.

Change the value in element.style instead and the edit is addressed to that element on that page.

One card or every card. The edit says which.

How far a change reaches is part of the change, not something you explain afterwards.

Responsive changes include the width

Pixy records the artboard width with every change. Pull the frame to 390px and your own CSS reflows through its breakpoints, so you edit the layout in the state where the problem appears.

Set the cards to one column at 390px and your agent receives the value together with the width you set it at. It changes the mobile layout and leaves the base grid style alone.

A comment works the same way when the fix can't be expressed as an edit. The note stays attached to the cards and goes over in the same batch.

Say Check Pixy

That is the whole handoff. No packaging step, no export, nothing to copy.

Your agent pulls the six changes with the key it stored during setup, makes them, and reports each one built, declined, or postponed. Whether it builds straight away or shows you the batch first and waits for your yes is the answer you gave it at setup. A change stays open until it gets one of those three answers, so closing the terminal costs you the terminal and not the work.

What arrives in your editor is a diff. Review it as code.

Stop writing instructions for visible changes

Between them, the six changes carry position, width, size, spacing, scope and breakpoint. All of it is settled the moment you make them on the running page.

So make the edit instead of translating it into a prompt. Pixy records what changed, which rule it belongs to, and the width you were working at, and your agent gets all of it.

The six changes above take about two minutes on the page. Writing them out took the first two paragraphs of this post, and those are the paragraphs you stop writing.

Make your next batch from your projects, then say Check Pixy.