If you're shipping static sites, or building on a standard design system, the Figma MCP server is probably doing great work for you, and you can skip this one. This is for the people who have hit the friction: anyone trying to make the design-to-code pipeline more modular, maintainable, robust, and tool-agnostic, and get better code out the other end.
I started writing this as a takedown.
The plan was simple: Figma-to-code is overhyped, the demos are slick, and on most teams the reality is a mess. I was going to show you how bad it gets: the hard-coded colours, the components the model invents, the output that looks right until you actually read it.
Then I came across monday.com's design-to-code pipeline1, and I was genuinely impressed.
What monday showed me is that it can be done well, even if a developer is still cleaning up the code behind the demo.
The closer I looked, the more the piece stopped being about tools at all. The tools, the pipelines, the pricing, all of it keeps shifting. But underneath that noise is a quieter shift, the one I did not expect and cannot stop thinking about: a change in who actually does the work, and, perhaps more importantly, who owns the decisions the tools quietly make for us. That is where this ends up, and I think it raises deeper questions about code quality and responsibility.
Point a large language model at a Figma file through an MCP server, and it hands you back components. That is the pipeline the whole industry is converging on. Design happens in Figma; the code gets generated by a small set of AI agents: Copilot, Cursor, Claude Code, Codex.
That convergence is real, and the numbers behind it are lopsided. Figma is the default surface, named by 82.3% of designers as their primary UI-design tool.2 Its own codegen feature, Figma Make, is already used weekly by around 60% of Figma customers who spend over $100k a year.3 The inputs are consolidating onto one tool.
So is the format. Design tokens reached their first stable standard, DTCG, in late 2025, backed by roughly two dozen of the largest names in the field: Adobe, Google, Microsoft, Meta, Amazon, Figma.4 The build tooling is adopting it. Style Dictionary,5 the most widely used token transformer, now ships first-class DTCG support. Smaller tools like Terrazzo6 are DTCG-native, built around the format from the start. Google publishes DESIGN.md,7 a way to describe a design system to a coding agent. Everyone is pointing the same direction. Even Figma backs the standard. A widely used community token plugin for Figma, Tokens Studio,8 reads and writes the DTCG format too. The incumbent is lining up behind an open format that makes its own tool easier to leave.
From a distance, the problem looks solved. One tool for design, a converging standard for tokens, a handful of capable agents to write the code. Call this the shift everyone already noticed: the tooling converged. Settled.
Point an unscaffolded model at a real Figma file and the output is plausible until you read it. It reaches for components that are not in your system, hard-codes colours that should be tokens, and mixes conventions across versions (Tailwind v3 patterns dropped into a v4 project).9 Sometimes it invents CSS outright, a value like fit-parent
that no browser understands.10 This is not a skill problem or a bad prompt. It is what the naive pipeline does, to everyone.
Figma says so itself. Its own MCP setup guide11 is blunt about the limit: without Code Connect linking your Figma components to your real code, "the model is guessing." Coming from the vendor of the design tool itself, that admission is worth more than any third-party benchmark.
Why does it guess? Because the file hands it a bare value with no meaning: a FLOAT
of 10
, with nothing to say whether that is ten pixels, a z-index, or ten milliseconds. I dug into that failure in Even Figma isn't sure about its own design tokens; the short version is that the step from raw value to semantic meaning, the resolve step, is unowned and lossy. The model has to infer what the design meant, because the file never says.
To be fair, Figma is closing part of this. Native DTCG export is rolling out, so you can pull your tokens out as typed JSON where a value finally carries its meaning.12 But that types the tokens you export, not the values a model reads back when it generates code from a component. On that path it often gets a bare resolved number with no token attached, and is left to improvise. That gap is here now, not on some roadmap, and it is the one monday set out to close.
The token is only the visible edge of it. "Point an LLM at Figma, get UI" looks like one task, but it is a stack of collapsed decisions the model resolves silently in a single pass. Amrutha Kollu13 frames the split well. Some of those decisions are deterministic and have a correct answer: which token, which spacing, which component. Others are genuine judgment calls. The mistake is handing both kinds to the model at once and hoping. Nobody owns that deterministic layer, the missing middle I wrote about before, so the model fills it in.
You do not have to take my word for it. When Yi Gui and colleagues built Figma2Code,14 a benchmark for turning real Figma files into code, the strongest proprietary models produced visually faithful output but stayed weak on layout responsiveness and maintainability, because they map the primitive values straight out of the Figma metadata without recovering the structure. Faithful pixels, guessed architecture.
If this were a prompting problem, the vendor that owns the entire stack would have solved it. Figma didn't. Figma Make, its own generator, produces standalone code by default; to make it build against your design system, you first have to author "Make kits"15 that package your components, tokens, and guidelines so the generator has something real to work from. So even the company that owns the whole stack cannot make its generator fit your design system for you. It hands you some tooling, but as it stands today that tooling is thin. You still author and maintain the kits yourself, and that is not free. It is real, ongoing work, heaviest on the small or mid-size team just trying to get up and running. Worse, those kits are Figma-specific, so the effort ties you tightly to one vendor instead of leaving you portable. None of this is a technical wall. DTCG is a standard, and any model can read agnostic tokens from any system that exports them cleanly. What keeps you locked in is not the tech; it is that every vendor has a reason to keep you inside its walls. That could change. Right now it has not, and that is the tell. The problem is not the prompt. It is the architecture.
The teams I've seen who have solid design-to-code pipelines stopped tinkering with prompts and rebuilt the pipeline itself. The team at monday.com hit exactly this problem, and instead of prompting harder, they built the sharpest version of the standard pipeline I have found anywhere publicly. It is not a new kind of thing. It is a far better-engineered version of what everyone is already reaching for: a real multi-agent pipeline, and a simple but effective workaround for the token problem. Their engineering team wrote it up1: the naive version failed the same way it fails everyone. "The problem wasn't that the model was bad," they note. "It's that the model had no understanding of what the design system actually was... Without that context, it guessed." So they gave it the understanding.
There is one detail that amuses me. Figma hands over bare values (the FLOAT
10
problem from earlier), so monday makes the spacing and token values visible inside the design itself, laid out for the model to read. The spec, they say, is written for AI, not for a person.16 It is a workaround for sure, not elegant. However, sometimes the low-tech fix is the easiest one, even when the rest of what they built is this advanced.
The shape is a pipeline of eleven small nodes, each with one job, orchestrated with LangGraph. It pulls the raw design out of Figma, then resolves it: raw values become semantic tokens, components get matched against the real library, examples get retrieved. What comes out the far end is not code. It is structured context, everything the model needs to know about the design, handed to whatever agent the developer already runs in Cursor.
That last choice is the clever one. Internally, monday runs hundreds of microfrontends on different React and design-system versions, so forcing a single generated code style would break ownership. By returning context instead of code, they kept the codegen model-agnostic and left authority with each team. They even exposed the whole agent as an MCP tool, so from Cursor's side it is just another tool call. In their words, this is "orchestration, not magic."1
There is a second thing I appreciate, further down the flow. What the developer ends up with is not a bare component but a full Storybook entry. The stories, the tests, and the documentation are generated alongside it, and the props table is drawn from the real component rather than filled in by hand.17 The deliverable is a documented, tested component, not code that merely renders.
It works for one reason: someone owns the resolve step that almost everyone else leaves to chance. It also took a mature design system to resolve against, a dedicated pipeline, and the engineers to build and run it. Hold onto that, because it is where the story turns.
For all that, it is still not hands-off. The honest part is that they say so themselves. In their walkthrough talk,18 Elad Mizrahi, monday's design-systems lead, puts the number at 70 to 90 percent of a component's code generated, higher for the simple ones, lower for the complex, and then "our developers take it from there." Impressive, and a long way from automatic. Someone still writes the last 10 to 30 percent.
Notice what that number costs, too. The 70 to 90 percent is what a mature design system, a dedicated pipeline, and a team of engineers buys you, not to mention an AI bill they have never put a number on. It is the ceiling for the best-resourced setup in the room, not the starting line for everyone else.
One of Mizrahi's observations points ahead. The model does better on new components than on edits to old ones.19 He does not say why. My guess is that the old components carry incomplete recorded reasoning to edit against, so the model is back to guessing what the original decision was.
You can watch the ceiling on camera. Asked to flip a component to an inverted colour scheme live, the model missed; he fed it an example; it missed again. This component, he explained, "we need to do some overrides to make it work," and he was candid: "when you show it to somebody it's not always working."20 So he fixed it himself, by hand, applying the override the model could not. The pipeline got him close; a person closed the last gap.
Even with its faults, you could argue this will only keep getting better with time. The real strength here is not the last mile of code; it is the shape of the multi-agent pipeline and the guardrails and rules they have built around their ecosystem. Every feature still gets a manual design review and a manual code review; the changes "still need to be approved by a person." As he puts it, "we don't want to just rely blindly on AI."21 This is a very good head start, not an autopilot.
The wall is not a monday problem. The same ceiling shows up across setups that could not be more different. At Shopify, designers prototype in a code-connected clone of the actual admin. A designer there described the handoff plainly: the generated code gets an engineer to about 80 percent,22 and the rest is the tightening, the internationalization of strings, the polish, the slop code, the parts that are not production-aligned. At Ramp, a designer using an off-the-shelf prototyping tool with rough approximations of the design system gets to about 70 percent, then goes back into Figma for the real handoff.23 Line the self-reported numbers up and they cluster tight: monday's 70 to 90 percent,18 Shopify's 80, Ramp's 70. Optimistic, self-reported figures.24 Whether it is monday's bespoke pipeline or Ramp's off-the-shelf tool, the number lands in the same place.
There is a stranger shift buried in those setups. Here is what I expected. With seemingly every company now hiring full-stack developers, I assumed the developers would be the ones vibe-coding the UI, reaching for AI to get their own work done faster. What I found is the reverse: it is the designers building the prototypes, and the dev team reuses and finishes them. That inversion blurs the line between designer and developer, the same pendulum I wrote about with the Dreamweaver era.
I will be honest: I am skeptical of that number as a measure of code quality. Even 70 percent seems high unless the component is very simple. Pointing Cursor and Claude at a Figma file through the MCP server, I have had output that looked 70 percent done and turned out closer to 30 once I read it, because the number counts only the visible layer. The layout and the happy path are the cheap part; the states, the edge cases, the accessibility, and the production-alignment are most of the real work, and none of it shows up in the demo that produced the number. That is where a developer comes in. Ramp's designer admits those prototypes are not even functional.23 The prototype is not the product.
None of that makes the prototype worthless. Getting a designer to a clickable version of the real thing is genuinely useful. They feel how it behaves, they catch what a static mockup hides, and they can put it in front of a stakeholder to win sign-off before anyone writes production code. The generation earns its keep. It just earns it as a prototype, not as the product.
The field beyond them is crowded. Some generate from scratch (v0, Lovable, Bolt, Figma Make);25 some do vendor codegen (Builder.io, Anima, Figma's own Dev Mode and Code Connect);26 some make the canvas the code (Subframe, Paper).27 Others work the edges: Google's DESIGN.md7 and Christine Vallaure28 improve the input, Brad Frost29 constrains generation to the system, Romina Kavcic30 detects and heals drift, and Amrutha Kollu's Fixel13 commits a versioned spec and logs every intentional deviation with its reason, keeping a real history of the changes. I can't do justice to any of them here; the point is to document a snapshot of the current shape of the field.
Step back and the gap is clear: we are trying plenty of ways to generate the code, but no one is fully mapping the decisions that need to be made.
The pipeline that looks settled is not settled, and it is unsettled in two separate ways. Getting started is easy; getting good results is not, and that takes a foundation most teams do not have. Then there is an external market that will not sit still. They are not the same problem, and blaming the tools for the first one is a mistake.
Start with the prerequisite. Even monday's pipeline presupposes a mature, documented design system to resolve against, and most teams do not have one. Romina Kavcic analyzed 158 public design systems31 and the drop-off is steep: 89 percent ship code examples, but only 37 percent document usage guidelines, 21 percent accessibility, and 13 percent the content inside components. The systems that score full marks are Polaris,32 Paste,33 and eBay's Playbook,34 the ones run by companies with dedicated infrastructure teams and years behind them. Her conclusion is the one that lands here: "agents can only work with what's documented... many systems aren't ready for a human to use properly, let alone a machine. Fix the layers first." This part is not a failure of the AI. It is a mirror held up to how most design systems are actually run. Point an agent at a chaotic system and it does not fix the chaos; it automates it at scale. Garbage in, garbage out, faster.
There is a fair objection here: just adopt a standard design system like MUI or shadcn and inherit a documented, mature foundation. For a small team starting out, that is genuinely the better move. But it stops covering you the moment you need custom work, and then you are back to authoring and documenting the decisions the model cannot make on its own, the exact foundation most teams were just found to be missing. A standard system is a great place to start. It is not a place most real products get to stay.
Clear that barrier, build a pristine foundation, and you are still not on solid ground. This is the only part of the piece with a dollar sign in it, and you do not need to care about stocks to read it. But the economics underneath these tools are brittle, and that matters for your pipeline.
Start with the bill. The AI coding underneath all of this is sold below what it costs to run, funded by investors betting demand catches up.35 It might. But the gap is stark: Anthropic, whose Claude models most of these tools run on,36 just committed to pay xAI $1.25 billion a month for GPUs, per SpaceX's own SEC filing,37 while its CFO testified in court that the company has earned a little over $5 billion across its whole existence.38 A capital-fuelled buildout running ahead of its revenue is a shape we have seen before.39 The price you build against today is not the price you are promised tomorrow. GitHub already moved Copilot to metered billing;40 monday can absorb a reprice, but the three-person team running the same agents is exactly who gets caught when the meter turns on. The deeper you build on it, the worse the exposure: a pipeline scaffolded to one model does not swap out cleanly.
The ground under the tools is moving too. Figma peaked near $142 a share after its 2025 IPO and trades in the low $20s now; Adobe, still posting record revenue, is down more than a third on the year.41 You do not need to call where any of it lands to plan around it.
So what do you do while all of this keeps moving? You keep your project as loosely coupled to any one tool as you can. The pull is always toward the single integrated vendor that does everything, and it is a real pull, because one place to design, generate, and deploy is genuinely easier. Resist it anyway, because the dominant design tool has already turned over twice in about fifteen years, Photoshop to Sketch to Figma,42 and betting your whole pipeline on today's leader is a bet. Treat any one vendor as a swappable adapter, and keep the parts you own (the resolve step, the token layer, the codegen) open, decoupled, and portable. In times this uncertain, the decoupled project is the one that survives the next shift.
The shift I did not see coming is not in the tooling. It is in who does the work, and it is already happening.
On one side, designers moved up the pipeline into code. They vibe-code the prototype now, they feel the real thing behave, they win the stakeholder sign-off, and they do it in a running interface instead of a static mockup. That is a genuine expansion of the job. It is also bounded: the prototypes are "not functional," the demo is not the product, and the layer they own stops at the prototype. I would call this role prototyping designer: a designer who now designs or validates their work in code, up to the edge of production.
On the other side, developers moved down the pipeline. They pick the work up later now, cleaning and finishing the code after its shape is already set, and they are less involved in the early structural decisions they used to own. That leaves a gap. The decisions that need the most engineering judgment are the ones no human is clearly making anymore, so the model guesses them.
Here is where I stop reporting and start speculating. I do not think the gap is mainly about resources or model quality; resources get you to this ceiling, and better models will keep nudging the percentage up. I think it is about what the pipeline actually carries. Concretely, monday's pipeline resolves values: it turns a raw Figma value into the right semantic token. What it does not carry is decisions, the recorded reasoning for why a component was built the way it was. When the model edits an old component, it has no record of that reasoning, so it is left to assume. Kavcic, who has built one of these systems herself, names the cost of that plainly: "when a human expert fails, they come back with a reason... with agents, 25 failures land on your desk, and none of them come with insight. No ownership, no explanation, no learning."30 A pipeline that cannot explain itself cannot really be trusted to maintain itself. Or, as she puts it, AI cannot fix taste.
Someone has to own that gap, and there is already a name for the person who sits between design and engineering: a Design Engineer.43 What is new is how they spend their time. Part of it is making the decisions the pipeline leaves unmade, mapping the design into terms the code and the model can both act on. Those decisions run a wide range: at the simple end, a design token to a code variable, where the designer's "x" becomes the code's "y"; in between, a relationship, where a new component is really a variation of an existing one to import and reuse; at the hard end, major architecture decisions, splitting one screen into ten microfrontends across separate repos, frameworks, and design systems. Beyond the mapping, I am speculating. A Design Engineer might also push prototypes the last stretch toward production. My impression is that the role works best when they sit close to the designers as they prototype, not only downstream once the code needs finishing. Close to both sides is where they would keep finding new ways to make the system itself better. Write the decision down and a model can execute it. It still cannot reliably make it for you.
Maybe one day a model does that mapping too, if it gets good enough. But someone or something still has to own it, and the ownership is the durable part, not the person doing it.
What monday built, by hand and in private, is the closest thing to closing that gap I have found, a real step in the right direction. What it still lacks is the mapping: its context resolves values and is regenerated from the design on every run, not a record of the decisions that a team owns and re-enters.
There is a harder edge to owning that last mile. Companies want to move fast, and something that looks 80 percent done looks 80 percent done to a boss, who cannot see that most of the real work is the part that never shows. So the pressure is to ship: the demo convinces, and the person who says "not yet" becomes the visible bottleneck. Organizations are being told to treat AI as a multiplier, and they are learning to count the output: components shipped, pull requests merged. Against that scoreboard, holding the line on quality does not look like protecting the product. It looks like slowing it down. Owning the work now means owning that pressure too.
Here is the anticlimax: the fix is boring, decoupling. Keeping the parts of a system independent so you can swap one without breaking the rest has been a foundation of good software for decades. We already know how to do this.
This is not a call to go back. The roles are shifting, and they will keep shifting. AI is part of that, and the speed is real. But we are still in the hype phase, and the fear of missing out is pushing teams to collapse every boundary at once, before the industry has settled. Keep the discipline we already have while the ground is still moving. The lines will move; move them with purpose, not because a demo felt fast.
Whatever stack you are on, start by recording the decisions, not just the tokens: write down the reasoning the pipeline is otherwise left to assume, so the next edit works from a record instead of inventing one. Keep the resolve step, the token layer, and the codegen modular and portable. The decisions are the part to hold onto, precisely because they are the part the model is worst at.
Right now everyone is rebuilding that layer in private. Custom pipelines will always exist, and that is fine. I just wish we had a good open-source option too, decoupled enough that no one is locked to a single vendor, LLM, or tool. It is modular, so no one needs to build the whole thing. Working on a piece? A resolve step, a token layer, typed CSS inputs, a codegen, a way to record the decisions? Tell me about it in the comments. A decoupled system comes together one part at a time. I would like to build it with you.
A few of the people and teams whose work informed this piece, or who are circling the same problem, all worth following:
$extensions
field.monday.com Engineering, "How We Use AI to Turn Figma Designs into Production Code." ↩ UX Tools 2024 Design Tools Survey, interface-design segment, where Figma leads at 82.3%, roughly 46:1 over Sketch. uxtools.co/survey. ↩
Figma Q1 FY2026 earnings call: roughly 60% of customers spending over $100k a year used Figma Make weekly, up from over 50% the prior quarter. ↩
The Design Tokens Community Group is a W3C community group; its format module reached first-stable (v2025.10) on 28 October 2025, with 20+ editor organizations and two dozen-plus participating companies including Adobe, Google, Microsoft, Meta, Amazon, Shopify, Salesforce, and Figma. w3.org/community/design-tokens and designtokens.org. ↩
Style Dictionary v4 ships first-class DTCG support. styledictionary.com/info/dtcg. ↩
Terrazzo is a DTCG-native design-token toolchain: its CLI is "for managing design tokens using the Design Tokens Community Group (DTCG) standard and generating code for any platform via plugins" (@terrazzo/cli
). [terrazzo.app](https://terrazzo.app). ↩
Google's DESIGN.md, a spec for describing a design system to a coding agent. [github.com/google-labs-code/design.md](https://github.com/google-labs-code/design.md). ↩
Tokens Studio for Figma (300k+ users) is a community plugin for managing design tokens; it supports the W3C Design Tokens Community Group (DTCG) format. Figma Community plugin; DTCG support documented at docs.tokens.studio. ↩
AI models routinely apply Tailwind v3 conventions to v4 projects; Tailwind documents the breaking changes in its upgrade guide (tailwindcss.com/docs/upgrade-guide). Reported example: Prathit, "AI Models Still Can't Configure Tailwind Correctly." ↩
fit-parent
is not a real CSS value; the valid keyword is fit-content
(developer.mozilla.org/en-US/docs/Web/CSS/width). The hallucination is documented in Shahid Pattani, "Design-to-Code AI Is Not Magic." ↩ Figma's MCP server setup guide: "Link components to your codebase via Code Connect. This is the best way to get consistent component reuse in code. Without it, the model is guessing." github.com/figma/mcp-server-guide. ↩
Figma announced native DTCG variable export at Schema 2025 and it is rolling out gradually: right-click a variable collection and Export to JSON in DTCG-aligned form. Primitive tokens (colour, dimension) export cleanly; the composite types and the description
field still trail, though a composite that comes out as its constituent primitives is trivial to reassemble (open community request). Either way, this is the token-export path, separate from what the Figma MCP hands a model when it reads a component to generate code. I dug into the underlying variables data model in Even Figma isn't sure about its own design tokens. Rollout status as of July 2026. ↩
Amrutha Kollu, "Why AI Keeps Generating the Wrong Design Tokens, and How I Fixed It with Figma's API." ↩
Yi Gui, Jiawan Zhang, Yina Wang, Tianran Ma, Yao Wan, Shilin He, Dongping Chen, Zhou Zhao, Wenbin Jiang, Xuanhua Shi, Hai Jin, and Philip S. Yu, "Figma2Code: Automating Multimodal Design to Code in the Wild" (arXiv 2604.13648, ICLR 2026). Benchmarking ten leading models on real Figma files, they find proprietary models achieve superior visual fidelity but stay limited in layout responsiveness and code maintainability, mapping primitive visual attributes straight from the Figma metadata. arxiv.org/abs/2604.13648. ↩
Figma Make produces standalone code by default; aligning it to a design system requires authoring "Make kits." figma.com/blog/introducing-make-kits-and-make-attachments. ↩
Same walkthrough: the spacing and token values are surfaced inside the design for the model to read, a spec written for AI rather than a person, "instead of writing for a person we write for AI... all the spacings are visible. It helps the AI to see the spacing in cursor" (0:16). ↩
Same walkthrough: the flow produces a full Storybook entry, not just code, "it's available already in storybook and all the documentations are generated all the props are generated" (11:31); "at the end of the flow it's creating all the stories all the tests for the developers" (12:05). The engineering blog separately notes the pipeline "resolved valid variants and props" for system components (engineering.monday.com). ↩
Elad Mizrahi, monday.com's design-systems lead, Sneak Peek walkthrough: 70 to 90 percent generated, then "our developers take it from there" (43:01). ↩
Same walkthrough: the model does better on new components than edits to old ones (32:34). The reason is my own hypothesis, not his. ↩ Same walkthrough, the live colour-flip stumble: "we need to do some overrides to make it work" (32:04); "when you show it to somebody it's not always working" (32:16). ↩
Same walkthrough: changes "still need to be approved by a person" (40:59); "we don't want to just rely blindly on AI" (44:03). ↩
Shopify product designer Kazden Cattapan, Sneak Peek: a code-connected clone of the admin; generated code gets an engineer to about 80 percent (43:31), with the internationalization of strings, polish, and "slop code" (43:15) left over. ↩
Ramp product designer George Visan, Sneak Peek: asked what share of the design he targets in Magic Patterns, "0 to 70ish", then "I am going back to Figma" for the real handoff (18:06); the prototypes are "not functional" (36:54). ↩
These are each team's own numbers, and self-reported bests round up, so read them as a ceiling, not a measurement. ↩
Generate-from-scratch tools named here: v0 (v0.app), Lovable (lovable.dev), Bolt (bolt.new). Figma Make is covered above. ↩ Vendor codegen tools named here: Builder.io (builder.io), Anima (animaapp.com), Figma's Dev Mode (figma.com/dev-mode). Code Connect is covered in the MCP note above. ↩
Canvas-as-code tools named here: Subframe (subframe.com), Paper (paper.design). ↩ Christine Vallaure, on designing Figma files a machine can actually read. christinevallaure.substack.com/p/agentic-ai-design-systems-and-figma. ↩
Brad Frost, on constraining AI generation to the design system. bradfrost.com/blog/post/agentic-design-systems-in-2026/. ↩ Romina Kavcic, on self-healing design systems: "when a human expert fails, they come back with a reason... with agents, 25 failures land on your desk, and none of them come with insight. No ownership, no explanation, no learning." Also "AI cannot fix taste." ↩
Romina Kavcic, "What I Learned from Analyzing 158 Design Systems." Figures are self-reported. Three systems scored a perfect 7 (documenting all seven layers): Polaris, Paste, and eBay Playbook. ↩
Shopify's Polaris design system. [polaris.shopify.com](https://polaris.shopify.com). ↩
Twilio's Paste, an open-source design system. [paste.twilio.design](https://paste.twilio.design). ↩
eBay's Playbook design system. [playbook.ebay.com](https://playbook.ebay.com). ↩
On AI coding tools priced below what it costs to serve them: Ed Zitron, "AI's Economics Don't Make Sense", for the framing; Arize, "AI Model Subsidies Are Ending", on the subsidy mechanism. Framing, not hard numbers; the hard figures are the xAI-versus-revenue gap below. ↩
Menlo Ventures: in surveys of technical leaders, Claude led code generation at roughly 42% share versus OpenAI's 21% by mid-2025 ("2025 Mid-Year LLM Market Update"), rising to about 54% by late 2025 ("2025: The State of Generative AI in the Enterprise"), driven by Claude Code. ↩
Per SpaceX's SEC S-1 filing, Anthropic committed to pay xAI about $1.25 billion a month for compute through 2029, after a two-month discounted ramp (reported by TechCrunch, 20 May 2026). ↩
Anthropic CFO Krishna Rao, sworn declaration (9 March 2026) in Anthropic's suit against the U.S. Department of Defense (now the Department of War; N.D. Cal. No. 3:26-cv-01996), stated the company's revenue to date exceeds $5 billion. Docket on CourtListener. ↩
The precedent is the late-1990s telecom fibre-optic overbuild: carriers spent hundreds of billions laying capacity ahead of demand and were left with a glut when adoption arrived slower than the buildout. Paul Kedrosky draws the same parallel to today's AI data-centre spending in "SPVs, Credit, and AI Datacenters" (30 June 2025): "AI data centers, like telecom fiber before them, are highly capital-intensive, and the long-term returns remain speculative." ↩
GitHub moved Copilot to usage-based billing effective 1 June 2026. github.blog. ↩ Stock figures as of early July 2026. Figma peaked near $142 after its 2025 IPO and trades in the low $20s; Adobe is down more than a third year-to-date while still posting record revenue. See stockanalysis.com for current prices. ↩
The dominant design tool has turned over twice in about fifteen years, Photoshop to Sketch to Figma; Sketch peaked near 70 percent around 2017 and fell below 2 percent by 2024. ↩
"Design Engineer" is not my term. Its use for the design-and-engineering intersection traces at least to Natalya Shelburne's 2019 talk "CSS at the intersection"; David Luhr collects the lineage in "The Origins of Design Engineering" (Brad Frost's related "front-of-the-front-end", 2021, is a distinct term). ↩