An AI-native design system, from zero

The starting point was zero: no mobile token foundation, no component ownership model, and three design languages that had to coexist without collapsing into each other — iOS 26 (Liquid Glass), Material 3, and an existing web design system (BDS) holding the brand. Rebuild every component custom and you fight the platforms forever — every OS update becomes a re-audit. Go fully native with no system and the brand evaporates and every screen becomes a one-off decision. The system had to answer, structurally, the question every component would otherwise re-litigate: when do we use the platform's component, when do we build our own, and how does brand flow through both? And it had to ship against real deadlines — three priority flows already mapped for delivery — not as a two-quarter foundations project.

A tri-platform token system with a component library is traditionally a team-of-several, multi-month effort: writing token specs, transforming them per platform, scaffolding components, keeping documentation in sync. Most of that work is high-precision but rule-following — exactly the profile where AI excels if the rules exist. That's the thesis of this build: AI doesn't lower the bar for design-systems work, it moves the designer's job up a level — from producing the artifacts to defining the standards the artifacts must satisfy. Instead of hand-building tokens and components, I wrote the constitution — naming conventions, aliasing rules, platform-override boundaries, accessibility gates, escalation triggers — encoded it as custom Claude skills, and delegated the production work to Claude Code with acceptance criteria attached. A solo designer operating at library scale, without the usual solo-designer failure mode (inconsistency creeping in around week three, dark mode retrofitted at the end, hardcoded hex hiding in components).

1. 01

   Foundations & audit

   • Claude
   • Existing BDS
   • iOS 26 · M3 refs

   Every existing token classified as correct, defective, or missing — with the specific fix. I set the strategic frame (platform-nativeness first, three-layer model). The AI executed the audit against the frame and returned a defect and gap list.

   then
2. 02

   Token architecture

   • Primitives
   • Semantic
   • Platform

   Three strictly aliased tiers. Primitives → semantic (Light + Dark from day one) → a platform tier carrying only what genuinely differs between iOS and Android. Iron rule: components consume semantic tokens only. No raw hex on a component, ever.

   then
3. 03

   Encoding the standards

   • Custom Claude Skills
   • Acceptance criteria
   • Escalation triggers

   Turned the system's rules from a document a human might read into skills the AI had to follow — with acceptance criteria and explicit escalation triggers ("if a semantic role has no primitive, flag it as a gap — do not invent a value").

   then
4. 04

   Component implementation

   • Claude Code
   • Scoped to priority flows
   • Per-PR review

   Scoped strictly to what the priority flows touched — no speculative library-building. Each Claude Code session ran against the encoded skills; review focused on the small set of things the AI can't self-check: architecture, brand intent, edge cases.

   then
5. 05

   Validation gates

   • WCAG AA contrast
   • 44pt · 48dp targets
   • Dark-mode per component

   Non-negotiable gates, not afterthoughts: contrast checks on every case where brand tint sits on a system surface (tinted materials fail contrast quietly), touch targets, and dark mode validated per component — not per screen.

• Platform nativeness over cross-platform consistency

  The foundational call, made early and held: when an element has a system equivalent — nav, tabs, sheets, inputs, switches, pickers — use the native component and apply brand as tint only. Build custom only where the element is unmistakably ours: brand lockup, our data surfaces, our primary CTA. Accepted cost, stated out loud: iOS and Android screens deliberately look and feel different. That's intended, not a bug — and writing it down once ended per-component relitigating forever.

• Treat material as material, not palette

  iOS 26's Liquid Glass surfaces are dynamic materials, not fills. The tempting move — repaint them with brand color to "own" the chrome — breaks the platform. The rule I set: brand flows into glass as tint; we never tokenize the material or fight system rendering. This one sentence prevented an entire category of components from being built wrong.

• A bounded platform tier, not a junk drawer

  Having tiers is table stakes; the real call was what the platform tier is forbidden to contain. Only five things may differ per platform: font family, system radii, elevation model, motion easing, minimum touch target. Everything else is shared. Without that boundary, "platform override" becomes the drawer where consistency dies — the fix is a fence, not vigilance.

• Design the workflow around what AI genuinely can't do

  The AI-native part wasn't blind delegation. Per stage I mapped what agents could actually execute versus where output had to hand back to me, and restructured deliverables accordingly — import-ready specs where direct writes weren't possible, escalation instead of guessing on architecture. Judgment calls route to me; the AI never guesses on architecture.

• 594 tokens across primitive and semantic tiers — the full foundation for iOS and Android.
• 42-component ownership map — every component assigned, no orphans, no overlap.
• 2 platforms covered: iOS and Android, with a bounded platform tier that keeps brand and native behavior intact.
• System correctly tiered, aliased, dark-mode-native, and platform-bounded — a brand change is a primitive edit, a theme is a mode switch, and an OS redesign touches the tint layer, not the library.
• Rules encoded as Claude skills, versioned, and machine-enforceable on every generation run.
• Explicit accessibility gates (WCAG AA contrast on tinted materials, 44pt / 48dp touch targets, Dynamic Type) treated as build-time invariants, not launch-time audits.

I encoded the standards after the first AI outputs surfaced defects — mis-tiered tokens, values where aliases should be. The audit caught everything, but it was a correction loop I paid for. Next system, the skills come first: write the constitution before the first generation run, and the audit becomes confirmation instead of cleanup. The broader lesson in one line — with AI, the leverage isn't in generating faster; it's in specifying better.