The Informal Contract Is Over.
Issue #66
A promise is a strong word. Most teams reach for softer language: guidelines, patterns, recommendations, standards. We build component libraries with the implicit hope that people will follow them, and we write documentation with the quiet understanding that most of it will not be read. We have grown comfortable with the gap between intention and adoption, and we have learned to call that gap “maturity.”
But the gap is closing, and not because teams have suddenly become more disciplined. It is closing because agents do not read documentation. They read structure. They read naming. They read the shape of the API and the logic encoded in the token. When a machine consumes your design system, it does not interpret intent. It executes whatever you actually built, not what you meant to build. The informal contract that humans could navigate by instinct becomes a hard boundary an agent will test without mercy.
This changes what it means to maintain a design system. Naming conventions that were always best practice are now functional interfaces. Tokens that drifted quietly for months are now producing inconsistent outputs at scale. A codebase that bypassed the system for the sake of speed is now a liability that compounds with every agent-generated pull request. The work that teams quietly deferred has not gone away. It has simply become more visible, and considerably more expensive.
The question worth sitting with is not whether your design system is ready for AI. It is whether it was ever as solid as you thought it was.
In this issue
📚 Featured Articles
💡 Monthly Signals
📰 Published in the Last Week
✨ Inspiration
🎗️Support us
📝 Closing Thoughts
📚 Featured Articles
Must-read articles at www.designsystemscollective.com.
💡 Have an article to share? Submit it here!
Your Design System Is Not Failing. Your Codebase Is Bypassing It. by George William Amalan
Why We Like It: A granular, engineering‑first examination of how code bypasses tokens and components, with pragmatic enforcement patterns you can apply immediately.
Pro Tip: This article is a playbook for turning design tokens into enforceable infrastructure. It includes concrete examples—ESLint rules, Style Dictionary config and component patterns—that make it easier to stop token drift and make the design system the path of least resistance for engineers.
Every component in your design system is a promise by Murphy Trueman
Why We Like It: A sophisticated unpacking of contracts versus documentation and why machine‑readable contracts matter now that agents consume systems.
Don’t Miss: A clear framework for encoding intent—typed props, semantic tokens and structural specs—so agents and humans make the same choices. The article shows how small changes to naming, typing and composition produce dramatically better agent output and fewer surprises in production.
Naming conventions were important. AI agents made them essential.by Daniel Klinke
Why We Like It: Practical, prescriptive naming rules that map directly to component APIs and agent behaviour.
Hot Take: This piece converts an abstract best practice into an actionable naming standard designers and engineers can adopt today. It explains how property names, boolean prefixes and slot naming become the API an agent reads, and gives ready‑to‑use examples that reduce ambiguity across design and code.
Design systems are evolving. Our migration tools aren’t. by Yogesh Shetty
Why We Like It: A clear treatment of the migration problem with a pragmatic tool (Token Map) and sensible rules for safe bulk fixes.
Pro Tip: Migration is the unsung cost in variable and token transitions. This article outlines deep token detection, weighted matching and scope awareness as essential migration features, and points you to a Figma plugin that demonstrates the approach. It is a useful primer for teams planning Variables migrations.
Monthly Signals
💡 April 2026
Every month I read everything that comes through DSC: the articles, the arguments, the quiet shifts in how the community thinks about its own work. Monthly Signals is my attempt to make sense of it. Not a roundup. A point of view on what the community is actually saying, and what it means.
The first edition is called The Layer Nobody Documented, and it’s about a shift I’ve been watching happen in real time: the community moving from thinking about design systems as a product to recognising them as infrastructure. And what that exposes about the layer most teams are still skipping.
📰 Published in the Last Week
To stay updated on the latest articles, we share every new article on our LinkedIn page.
AI and the Future of Design Systems
👉 Naming conventions were important. AI agents made them essential. by Daniel Klinke
👉 From UX Designer to UX Engineer: The Hybrid Role AI Just Made Inevitable by Abhi Chatterjee
👉 When the Autocomplete Changes Its Mind by Phillip Lovelace
👉 The Design System has joined the chat. by Mike Fortuna
Component Architecture and Tokens
👉 Every component in your design system is a promise by Murphy Trueman
👉 From Color Shades to State Layers by Setarehkhatapoosh
👉 Token drift is real by The Maker’s Lab
👉 Designing Component APIs That Engineers Actually Love by Madhesh P
Governance and Consistency
👉 Your Design System Is Not Failing. Your Codebase Is Bypassing It. by George William Amalan
👉 The hidden cost of Design-Dev mismatch by The Maker’s Lab
👉 When Interfaces Change Without Telling You by Gantushig Javkhlan
👉 Design systems are evolving. Our migration tools aren’t. by Yogesh Shetty
👉 The Layer Nobody Documented by Shane P Williams
Building and Scaling Design Systems
👉 How I Built ANACITY’s Design System, And Why Dark Mode Didn’t Make the Cut by Ishaan Sharma
👉 Building a Design System Shouldn’t Take Weeks. So I Built a Tool That Does It in Minutes. by Narendra Keshkar
👉 How to actually create a design system (Step by Step) by Hriday Checker
👉 What’s actually included in a design system by Hriday Checker
Accessibility and Inclusive Design
👉 Accessibility Isn’t a Checklist. It’s a Design System Discipline by Madhesh P
👉 Designing for Everyone by Setarehkhatapoosh
Perspective and Opinion
👉 The Invisible Thread: How Design Systems Create Quiet Continuity in a Fragmented World by Damini Patil
👉 I’m an Electronics Engineer Who Fell in Love With Design Systems — And Yes, It’s Serious by Damini Patil
✨ Inspiration
Are you constantly searching for innovative ideas and fresh insights in design? Look no further! Here’s a curated list of intriguing content that has sparked our interest lately:
🔗 Good Design Practices Unveiled
Discover key principles that elevate your design strategy and create impactful user experiences.🔗 Open Source Success with Omlet
Explore Omlet’s journey and the value of embracing open source in product development, authored by Austin Poor.
🎗️ Support us:
If you find our content helpful, here’s how you can support us:
Forward this email to a friend and invite them to subscribe
Support our writers by visiting the Design Systems Collective website
📝 Closing Thoughts
There is something clarifying about the moment when informal agreements become unworkable. For years, design systems succeeded on a kind of social contract: if the documentation was good enough, and the components were well-named enough, and the team trusted each other enough, things would mostly hold. That was never a system. It was a relationship.
What this issue keeps returning to is the cost of that distinction. Token drift does not announce itself. A codebase bypass does not file a ticket. A poorly named property does not fail loudly; it just produces subtly wrong output for long enough that nobody remembers the original intention. These are not new problems. They are old problems that have finally become legible.
The infrastructure framing matters here. Infrastructure does not rely on goodwill. It is either load-bearing or it is not. And teams that have been building systems as though they were living documents, maintained by people who understand their nuance, are now discovering that nuance does not transfer to the next team, the next platform, or the next generation of tooling that will consume their work.
The components were always promises. Most teams just never had to honour them at scale.
Founding Editor, Design Systems Collective