Name Colors by Purpose, Not Appearance

Say you ask AI to build a website using blue (yes designers, I know there are 154+ shades of blue) as the main brand color.

It adds blue buttons, blue links, blue focus states and a few blue backgrounds. Everything looks good, so you continue building.

A few weeks later, your CEO decides the brand needs a breath of fresh air and should be green instead.

That sounds like an easy change. Just ask AI to replace blue with green, right?

Well more often than not you end up with 20% of the buttons still being blue, a few of the backgrounds defaulting to white for some reason and a single h3 is either blue or green depending on which phase the moon is currently in.

The problem is not that changing colors is difficult - it’s rather that the application was built without knowing what those colors were for.

The problem with calling blue blue

AI frequently adds colors directly to individual components.

For example:

<button className="bg-blue-600 hover:bg-blue-700 text-white"> Get started </button>

Even if you do not understand the code, you can probably spot the problem. This button has been told to be blue.

A better version would look something like this:

<button className="bg-primary text-primary-foreground"> Get started </button>

Now the button has been told to use the application’s primary color. The actual value of that color is defined somewhere centrally.

Today, primary might be blue. Tomorrow, it could be green, orange or caput mortuum (googled it, apparently it’s a color).

The button itself does not need to change.

Give each color a job

A well-organized application uses names that describe why a color exists, not simply what it looks like.

Common examples include:

• primary for main actions and important brand elements
• background for the main page background
• foreground for text displayed on that background
• muted for less prominent areas or information
• border for borders and dividers
• success for successful actions or positive statuses
• warning for something requiring attention
• destructive for dangerous actions and errors

The exact names can vary between projects. What matters is that they are defined centrally and used consistently.

If the project requires several shades of the primary color, names such as primary-100, primary-500 and primary-900 are still much better than blue-100, blue-500 and blue-900.

The primary palette can then change without every component needing to be renamed or rewritten.

The same color can have different jobs

There is an important detail AI can easily miss when reorganizing an existing project.

Two colors may look identical today but still serve different purposes.

Your primary brand color and the color used for information messages might both happen to be blue. That does not mean they should share the same name.

One should be called something like primary, while the other should be called info.

If you later change the brand to green, information messages can remain blue. A blind search and replace would not understand that distinction.

This is why you should ask AI to identify what each color is doing before it starts replacing values.

This also makes dark mode easier

Hard-coded colors regularly cause problems when adding dark mode.

A component that explicitly uses a white background and black text may look fine in light mode, but completely out of place when everything around it becomes dark.

Semantic names such as background, foreground, card and border can have different values for light and dark themes.

The component continues using the same names while the theme decides what those names currently mean.

A prompt you can reuse

You can give your AI coding tool instructions like these:

Audit the project for colors applied directly inside components, including literal hex, RGB and HSL values, as well as framework-specific color classes such as blue-500, gray-100 or red-600. Create a centralized set of semantic color tokens that describe the purpose of each color, using names such as primary, background, foreground, muted, border, success, warning, info and destructive. Update components to reference those semantic tokens instead of literal colors. Do not change the current visual appearance while reorganizing them. Do not blindly replace colors based only on their current value. Determine what each color is being used for. If the same value serves different purposes, create separate semantic tokens for those purposes. Keep legitimate exceptions, such as logos, photographs and data visualizations, where a specific color may carry its own meaning. Make sure the tokens support both light and dark themes if the application uses them. When finished, run the relevant checks and list any remaining hard-coded colors with the reason each one was kept.

You can also add this as a permanent instruction before AI builds the first component. That is much easier than cleaning up the entire application later.

Before changing the palette

Ask AI to show you where the color tokens are defined and confirm that ordinary components no longer contain direct color values.

Then changing the brand color should require editing a small number of centralized values rather than searching through the whole project.

Your website may be blue today. Your components do not need to know that.