Codegen as an extension, not an automation

Codegen—generating code automatically from rules or specifications—covers everything from IDE autocompletion like Microsoft’s IntelliSense and Figma’s code snippets, to visual programming tools and modern AI assistants such as GitHub Copilot. But the useful question isn’t whether it can replace a developer. It’s where it amplifies one.

Figma’s own path to Dev Mode illustrates this. Early versions aimed at automating design-to-code conversion, but developers often found the output less than useful: one-size-fits-all generated code rarely fits a team’s actual framework and patterns. The pivot was to treat codegen as an extension rather than a replacement—an intelligence amplification (IA) tool in the spirit of Steve Jobs’ “bicycle of the mind.” IA, a concept from William Ross Ashby’s 1956 “Introduction to Cybernetics” and elaborated by Douglas Engelbart, keeps the human in the driver’s seat while enhancing their ability to handle complex problems. The codegen that teams actually benefit from does exactly that.

Realistic leverage: design systems over full automation

While fully automating design-to-code that respects your codebase’s idiosyncrasies remains out of reach, codegen earns its keep in a narrower but vital role: the design-to-development handoff. When a product uses a component library, codegen shortcuts the guesswork by surfacing component names and property values. If your design system is the toolbox, codegen suggests the tool.

The most effective codegen is specific to your team, not generic. For teams that already keep components in Figma, automating the full pipeline is unnecessary. Better to reference design tokens, use documentation, or build a codegen plugin for custom snippets. This gets you from 0 to 0.5—a stronger starting point—quickly, even if the final code is still yours to write. Codegen also helps decode design requirements, like interpreting raw hex codes and pixels into meaningful token names or component property values during implementation.

The distinction between writing a component’s definition and using an instance matters here. Building a component library means authoring the underlying visual styles plus the variant and property definitions; using it means writing instance code and its surrounding layout. Codegen assists both but in very different ways.

Set up patterns before you build plugins

Internal plugins—like the one IKEA’s Elliot Nolten built to pull product data into designs—are the ideal endgame, but a custom solution takes time and resources. First, focus on establishing a solid foundation. Figma’s native code generation works best when names from the design match code conventions: a spacing component called “spacing” in both places generates the right code. Getting that mapping right—using variables and components to cement patterns in tokens and properties—makes designs easier to implement and simplifies long-term upkeep. A variant name carries all the styles it represents, which is less literal code to write and maintain.

This alignment pays off precisely because codebases get more complicated as teams grow. The hardest part isn’t writing new code—it’s staying on top of changes. Codegen’s real value is in highlighting what has shifted and conserving the time and energy spent in that design-to-development handoff.

Today’s constraints

None of this means codegen is ready to automate the whole design-to-code process, especially for teams with established design systems. Yet the tools already offer a meaningful help: moving the work forward faster, directing attention to important details, and giving engineers something better than a blank file to start from.

Why generated code rarely lands as-is

Design systems, coding conventions, and project structures exist because your team has accumulated specific decisions about how the work should look and be organized. Those decisions touch UI component frameworks, design token schemas, file and component naming, and even syntax preferences. With that organizational context baked in, pasting raw generated output directly into the codebase usually results in needing further edits.

Generated code can still provide a solid starting point. But you'll typically need to modify these snippets to include extra properties, formatting, styles, and other custom additions. Once you've made those adjustments, subsequent design file changes can't simply be "pasted in" via codegen without clobbering the work you've already put in. At that stage, codegen's value shifts from being a paste-ready snippet to serving as a reference for your next round of edits.

The practical role of codegen

Every tool hits its ceiling eventually. Codegen won't replace your team's established patterns, but it can still enhance your own coding abilities, helping you translate designs into working code faster and with less friction. It's not an automated, hands-off replacement for the design-to-code process; it's most useful as an augmentation that helps you quickly understand design changes and keeps your team aligned with the latest work.

For teams starting out or looking to refine their workflow, the following resources can help: