How Figma built its generative plugins and shaders: the story behind the feature

Figma has published on its official blog a first-person account by Rogie King, a product designer at the company, about how the "generative plugins and shaders" feature was conceived and built — a feature unveiled at the Config conference and expanded today with several additions. The article combines a product announcement with a chronicle of the internal design and engineering process, and offers an unusual window into how a design tools company is reorganizing the way it works around generative AI.

As for the specific features rolling out starting today, Figma is announcing four blocks of functionality. First, community publishing: it is now possible to publish to Figma Community the plugins and shaders created with Figma's design agent, or to share them privately within an organization for those on an Organization or Enterprise plan. Second, animated and interactive shaders: the agent can add motion and interactivity to any effect the user describes by prompt. Third, code access: users can view and download the underlying code of any shader or plugin they create, so they can edit it directly in a third-party agent. And fourth, updates to Figma's MCP server, which lets an external agent view and modify generative plugins and shaders, or export shaders to an agent that implements them precisely in React code.

The most interesting part of the article, however, is the project's genealogy. King explains that shaders make it possible to visually manipulate layers in Figma Design, either as a fill or as an effect, and that they are GPU programs capable of transforming pixels in real time. His personal interest in bringing this technology to the Figma canvas goes back a long way: in 2022 he had already built the Noise & Texture plugin, but at the time there was no clear path toward a deeper integration within the product. The turning point came, by his account, when large language models (LLMs) allowed him to "show" his vision rather than merely "tell" it: he began vibe coding a WebGPU environment that mimicked Figma's behavior, where shader effects could be added to any layer on the canvas, including vectors, 3D layers and even particle systems. In that personal prototype he focused on three pillars: composability (having one shader's output feed the next), editor ergonomics (dynamically generated controls that let you "touch" the design, something plain prompting does not offer) and agentic creation (LLMs able to suggest controls the user can then experiment with).

The article also details how the team came together. King turned to Yassir Solomah, a rendering and animation engineer, to validate whether the idea was technically feasible and whether it could hurt Figma's performance. Solomah replaced the initial prototype's WebGL 2 shader system with a WebGPU pipeline architecture, so that shaders could work as small programs capable of rendering 3D objects and applying logic based on mouse position and time. That architecture made it possible to isolate graphics-generation scripts in their own sandboxes, harnessing the full power of WebGPU and thereby achieving safer user scripts, along with logic, particle systems, compute shaders and 3D support. Shortly afterward, product director Georgia Rust, with an overview of what was happening across different Figma teams, noticed that product designer Jason Calleiro was working in parallel on prototypes of adaptive and generative plugins, and proposed merging both efforts under the umbrella of "generative tools": a way to use agents on the canvas to create custom plugins and shaders on the fly.

The account devotes considerable space to the project's internal sales pitch: several planning sessions between King, Solomah and Rust turned a handful of demos into a proposal capable of convincing executives, combining a live demonstration, an explanation of the security and implementation model, and a plan for what to build first and where to scale next. The proposal was approved, with the launch date set for the Config conference, leaving only two months of development. King even designed an eighties-inspired team logo, with a wrench and a lightning bolt as symbols, and a rainbow representing the feeling of "magic" that prompting brings.

On working methodology, the article is explicit: given the tight deadline, the team dispensed with product requirements documents (PRDs) and formal design critiques, betting instead on constant prototyping and demos. Engineers and designers shared a single massive Slack channel, with weekly presentations to the project's sponsors, and the initial 15-person team grew as the demos gained visibility in company meetings. As shared infrastructure, King built PropsKit, a Figma interface kit based on web components that agents could use. He also recounts how, after his good experiences with vibe coding, he wanted every design to start as a working prototype, thinking it would speed up the work; but he found that while those vibe-coded prototypes were very useful for designers themselves to validate and question their assumptions, they did not work as a reference for developers, product managers or stakeholders. So the team changed its approach: first static mockups in Figma to align expectations about the possible states, and then working code prototypes to converge on the best solutions without the usual design-implementation-review back and forth. King even went as far as writing production code directly in Figma's repository and submitting several pull requests.

The two weeks before Config are described as the hardest: with 90% of the work done, the last 10% proved the most difficult stretch, to the point that leads and sponsors were reviewing versions already outdated by the pace of change, and there were moments when the project seemed at risk of being left out. The response was fast, frequent communication, gut decisions and improvised solutions: when the plugin layouts were not quite working, they built three new interface components to help the agent decide; when custom property controls for color palettes needed three more days of engineering, they opted for a simple selection list as a temporary fix. King admits that, as the project's original champion, cutting features was the hardest thing to accept, but it was necessary to make it in time. In the end, he and Rust presented generative plugins and shaders on stage at the Config keynote.

The text closes with a reflection on how the project changed the way the team itself uses Figma: the Config microsite for the shaders leaned heavily on Figma's MCP server, to the point that, according to King, an engineer running an agent locally today expects to be able to "read" the design through the MCP's get_design_context function. Shaders can also be exported in HTML and React, something that is part of the updates published today. As for availability, the Figma design agent that allows these generative plugins and shaders to be created is in open beta for users with a full seat on all plans, while Collab, Dev and View seats can use it in their drafts; use is free during the beta, but Figma notes that in a few weeks it will begin consuming AI credits.

Taken together, the article works less as a press release than as a case study of how a design software company is reinventing its own internal processes — from the formal critique to the vibe-coded prototype, from the PRD to the shared Slack channel — to adapt to a development pace set by generative AI. It is worth noting that this is content published by Figma itself on its corporate blog, so the account necessarily reflects its own version and its interest in showing the product and its working culture in a favorable light; the text contains no adoption figures, no timelines for expanding the features and no technical details beyond those mentioned (WebGPU, sandboxes, PropsKit) that would allow independent verification of the feature's real scope.