The design handoff is the most expensive ritual in digital product development, and most teams don't even measure its cost. A designer polishes a screen for weeks. An engineer receives a Figma link, a Slack message, and a deadline. What ships six weeks later resembles the design the way a photocopy of a photocopy resembles the original.

At Things, we've spent eight years building products where design and engineering sit at the same table, literally. Since 2018, our studio in Istanbul and Elazığ has shipped more than fifty products for leading brands in Turkey and worldwide, and our position has always been simple: we ship what we design. Over the past two years, AI has changed how we do that. Not by replacing the handoff with magic, but by removing the gaps where intent used to die.

This is how design-to-code with AI actually works: what the tools do well, where they fall short, and why the teams that win will pair AI with designers and engineers who work as one unit.

Why does traditional design handoff fail?

Traditional handoff fails because it's a translation exercise between two people who speak different languages, mediated by artifacts nobody fully reads. Design intent is rich: spacing rhythm, motion, state logic, tone. Handoff artifacts are thin. Everything that doesn't survive the translation becomes a bug, a compromise, or a fight.

The failure shows up in three recurring patterns:

Lost intent

A static mockup captures maybe a third of what a designer actually decided. What happens when the list is empty? When the name is 47 characters long? When the request fails? When the user is on a 320px screen? Designers hold answers to these questions in their heads. If those answers never make it into an artifact the engineer uses, the engineer invents their own, usually under deadline pressure, usually differently than the designer would have.

Spec drift

The design changes after handoff. It always does. Stakeholder feedback arrives, a legal requirement surfaces, the designer refines a flow. Now there are two sources of truth, the Figma file and the codebase, and they diverge a little more every sprint. Six months in, nobody can say which one is correct.

Redlines nobody reads

Annotated specs, spacing overlays, handoff plugins that export padding values: these exist because teams know intent gets lost. But a 40-page spec document is write-only media. Engineers skim it once, then work from the picture. The effort that went into redlining is largely ceremonial: it protects the designer's ability to say "it was in the spec" more than it protects the product.

The root cause underneath all three: handoff assumes design and engineering are sequential phases performed by separate parties. Every gap between those parties is a place where the product quietly degrades.

What does AI actually change in design-to-code?

AI changes the economics of translation. The work that used to make handoff expensive, turning visual and written intent into working frontend code, is now largely automatable, provided you feed the AI the right inputs. Four shifts matter most.

Agentic coding tools

Tools like Claude Code don't just autocomplete lines. They read a codebase, follow project conventions, plan multi-file changes, run the build, and iterate. Point an agentic tool at a well-documented component library and a clear description of a screen, and it can produce a working, convention-respecting implementation in minutes. The engineer's role shifts from typist to reviewer and architect.

Design tokens as source of truth

AI-generated code is only as consistent as its inputs. Design tokens (colors, type scales, spacing, radii, elevation, motion values expressed as named variables) give the AI a vocabulary that matches the design system exactly. When tokens are the single source of truth, "make the card use the elevated surface style" resolves to surface-raised in both Figma and the codebase. The AI never invents a hex code, and design changes propagate by updating a token, not by re-briefing a team.

Markdown design docs the AI reads

This is the quiet revolution. Agentic tools read plain-text documentation as part of their working context. So we write design intent (component behavior, states, edge cases, content rules, accessibility requirements) as markdown files that live in the repository next to the code. The "spec nobody reads" becomes the spec the AI always reads, on every task. When a designer updates the doc, the next AI-assisted change picks it up automatically. Documentation stops being ceremony and becomes infrastructure.

Figma-to-code tooling

Figma's APIs, Dev Mode, and MCP-style integrations now let coding agents inspect real design files: exact layout structure, token bindings, variants, and component properties. Instead of an engineer eyeballing a screenshot, the agent reads the same structured data the designer authored. Raw one-click "export to code" still produces throwaway markup, but Figma data plus an agentic tool plus an existing component library is a genuinely different proposition: the agent maps design components to code components rather than generating divs from pixels.

Is AI-generated frontend code actually good enough to ship?

With the right setup, AI produces production-quality frontend for well-defined work, and it still needs human engineers for architecture, judgment, and the last ten percent. Being honest about this line is what separates teams that ship from teams that demo.

Where AI-generated frontend is genuinely strong today:

  • Implementing screens from an existing, token-driven component library
  • Responsive layout, standard interaction states, and form handling
  • Refactoring for consistency across a codebase
  • Accessibility fundamentals (semantic markup, focus order, ARIA) when explicitly required in the docs it reads
  • Catching drift between the design spec and the implementation

