Article

What AI-Ready Means for a Design System

The useful advance is a system that people and machines can read, compare, govern, and update without surrendering judgment.

Hands organize scattered guidance into a linked ledger while a retrieval arm waits at a human review point.

Year

2026

Topics

Design Systems · AI Governance

Format

Leadership perspective

Make the guidance dependable before asking an agent to use it

A design system becomes useful to AI when its guidance is structured, current, and connected to the work people actually implement. Adding an assistant to conflicting names or missing state definitions gives teams another place to get an uncertain answer.

I ran into this while recovering a stalled enterprise design system. The partial Figma library and uneven documentation left implementers filling in the gaps. We rebuilt the components and the written guidance together, working with framework developers, theme implementers, and a dedicated Storybook developer. AI readiness was one of the goals of EDS 1.1 because the original system did not provide a dependable structure for that work.

The question I wanted us to answer was practical: can someone find the released rule, see the relevant design and code, and know who can resolve a discrepancy? The agent needs that same path.

One component question makes the requirements visible

Suppose a developer asks how a field error should behave. A red border in a screenshot answers only part of the question. The implementation also needs the supported state, error text, accessible naming, keyboard behavior, tokens, and the release that guidance belongs to. This is an illustrative question, not a recorded agent exchange.

Our guideline template covers purpose, variants, states, behavior, content, accessibility, keyboard interaction, and implementation expectations. AI helped produce drafts, and the guidance was human-reviewed. EDS 1.2 was released on August 28, 2026. As of October 4, the corpus contained 96 released guidelines. Repeated sections helped expose omissions; review determined what we would endorse.

Those references serve different jobs. A requirements engineer can establish the expected behavior, a developer can implement it, and a quality engineer can cross-reference the acceptance criteria. They need to reach the same standard without having to reconstruct the reasoning from a picture.

Reviewed design and code guidance supplies a versioned source for retrieval. People review the answer and route approved changes back into that source. — Reviewed guidance supplies the answer; people own the decision and the next approved change. This explains the operating relationship, rather than measuring agent accuracy. Scroll or open the diagram to inspect it on a small screen.

Design and code references need to travel together

I performed the Code Connect pull into TSX and token JSON for the developer handoff. Written guidelines, Figma components, Code Connect, and Storybook gave us several views of the same implementation contract. Regular reviews across design, framework, theme, Storybook, and product teams helped keep those views coherent.

The July 15, 2026 verification snapshot recorded 177 Code Connect mappings across 70 files, with 172 resolving to live Figma nodes. That is a dated traceability check. A working mapping helps a developer find the reference; it does not establish correct use in every application screen.

The components-and-patterns agent references the written guidance. Workspace instructions support assembling a page from a PRD using EDS patterns, followed by developer review and the required EDS linter before a commit or push. The linter enforces its configured rules. Code review and product QA still check behavior in context.

Keep ownership and versioning in the loop

AI helped with drafting, retrieval, extraction, audit tooling, code assets, and publication. The system owner and reviewers still decided which variants to support, how to resolve a gap, and whether a release was ready. An agent should make those decisions easier to find, not quietly replace them with a plausible answer.

An answer from the wrong release can cause trouble even when the rule was once correct. The references need an owner, an update path, and a clear way to raise an exception. When the sources disagree, that disagreement needs to become visible.

The process continues to develop through cross-functional collaboration. Requirements, software, and quality engineers have had to incorporate the shared references and checks into their work. The same resources support the UED team's initial design work: a PRD can provide a starting point for a workflow, which designers then iterate and refine. Faster generation increases the importance of reviewing the choices it produces.

Check usefulness with a real question

Ask a designer, developer, and quality engineer the same component question. Can they find the applicable release, inspect the behavior, and identify the owner of a gap? Then ask the agent and follow its references. A fluent answer with a broken source path is something to correct.

As of October 4, 2026, 16 of the 22 teams in scope were using EDS 1.2. That is release adoption, not a measure of agent use or answer accuracy. We have not established a sampled retrieval-accuracy result or a comparable end-to-end delivery improvement. Those measures need their own definitions and observations.

The useful advance is the connection between maintained guidance, implementation references, and accountable review. The EDS recovery case study shows the release and handoff decisions behind that connection.