Don’t Change Anything Else

I have started adding a strange sentence to more and more of my prompts: don’t change anything else.

It usually appears after a task that sounds almost embarrassingly small. Make the mobile arrow look more like the design. Move the skills navigation to the bottom of the page. Add the HAAM sticker to the other interactive tools. Preserve the desktop layout. Keep the existing animation. Do not redesign the component. Don’t change anything else.

This is very different from how I spoke to AI when I began building websites with it. The early prompts were open and optimistic. Build the page. Try an interaction. Make the transition feel more physical. What if the input bar moved down while the bird flew away? I was describing feelings and the AI was turning them into working interfaces, sometimes in a few minutes. It felt like the distance between imagining something and seeing it had collapsed.

Then the website accumulated history.

One arrow already had a relationship with another arrow. A movement on one page had established what horizontal motion meant in the rest of the site. The spacing around a card had been adjusted several times until it felt right, although I could no longer explain exactly why. The site had started to contain decisions that were larger than the individual elements carrying them.

The AI could see the code, but it could not reliably see this history.

I would ask it to fix an icon and it would also adjust the container. I would ask it to improve a mobile interaction and discover that the desktop version had changed. It would recreate a component that already existed, close enough that I might not notice immediately, but with a different radius, another spacing value or a slightly more generic animation. Each decision was defensible. The result would often look polished. Yet after enough reasonable changes, the website would begin to feel as though several designers had worked on it without ever speaking to one another.

People building with AI seem to arrive at this stage through remarkably similar routes. One Lovable user described becoming technical support for friends who had started making applications. A friend built a client dashboard in two days. Then she tried to add a date filter across several views and spent an entire weekend prompting the system. By Sunday, the application was worse than it had been on Friday. The person telling the story said the first few days of these projects were always magic. After about a week, every request began touching several interconnected parts, and the prompts started including some version of “don’t break the existing functionality.”

There are now whole guides in AI-builder communities about how to stop your interface from morphing every time you touch it. People describe becoming afraid to prompt a page that currently looks acceptable. A request to change the navigation causes text elsewhere to become white on white. A new feature quietly creates a third version of an existing card. Someone asks Claude to work on a large website and watches it invent new styles, modify earlier layout choices and gradually lose the original brand intention. Someone using Cursor finds that each page comes back with different colors and spacing, as though the design system were being reconsidered from scratch every time.

These stories are usually discussed as technical problems. The recommended answers are sensible: reusable components, design tokens, Storybook, visual regression testing, project instruction files, stricter prompts. But I think the feeling underneath them is more interesting. The builder has moved from excitement about what the machine can create to anxiety about what it might erase.

The first version of an AI-generated project feels almost weightless because there is so little to protect. The machine is free to generate. The builder is free to reject everything. Once choices have accumulated, generation becomes more complicated. A new answer is no longer competing only with an empty page. It is competing with all the decisions that already survived.

Traditional production placed a certain amount of friction around those decisions. A new component had to be designed, discussed and built. Even a mediocre team was forced to remember that the product already contained other components. AI removes much of that friction. Creating a fresh solution can be easier than understanding the existing one. The machine can make another card before it has finished discovering why the previous card looks the way it does.

This reverses an old constraint. Production used to be expensive, so reuse was economically attractive. Now production is close to free, while coherence remains expensive.

I saw a developer describe an “Iron Man moment” while designing an interface with AI. He could tell it to move something, reduce the emphasis, change the layout and immediately see another version. He reached a visual direction that he did not think he could have designed alone. Then he looked at the implementation and found it impossible to maintain. The interface worked and looked right, but the code was a dead end, so he rebuilt it manually while using the generated version as a reference.

The story contains two different kinds of success. The AI helped him reach an idea. It failed to preserve the conditions required to continue developing that idea. The first achievement was visible. The second failure was hidden inside the next change.

This may be one reason AI-generated products can feel so impressive in screenshots and so fragile when they become ongoing projects. Most demonstrations end at the moment when the interface appears. Real products begin there. A product has to survive its next feature, its next breakpoint, its next contributor and its next supposedly minor repair. It has to remain itself while changing.

Even experienced people can struggle to see the failure when it occurs outside their own discipline. A developer immediately recognizes bad code while accepting a visually mediocre interface because it appears functional. A designer may recognize that the interface has lost its character while failing to notice that the implementation has become structurally impossible to extend. AI gives both of them the sensation of unusual competence in the area where they may have the weakest ability to judge the output.

The visual problem also moves in two opposite directions at once. Between products, AI creates sameness. Within one product, it creates fragmentation.

Designers have started documenting the shared aesthetic fingerprints of AI-made websites and presentations: cream backgrounds, rusty orange accents, oversized serif headlines, outlined rectangles, generous empty space, rounded dashboards, little dots, ticker-like labels and perfectly tasteful combinations that begin to feel suspicious after you have seen them enough times. A designer was recently shown sales decks from two unrelated companies. They followed almost the same visual structure, down to the sequence of mission statements, market diagrams and strategic declarations. The logos were different. The design was effectively the same.

