The Persona Decoder — Figma's System-of-Record Gamble

Config India reveals a company building past design tooling. The pricing, competitive exposure, and trust questions tell you how far.

The signal: Figma's Config India announcements run from the agent's October 6 general availability through yesterday's (October 15) rollout of Code Layers and Specs, and they cover five product moves. Read one at a time, they look like feature releases. Read together, they describe a company moving from design tool to product-development system of record. Figma's public language still says "design platform." Its product choices describe something larger and riskier, and that matters for anyone trying to work out where design leadership gains or loses power over the next two years. If the Columbus Day weekend put you behind and you have a conversation scheduled at a Figma-centric company this week, skip to the last section first and come back for the rest.

Confidence level: High on the directional bet. The product evidence is unambiguous. Low on execution timeline. Code Layers and Specs began rolling out October 15 in limited availability, and one day of gradual access proves intent, not viability.

The stated frame

Dylan Field's Config India keynote introduced the phrase "full-stack creative canvas", meaning one shared space for "your team, your agents, your designs, and your code." He compared Figma to developer environments and then, almost in the same breath, reassured the audience that this was still about design. His argument is that as AI makes code cheaper to produce, "design is increasingly the differentiator."

The positioning is careful. Figma is expanding into code, backend infrastructure, and agent orchestration, and the narrative presents each expansion as design becoming more important rather than Figma becoming a different kind of company. That framing covers a lot of ground, so look at the products themselves.

The actual frame

Code Layers bring a live code project from GitHub onto the Figma canvas as a running application. You can place it next to your design comps and interact with both. Figma's own documentation is candid about current limits: imports can take ten minutes or more, some projects need modification, and the feature is scoped to front-end prototyping for now. The architectural claim is bigger than the current capability. It says the design file is where the canonical version of the product should live.

Figma Specs assemble designs, code references, FigJam materials, and project context into structured Markdown packages. Figma says they're for team alignment. Operationally, they're agent context. Specs are how you give an AI helper what it needs to act on a design while knowing what the design is for, which constraints apply, and what the team has already decided. Read them as context infrastructure for agentic workflows that happens to ship as a collaboration feature.

Payload integration scaffolds backend infrastructure (databases, APIs, authentication, admin panels) from Figma Make projects. Figma has never operated past the front end before. This puts it in territory owned by purpose-built backend-as-a-service providers like Supabase, Firebase, and their competitors, where Figma has no track record and the competitive set has almost nothing in common with design tooling.

20+ MCP integrations let external AI coding tools connect to Figma using a real user's account and permissions. (MCP, the Model Context Protocol, is the emerging standard for plugging outside AI tools into an application.) Agents from other platforms, Cursor and Replit among them, can read from and write to the design file. That's a platform play, with Figma as the hub of a multi-agent ecosystem.

The Figma agent goes GA with design-system awareness, custom skills, and team-visible activity logs. You can teach it repeatable tasks, and your team can see what it's doing.

Each of these is its own product decision. Together they describe an architecture where the design file coordinates product development: humans set intent there, agents take instructions from it, code runs in it, backend gets provisioned from it, and external tools connect to it.

In Issue #14, I flagged a Figma posting for "Director of Product Design, AI & Context" as a sign that Figma wanted design to own more of the product-development workflow. Config India confirms that read and extends it. The posting suggested Figma was reorganizing influence internally. The product announcements show it building the surface that would make the design file the authoritative source for how a product gets built.

The tell in the pricing

Figma's revenue model is seat-based. Current pricing runs from $16/month for a basic full seat to $90/month for the top business tier. AI features consume "credits," a usage-based currency. Each full seat includes 3,000 to 4,250 credits per month depending on plan, and you can buy more.

The structural tension is straightforward: agents don't have their own seats. An agent logs in as a person and draws from that person's credit allocation. Commercially, it's invisible, with no revenue line of its own.

Figma has acknowledged this publicly. Its annual filing with the SEC warns explicitly that AI could reduce the number of paid seats customers need, shrink the overall population of designers and developers using the tool, and push the company to experiment with credit-based, usage-based, or outcome-based pricing.

The credit model is already live and growing. Figma's Q2 2026 earnings reported net revenue retention of 136%, meaning existing customers spent more year over year through a mix of added seats and AI credit purchases. More than 80% of customers spending over $10,000 a year use credits weekly.

So the move from pure seat pricing to a hybrid model has started. The underlying arithmetic hasn't been settled. Every task the agent handles well is a task that used to justify a person, and that person's seat. Early users describe the agent as useful for populating data tables, generating design variations, and keeping components consistent — production work that currently fills junior and mid-level seats. Payload pushes further by scaffolding backend structures from Make projects, though there's no independent usage evidence for that integration yet.

Figma's pricing has to answer one question: does revenue from AI credit consumption grow faster than the revenue lost as teams realize they need fewer people for the same output? Figma is betting it does. The risk language in its SEC filing says it isn't sure.

Watch net revenue retention over the next two quarters. If it holds above 130% while headcount at Figma's largest customers flattens or falls, the credit model is working. If it drops below 120%, the seat-cannibalization math is winning.

Where the new surface creates new competitors

Code Layers and Payload put Figma in territory where established players started from the other end.

Replit's Agent 4 embeds a design surface inside a coding environment, so you start with the running application and layer design on top. Vercel's v0 imports code from GitHub, lets you manipulate layouts in live code, and deploys through Vercel's own infrastructure. Both already have working pipelines from code to live product. Cursor works the same space from the IDE side.

Everyone is heading toward a single environment where design, code, and deployment coexist. What's still open is which starting point captures the workflow.

