Where web development goes next, and why the storefront is the test case

In November 2025, Figma published a talk from its Schema conference under a title that could have been generic: "The future of design systems and AI." Eleven minutes, delivered by Matt Fichtner, the design manager who looks after design systems at Figma. What makes it worth an hour of a storefront team's attention is one phrase inside it, and the way the rest of the talk follows from it.

He calls the gap between design and code the chasm of despair. Not a gap in taste or in tooling. A gap in truth: the file says one thing, the codebase says another, the documentation says a third thing from eight months ago, and the team's actual convention lives in somebody's head.

Design systems people have argued about closing that chasm for a decade. The claim in this talk is different in kind: closing it is now a precondition for using AI at all. "We expect AI to help our teams in miraculous ways," he says, "but we still haven't set it up for success because today's systems just weren't built with AI in mind."

That is a web development argument wearing a design systems jacket. And a storefront is the cleanest place to test it.

The two problems, stated plainly

The first is that design and code live in different worlds. Teams build automation, manage the change between files and repositories, try to keep documentation fresh, and it never stays in sync. Inside the chasm is where systems stop scaling, trust erodes, and people go back to building everything from scratch, which widens the chasm further.

The second is fragmentation of context. Tokens in one file, rules in a wiki, states in a design doc, exceptions in a support article with a 2023 screenshot, and a few conventions that were never written down at all. A person can eventually piece that together. A new hire takes months. A model takes what it is given, and what it is given is usually a screenshot.

Why this is a web development argument now

Because the price of producing a first version of an interface has collapsed. A page, a filter panel, a form with validation: minutes, not weeks.

What did not collapse is the cost of being wrong. Generated interface is exactly as good as the context it was generated from. If your system's tokens, component boundaries, usage rules and states exist as a maintained, readable source, the output lands close to your house style and, more importantly, references behavior you already tested. If the only input is a picture, the output looks right and behaves wrong, and the review that catches it is now the scarce step in the process.

So the interesting question for web development over the next two years is not which framework wins. It is which of your decisions are written down somewhere a tool can read.

What context means in a storefront

Take the ordinary component from a parts catalog: the fitment filter.

It has a default state, a partially selected state, a "does not fit your saved vehicle" state, a no-results state, a backorder state, a trade-pricing state only some accounts see, and a loading state on a slow connection. That is seven. The design file usually draws one, the wiki documents two, and the trade-pricing rule lives with the person who negotiated it.

Everything that was never written down gets invented again in code, separately, by whoever hits it first. Two years later one implementation allows an order for a part that does not fit, and nobody can say which of the four filters is the real one. That is the chasm, and it costs money in returns, not in critique.

The pieces the talk actually names

Fichtner is careful to say the features are first steps. The interesting thing is the direction they point.

The vocabulary came from code in the first place. Auto layout, components and variables all originated in engineering. Figma brought them into the design tool, and the talk makes a specific observation: using them produces better model output, not just better files. A frame that is a real layout with real constraints is legible; a rectangle drawn to look like one is not.

Code Connect and an MCP server together form the bridge. MCP exposes a system's tokens, component properties and usage patterns as a live service other tools can consume, rather than as an export somebody re-uploads on Fridays. The line worth keeping is his: "We're not just trying to sync artifacts anymore. We're actually starting to sync meaning."

Validation moves into the act of making. Check designs reviews decisions inside the file and nudges them back into alignment, and he frames where that ends up as adherence that is "as simple as autocomplete." The system becomes a collaborator rather than a document you consult after the fact.

Production components come back into the design stage. Importing a component library via npm, and generating component sets from a Figma library when the production set is imperfect, so a prototype can be built from the real system instead of a drawing of it.

None of that is a promise that storefronts build themselves. It is a reshuffling of where the work is.

What it does to the test case

Two consequences, and one hard ceiling.

The first consequence: if tokens and usage rules are served as live context, a generated catalog filter arrives already using your spacing scale, your focus treatment and your component boundaries. Review time then goes where the system cannot see: latency, focus order, an empty state at 70 miles an hour on one bar of signal, the exception a manufacturer's brand rules do not cover.

The second: a system that can validate adherence turns brand compliance from a manual review into a rule. For a dealer group juggling OEM component requirements across ten rooftops and a third-party build, that is the difference between an argument and a check.

The ceiling is data. A perfectly systematic component reading bad fitment data produces confident, wrong answers faster than any person ever could. Closing the design-to-code chasm makes the interface honest; it does nothing for a catalog whose compatibility table is free text maintained in two systems by hand. That work remains, and it is the work that actually decides whether a customer is told the truth about a part.

What still breaks first

Not the framework. Usually one of three things.

The script tax. A marketing stack heavier than the product it wraps, loaded before the first image, owned by a team that never sees the page-speed report.

The ownership gap. Marketing owns the site, product owns the storefront, someone else owns the inventory feed, and nobody owns the seam where the fitment badge and the filter disagree.

The data model that cannot answer in one request. So every surface calls something else, caches something different, and contradicts itself by Thursday.

What to do with the talk this quarter

1. Write the context down. Semantic names, component descriptions, and a state list for every component that has more than one. The parts that stay in people's heads are the parts that get reinvented.
2. Map components to code, and keep the map alive. A maintained mapping is what lets a tool read your implementation instead of copying a picture.
3. Expose the system as a service. Whether that is Code Connect and MCP or an equivalent of your own, the point is a live source rather than a quarterly export.
4. Name tokens by role, not by value. Surface, muted, critical. A rebrand should not require a find and replace across the storefront.
5. Treat fitment and service data as the input contract. The interface can only be as truthful as the answer it was handed.
6. Keep a human review for what the system cannot see. Generated output that looks right and behaves wrong is precisely the failure mode a fast pipeline produces at scale.

Fichtner ends in the direction you would expect: richer systems, systems that evolve alongside the product, governance that shifts from updating a file to updating the system itself. Whether that arrives in two years or seven is not the part to plan around. The part to plan around is the sentence underneath it. A system is not finished when it is documented. It is finished when something other than a person can read it.