Taste Is Your Moat: Figma’s Case for Design After Code Generation

From image-editing demos to Figma Make

Before Figma incorporated, Dylan Field and his co-founder Evan explored a concrete problem: could software fill missing parts of an image using internet-scale data, or turn a flat image into a three-dimensional scene? Field credits Evan with most of the demos. He remembers the techniques getting roughly 85% of the way to the desired result—a qualitative assessment, not a benchmark—and credits deep learning with closing the gap.

In the Latent Space conversation, published October 2, 2025, that ambition leads into Figma Make, a tool for turning prompts into code and shortening the path from an idea to a shipped product. Uses include exploratory prototypes, internal applications, and Field’s own ad hoc data munging instead of writing a Python script. For Figma Design, he also wants prompted edits to respect a team’s existing components and patterns, drawing on work already in Figma to understand intent.

Field’s exposure to machine learning began during a LinkedIn data science internship, before Flipboard and Figma, but his conviction developed slowly. Around 2014, possibly earlier, Chris Olah showed him a small neural network learning to classify handwritten digits. Field saw an already-solved problem; Olah was excited about adjustable training settings and the possibility of another network learning to tune them. GPT-3 later convinced Field that the improvement over previous models was consequential. Acting on that recognition took longer: he says AI research requires different team practices from deterministic software development, and Figma needed substantial additional time to ramp up.

Prompting and the changing specification

Alessio reports building a Figma clone inside Make, then asks how design, generated code, and model-driven tools fit together. Field begins with the interface. He calls natural-language prompting the MS-DOS era of AI: an early way to explore what models can produce, with considerable room for new interaction designs.

His proposed mechanism is to constrain the destination and reduce the number of choices a person must manipulate. A general prompt can push a model in many directions; a focused interface could make a smaller set of possibilities easier and more enjoyable to explore. Constraints could therefore support creativity. Familiar natural language remains useful while those alternatives are being refined.

The same shift changes what counts as a specification. A prototype can accompany or replace a product requirements document (PRD), and a detailed visual design can help a team agree on product intent. Yet these artifacts leave behavior unresolved. Code is framed as the most fully determined specification, including edge cases; how much a model can infer from a less complete description remains an open question.

The competitive thesis follows: as code generation improves and software supply grows, taste, craft, brand, and a coherent design system become more valuable. AI can accelerate exploration, while human judgment selects a direction and develops its details. Differentiation requires thinking beyond individual generated screens to how the product works as a whole.

Design and code can describe different moments

The interviewer raises an integration problem: he uses Figma’s MCP tooling to bring work from Make into a Cursor codebase, but reports no way through that connection to write implementation changes back into the design. Which representation should be authoritative? The answer depends partly on the project: - Disposable prototype: little existing implementation may need preserving. - Small personal project: existing code matters, but its patterns may be easy to understand. - Established codebase: generated work must fit a substantial body of components and conventions.

A design system supplies reusable components and patterns, helping teams maintain consistency without repeatedly recreating basics such as buttons. Its design library can describe two legitimate states: components that correspond one-to-one with implemented code, or what the team plans to build next. In the second case, the difference between design and code represents future work.

CodeConnect addresses the one-to-one case by formally mapping Figma components to codebase components. That mapping supplies context through MCP, the tool connection used here to pass Figma information to coding agents, so an implementation can reuse the team’s existing components. Setup is acknowledged to be cumbersome; easier setup and broader access are described as ongoing work, without a delivery date.

Several workflows may coexist. Code can be authoritative, with planned work to bring code-based design systems into Make or Design. Visual surfaces still support rapid exploration and people less comfortable with code. They may also become useful planning tools for experienced engineers who know less of their application’s implementation as agents write more of it.

A starting artifact, then a feedback loop

The interviewer describes Make’s value through the blank-canvas problem: creating a design from nothing felt beyond his ability, while modifying a generated artifact felt achievable. This offers an entry point into a product whose experienced users want ever more controls, even as newcomers need help getting started.