Figma's advantage is installed base. Design teams already live in Figma files, and their review workflows, component libraries, and collaboration habits are built around that environment. Pulling those teams into a code-first tool means changing deeply embedded behavior.

Figma's disadvantage is that Code Layers and Payload are in beta with documented limitations, while code-first competitors already ship working deployment pipelines. Those competitors don't have to convince anyone that code belongs in their tool. Figma has to convince people that code belongs in a design file, and that backend infrastructure should start there too. On both counts, the burden of proof is Figma's.

What happens when agents write into the authoritative record

Since this connects to your work on trust in agentic systems, I'll be specific about the mechanism.

If the design file becomes the system of record for product development, being in the file carries institutional weight. Today, when a component sits in a team's shared Figma library, people treat it as reviewed and approved. Specs formalize that further by turning design decisions into structured instructions that agents treat as authoritative.

The risk is that AI-generated work lands in the same file as human-reviewed work and picks up the same perceived legitimacy before anyone has verified it. The agent populates a table, links elements to the design system, generates a layout variation. Because the result sits next to approved components in the canonical file, it reads as approved.

MCP makes this harder. When external agents from Cursor or Replit write into the Figma file through MCP integrations, provenance gets murkier. The activity log may record that an action came from an external tool, but the output still occupies the same canonical space as work from the team's own designers.

Figma's agent activity logs help, since the agent's actions are recorded and visible to the team. But recorded and reviewed are different states, and on a team moving fast, "it's in the file" can quietly become "it's been checked."

Early users have already hit this. One reported that asking for a minor change led the agent to delete an entire section and affect the file's version history. Their fix was to keep the agent in disposable scratch files and out of the production file entirely. Others noted fabricated data and generic output.

Those are beta-quality problems, and they'll probably improve. The structural question stays: when agents write into the authoritative record, what separates verified work from generated work? Figma's current answer, activity logs plus team visibility, handles traceability. It doesn't address the legitimacy transfer that happens when generated output sits in the same canonical space as reviewed output.

If you're evaluating Figma or a company building on this model, ask how they distinguish "present in the file" from "approved by a human." The answer tells you whether they've thought about trust architecture at the system level or are planning to treat it as a UX problem later.

What this means for design leadership

Two scenarios frame this, and your evaluation depends on which one you're walking into.

If the system-of-record bet works: The design file becomes the coordination layer for product development. Whoever controls that file holds a structural position in how products get built — and control here means setting the design-system rules the agent follows, writing the Specs that direct automated work, and reviewing what the agent produces. Design leadership at Figma-centric companies gains operational authority on top of influence. The role moves from making the screens to maintaining the source of truth that agents and engineers consume.

If the bet stalls: Code Layers stay a prototyping novelty. Specs drift out of sync with the actual designs while agents keep treating them as current. Payload can't match purpose-built backend tools. Figma ends up with a sprawling product surface that doesn't cohere, and design teams are left in a tool that tried to become a platform and lost focus on what made it essential.

How to tell which one you're walking into. If you're evaluating a design leadership role at a company that has organized its workflow around the design file as system of record, Figma or otherwise, four organizational signals separate real structural authority from a bigger pile of tooling responsibility. If you only get one of these into a conversation, ask the first.

• Who owns Specs? If design writes and maintains the Specs that agents consume, design controls the instructions. If product management writes them and design only fills in the visual layer, the file belongs to design but the authority doesn't.
• Who sets agent constraints? Find out whether the design leader's scope includes defining what the agent can and can't modify in the production file. If engineering or product ops controls the agent's permissions, design is a tenant in its own system of record.
• Does the design leader's mandate include review governance for generated output? The system-of-record model only empowers design if someone with design judgment decides which generated work gets promoted to canonical status. If there's no review gate, or engineering owns it, the expanded surface brings more exposure without more authority.
• Reporting structure. A design leader who reports to a CPO or CEO and has direct input on how the file-as-platform gets built sits in a different position from one who reports to an engineering VP who treats the design file as an input to their pipeline.

What I can't tell you yet: Which scenario is more likely. Code Layers and Specs have been available for one day in limited rollout. The earlier Figma AI beta produced mixed results: reliable for repetitive, design-system-bound tasks, unreliable for anything requiring judgment or accurate data. A Figma-sponsored preprint study (100 participants, not peer-reviewed) found roughly 20% shorter completion times with Figma Make, with bigger gains for product managers than for designers. That's evidence AI-assisted design production can be faster. It says nothing yet about whether the system-of-record architecture works, whether Specs stay fresh, or whether Code Layers will attract developers. The Config India announcements describe architectural intent, and it will take two to three quarters of real usage data to see whether execution matches it.

Four signals to track:

• Developer adoption of Code Layers. If usage stays with designers making prototypes, the system-of-record claim doesn't hold. Watch for engineering teams citing the Figma file as a working reference rather than a design handoff.
• Spec freshness. Specs that go stale while agents keep consuming them as current produce a specific failure: confidently wrong automated output. Watch for user reports of drift between Specs and the actual design state.
• Credit revenue vs. seat revenue. The ratio between these two lines will show whether Figma is transitioning its business model or slowly cannibalizing it.
• Code-first competitors adding governance. If Replit or Cursor ship design-system enforcement and structured review workflows, they take over the trust layer that justifies Figma's expansion. Of the four, this one has the shortest fuse.

Right now Figma sits between two identities. It no longer positions itself as a design tool, and it isn't yet the product-development system of record it's building toward. That in-between state is useful to you because the same test applies to any company making this kind of bet. An expanded tool surface tells you very little on its own. What you need to know is whether the person governing that surface — deciding what's canonical, what agents are allowed to do, and which generated output gets promoted to production — holds that authority by organizational design or is simply the one standing closest when something goes wrong.