We spent twenty years getting designers out of the code. AI just put the design back in charge of it.

The pendulum swings back

Designers used to be in the code. In the Dreamweaver and WYSIWYG era, you laid out a page in a visual tool and it wrote the markup for you. The industry then spent the better part of twenty years undoing that. We drew a line: designers design, developers build, and a human translates between the two.

AI is swinging the pendulum back. Not by putting designers back in the code, but by handing their design to a machine that writes it. Point the model at the file, get components out. The design drives the code again.

Here is the part that should give you pause. This is not a clean return to the Dreamweaver days. Back then, however messy the generated markup was, a person still sat in the translation and owned it. Now the design goes straight to code with no one in the driver's seat. That seat is where quality used to get enforced.

Two quick things before I go further, because this argument gets misread in two predictable ways.

First, this is not a knock on designers. Designers do great work. The point is a distinction. What makes a great design file is not what makes a great design system, or what makes good code. A file is judged on the design. A system is judged on reuse, on states, on durability. The AI workflow blurs that line, and the blur is the whole subject.

Second, if you are building a simple static site, pointing AI at the design is genuinely fine. The snapshot is the thing. Ship it. The problem I am describing only bites when the design is meant to become a reusable system: a design system, a custom CMS, a dynamic UI. Keep that scope in mind.

The dream is real

I want to be fair to the dream, because it is seductive and it is partly true. Point AI at the design, get working code, one step.

AI is genuinely valuable. I use it. It has let me do things I could not have done before, and finish projects under tight deadlines in codebases I did not know well. I am not here to tell you the tool is bad.

But notice where that value lands. It lands at the snapshot level. Real value is not the same thing as a foundation. That gap is the rest of this post.

A design is not a foundation

Here is the concrete failure, and it is not hypothetical. Teams build entire token pipelines around the variable names a designer chose in Figma. Naming is a design decision, but auto-translation quietly promotes it to a load-bearing contract. Rename one variable in the design file and the pipeline snaps three steps downstream. The design is doing a foundation's job, and breaking, because it was never built for it.

You can see it in a single pair of names. --blue-500 is a value; --color-primary is an intent. A system should depend on the intent, and AI cannot reliably tell which one the design meant.

The obvious fix is to train designers to name things the system-correct way. But that points the effort at the wrong person. I love working with designers, but the answer is not to turn them into systems engineers, negotiating every token name. Translating their vision into a durable system is my job, not theirs. That translation wants to be a pipeline: map the design tokens onto a universal standard, then watch for drift. I will come back to what that standard is.

Naming is only the first failure mode. Set it aside and a deeper one remains. A design is a static snapshot. It shows one state of one screen. It does not encode reusable versus one-off, the empty, loading, and error states, what is content-driven versus fixed, or how a CMS feeds it. That systemic context lives in the developer's head and in the code. It is not in the file.

The industry has noticed the input problem, and it is moving on it. Google recently open-sourced DESIGN.md, a format for handing a structured design system to a coding agent instead of a raw file, and a catalogue of them is already forming.¹ That is a real step, and it tells you the input was a weak link all along. Hold that thought, because where DESIGN.md stops is exactly the point.

The deeper limit is not the input format. It is that the design, in any form, is the wrong source for the decisions. The model's best case is the guts of the design file, an artifact optimized for none of the things a foundation needs: not design-system structure, not coding best practices, not the developer or agent experience. Its worst case is a screenshot, pixels with no structure at all. Even a flawless extraction cannot supply the architectural decisions a human makes to accommodate a design.² The deciding stays human.

So the verdict. A design is not a foundation. Auto-translating it into code silently promotes it to one, and it was never built for the role.

People are working on this

This gap is real, and a lot of people are working on it right now, from the biggest players to solo builders. Google's DESIGN.md is one move. An ecosystem has formed around it almost overnight, and it is already being put to the test in production. My friend Amrutha Kollu is one of the independent builders coming at it. Her tool, Fixel, validates your code against Figma in continuous integration and catches design-system drift before it merges. When it finds drift, it posts the finding back onto the Figma canvas as a comment, so the designer sees it in the place they already work.³ It is promising work on a real problem.

Where all of this lands is genuinely open. A lot of smart people are coming at the same problem from different angles at once. That open question is the honest state of things, and it is a big part of why I am writing this.