A feature reported as shipped on the recording day lets users copy designs from Make into Figma Design. The proposed progression is to generate an artifact, move into direct visual manipulation, and build confidence through iteration. For some changes, visual editing may be faster than editing code. This copying feature provides a bridge, while the earlier question about automatic two-way synchronization remains unresolved.

The next challenge is understanding design diffs—changes whose visual effect depends on how components fit together. Figma’s Version History presents composites of changes and is backed internally by a journal of every edit. Combining that history with the timing of tool calls could help an agent identify what changed between interactions. The interviewer proposes having a language model interpret those changes and update related documentation or system components; the response says that capability is not available at the time.

Design-to-code fidelity also needs iteration. One participant reports a Figma-to-Cursor result that got everything right except a border color; the other cautions that the workflow sometimes fails. Even a strong result translates only the first visual state. Working through the remaining states, intended behavior, and interactions remains substantial frontend engineering.

Beyond the median website

The aesthetic ambition is to widen the range of possibilities without imposing one preferred style. AI could blend styles and expose underexplored directions for designers to develop. The guest treats generation of the median website as a limitation to move beyond, recalling the experimentation and dynamism of the Flash-era web—without claiming its output was always high quality.

Richer interfaces bring more states, screen targets, and surfaces to coordinate. The interviewer adds a constraint from working with a designer on a landing page and product: even an extraordinarily capable tool would not necessarily tell him what to ask for. He proposes Figma as a repository of aesthetic context, grounding generation across products in a person’s or team’s preferences. A personal equivalent for image generation is his suggested extension, not an announced feature.

The response describes a progression in design judgment: 1. from noticing appearance, 2. to evaluating entire flows, 3. to considering mental models and metaphors, 4. and finally to understanding the experience within brand, culture, and business constraints. Broader participation could expand designers’ role in guiding that process. Engineers and product managers should be able to express ideas with enough fidelity and consistency that presentation does not distract from evaluation. Developing those ideas into excellent work remains a demanding design task.

Cheap generation still needs product knowledge

The interviewer argues that software can remain highly valuable even when it becomes quick and inexpensive to produce. The guest sees potential in reusing patterns from a team’s previous Figma work, explicitly with that team’s consent, but questions the idea that software will become disposable fast fashion. His strategy for Figma is to assume models improve and ensure those improvements make the product better; if that relationship stops holding, change strategy. This does not require predicting the exact trajectory of model progress.

A personal tool encounters familiar requirements when others start using it: enough consistency to be learned, shared, and taught. Coding agents also still require software expertise to break work into manageable tasks. At the time of the conversation, the guest does not expect a broad instruction to build Figma to produce the complete product in the near term, even with longer-running agents.

Workday and Rippling illustrate why code generation alone cannot replace accumulated product knowledge. Their value includes knowledge of human-resources workflows, edge cases, and underlying data platforms. A new builder still has to discover and address those requirements. AI may accelerate the iteration, but users’ needs still have to be understood.

Interfaces communicate in both directions

The interviewer proposes that interfaces remain valuable with more capable models because they compress the expression of intent. In data analysis, users still need to supply the right data, select useful charts, and develop follow-up questions. An interface can help them make those choices without spelling out every detail in conversation.

The response separates query correctness from analytical exploration. - A wrongly constructed query undermines everything built on its results. - Suggested follow-up queries serve a different purpose: even an unselected suggestion can provoke a useful question. The guest is more optimistic about this exploratory assistance than about perfect query-construction accuracy.

Communicating the answer is another design problem. Examples include explaining federal spending at a relatable scale and making biological data understandable to someone without biology training. The guest says the federal-budget visualizations he has seen have not achieved the clarity he wants. The interface must help users express their needs and understand the response; components embedded inside chat may address only part of that challenge.

