The model starts from zero

A prompt does not arrive with your last mistake. It arrives fluent, finished-looking, and empty of the afternoon you spent fixing a screen. The training data has plenty of tables. It does not have the one that broke for you.

The work that made a product specific was rarely the first draft. It was the revision after something failed in a hand. A dense row on a small screen. An empty state that said nothing a person could use. A color copied until it no longer meant one thing. Someone who was there carries that into the next screen. A model starts the next screen from zero.

A new person, every time

The honest picture of a prompt is a new teammate. They have read widely. They were not in the room when a table wrapped and the action slid off the edge. They will build a reasonable table. Reasonable is how an old bug returns inside a clean diff.

You cannot paste the afternoon into the context window and call it culture. A thread goes stale. A decision written in a doc gets skipped when the deadline moves, by people and by models. What survives is the thing the next change has to pass through.

Put the scar in the component

An empty state written fresh on each screen will keep coming back as “No results.” The person in front of it learns nothing about what is missing or what they can do. An EmptyState that already uses the product's words, and already says what to do next, hands that sentence to every prompt that composes it. The model does not need the story. It needs the component the story produced.

The narrow screen works the same way. A table primitive that already collapses, keeps the label with the value, and leaves the action in reach has absorbed the break. A prompt that uses it has a hard time shipping the version that failed. A prompt that emits a new table has an easy time, and the result will look done.

A lint rule that rejects a raw color still earns its place. It blocks a class of mistake you can name before anyone makes it. A primitive holds a different kind: this product, this failure, and the decision you made after.

Only encode what cost you

Not every argument belongs in the system. A debate that was really about preference can stay in review, where a person is supposed to have a point of view. I write down the decisions that were expensive when they were wrong.

• What the screen says when there is nothing to show, in the product's own words.
• How a dense row behaves on the viewport that already failed.
• Which name is a meaning, so the next prompt does not mint a one-off value for the same idea.
• What a person may trust while the data is still arriving.

If I cannot point at the component that holds the decision, the decision is still a memory. People leave. A prompt never had the memory to begin with.

Ask it to make the old mistake

Take a screen you have already paid to fix. Ask a model to build it again, and give it no extra instructions about the last failure. If the old break comes back, the lesson was remembered by someone and stored nowhere the prompt can touch.

Then put the lesson in the primitive and ask a second time. The draft should get boring. Boring is the result you want. The prompt still started from zero. It could not take the path that broke, because that path no longer exists on the way through the system.