Design-as-Code and the Tool Landscape

This module is the one most likely to age, and it is worth saying that to the room before any product name appears. Versions, prices, and even whether a tool exists next quarter all move faster than course material can. The protection against that is the structure of the module: the format layer first, because diffable artifacts are the slow-moving foundation; the tools second, as a dated snapshot; and a decision path last, built on the differences that change slowly rather than the features that change weekly.

Set the relationship to the previous modules. Module 1 introduced diffability as a single property and promised the full treatment here. Module 4 built the harness — instruction files, tokens, skills — and that harness is exactly the asset that makes the tool choices in this module low-stakes, because it ports between platforms. If participants skipped Module 4, the choosing-a-stack slides will still work, but the migration slide will land harder.

Also flag what this module is not: it is not a recommendation of one platform or one canvas. The course's published platform and canvas articles are kept current and date-stamped; this module teaches the comparison dimensions and the decision structure, and points at those articles for the latest figures.

This slide restates the Module 1 claim with the precision the rest of the module needs. An agent's reach is bounded by what it can read and write. A coding agent can open your repository, your CSS, your token JSON, and your markdown design system in seconds. It cannot open a proprietary binary design file at all, except through a vendor API or a plugin that returns a partial copy. When the canonical version of a design decision lives in a format the agent cannot open, the agent fills the gap with the most common pattern it knows — which is how you get plausible, generic output that was never grounded in your actual system.

Name the two families of text artifact. Decisions live as design tokens — structured DTCG JSON transformed into CSS variables or theme files — and as written guidance like DESIGN.md. Surfaces live as text in three forms: token output, text-based canvas files such as .pen and .op which store the canvas as a JSON tree of nodes, components, and variables, and HTML or component code where the artifact is already the implementation.

The practical consequence to land: most design-versus-implementation arguments are not disagreements about taste. They are two copies of the same decision quietly diverging because the decision was recorded in a place only one application could read. Design-as-code is the inversion that stops that drift, and it is what makes the rest of this module's tooling worth discussing at all.

Walk the failure modes concretely, because each one maps to a frustration designers already have. Read access: a flattened export carries no token names, no spacing intent, no component boundaries, so the agent guesses. Precise edits: in the hand-off world a colour change is an edit inside the design tool, a notification, a re-export, and a manual re-type into CSS — every hop a chance for drift. Honest review: a commit that touches a binary says only that a binary changed, so code review cannot see what moved and CI cannot lint it. History: six months later the simple question — when did this change, who changed it, why — has no answer.

Then show what diffability buys, using the worked evidence from the design-as-code article: a single semantic token change produced a two-file diff with one meaningful line in each — the token source recording the decision, the generated CSS recording the consequence — and the components that consumed the token did not appear in the diff at all because they only ever referenced the variable. That is the contract working: decisions change in one place, surfaces follow, and the review shows the exact blast radius.

Be honest about the limit. Diffable does not mean every diff is pleasant. A canvas-file change that moves forty nodes is technically text but practically unreadable; you review it through the rendered screenshot, not line by line. The claim worth making is narrower: the decisions you care about reviewing — variables, components, bindings, tokens — produce diffs a human can actually read.

Walk the diagram from the base. The bottom layer is the diffable artifacts: .pen and .op canvas files, HTML and component code, DTCG token JSON, SVG and markdown design docs — text in the repository, owned by the team rather than a vendor. The next layer up is the agent platforms — Claude Code, Codex CLI, OpenCode, Gemini CLI — which read and edit those artifacts directly, so every change lands as a diff that goes through the same review gates as any other change. The bridge layer is the connected canvases and MCP servers — Paper, Pencil, OpenPencil, Open Design, and Figma's MCP server — which give the agent a visual surface or an external tool to read from and write to. The top layer is what comes out: prototypes, production UI, decks and audits.

Point at the two arrow styles. Solid arrows are work flowing upward — artifacts into platforms into outputs. Dashed arrows are MCP: one protocol, both directions, used to read frames, variables, and screenshots and to write nodes, styles, and tokens back. MCP is what stops every canvas-platform pairing from needing its own bespoke integration; the next slides cover the platforms and canvases individually and MCP gets its own slide after that.