I want to be precise about where it sits, because the boundaries are the interesting part. Fixel is on the code side, and it does not claim to have solved the whole thing. The limit worth naming, and I mean it as architecture, not criticism: it reads directly from the design tool, so any tool-coupled approach risks going obsolete unless it targets the open standard underneath. That standard is the W3C Design Tokens format, or DTCG, the vendor-neutral spec the major tools are converging on, and it is the durable anchor here.

The missing middle

You might think the newest tools already close this. They have gone well past reading a screenshot. Claude Design imports your design system straight from your codebase and checks its output against it before you see it.⁴ Google's Stitch reads your tokens before it draws a screen. That is real, and it is the convert step getting genuinely good.

But two things none of it does. It assumes the system already exists and is clean enough to import, which means someone built that foundation and still owns it. It also checks only once, at generation. The harder problem is what happens after the code merges, when the design and the system keep moving and quietly drift apart.

So that is where this leaves us. Not with the design driving the code, and not with a person hand-translating every screen either. It leaves us with a middle that someone has to own.

Here is the bet I would make on what the missing middle looks like. I think it starts with typed CSS inputs at build time: a foundation where a value carries a type and a meaning, not just a string the model can get wrong. On top of that, the AI does what it is good at. It pulls the variables out of the design and proposes how they map onto the system you already have. Then the UX engineer does what only they can. They shape that proposal into the system they actually want, decide what each value means, and set the behaviour and the success criteria the result has to meet. Typed inputs and automated checks keep the AI's suggestions honest.

Those decisions do not live in someone's head, or get re-derived on every run. They become an artifact: a committed, versioned record of how this design maps onto the system, owned by the engineer. Fixel already does a version of this. Its overrides registry commits each intentional deviation to git with a reason and a timestamp, an audit trail instead of a silent guess. This is the part DESIGN.md cannot reach. Its prose "why" is re-read and re-interpreted by the model on every run, where a committed artifact is a decision someone made and signed.

Notice what did not happen there. The design never became the system on its own. Clean variables out of Figma are a real step, but they are not the finish line, because the same tokens can be implemented a hundred ways. Choosing which one is the judgment, and the judgment is the job.

The mistake, named

Here is the irony to leave on. AI makes designers more responsible for code quality than they were back when we actually wanted them writing it. The design becomes the code, and no one is left gatekeeping the translation.

So the real mistake is not that we use AI to get there. It is that we are writing the UX engineer out of the loop, right when that judgment most needs an owner. The role is not going away. It is changing into the person who owns this middle: the system the design feeds into, the mapping, the contract that keeps a design from quietly becoming the foundation.

The durable anchor under all of it is a standard with the mapping in your hands, and that standard is where I am headed in my next article.

If you are building this middle, I would genuinely like to hear how you draw the line between what the AI proposes and what stays yours to decide. That is the conversation I am trying to start.

---

---

1. DESIGN.md is a Markdown file that describes a design system to an AI coding agent in a structured way: machine-readable tokens plus human-readable prose. Google Labs open-sourced it in April 2026. See the Google Labs announcement (blog.google, "Stitch DESIGN.md") and the spec repo (github.com/google-labs-code/design.md). A community catalogue at getdesign.md (maintained by VoltAgent) already lists 75 DESIGN.md files built on the spec (as of June 2026). ↩

2. This limit shows up in practice. When Atlassian benchmarked DESIGN.md against their own design-system tooling, they reported it was more likely to re-create existing components than to import the ones already in their system. A faithful description of how a component looks does not carry the decision to reuse the component that already exists. See Atlassian, "Atlassian's DESIGN.md is here: what we learned testing portable design context in practice" (atlassian.com, June 2026). ↩

3. Amrutha Kollu's writing on this gap: How I shipped 60+ design system components in 5 weeks using Figma as the single source of truth, Why AI keeps generating the wrong design tokens and how I fixed it with Figma's API, and Check Designs validates your Figma. What validates your code?. Fixel validates code against Figma in CI to catch design-system drift. ↩

4. Claude Design, Anthropic Labs (anthropic.com/news/claude-design-anthropic-labs). A June 2026 update added importing a design system from a repository or files and checking generated output against it. ↩