Every AI design and coding tool I use is built around the thing it produces. The screen gets a canvas, a piece of interface gets a preview, the code gets a side-by-side view of what changed. The problem it was solving gets a text box, and the text box scrolls away. There is no place in these tools for the brief, for the options that were considered, for the constraint that cannot move, or for the reason the last version was thrown out. So each time the tool generates something new, that knowledge is gone, and the only thing left is the output.
That is a flaw in the tools, not a habit of the people using them. You can be as disciplined as you like about understanding the problem first. If the tool has nowhere to keep what you understood, it does not survive the next run.
The right argument, one step short
Karri Saarinen made the designer's half of this case in Output isn't design (opens in a new tab). He borrows Christopher Alexander's idea that design is the search for a fit between a form and its context, and argues that the new generation of tools treats design as the production of interfaces, when the difficult part is understanding the problem well enough to know what should exist. His verdict on products built mostly by generation is exact: "The form is there. The fit is not."
His answer is about practice. Stay close to the problem, work visually and by hand, give the thinking time, because the understanding forms while you work. I think that is right, and I think it stops one step short. The understanding he describes has to live somewhere once the session ends, and the tools give it no address. A designer who does everything Saarinen asks still loses that work at the edge of the session, because the tool keeps the form and discards the context.
What the surface tells you
You can read a tool's priorities off its interface. Look at what gets space, what gets kept, and what gets a button.
The output gets all three. It is the largest thing on screen, it is saved, kept in versions and exportable, and there is a button to make another one. The reasoning gets none. It lives in a chat column, if it lives anywhere, as a linear transcript attached to nothing it produced. Nothing in the result points back to the sentence that caused it. Nothing in the transcript is marked as a decision rather than a passing remark.
Regenerate is a delete button with a nicer name
The most telling control is the one that makes a new version. Press it and the previous output is replaced. It was not rejected, because rejection would need a reason, and the tool never asks for one. The next generation has no idea what was wrong with the last, so it is free to wander back to it, and it often does.
History records states, not reasons
Undo and version history are thorough about what the thing looked like at each step. They hold nothing about why it changed. Scroll back through twenty versions of a screen and you can watch the spacing shrink and the button move, and you cannot tell which of those moves was a decision and which was the model drifting.
Every constraint is equally soft
A prompt is flat text. "Use our colours", "keep it friendly" and "this amount must never be rounded" arrive with the same weight, and nothing in the interface lets you mark one of them as immovable. I have written about checking output against the constraint that cannot move; the tools give you no way to tell them which one that is.
This is the same loss I described in the handoff, where a design file arrives with its reasoning stripped out. The difference is that a handoff loses the reasoning between two people. A generation tool loses it between you and yourself, ten minutes later.
Why the tools look like this
Output is what demos. A tool is judged in its first minute, on how good the first result looks, and a first result needs no history. Reasoning pays off on the twentieth generation, in the second week, when someone new joins, and no evaluation reaches that far. So the surface is shaped around what gets measured, and what matters later gets a text box.
Underneath that sits an assumption: that the prompt is the brief. It is not. A prompt is an instruction for one run. A brief is a standing description of the problem that every run should be checked against. Treating the first as the second is why a session that opened with a careful description has drifted away from it by the tenth exchange. The description is still there, forty messages up, carrying no more weight than anything said since.
A tool that kept the reasoning
This does not need a new kind of model. It needs an interface that gives the reasoning the same standing as the output. Concretely:
The brief is a pinned object, not the first message
A panel beside the canvas holds the problem, who it is for, and what done means. It is versioned and editable, and every generation runs against its current version rather than against whatever was typed most recently. Change the brief and the tool can show you which outputs were made against the old one.
Constraints have a strength, and some are locked
Each constraint is a row with a hardness: fixed, preferred or open. Fixed ones are checked on every output, and a result that breaks one is flagged before you see it, not after you ship it.
Rejecting costs one sentence
Dismissing an option moves it to a rejected shelf, with a required line of reason. The shelf stays visible, and the generator reads it. "Too dense for someone paying for the first time" is something a model can respect on the next run. A silent regenerate is not.
Decisions attach to the element
Accepting an option records why, and the record hangs off the thing it decided. Select a component and you see its decisions, the way a code editor shows who last changed a line. Export the component and the decisions travel with it into the code.
History is a tree, not a scroll
Abandoned directions stay as branches, labelled with why they stopped. Going back to try an earlier idea becomes a move on a map rather than a hunt through a transcript.
Each of these is ordinary interface work. They are missing because the tools were designed around a different idea of what the work is.
What I do in the meantime
Because the tools have no place for reasoning, I built one beside them. My coding agents read a set of conventions before they start, write a decision record for any choice that is not obvious, and keep my corrections verbatim before interpreting them. I have described how that system works and will not repeat it here.
What matters for this argument is where it lives: in plain text files kept with the code, outside every tool I use. The conventions file is the pinned brief. The decision records are the rejected shelf. The feedback log holds the reasons a regenerate button never asks for. I rebuilt, in text, the half of the interface the tools left out.
It works, and it is a workaround. It depends on me keeping the files honest, and it only covers work that ends up in code. A screen explored in a design tool and discarded leaves nothing behind, because there was nowhere to write down why.
The missing half
A tool's surface is its argument about what the work is. Today's tools argue that the work is the thing produced, and they are very good at producing things. The work I am paid for is mostly the part they have no screen for: knowing what the problem is, what was tried, and why the obvious answer was wrong.
The tools remember everything I made and nothing I decided.