How we name what the system cannot do,
what the design cannot break,
and what must remain stable

_{—Part of CSS Primer for the AI Era — CSS Communication Toolkit}

AI does not sense limits.
It does not feel risk, cost, or fragility.
If we do not name the constraints,
AI assumes freedom — and freedom in the wrong place becomes damage.

So, the sixth communication skill is simple:

We express the constraints of the system
before AI begins the work.

Constraints are not restrictions. \\They are the architecture that keeps the system real.

When we say:

“Don’t break the layout”

“Keep this stable”

“Don’t change too much”

AI cannot interpret these phrases.
They describe fear, not structure.

AI needs constraints that are:

• explicit
• structural
• grounded in the system
• tied to real consequences

A simple truth:

AI respects limits only when we name them.
So, we name them clearly.

Every system has four kinds of limits:

1. Structural constraints
   What the architecture cannot change.
2. Historical constraints
   What past decisions protect.
3. Behavioral constraints
   What must continue to work.
4. Design constraints
   What keeps the visual system coherent.

When we name these,
AI understands the real boundaries
of the work.

Let's see some examples.

Structural constraints protect the architecture.

We say:

“We cannot change the HTML structure.”

“We must keep this grid intact.”

“We cannot introduce new classes.”

“We must preserve the component API.”

“We cannot reorganize the layout.”

These are non‑negotiable.

A simple principle:

Structural constraints protect the
shape of the system.

Historical constraints protect decisions made for reasons AI cannot see.

We say:

“This spacing scale is historical — do not modify it.”

“This naming pattern is legacy — keep it consistent.”

“This layout supports older content — do not refactor it.”

“This selector is fragile — avoid touching it.”

History is invisible to AI.
We reveal it.

Behavioral constraints protect how the system works.

We say:

“This must remain responsive at all breakpoints.”

“This element must stay in normal flow.”

“This component must not overlap adjacent content.”

“This interaction must remain unchanged.”

Behavior is
the lived experience of the system.
We protect it.

Design constraints protect coherence.

We say:

“Use only the existing color scale.”

“Follow the spacing scale.”

“Keep the typography consistent.”

“Avoid introducing new decorative elements.”

“Maintain the existing hierarchy.”

Design is a system, not a palette.
We name the rules that keep it whole.

A complete constraint statement looks like this:

“We want this section quieter.
Use the existing color scale.
Do not introduce new shadows or borders.
Keep the spacing scale unchanged.”

Or:

“We want this layout to adapt on small screens.
Do not change the HTML.
Keep the grid structure intact.
Maintain the existing responsive pattern.”

Or:

“We want this element centered.
The parent container is fixed — do not modify it.
The siblings are fragile — avoid touching them.
Keep the behavior stable across all breakpoints.”

Constraints give AI the real limits
of the system.

When we express constraints clearly:

• AI stops refactoring
• AI stops redesigning
• AI stops unifying patterns
• AI stops rewriting the system
• AI stays within the real limits
• the change stays small
• the system stays stable

A simple reminder:

Constraints are not obstacles.
They are the shape of the system.

When we name constraints and limits:

• we protect history
• we protect structure
• we protect behavior
• we protect design
• and we protect the collaboration itself

A simple closing thought:

Constraints are
the real boundaries of the system.
We name them,
and AI learns to work within them.

• Suggested Next Reading: How to Describe Relationships Between Elements

_{Tony de Araujo —New York | Lisbon}

• Top↑
• Back to Topic ↔
• Home←