The Design System Your AI Ignores

I've spent the last few months using an AI coding assistant (Cursor, though this isn't really about Cursor) to build against our internal design system — I'll call it Prism here, since the specific name isn't the point. We've got the components documented, we've got a skill/rules setup describing tokens, spacing, and usage patterns, and on paper that should be enough to keep every generated screen visually consistent with the ones before it. It wasn't enough. And the way it failed taught me more than the setup ever did.

The Pattern

Early in a session, the model uses Prism correctly. Right tokens, right components, right spacing scale. Then, somewhere between "early" and "an hour later," it starts reaching for things that don't exist in our system — a shadow value it invented, a spacing unit that isn't on our scale, a button variant that looks suspiciously like default Tailwind. I hadn't changed my instructions. I hadn't removed the rules file. The system prompt was still there, technically, in the context window.

So I stopped treating this as an annoyance and started treating it as a question worth actually answering: why does adherence degrade over a session, even when the instructions never left?

I ran something closer to an informal experiment than a rigorous one — no control group, no p-values, just repeated observation across real work — but the pattern was consistent enough to take seriously, and it turns out there's real research explaining exactly why it happens.

Three Things That Are Actually Going On

1. Position in context matters more than presence in context

There's a well-known 2023 Stanford/Berkeley paper, "Lost in the Middle: How Language Models Use Long Contexts" (Liu et al., later published in TACL 2024), that tested this directly with retrieval tasks. The finding: models are noticeably better at using information placed at the very start or very end of their context, and measurably worse at using the same information when it's buried in the middle — a pattern that held across every model family they tested. Your design-system rules, loaded once at the start of a long session, are exactly the kind of content that ends up "in the middle" an hour later, after the context fills with file contents, diffs, and back-and-forth.

2. Longer sessions degrade output even when nothing relevant changed

Chroma's 2025 technical report, "Context Rot: How Increasing Input Tokens Impacts LLM Performance" (Hong, Troynikov & Huber), tested 18 frontier models — including ones from the Claude, GPT, and Gemini families — and found that output quality drops as input length grows, even on simple tasks, and even well before the context window is anywhere near full. It's not that the model runs out of room. It's that more tokens, on their own, dilute how precisely the model attends to any one of them — including your rules file.

3. Multi-turn conversations are worse than the equivalent single-turn prompt — and errors compound

This is the one that maps most directly onto how people actually use Cursor: not one giant prompt, but dozens of small back-and-forth turns over a working session. A 2025 Microsoft Research / Salesforce paper, "LLMs Get Lost in Multi-Turn Conversation" (Laban et al., which went on to win an ICLR 2026 Best Paper Award), ran large-scale simulations comparing single-turn and multi-turn instruction-following and found an average 39% performance drop in the multi-turn setting — not mainly from the model getting "dumber," but from a sharp rise in unreliability: models lock onto an early assumption, and once they take a wrong turn, they generally don't self-correct. In their words, they "get lost and do not recover."

Put together, these three findings describe exactly what I was watching happen with Prism: the rules were present, but positionally weakened; the session got long enough for quality to drop on its own; and once the model made one small deviation from Prism — a wrong spacing value, an improvised component — it tended to keep building on that deviation rather than snapping back to the source of truth.

What Actually Changed the Outcome

None of this is really about prompting harder. Here's what moved the needle in practice:

• Scoped, file-triggered rules over one big prose doc. 

  Rules that reattach automatically whenever a matching file (*.tsx, *.vue, whatever) is touched behave very differently than a rules file loaded once and left to compete with everything that comes after it. Reinjection beats persistence.
  

• Concrete component code over descriptions of components.

  "Use Prism spacing tokens" is a sentence for the model to interpret. Three or four real, working Prism component snippets are something for the model to pattern-match against — a much stronger anchor once the session gets long and interpretation starts drifting.
  

• Shorter working sessions, deliberately. 

  Given that multi-turn degradation is now a documented, replicated finding and not just a vibe, starting a fresh session for each meaningfully separate task isn't paranoia — it's the direct, obvious mitigation the research points to.
  

• An enforcement layer outside the model entirely. 

  This is the one that actually matters most. Everything above reduces the rate of drift. None of it eliminates it, because compliance is still a probabilistic choice the model makes on every generation. A lint rule blocking non-Prism class names, a restricted import allowlist, a CI check that fails the build on raw hex values — these turn "please use Prism" into "the code doesn't ship otherwise." That's the difference between hoping for consistency and having it.

The Actual Takeaway

The instinct when a model stops following your design system is to write a longer, more emphatic prompt. Based on what I was seeing — and what the research backs up — that's treating the symptom. The rules didn't disappear from context; their effective weight dropped as the session went on, and once one deviation slipped through, the model tended to build on it rather than catch it. The fix isn't a louder instruction. It's shorter sessions, rules that reattach instead of just persisting, concrete examples over prose, and — critically — something outside the model that can actually say no.

Skills and rules files get you a strong first draft. They were never going to be the whole system, and now there's a decent stack of research explaining precisely why.