The strategic reading is in the highlight: the base layer plus the Module 4 harness is the durable asset. Platforms get repriced, canvases are in early access or beta, and one of the four CLIs in the middle layer is being retired for individual users this very month. The teams that absorb that churn cheaply are the ones whose design knowledge lives at the bottom of this diagram, not the middle.

This expands the one-line comparison from Module 1 into the dimensions that actually decide a team's week. Start with what is the same, because it is the reason the choice is reversible: all four read a project instruction file — AGENTS.md natively or via a one-line import — all four support the SKILL.md format, all four speak MCP, and all four have a plan-before-build mode. That convergence on open standards is why the Module 4 harness ports between them in roughly an hour.

Then the honest differences. Claude Code pairs the deepest design ecosystem — skills, plugins, design-adjacent MCP servers — with subscription-window economics; heavy iteration days can hit the five-hour windows. Codex CLI has the clearest containment story: OS-level sandbox modes separated from the approval policy, plus cloud sandbox tasks for parallel work; usage is metered as token credits inside ChatGPT plans, which never stalls but can surprise. OpenCode is open source and model-agnostic — over seventy-five providers, bring your own key — and the most accommodating of an existing harness, but there is no OS sandbox underneath its policy rules and the model, cost, and data-handling decisions become your job. Gemini CLI offers the largest context windows and a generous free tier, and is also mid-transition: individual access ends in June 2026 in favour of Antigravity, which is the strongest available evidence that deprecation risk belongs in the comparison.

Close with the method point: every figure in this table was verified on a stated date and will drift. Teach the habit of writing last verified next to any volatile fact, and of running your own brief through a candidate platform rather than trusting benchmarks — including this table.

Walk the table by family rather than row by row. Paper is the HTML-native canvas: the design is already markup, the desktop app runs a local MCP server with roughly twenty granular tools, and the trade-off is that the document lives in Paper's cloud, so review leans on before-and-after screenshots rather than git diffs. Pencil and OpenPencil are the repo-resident pair: .pen and .op are JSON trees of nodes, components, and variables that live next to the code, diff cleanly at the decision level, and expose MCP so the agent in your editor can read and write the canvas — Pencil proprietary and free during early access, OpenPencil MIT-licensed with concurrent agent teams and the usual young-project caveats. Open Design and Huashu sit at a different layer: Open Design is an open-source shell that drives whatever agent CLIs you already have and bundles a large library of skills and DESIGN.md-style design systems; Huashu is the proof that an entire design tool can be one SKILL.md — taste, procedure, anti-slop rules, and export scripts shipped as text.

Figma is in the table because pretending it is not in the room helps nobody. Its MCP server is real, official, in beta, and no longer read-only — but the architectural difference stands: the artifact stays in Figma's cloud and the agent works through an API translation, not on a file in your repository. That is a legitimate arrangement; it just optimises for collaboration breadth rather than agent participation. The next-but-one slide treats Figma's position fairly on its own.

Remind the room that columns like status and pricing are dated June 2026 and that two of these tools are pre-1.0 or early access. The diffability and agent-readability columns are the slow-moving ones; weight them accordingly.

Keep this deliberately plain, because the acronym makes it sound more mysterious than it is. Without MCP, the designer is the integration: export a frame as a PNG, paste it into chat, copy hex values one at a time, screenshot the half-built page, and ask the agent to compare two images it can barely see. The agent works from degraded copies of intent, guesses, and you correct the guesses. With MCP, a server exposes a few named tools — return the variables for this frame, screenshot this artboard, write these styles back — and the agent calls them mid-conversation, with the results landing in its context like a file it just read.

Give the two distinctions that predict how servers behave. Local versus remote: local servers run on your machine, often inside a desktop app, and only exist while that app is running — Paper, Pencil, Playwright, Chrome DevTools all work this way; remote servers live at a URL with OAuth — Figma and Miro — and bring rate limits plus the question of what data leaves your machine. Design servers versus browser servers: the design server reads intent, the browser server observes the built reality, and chaining them is what makes a real design-versus-implementation review possible.

