Use AI to Need Less AI

Component specs, token specs, and contracts are converging on the same idea. Let the model do the heavy lift once, then hand the work to machinery that can't improvise.

The most interesting AI work in design systems right now is the work that takes AI out of the loop.

That sounds backwards, so let me say it plainly. I don’t think people are sick of AI. I think they’re sick of paying inference costs for problems that were never probabilistic to begin with. What token colors the primary button. What props the Card accepts. Whether Figma and code still agree. Those are lookups, not judgments. Asking a model to re-derive them on every request is slow, expensive, and slightly different every time.

The sharpest people in this space have sorted the work into two piles. Authoring is judgment-heavy and happens once. Enforcement recurs forever and has to be boring. AI is great at the first pile and a liability in the second. The new wave of tools puts the model where it belongs: helping you produce a spec, then stepping aside while deterministic machinery does the rest.

It’s happening at three layers at once. Tokens have a spec. Components are getting one. Documentation just got one last week. Here’s what that looks like.

Tokens made the trip first

The Design Tokens Community Group shipped the first stable version of the token spec (2025.10) last October. Figma, Penpot, Sketch, Tokens Studio, Style Dictionary, and Terrazzo support it or are implementing it, and Carbon has an open issue to migrate its entire token pipeline to the format.

Tokens are the proof that this model works. Standardize the format and drift becomes checkable. Checkable drift means tooling compounds instead of every team rebuilding the same pipeline from scratch. The rest of this roundup is the same move, climbing one level up the stack to components.

→ designtokens.org

Component specs: computation over inference

Nathan Curtis has been building Specs, a deterministic system that extracts structured, schema-valid component specs straight from Figma. His comparison table is the whole argument in miniature: about a second per component versus five to ten minutes of agentic extraction, zero AI tokens versus a hundred thousand, identical output every run versus inference gaps and overconfidence. He calls it “computation over inference.” I’d put that phrase on a t-shirt.

Murphy Trueman has been making the adjacent case for a while: treat the component library as an API other systems consume, not a folder of pictures. Her latest piece, Design systems need evals, follows that logic to its conclusion. If agents generate against your system, you need held-constant inputs and assertions on the output. And you can’t write assertions against vibes. You need a spec to assert against.

Contracts: the component lives in neither Figma nor code

Christine Vallaure just published the clearest designer-facing walkthrough of this idea I’ve read: Design system contracts: the component lives in neither Figma nor code. Her framing: stop crowning Figma or code as the source of truth. Put a small machine-readable contract in the middle and generate both surfaces from it. Neither is the original. Both are printouts of the same recipe. And the part she singles out as new isn’t the generation. It’s the checker that proves the two copies still match.

Full disclosure: the project she’s writing about is ours. DS Contracts is Southleft’s proof of concept and candidate spec for exactly this. 51 component contracts and 282 DTCG tokens generate a typed React library and a Figma library, a three-way differ classifies every mismatch between contract, code, and canvas, and extraction adapters pull proposed contracts out of systems you already have. There’s a browser playground running the real engine, and the docs walk the whole model.

The result I keep coming back to is the A/B test on honest generation. An ungoverned agent building screens scored 69/100 with 90 violations. Invented props, hard-coded colors, restyled components. The same model, held to the compiled contract catalog, scored 100/100. And when it hit a real gap in the system, it reported the gap instead of faking around it. Same deterministic judge, both runs. Read it skeptically. That’s what the receipts are for.

Documentation gets a schema

The newest one, and the one I think is most underrated: the Design System Documentation Spec, maintained by PJ Onori. Draft 0.15.2 posted July 16.

It’s a machine-readable format for design system docs covering components, tokens, themes, foundations, patterns, and guides. Everything structured runs through one document block system, typed objects with a kind field, 17 block kinds including guidelines, api, states, motion, and accessibility. Each entity type only accepts the blocks that fit it.

The principle I’d underline: documentation shouldn’t have to pick a side. Humans, parsers, and agents need the same docs, and nobody should be writing a separate version for each audience. That’s the argument I’ve been making about declared documentation for a while, now with a schema behind it instead of just an opinion.

Worth saying plainly: it’s a draft, no standards body has endorsed it, and the version number tells you where it is. That’s fine. DTCG spent years in exactly this state.

Cristian Morales Achiardi already has it integrated on a live project, and reports it was more useful for surfacing what was missing than for confirming what was there. He makes the broader case for contracts over libraries too.

Same lane, different vehicles

Three more projects circling the same center of gravity:

→ Spektral is spec-first design system generation. Describe intent, get a component contract, code, DTCG tokens, and stories, produced by an agent that validates its own output against the spec before anything ships.

→ Primitiv is a contract layer for systems you already have. It reads Figma, Storybook, and your codebase, reconciles conflicts into one contract, gates PRs in CI when drift appears, and serves the contract over MCP so Cursor, Claude Code, and friends all build from the same truth.

→ Aiko compiles design system knowledge into a canonical graph, projects task-sized contracts to agents, and verifies output against the contract’s evidence. Less “read my docs,” more “here is exactly the neighborhood you need.”

Different entry points, same bet: the agent gets a contract, not a vibe, and the checking is mechanical.

The same bet, one layer down

Tony M is running this play beneath the design system entirely, at the pipeline layer. Stably is a small, pure functional substrate for deterministic, contract-driven pipelines. A plan is pure data. A contract defines the allowed actions, required steps, and ordering. A generator yields the next step only when the structure validates. Its own line: “Stably provides structure, not execution.” Orchestrators and workers live outside it, and the substrate refuses to advance anything malformed. There’s a stateless MCP server, so an agent consumes the gate the same way it would consume a design system contract.

His CGraph applies the same discipline to agent memory: a file-backed context kernel that enforces a Root → Branch → Summary → Canon → Archive lifecycle, append-only, with Git as the truth substrate. Context stops being a junk drawer of flat files in a /memory folder and becomes something you can audit.

I’m including this because it shows the pattern isn’t a design system quirk. Wherever an agent loop runs, someone is installing a deterministic gate the model can’t talk its way past.

The kicker

None of this is AI fatigue. The people building these tools are among the heaviest AI users in the field. They use models to extract contracts from legacy code, to propose a spec from a sentence, to draft the migration nobody wants to type by hand. Then they hand the result to compilers, schemas, and differs, where the same input produces the same output, checked byte for byte.

That’s the pattern I’m all in on. AI at authoring time. Determinism at run time. The model helps you build the thing, and the thing doesn’t need the model.

It also answers the governance question everyone circles once agents enter the workflow: where does authority live? My answer is that authority belongs to whatever layer can refuse deterministically, not whatever layer instructs loudest. A model can be talked around. A schema can’t.

Tokens took roughly a decade to go from a good idea to a stable spec with real adoption. The component layer is moving faster, because agents made the cost of ambiguity visible to everyone at once. If these projects converge on a shared contract format the way tokens converged on DTCG, this stops being a roundup and starts being infrastructure.

The list, in one place

• DTCG token spec: designtokens.org

• Design System Documentation Spec, PJ Onori: designsystemdocspec.org

• Specs, by Nathan Curtis: specsplugin.com

• Murphy Trueman, Design systems need evals: blog.murphytrueman.com

• Christine Vallaure, Design system contracts: christinevallaure.substack.com

• DS Contracts (ours): repo · playground · docs

• Spektral: spektral.design

• Primitiv: primitiv.design

• Aiko: aiko.systems

• Tony M: Stably · CGraph

• Cristian Morales Achiardi, Design systems are contracts, not libraries: giorris.dev