At the same time, an individual AI-built product may contain three almost identical buttons, several spacing scales and slightly different interpretations of its own visual language. Everything begins to resemble everything else, while the parts of one website stop resembling one another.

This is why “generic AI design” and visual drift are related but distinct problems. Generic design is visible immediately. Visual drift often appears only when comparing the current product with its earlier self. The website still looks competent. It may even look better according to conventional measures. Something more difficult to name has weakened.

With HAAM, the loss often appears in details that seem too small to carry much importance. An external-link arrow becomes a familiar icon rather than the awkward little shape used elsewhere. The strips representing an intermission become visually cleaner while losing the actual features of the interactive tool. A HAAM sticker appears on one experience but not the others, making something intended as a recurring signature feel accidental. An animation works, yet its direction no longer corresponds with the navigation logic of the site.

None of these changes destroys the interface. They reduce the number of relationships inside it.

I am beginning to think taste mostly exists in those relationships. It is tempting to describe taste as a collection of properties: these colors, this typeface, these radii, this animation speed. Those properties can be written into a design system and handed to an AI. But the difficult part is often why one element should break the system, why two screens should feel related without being identical, why an imperfection carries more personality than the technically improved alternative.

The machine can be told that the spacing value is sixteen pixels. It is harder to tell it that the slight awkwardness of an object is the reason the page feels made rather than generated.

Companies working seriously with coding agents are starting to build memory around this problem. Vercel has described placing accepted product decisions inside its repositories so agents can understand more than the final code. Code tells the agent what shipped. It rarely explains why the team chose it, what alternatives were rejected or which seemingly unimportant details became standards after a design review. That reasoning usually survives in Slack conversations, comments, meetings and the minds of people who were present.

An agent entering the repository later resembles a talented new colleague who has access to every file but attended none of the conversations. It knows the outcome without inheriting the instinct.

Every prompt effectively hires another version of this colleague. It may be extremely capable. It may read the documentation. It may inspect the existing components. It still arrives after the decisions were made.

The obvious response is to document more. I am already doing this through components, screenshots, design instructions, tests and increasingly specific prompts. A project that began with natural-language descriptions of feelings gradually develops a legal code. Use this component. Preserve these states. Never invent a new icon without checking the existing set. Do not modify unrelated files. Here are the screenshots. Here are the rules. Here is what horizontal movement means.

Some of this works. It turns preferences into infrastructure. The AI has less freedom to produce plausible alternatives and a better chance of continuing the system already there.

But there is something slightly absurd about using a machine to make production effortless and then spending so much effort preventing it from producing. I ask it to generate freely, choose what I like and then build fences around those choices so that the next generation does not wash them away. The creative process begins with abundance and slowly becomes conservation.

A Claude Code user described spending a week turning preferred visual decisions into design tokens. Before that, he had asked the AI to create dozens of experimental pages, selected the parts he liked and combined them. This may be the emerging rhythm of AI-assisted design: generate far too much, recognize a few things worth keeping and then convert those recognitions into constraints.

The human role shifts somewhere during this process. At first I feel like a director, asking for things that did not previously exist. Later I feel more like an archivist or custodian. I remind the system what happened before. I protect certain decisions from being optimized away. I compare the current version with screenshots because I am no longer confident that either of us remembers exactly when the site started to feel different.

Perhaps this is still design. Designers have always maintained coherence across changing requirements, technologies and teams. AI only makes the conflict more visible because it can propose another reasonable future almost instantly. The difficulty is no longer obtaining possibilities. It is sustaining a relationship with one possibility long enough for it to develop an identity.

This is also why “don’t change anything else” feels more significant than a technical instruction. It is a request for continuity. It assumes that what already exists contains value beyond the part currently being discussed. It asks the machine to recognize that an object has a past.

I still want AI to surprise me. I do not want to turn the entire process into the mechanical enforcement of a finished system. Some of the best parts of the work appear when the machine misunderstands me in an interesting way or produces something I would not have considered. The problem is that surprise and amnesia can look similar at first. Both create difference. Only one extends the work.

I used to think the main challenge was explaining what I imagined clearly enough that the machine could make it. Increasingly, I find myself trying to explain what has already been made clearly enough that it can survive the next idea.

Then I look at a tiny arrow that has somehow changed again, open the prompt box and write: fix this one thing. Keep the rest exactly as it is. Don’t change anything else.

Connected reading

• The Edits Are the Training Data
• The Real Test of AI Code Is the Next Prompt
• AI Knows Visual Styles We Barely Have Names For
• The Prototype Has Become Too Cheap to Trust

AI authorship note

This essay began with Kris Haamer noticing that he increasingly ended prompts for small HAAM interface changes with “don’t change anything else.” AI helped research visual drift, design-system divergence, and firsthand accounts from people using Lovable, Claude Code, Cursor, and other AI development tools. Kris chose the central argument, connected the practitioner stories to his own work on HAAM, pushed the writing toward full exploratory paragraphs, and approved the final version for publication.