Two governance and hygiene points close it. MCP moved to neutral governance under a Linux Foundation body in late 2025 and has an official registry, so building team workflow on it is a safer investment than any single vendor's plugin system. And servers sit inside the agent's trust boundary: prefer official servers, check the registry before installing community ones, and keep write actions behind permission prompts — the same discipline Module 4 applied to the harness.

This slide exists to take the religion out of the conversation. Some of the room will hear this module as Figma is dead, and that reading produces bad decisions. The fair statement, dated June 2026: text-based formats win on review, history, CI, and agent participation; the canvas-first incumbent wins on real-time collaboration with non-technical people, mature component and prototyping tooling, an enormous plugin ecosystem, and being where stakeholders already live. Figma is also narrowing the gap from its side — the Dev Mode MCP server is official, in beta, and no longer read-only, and DTCG-conformant variable export has been announced — so the trajectory is toward interoperability, not away from it.

What does not change is architecture. The Figma file stays in Figma's cloud; the agent works through an API translation rather than on a file in the repository; a change to the file is not a diff anyone outside the tool can read. For exploration, stakeholder workshops, and collaborative iteration, that costs little. For the production loop this course teaches — agent edits, review gates, CI checks — it is the difference between participating directly and participating through a window.

Give the practical posture: most teams run both for a while, and tokens are the bridge. Keep decisions in DTCG JSON in the repository, sync them into Figma variables and into the codebase, and the canvas and the runtime become two projections of one source. The anti-pattern is the purity move — ripping out the tool your designers, PMs, and stakeholders actually use to satisfy a diagram. The other anti-pattern is pretending the agent can fully participate in work whose source of truth it cannot open.

Keep every number on this slide attached to its date — these figures were captured on the first of June 2026, all three major vendors changed plans or metering in the eight weeks before that, and the official pricing pages are the only source that counts on the day a team decides. What is more durable than the numbers is the shape. The three vendors have converged on the same individual ladder — roughly twenty, one hundred, and two hundred dollars a month — and they describe limits relative to other tiers, five times Pro, twenty times Pro, never as absolute counts. Anyone quoting a hard number of messages per tier is making it up.

The metering models are the real comparison. Subscription windows fail by making you wait: a heavy iteration day exhausts the rolling allowance and the loop stalls mid-critique. Credit metering fails by surprising you: nothing stalls, but a screenshot-heavy review day costs multiples of a normal one. Bring-your-own-key fails by becoming nobody's job: spend spreads across personal keys until finance asks a question no one can answer. None of these is wrong; the right plan is the one whose failure mode the team can actually manage. Design work stresses all three because it is multimodal and iterative — screenshots in, screenshots out, long token and design-system context, repeated regeneration.

Two closing notes. The team and business tiers mostly sell seat administration — central billing, SSO, usage visibility — rather than more capability per person; that matters from about three designers up. And there is a habits dividend that works on every plan: scope context to the task, crop screenshots to the component, use cheaper models for drafts, and measure a real week of usage before paying for the next tier.

Frame the decision path the way the platform article does: ordered by how much each question constrains the answer, not by how interesting it is to debate. Existing subscriptions come first because they make the evaluation nearly free — most organisations already pay for Claude or ChatGPT, and the agent inside that plan is the cheapest serious trial. Safety rails come second because they are non-negotiable where they apply at all. The deliverable question is the design-specific one this module adds: what the team makes most often points at a canvas family — HTML-native for marketing and prototype work, repo-resident files for product UI that lives with a component library, and the Figma-plus-MCP-plus-tokens route for teams whose system already lives there. Model flexibility and licensing constraints point at the open-source options, with the honest reminder that flexibility is work you take on, not a free feature. Churn tolerance is last but real: the Gemini CLI retirement happened to a tool that was open source, actively maintained, and backed by one of the largest companies on earth.

A sensible default for a team starting from zero, stated as a default rather than a verdict: the agent platform an existing subscription already includes, one connected canvas matched to the dominant deliverable, tokens in DTCG JSON from day one, and the harness from Module 4 in AGENTS.md and skill files. That stack can be assembled in a week and abandoned in an afternoon, which is exactly the property to optimise for.

