I started giving my AI agent a “don’t change” list before UI work
I noticed something annoying with AI-assisted frontend work.
The agent could implement the requested feature correctly...
and still make the product feel slightly worse.
Not because the code was broken.
It would change things like:
spacing conventions
button hierarchy
loading states
empty states
navigation patterns
component behavior that already existed elsewhere
Each change looked reasonable on its own.
The problem was that the agent was optimizing for the feature in front of it, not the consistency of the product around it.
So I started adding a small section to my implementation requests:
DO NOT CHANGE
Existing navigation pattern
Shared button component
Existing loading behavior
Page spacing system
Empty-state pattern
Then I explicitly tell it:
Reuse existing patterns before creating new ones.
It's a surprisingly small addition, but it changes the output.
The agent has a clearer boundary around what "correct" means.
I'm starting to think that with AI coding, a good specification isn't only:
"What should I build?"
It also needs:
"What should remain untouched?"
Curious how others handle this with AI-generated UI:
Do you give your agent explicit constraints about what it must not change, or do you rely on it discovering the existing design patterns itself?
Replies
The list works, but keeping it in the request is not the strong part. It only protects the requests where you remembered to paste it, and the next user on the repo has no idea it exists.
Mine lives in a file the agent reads every session. The useful shift was writing the entries as "reuse this or that" with a path instead of "do not change this". Do not change tells it to avoid something, a path tells it where the button component actually is, and that is what stops it building a second one.
The rules I trust are the ones a machine checks. We have lint rules for the code style ones and a test that fails when a pattern we deleted comes back, so CI corrects the agent even when nobody remembered the rule. That covers maybe 50%+ your list though. Spacing, empty states and button hierarchy have no test I know how to write, so those stay in a file that keeps growing, and past some size the agent starts skimming it. No answer for that part yet 🙃.
@siarheihamanovich This is a really useful distinction.
I like the shift from "don't change this" to "reuse this, and here's exactly where it lives." That's much more actionable for an agent.
The persistent file also makes more sense for a long-running project. A constraint that only exists in my prompt is easy to lose, whereas putting the rule where every session can see it gives the project some actual memory.
And I agree about machine-enforced rules. The things we can turn into linting or tests are much safer than relying on the agent or human to remember them.
The part about spacing, empty states, and hierarchy is probably the harder problem. Those are product conventions that are obvious to a human looking at the whole UI, but much harder to express as a rule the machine can reliably enforce.
@evolvix_ai The spacing and button parts might be more testable than they look.
Our buttons come from one variants file: a fixed list of variants and sizes, and every button in the app takes one of those names. A test asserting that list is exactly the set we agreed on turns the fourth button variant Molly described into a red CI run, because the agent has to edit the list to invent one. Spacing works the same way when it comes from a scale. In Tailwind the tell is the arbitrary value, p-[13px], so a check that fails on that pattern catches invented spacing without anyone having to judge whether the design is good.
Both checks may catch a new vocabulary, not wrong use of the existing one. The agent can still reach for the small padding where the convention is the large one
Explicit constraints, definitely, I stopped trusting "it'll discover the patterns" after watching an agent invent a fourth
button variant in a codebase that already had three. I'm on the ops side of the house (shipping internal dashboards,
not core product), so my version of your DO NOT CHANGE list is a small "design constitution" file — spacing scale, approved components, and one rule at the top: reuse before you create.
It gets pasted into every request. The other trick that helped: before any code, I ask the agent to list which existing components it plans to reuse. If that plan invents something new, I catch it there instead of in the diff.
@jaden1826_del The "design constitution" idea is great.
And I really like the extra checkpoint of asking the agent to list the components it plans to reuse before writing code.
That makes the constraint actionable instead of just defensive.
The fourth-button-variant problem is exactly the kind of thing I'm trying to prevent. Each new component can look reasonable in isolation, but the product slowly loses consistency.
I'm going to experiment with combining the two ideas: a persistent design-rules file + a reuse plan before implementation.