AI can generate a screen in seconds. That part is no longer impressive.
What matters is whether it can generate one that is on-brand, accessible, state-aware, and buildable. Figma’s 2025 AI report put the trust problem in plain terms: 78% of designers say AI improves efficiency, while only 32% say they can rely on the output.
That gap is not mainly a model problem. It is a context problem.
Most design systems were built as human-readable libraries. AI needs something else. It needs a machine-readable schema that tells the model not just what a component is, but why it exists, when it should be used, what states it supports, how those states transition, what code it maps to, and where it is allowed to fail.
That is what I mean by a context engine.
A context engine is not a documentation site. It is the data layer that feeds the model's context window.
For an enterprise team, that means the design system has to exist in machine-readable form. Not just polished guidance in Figma, Zeroheight, or Notion, but structured metadata the model can retrieve and use: semantic tokens with intent, JSON schemas for components, props, state, and variant definitions, transition logic, ARIA and keyboard requirements, content constraints, code mappings, and usage rules tied to a governed source of truth.
That data then has to move through an actual delivery path. In practice, that usually means some combination of component manifests, APIs, MCP servers, and retrieval pipelines that pull the right component contract at generation time instead of dumping generic documentation into the prompt. A library helps a designer browse. A context engine helps a model decide.
When that layer does not exist, the model fills the gaps with probability. That is where polished nonsense comes from.
Accessibility is the integrity test
Brand drift is embarrassing. Accessibility failure is a legal, operational, and reputational risk.
AI cannot infer accessibility from aesthetics. It cannot look at a clean interface and somehow know whether the focus order works, whether the error state is announced correctly, whether the control needs an ARIA role, or whether the keyboard behavior survives real use. It can only follow the logic it is given.
That is why accessibility is the best test of whether a context engine is real or fake. A human-readable library can describe a component beautifully and still fail the machine. A machine-ready system has to expose the behavioral logic itself: roles, labels, focus handling, interaction states, error messaging, validation rules, and the conditions for when a pattern is safe to generate.
If that logic is not encoded into the retrieval layer, the model does what models do. It guesses. And an inaccessible guess is not a design miss. It is a liability.
This is why accessibility should stop being treated as a final compliance pass. In AI-driven delivery, it is the clearest proof of whether your system is honest. Either the design system contains the logic needed to generate accessible output, or it does not. Either the pipeline exposes that logic to the model, or it does not. That is not a styling issue. That is infrastructure.
AI does not remove weak habits. It amplifies them.
Most AI failures in enterprise delivery are failures of the operating model.
Teams that already struggled with handoff, naming, governance, and documentation do not suddenly become coherent because an LLM can generate more options per minute. They just produce more debt, faster.
That is the risk leaders should care about. AI can turn repeated implementation mistakes into systemic debt. When a model repeats an inaccessible pattern across thousands of generated screens, the problem is no longer a design miss. It becomes an engineering recovery.
So the business question is not whether AI makes production faster. It does. The question is whether your operating model can stop AI from manufacturing expensive mistakes at volume.
The four layers of AI-ready DesignOps
If design knowledge is entering model workflows, someone has to govern the path.
This is where DesignOps gets misread. The new mandate is not tool policing. It is governing the AI delivery pipeline.
A mature setup has four layers:
1. Source layer
The versioned, immutable system of record for machine-readable contracts: tokens, components, code mappings, accessibility metadata, and approved patterns. The model needs to know whether it is retrieving the stable contract or an experimental branch. If this layer is vague or if versions are blurred together, everything downstream is guesswork.
2. Injection layer
The governed context-delivery layer: MCP servers, APIs, manifests, and RAG pipelines that inject the right metadata into the model at the right time. This is where DesignOps decides what the model is allowed to retrieve, from which source, at what level of detail, and with which prompt constraints.
3. Evaluation layer
The automated fail-safe layer that decides whether the generated output is acceptable. Not just visual comparison, but component validity, token compliance, keyboard behavior, ARIA coverage, forbidden patterns, and code alignment. If the output fails the contract, the pipeline should break, flag the prompt or retrieval path, and force remediation upstream.
4. Dynamic audit layer
The operational record of what was generated, what failed, what humans corrected, and which issues were repeated. Human-in-the-loop can become new training and evaluation data: new evaluation cases, updated retrieval rules, tighter schemas, refined prompts, and better model behavior over time.
That is the real infrastructure work. Not buying tools. Not writing policy decks. Governing the path between design intent and machine output.
Design systems reduce AI chaos only when they behave like infrastructure. The chaos does not come from the model alone. It comes from letting a model generate without a governed context.
From maker to orchestrator
The leverage of senior design leaders is moving upstream.
The leaders who matter most in the next few years will not be the fastest artifact producers. They will be the ones who can define system behavior, specify review thresholds, protect accessibility and brand integrity, and explain why a missing metadata field upstream can create legal and operational risk downstream.
That is the shift. Not from creativity to automation. From artifact production to operational authorship.
The new DesignOps question is no longer, "How do we support the team?" It is, "How do we govern the model and the pipeline around it?"
Who decides which LLM is allowed to retrieve from the design system? Who decides what counts as trusted context? Who audits generated code against accessibility behavior, not just visual fidelity? Who turns repeated correction patterns into updated schemas and better evaluation cases?
That is the new orchestration work. It is not soft enablement. It is delivery governance.
The companies that handle AI well will not be the ones with the flashiest demos. They will be the ones with the clearest system contracts. Their design systems will behave less like libraries and more like structured context engines. And their DesignOps teams will stop being treated like support staff and start being recognized for what they are: the people who make AI delivery governable.
If your design system cannot expose intent, constraints, and accessibility logic in a form a model can use, it is not AI-ready. It is just tidy.
Key takeaways
- The real AI problem in design is not generation. It is missing a governed context.
- A context engine is a machine-readable data layer that feeds the model's context window.
- DesignOps is evolving from team support to pipeline engineering, delivery governance, and dynamic audit.
Selected literature
- Figma — 2025 AI ReportOriginal report: https://www.figma.com/reports/ai-2025/Summary and analysis: https://www.figma.com/blog/figma-2025-ai-report-perspectives/
- Figma — Design Context, Everywhere You Buildhttps://www.figma.com/blog/design-context-everywhere-you-build/
- Figma — Introducing our MCP server: Bringing Figma into your workflowhttps://www.figma.com/blog/introducing-figma-mcp-server/
- Figma Help Center — Code Connecthttps://help.figma.com/hc/en-us/articles/23920389749655-Code-Connect
- Storybook Docs — Using Storybook with AIhttps://storybook.js.org/docs/ai
- Storybook Docs — Manifestshttps://storybook.js.org/docs/ai/manifests
- Storybook Docs — Best practices for using Storybook with AIhttps://storybook.js.org/docs/ai/best-practices
- Model Context Protocol — Specificationhttps://modelcontextprotocol.io/specification/2025-11-25
- Model Context Protocol — Resourceshttps://modelcontextprotocol.io/specification/2025-11-25/server/resources
- W3C WAI — ARIA Authoring Practices Guidehttps://www.w3.org/WAI/ARIA/apg/
- W3C WAI — Developing a Keyboard Interfacehttps://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/
- W3C WAI — Dialog (Modal) Patternhttps://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/
- NIST — AI Risk Management FrameworkOverview: https://www.nist.gov/itl/ai-risk-management-frameworkFramework PDF: https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
- OWASP GenAI Security ProjectHome: https://genai.owasp.org/OWASP Top 10 for LLM Applications 2025: https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/