Where human engineers step in:

  • Architecture. Data flow, state management, caching, API contracts, performance budgets. AI executes within an architecture; experienced engineers define it.
  • The last ten percent. Easing curves that feel right, scroll behavior on real devices, keyboard traps, the difference between "passes review" and "feels crafted." This is taste applied to code, and it's still human work.
  • Novel patterns. When a product needs an interaction that doesn't exist in the component library, someone has to design and build it deliberately.
  • Review and accountability. Every AI-written line ships under an engineer's name at Things. AI accelerates; it doesn't absolve.

Treat AI as a very fast mid-level implementer with perfect recall of your documentation and zero ego about revisions. That's an extraordinary teammate, provided senior humans direct it.

Why do design and engineering under one roof still matter in the AI era?

Because AI removes the cost of translation, not the need for shared intent. An agency that designs and throws files over a wall to an outsourced dev team can now throw them faster, but the gaps remain, because the two sides still don't share context, vocabulary, or accountability.

When designers and engineers work in one studio, the AI-era advantages compound:

  1. The tokens are real. Engineers help design the token architecture, so it maps cleanly to code from day one instead of being retrofitted after handoff.
  2. The docs are written for two readers. Design docs at Things are authored knowing both an engineer and an AI agent will consume them. That discipline makes them precise.
  3. Feedback loops close in hours, not sprints. When AI builds a screen in twenty minutes, the bottleneck becomes review. A designer sitting next to the engineer reviews the build the same afternoon and corrects course before drift accumulates.
  4. One party owns the outcome. There's no "design said / dev said." We ship what we design because the same team is responsible for both.

This is why we call ourselves a studio, not an agency. Agencies hand off. Studios ship.

What does a practical AI design-to-code workflow look like?

Start with tokens, write intent as markdown, let agents implement against your component library, and review with designers in the loop. Here's the workflow any team can adopt:

  1. Establish design tokens as the single source of truth. Define them in Figma variables and export them to code (Style Dictionary or similar). No hardcoded values on either side.
  2. Build or audit your component library. AI-generated screens are only as good as the components they compose. Document each component's props, variants, and states.
  3. Write design docs in markdown, in the repo. For every feature: purpose, states, edge cases, content rules, accessibility requirements, responsive behavior. Keep them short and current; they are AI context, not paperwork.
  4. Connect your design file to your coding agent. Use Figma's structured data (Dev Mode, MCP integrations) so the agent reads layout and token bindings rather than guessing from screenshots.
  5. Brief the agent like a senior engineer briefs a mid-level one. Reference the doc, the components, and the acceptance criteria. Small, reviewable tasks beat "build the app."
  6. Review in pairs. Engineer reviews the code; designer reviews the build. Same day. Log every deviation back into the design doc so the system learns.
  7. Treat drift as a bug. When design and code diverge, fix the source of truth (the tokens or the doc), not just the symptom.

How does Things run this in production?

At Things, every product team is a designer-engineer pair from day one. That's been true since 2018, long before AI. What's changed is the connective tissue. Our design systems are token-first and exported straight into each codebase. Design intent lives as markdown in the repository, versioned alongside the code it describes. Agentic tools like Claude Code implement against our component libraries with those docs in context, and our engineers review, harden, and finish every build. Our designers see working software within hours of a design decision, which means the research-driven rigor that earned us a Red Dot award survives all the way into production, across web, native, and hybrid mobile.

The result isn't fewer people. It's the same senior people spending their time on judgment, craft, and product thinking instead of translation. Design. Code. Mastery, with the gap between the first two finally closed.

FAQ

Can AI convert Figma designs directly to production code? Directly and blindly, no; raw exports produce unmaintainable markup. But an agentic coding tool that reads Figma's structured data and maps it onto your existing token-driven component library can produce production-grade implementations that engineers review and finish.

Will AI replace frontend developers? No. It replaces the translation labor of frontend work. Architecture, performance, novel interactions, accessibility judgment, and the final layer of craft remain human responsibilities, and reviewing AI output well requires exactly that seniority.

What do we need in place before adopting AI design-to-code? Three things: design tokens shared between Figma and code, a documented component library, and written design docs the AI can read. Without these, AI generates plausible-looking inconsistency at high speed.

How do design tokens help AI code generation? Tokens give the AI a closed vocabulary that matches your design system, so it references named system values instead of inventing arbitrary ones. Design changes then propagate by updating tokens, not rewriting screens.

Is AI-generated frontend accessible? It can meet accessibility fundamentals when requirements are explicit in the docs it reads, but accessibility must be specified, tested, and reviewed by humans. It's a workflow discipline, not a model feature.

Ship what you design

If your product still loses something between the Figma file and the release build, the problem isn't your designers or your engineers. It's the gap between them. We closed ours. We can help you close yours.

Talk to Things, a studio, not an agency, building AI-augmented design and engineering for brands in Turkey and worldwide. Write to us at hello@things.ist or visit things.ist.