Jesse Lumarie

Jesse Lumarie is a software engineer who helped build the Figma MCP server and Figma Make’s local-codebase workflows, connecting design tools with agents that work on production software. His work addresses a practical problem: translating a design into code requires both an understanding of its appearance and respect for the components, conventions, and engineering decisions already present in a codebase.

From law to design tools

Lumarie’s path into engineering began with a change of profession: he is a former lawyer. Before his work at Figma, he worked as a software engineer at Pinterest, where he used Querybook, the company’s open-source big-data interface. His connection to Querybook was as an engineer and user, rather than an established author of the project.

At Figma, Lumarie worked on growth initiatives before moving into AI integrations. An internal Model Context Protocol demonstration caught his attention because it suggested a way to make Figma more useful through AI tools, including for people who were not designers. He began experimenting with a plugin-based MCP server one day a week, pursuing the idea before it became a formal assignment. Other engineers joined, and the team developed Figma’s first MCP server in roughly three months.

The initial product served developers already adopting coding agents. It supplied information normally accessed through Figma’s Dev Mode—component data, spacing, and variables—directly to an agent. A developer asking for a design to be implemented could bring that context into the coding workflow without waiting for each AI tool to build its own Figma integration.

The team launched locally first, using Figma’s Electron desktop application and its connection between the web application and a Node process. That architecture let them reuse existing authentication and access handling while remote-server authentication was still developing. Shipping quickly had to coexist with respecting file permissions and product-access restrictions. Remote-server work began immediately after the local launch; the remote version arrived in September 2025, and both servers reached general availability that October.

What makes design context useful

Lumarie’s account of building the server connects product experimentation with detailed decisions about what agents receive and how their output is judged. He credits a larger engineering team throughout. Several concerns recur in that work:

• Structured code plus a visual reference. Figma’s canvas is a scene graph of connected nodes, and the team tested different ways to translate it into agent context. A sparse XML-like representation lacked the visual fidelity they wanted. Screenshots alone produced weak design-to-code results in their early-2025 experiments. An existing React-and-Tailwind representation, developed for Figma Sites, supplied a more explicit description of the interface; pairing it with an image improved the agent’s output. An early attempt to embed base64 image data consumed too much of the context window, so image assets became separate references.

• Component reuse is part of fidelity. A generated button can look correct while bypassing the accessible, internationalized component a company already maintains. The team integrated Code Connect, which links Figma design components to their counterparts in a codebase. Instead of sending a verbose reconstruction, the server could supply a compact reference directing the agent to use the existing component. That preserved more of the organization’s engineering work while reducing the amount of context required.

• Design-to-code evaluations need paired examples. Early tests checked variables and theming alongside qualitative questions about appearance and decisions made with incomplete information. After two hours grading results in a spreadsheet, the team built a web application to improve the process. Suitable evaluation cases were hard to find because open-source repositories rarely included matching Figma files, so the team created paired examples and other automated arrangements. By his 2026 account, evaluations ran hundreds of times a week, with model judges helping engineers compare prompt changes.

• Build interactions around actual client capabilities. MCP clients implemented different portions of the protocol at different speeds. When server instructions were unsupported, the team put guidance into individual tool responses. For component mapping, they wanted to combine elicitation—asking the user a question—with sampling—querying the client’s model. Where those features were unavailable or lacked codebase context, tools coordinated the interaction: ask whether the user wanted a mapping, have the agent search for candidate components, and return suggestions in a specified format so connections could be created in bulk. Optional language and framework arguments supplied additional signals about users’ environments, though Lumarie cautioned that agents could report them inaccurately.

Bringing visual editing into production code

Late in 2025, Lumarie began experimenting with MCP colleagues at an offsite after research indicated that some designers wanted to work directly in production code. That effort developed into Make’s local-codebase functionality for GitHub and local repositories, another project he helped pursue before being formally staffed on it.

Lumarie co-authored the May 2026 announcement with Iris Lin. The product gives visual decisions a path into an existing codebase: users can edit visual properties and attach contextual annotations to the interface, then have an agent apply the corresponding changes to relevant production code. The interface supplies a concrete target for the edit, helping users express what should change without describing every detail in a chat prompt.

The resulting work also fits into established software collaboration. Git branches, commits, and pull requests give teams a way to inspect and review the changes. That makes the workflow consequential beyond a generated preview: visual editing can produce code changes that enter the same review process as other engineering work.

Across the MCP server and Make, Lumarie has worked on both directions of the design–code relationship: giving coding agents better design context and giving people a visual way to change production software. The practical details matter in each direction—what the agent can see, which existing components it should preserve, how results are evaluated, and how a proposed change reaches review.