Point, don't drag

The drag-and-drop worked until the first list. I had built a canvas where a model generates the interface and the human nudges it around by dragging elements, halos and drop targets, the whole familiar kit. You could grab a card and move it and the underlying source rewrote itself to match. Then I rendered a list of five cards from one piece of code, tried to drag the third one, and the halo snapped to the first. Of course it did. Five cards on the screen, one expression that made them, and dragging asks “which source do you want to move” when the honest answer is that the source is not the thing you are pointing at.

That bug is not a bug. It is the shape of the problem showing through. When a model writes the interface, the screen and the source are no longer in correspondence. One loop becomes a hundred rows. One component definition becomes every instance of it. Drag-and-drop assumes you can pick up a pixel and find the one line of code behind it, and that assumption quietly dies the first time anything repeats, which is immediately, because interfaces are mostly repetition.

So I threw the dragging out and replaced it with pointing. You hold a key and click the element you mean, the specific rendered instance, the third card and not the expression that made it. The system records that selection as a fact: this instance, in this state, is what the human is talking about. Then you say what you want in words, and the model gets your sentence plus the identity of the thing you selected, and it rewrites whatever produced it. You are not manipulating the output. You are pointing at a piece of the output so the model knows which part of its own work your instruction refers to.

Pointing is only the visible half. It works because of what sits under the canvas, which is not a tree of components but a small relational document: typed tables of state, derived values computed from them, and views that are just code rendering that state. The model does not hand me a finished screen to manage. It mutates the document, and the screen falls out of the document the way a chart falls out of a spreadsheet. This is the part I find I have to say twice for it to land: the model is not generating an artifact you then own and edit. It is editing a live data model, continuously, and the interface is downstream of the data the whole time. Once you believe that, the unknown-component wall that every builder hits stops existing, because there is no fixed catalog of components for the model to fall off the edge of. There is state, and there is code over state, and the model writes both.

The document includes itself, which I did not plan and now would not give up. The toolbar, the side panels, the chat box I type instructions into: those are rows in the same tables and views in the same model as the app being built. So I can point at the toolbar and tell the model to change it, with the same gesture and the same sentence I use to change the app, and it does, because to the system there is no privileged editor chrome and ordinary content. It is documents all the way down.

The last piece closes the loop the way a person would. The model can ask to see what it rendered, take a picture of its own canvas, and read it back. An axis label is clipped, a column is too narrow, two things overlap: it notices the way you would notice, by looking, and fixes it without my telling it what was wrong. For a while I was the eyes in that loop, describing the visual mistakes back to it. Now mostly it sees them first.

I will not oversell where this is. It is one person’s canvas: there is no real story yet for two people in the same document, no permissions, no sharing with someone who only wants to use the thing and not build it. Those are the slots I left empty on purpose, because the bet I was testing was narrower than a product. The bet was that the right verb for steering a model that builds your interface is not drag. It is point. The first list told me that, and I have not found the case since where dragging wins.