What my master's thesis found about Figma-to-code AI tools

My master's thesis is called "AI-Assisted Web Development: Evaluating the Accuracy and Efficiency of Figma-to-Code AI Tools". It came from a very practical frustration: every few months a tool launches claiming to turn a Figma file into production-ready frontend code, and every few months the frontend community argues about whether designers and developers are about to be replaced.

I wanted data instead of takes. So I studied the tools the way an engineer would study a dependency: what do they actually produce, how close is it to what you would ship, and how much time do they really save?

What I measured

The study compared AI-generated implementations of interface designs against the expectations of real frontend work. For each generated result I looked at several dimensions:

• Visual fidelity — does it look like the design at the target breakpoints?
• Structural quality — is the generated markup semantic and maintainable, or a nest of absolutely-positioned divs?
• Responsiveness — does it hold up when the viewport changes, or was it generated for a single screenshot width?
• Accessibility — are interactions keyboard-reachable and are controls labeled?
• Efficiency — how much time does the tool save compared to hand implementation, including the time spent correcting it?

That last measure is the one most evaluations skip, and it is the one that changes the conclusion.

What the results showed

1. Visual fidelity is real and genuinely useful. Modern tools are good at reproducing layout, color, typography, and spacing from a design. As a starting point, that is a meaningful speed-up — especially for repetitive screens like dashboards, settings pages, and forms.

2. Structural quality is where it falls apart. Generated code tends to optimize for matching pixels rather than expressing intent. Deep wrappers, magic spacing values, and brittle absolute positioning are common. The layout looks correct and the code is hard to extend, which is a bad trade to discover two sprints later.

3. Responsiveness is treated as an afterthought. Tools generated for a specific frame size frequently produced layouts that looked fine at that width and broke at others. Responsive behavior is the part of frontend work that most benefits from human judgment, and it is precisely what a single-artboard input does not describe.

4. Accessibility is mostly absent. Semantic elements, focus states, labels, contrast, and keyboard flows were inconsistent at best. This is a predictable outcome: accessibility exists in the design and the intent, not in the pixels, so a pixel-matching model has nothing to match.

5. Time savings are real but concentrated early. For professionals, the tools were fastest at the first draft — getting to a rough, working layout quickly. For people without frontend experience, speed was deceptive: the output looked finished, and the effort to make it correct, responsive, and accessible was larger than writing it from scratch.

The pattern across all five: AI is an accelerator for people who already know what good output looks like, and a confidence trap for people who don't.

What this means if you build or design frontend

• Treat generated code as a first draft, never a deliverable. It is a very fast junior developer with no access to your design system, your conventions, or your users.
• Invest in tokens and components first. The better your design tokens and component primitives, the more the generated output has to snap onto — and the less cleanup remains.
• Make responsiveness an explicit input. If you ask for a screen, you get a screen. If you can describe the breakpoints and behaviors, the output improves measurably.
• Put accessibility in the review checklist, not the prompt. It is too easy to skip and too expensive to retrofit.
• Measure total time, not generation time. The demo ends at generation. The work begins there.

How this changed how I build

I finished the thesis while building Tempo and Enclave, and the findings show up concretely in both:

• Design systems over screens. Tempo has a small set of primitives — cards, pills, buttons, responsive grids — and the whole interface composes from them. Consistent inputs make any generated or human-authored code easier to integrate.
• Mobile is designed first, not squeezed in. The Tempo home dashboard and scorecard were built to adapt from a portrait phone to an ultrawide desktop with no horizontal overflow, because the gym device is a phone.
• Boring, semantic HTML. Divs are not a personality. Buttons are buttons, headings are headings, and focus states are part of the design.
• I still use AI heavily — for the parts it is good at. Boilerplate, tests, refactors, documentation, exploring unfamiliar APIs. Not for deciding what the interface should be.

The honest conclusion

The thesis does not say AI is bad at frontend. It says AI is excellent at the part of frontend that can be seen, and weak at the parts that must be reasoned about: semantics, responsiveness, accessibility, and maintainability. The best results come from a workflow where a human sets the constraints and reviews the output, and where the tool is judged by the quality of the final product rather than the speed of the first draft.

That is a much less exciting headline than "AI writes your app". It is also the version that survives contact with production.

If you want to dig into the details — method, tools, and results — the thesis is listed on my blog page. And if you are evaluating these tools on a team, I am always happy to compare notes.