The guest challenges the expectation that most software will live inside a language-model session. A request could begin with a model and continue in another application, or a dedicated application could embed a model. He is similarly reluctant to dismiss crowded startup categories: a distinctive insight can produce a different product. Founders should seek that insight rather than follow what others are building. Outside momentum investing, universal agreement with a thesis can signal a lack of differentiation.

Intuition proposes; users help test

Recalling his initially dismissive response to Bitcoin, the guest recommends evaluating technology in two stages: imagine its potential scale and social importance, then identify failure modes to mitigate. When the interviewer worries that X rewards negativity, the response acknowledges incentives toward controversy but remains optimistic about adaptation, citing fading fears about all-day Farmville play as an anecdotal comparison.

The guest searches X for Figma feedback and deliberately shapes his feed. Copying a post’s link appeared to influence recommendations even without sharing it; bookmarks had uncertain effects, and the “not interested” control seemed ineffective. He cautions that algorithm changes may have altered those signals. Social feedback sits alongside support, sales, community conversations, and qualitative and quantitative research. The principle is intuition as a hypothesis generator, with user feedback helping test its hypotheses.

An early Figma user test shows the value of users who anticipate broader needs. The product was so slow that the guest brought wine, expecting the session to take hours. Payam, a designer then at Coursera, followed up the next day with an eight-to-ten-page document. Much of it later overlapped with Figma’s roadmap, though the team did not literally follow it. Such users can validate a direction and generate new ideas. The guest prefers bringing their reports into team discussions and investigating with them, while acknowledging that he also advances his own views.

Recruiting for the long term

Some people approached in Figma’s first or second year joined only in year five or six. The recruiting advice is to maintain relationships and explain the mission, risks, and expectations without overselling. Those relationships can remain valuable even when someone never joins. Advice from John Doerr becomes an operating practice: maintain a recruiting funnel in a spreadsheet, review it frequently, add candidates, and keep conversations moving.

For AI work, Figma has hired researchers whose work follows a lifecycle less tightly tied to release dates. Strong full-stack engineers can also succeed on AI products if they are willing to learn and adapt their practices. The stated hiring priorities include agency, product sense, care for design, continued growth, and interest in hard problems.

Make’s advantage depends on integration

Returning to Make’s competitive position, the guest acknowledges that its initial prompt-to-code release had little integration with Figma, making comparisons with competing tools reasonable. Its proposed advantage is a visual environment for exploring alternatives: an infinite canvas where people can try directions and see them together, including people who find engineering environments intimidating.

Copying a state into Figma Design is an initial connection. Deeper platform integration, designed around designers’ specific needs, is the intended differentiation. In the conversation, that broader integration remains future work.

Creation, community, and speculative incentives

The closing discussion begins with a correction: the guest’s profile picture is a Chainrunner, not a CryptoPunk. Digital scarcity drew him into collecting and an inexpensive community organized around an unusual idea. He describes distancing himself as its emphasis shifted over three or four years toward flipping and scams. He stopped publicly discussing projects he liked because the attention could attract speculative trading and harm work he valued for its art, creators, and intention.

He sees a worrying parallel in AI’s growing passive-income and get-rich-quick culture. He welcomes people earning money with AI, while worrying that money could become the dominant motivation in a community concerned with long-term risks and possibilities.

Magic: The Gathering offers a more personal example of community’s value. At early Figma draft nights, a team member named Andrew demonstrated such deep knowledge of the game that it inspired his move from support into product education. The guest recalls Andrew excelling through similarly encyclopedic knowledge of Figma. Playing together had revealed a transferable skill.

The interviewer describes focused play as a way to disconnect and hopes AI can help small communities create entertainment and sustain themselves without making profitability the central criterion. The guest agrees: the aspiration is to move people from scrolling feeds to making things, while remaining concerned about get-rich-quick incentives. The conversation ends with an invitation for Dylan to join draft night at the new Kernel space, which he accepts.