Coding agents made building cheap. Describing is the expensive part now.

My agent wrote an authentication flow last week from a paragraph of description. Sessions, one-time codes, and rate limiting I hadn't thought to ask for. It took four minutes and I barely read the diff.

The next hour went to a heading that was too big.

"Make it smaller." Smaller than that. Now it's too close to the paragraph under it. No, keep the size and move the whole block up. Not that much. Eight messages in, I was still trying to describe a distance in words, which is the thing words are worst at, and the agent was still guessing.

That gap is strange once you notice it. The hard part, the logic and the wiring I'd have spent a day on, came free. The easy part, the one I could have done with my hands in half a second, turned out to be the expensive one.

The bottleneck moved

For twenty years the slow step in building software was writing it, and everything about how we work is shaped by that. You design first because implementing a design costs a lot and you want to be sure before you spend it. You spec it, review it, sign it off, and only then does anyone touch code.

Agents deleted the expensive step. Implementing is the cheap part of the loop now. What's left is the description: getting the intent out of your head and into a form something else can act on, precisely enough to be worth acting on.

For anything visual, that transfer is terrible. You know exactly what you want. You can see it. You just can't say it, because the way you know it is visual and the channel you've been given is a text box.

Mockups solve the wrong half

The obvious answer is a design tool. Draw it, then point the agent at the drawing.

I tried that for months. It never quite worked, because a mockup isn't your product. It's a picture of your product drawn in a different medium, and most of what's interesting about your actual page is missing from it: the state, the content that came back from the server, the dropdown that's only open for a moment, the empty state, the page that only exists after you've clicked three things.

So you draw the parts that are drawable. Then the export lands in front of your agent as a pile of divs with absolute coordinates, and it has to work out which numbers you meant and which are artifacts of a canvas that doesn't know your codebase exists. Half the round trip goes on undoing that guess.

The drawing was never the problem. Producing a picture of what I want has always been easy. The problem is that a picture has to be translated, and the intent leaks out during translation.

So skip the picture

The version that worked is embarrassingly simple. Edit the real thing.

You paste one script tag into your site. There's no build step and no plugin to install, it's just a script, and it goes on localhost or staging or production, on whatever stack you're on. Press a shortcut and the page becomes editable. The page itself, still running, with the same DOM and styles and session it had a second ago. The dropdown stays open while you restyle it. State stays alive, because nothing was copied and nothing was re-rendered.

Drag the heading where it belongs. Pull the button's handles until it's the width you meant. Click into the sentence and rewrite it. Change a colour or a radius or a font size, and watch the actual element change, in the actual layout, next to the actual content.

None of that is new as an interaction. Browsers have had devtools forever. What's new is what happens after.

The record is the product

Every change you make is captured as a structured edit: the element, the property, what it was, what it became. It's a list of intentions in a form that survives being read by something that isn't you, rather than a screenshot or a diff of generated CSS.

Your agent pulls that list and implements it in your source code, in your framework and your components and your git history. It's applying a spec you produced with your hands in about eleven seconds, instead of reverse-engineering a picture. The ambiguity that used to fill eight messages didn't get resolved by a better prompt. There was nothing left to be ambiguous about.

You show, the agent ships.

What that lets you design

The thing I didn't expect is how much this widens what you can work on at all.

Anything that only exists at runtime has been more or less undesignable. You can't draw a page that's assembled from a database. You can't mock the seventh item in a list that's only long on production. A modal in a static canvas doesn't really feel like anything.

When the canvas is the running page, all of that is just a page you're looking at. Log in and design the logged-in view. Load the customer account that's always the one that looks wrong, and fix it there, on their data, in the layout that actually broke.

Try it before you install anything

This site runs Pixy, and the page you're reading is editable. Press ⌘⇧E, or use the button on the landing page, and start dragging things around. Nothing is saved, nothing leaves your browser, and it all disappears when you reload.

When you want it on your own site, get a free key. Free is the whole editor on one project, with no card and no trial clock. Pro is $29 for unlimited projects and a longer history.

I built this because I got tired of typing "a bit to the left." If you've typed it too, I think you'll get it in about thirty seconds.