Close on the footer. Every answer above is reversible only if the design knowledge lives in open formats — the artifacts at the base of the stack diagram and the harness files. If the knowledge lives in one platform's proprietary config, the team has converted a low-stakes choice into a hostage situation, and no amount of careful comparison fixes that.

This slide keeps the module honest, because the worked evidence behind it includes failures. In the design-as-code case study, the token-to-CSS pipeline took three iterations: the sync script's first version copied DTCG alias strings straight into the CSS, the browser silently dropped the invalid declarations, and the card rendered unstyled — a quiet failure, not a loud one. The fix was one added sentence in the prompt about what aliases must become. The second friction was naming: the generated variables followed the token path while the existing codebase used shorter names, which means any real adoption chooses between renaming deployed variables, maintaining a mapping layer, or migrating component by component. None of those is free, and pretending otherwise is how token projects stall.

Give the sequencing that works: tokenize the decisions that actually change — brand colours, status colours, radius, a couple of spacing steps — enforce them with a no-raw-values check and a generated-file freshness check in CI, route every token change through the same pull-request gate humans use, and only then expand coverage. If a .pen or .op canvas joins later, bind its variables to the same token names so the canvas and the runtime stay two projections of one source.

Then the switching-cost honesty from the platform material: when a team later changes agent platform or canvas, the harness, tokens, and MCP server list move in about an hour; permissions, plans, and platform-only features get rebuilt; and the team's muscle memory — keyboard habits, prompt shapes, permission reflexes — takes a week or two, during which output dips. Portability makes switching cheap, not free. Saying that out loud up front is what keeps the second migration from becoming a crisis of confidence in the whole approach.

Like the Module 1 exercise, this one is analogue on purpose: no installs, no terminal, one page. The inventory step is where the learning happens, because most teams discover that their design decisions live in more places than anyone admits — the canvas file, a theme CSS file that has drifted from it, a brand deck, a wiki page last updated two years ago, and the memory of whoever has been there longest. Scoring each location against the four properties — diffable, git-trackable, agent-readable, MCP-reachable — turns the vague sense that our setup is messy into a specific map of where an agent could help today and where it would be guessing.

The source-of-truth question is deliberately uncomfortable. If colour has two sources of truth, the team does not have a design system; it has two, and an agent will faithfully follow whichever one it can read. That observation alone justifies the exercise for most teams.

The last two bullets connect the exercise to action. The defence sentence forces the decision path to actually be used rather than admired — existing subscription, safety needs, deliverable type, flexibility, churn — and the first-migration-step question keeps the output small and real: a tokens file for the five most-changed decisions, an MCP server connected to one canvas, or a single component rebuilt against tokens. Collect the expected-cost answers if running this live; they map almost exactly onto the friction points from the migration slide, which is reassuring rather than discouraging — the costs are known, named, and budgetable.

Recap by tracing the module's spine rather than re-reading the bullets. The format question came first because it is the slow-moving one: diffability is what lets an agent participate and lets a human review the participation, and that property does not expire when a vendor changes its pricing. The tool comparisons sat on top of that as a dated snapshot — accurate on the day they were verified, and built so that the comparison dimensions outlive the specific cells. The decision path and the migration slide turned the landscape into something a team can act on this month without betting itself on a moving target.

If one idea should survive the module, it is the asymmetry: the artifacts and the harness are the durable assets, the platforms and canvases are the replaceable layer, and a team that keeps its design knowledge in open formats can treat every tool decision in this module as low-stakes. That is also the answer to the anxiety this module sometimes produces — the sense that everything is changing too fast to choose anything. Choose quickly, keep it reversible, re-verify on a cadence.

Preview Module 6 concretely: it takes the artifacts and stack from this module and asks how you know the work is good — structured critique with named dimensions, screenshot evidence and visual QA, checks that can be made executable, the recurring failure modes worth automating against, and a plain statement of what agents are still bad at. The exercise page from this module feeds directly into it, because quality gates can only run on artifacts the agent can read.