Could Dev Mode become the system that keeps UX and AX in sync?
I was reviewing a frontend build against my Figma file. A few measurements were off.
“Didn’t you verify this through Dev Mode?”
“I barely open it. I connect Figma through MCP, let the agent build, then check the output.”
MCP = the protocol that lets the coding agent pull context from Figma.
AX = Agent Experience.
Incident reconstructionPrimary observation
MY FIGMA FILE
Checkout / Payment
→
AI AGENT
MCP context · reads Figma
→
FRONTEND
Built UI
Expected
24px
Built
20px
What changed
The developer stayed accountable. The agent became the first reader of the brief.
One tiny mismatch surfaced a bigger question: who is Dev Mode actually serving now?
Original job / JTBD02 / 12
Dev Mode served a clear purpose: helping developers read the design.
01
The original system assumed a human developer would inspect the design, translate it, and implement it.
Original delivery systemHUMAN READER
DESIGNERcreates
→
FIGMA FILEholds the spec
→
DEV MODEsurfaces what developers need to build
→
DEVELOPERtranslates
→
PRODUCTshipped UI
measurementsassetstokenscomponentschanges
This system was built with the human developer as the reader.
Primary research · n=10 · directional03 / 12
Developers increasingly supervise while AI takes more of the briefing and execution.
10
developer conversations
MCP, Claude/Codex, repo context, visual references, manual assets. Different tools, similar shift.
The agent increasingly builds first. The developer remains accountable for the result.
Dev Mode still matters when exact values, assets, or production mappings need to be checked.
Observed workflow pattern
FIGMA / MCP
REPO
DESIGN SYSTEM
→
AI AGENTbriefing interpretation first-pass execution
→
FIRST BUILDcandidate UI
→
DEVELOPERreview correct integrate + ship
PRECISION PATH · Agent or developer pulls deeper Figma / Dev Mode context when confidence drops or exactness matters.
SUPERVISION LOOP · human stays accountable for the shipped result↺ feedback returns to agent
Dev Mode can still serve its purpose. The reader may increasingly be the agent.
Second workflow shift04 / 12
AI is also changing what designers hand over.
01
Traditional
Designer→Figma file→Dev Mode→Developer
What gets handed over
Specs
02
Agentic
Designer→Figma file→AI agent→Developer
What gets handed over
Generated code
03
Emerging code-first
Designer / PM→Prompt→Working UI→Developer
What gets handed over
Working code
FIGMA FILE OPTIONAL
The context still matters. The reader and the handoff object are changing.So what happens to Dev Mode’s value unit?
Product + business tension05 / 12
The human may use Dev Mode less even as Figma context becomes more valuable.
Directional consumption shiftWHO CONSUMES VALUE?
↓
Human Dev Mode use
may become more occasional
↑
Agent / MCP consumption
may become more frequent
The design context does not disappear. More of it can be consumed programmatically, while the human opens Dev Mode mainly for precision, review, or exceptions.
Value unit today
Dev seat priced per human
That creates a packaging question if machine-mediated value grows faster than direct workspace usage.
PRO
$12
ORG
$25
ENT
$35
The strategic tension is packaging: does a human seat still cleanly represent the value being consumed?
Figma's response06 / 12
Figma has already started erasing the wall between design and development.
5×
MCP WAU QoQ
The agentic workflow is already showing adoption inside Figma.
~70% faster Full-seat growth among large customers using MCP vs comparable customers not using it. Traction signal, not causal proof.
01 · CONTEXT
MCP + Code Connect
Design and production-component context move directly into agentic coding.
02 · CODE ↔ CANVAS
Code layers + Make
Working code can move onto the canvas and back into product workflows.
03 · AGENTS
Figma Agent
Agents increasingly read, write, and act on product context.
Figma has connected context, code, canvas, and agents. The unresolved product problem is the quality of the agent experience itself.
Strategic bet07 / 12
If I were the PM handling Dev Mode, I’d focus on AX.
AX
Agent Experience is how well Figma helps an agent build the intended product with less human rework and less product drift.
One framework: understand what matters, verify what was built, preserve coherence as changes accumulate.
01
UNDERSTAND
What exists, and what matters for this task?
less guessing
02
VERIFY
Did the generated implementation preserve the intended UX?
less rework
03
PRESERVE
Does the product stay coherent as AI changes accumulate?
less drift
Same AX framework. Different mechanism depending on whether a Figma file already holds the context, or code is canonical.
BUILD FIRST · Figma-file workflow08 / 12
Would AX have caught the 24px → 20px mismatch before developer review?
Today
FIGMA FILE + REPO
→
AGENT
→
FIRST BUILD
→
HUMAN FIXES
What happened in Slide 1
Expected 24px spacing
Generated 20px spacing
developer remains responsible for catching it
precision context exists, but arrives too late
With AX
FIGMA FILE + REPO
→
AX BRIEF
→
AGENT
→
AX-DIFF
→
DEV
The same AX framework in practice
UNDERSTANDAX Brief sends the real codebase component, states, 24px rule, and only relevant context.VERIFYAX-Diff = automated implementation check. It catches 20px ≠ 24px before review.PRESERVEReuse the established token, component, and behaviour instead of inventing a local fix.OUTCOMEThe developer reviews a corrected first pass, not the avoidable mismatch.
BUILD FIRST earns investment if AX materially improves first-pass quality with less developer correction.
VALIDATE NEXT · Longer-term code-first bet09 / 12
Then AX has a harder problem: what if the product never started in a Figma file?
01
Move fast
The startup optimises for shipping speed, not a parallel Figma system.
Local AI decisions begin diverging from the product system as the product scales.
4button patterns
3modal behaviours
state drift
duplicated logic
03
Protect coherence
AX derives the product system from the repo + running product instead of asking humans to recreate it in Figma.
1
UNDERSTAND existing patterns from repo + running product
2
VERIFY each new AI change against those patterns
3
PRESERVE coherence by feeding corrections back to the agent
REPO STAYS CANONICAL
VALIDATE NEXT only if Figma can reduce product debt without asking teams to maintain a parallel Figma system.Now the two AX bets need different success metrics →
Measurement + evals10 / 12
How would we prove the first bet, then earn the right to pursue the next?
BUILD FIRST: prove that AX improves first-pass implementation when a Figma file already holds context. VALIDATE NEXT: pursue code-first coherence only if it reduces product debt without adding human maintenance.
Affected current signals
Dev Mode developer WAU
may flatten or fall without meaning AX failed
MCP / agent usage
should become more relevant
Paid agent / programmatic attach
business signal to watch after value is proven
BUILD FIRST · Primary north star
First-pass implementation acceptance
% of agent-generated builds accepted without material UX, component, state, logic, or system correction
PROPOSED PILOT GATE · SET AFTER BASELINE+15pp
VALIDATE NEXT · Long-term product health
Coherence defects per AI change
new duplicate components, arbitrary tokens, inconsistent states, or interaction drift introduced per merged AI change
ILLUSTRATIVE VALIDATION GATE−25%
Supporting product metrics
Correction time↓ vs control
Time to accepted build↓ vs control
System adherence↑ vs control
AX self-correction% fixed pre-review
AI eval guardrails
p95 AX latency ≤ +10%
tokens / accepted build ≤ baseline
hallucinated refs <5%
context truncation <1%
false positives <10%
track irrelevant-context ratio
CONTROLLED EVALUATION · same model · prompt · temperature · repo state · context-window limit · segment by task complexity + design-system coverageMEASUREMENT CHAIN · task ID → context sent → agent output → AX-Diff → human edits → accept / merge
Kill criteria11 / 12
What would make me kill this idea?
Build only if
AX removes more work than it creates.
FIRST-PASS QUALITY ↑ CORRECTION TIME ↓ PRODUCT DEBT ↓
The quality gain also has to outweigh added inference, context, and maintenance cost.
01
MCP + repo is already enough.
AX does not materially improve implementation quality.
02
Repo-native tools solve coherence better.
CI, linters, component tooling, or coding agents win.
03
AX creates another system humans must maintain.
We recreate the process AI-native teams were trying to remove.
04
The capability belongs somewhere else.
If MCP, platform, CI, or IDE infrastructure captures the value better, don’t force AX into Dev Mode.
IF AX ADDS MORE PROCESS THAN IT REMOVES, DON'T BUILD IT.
Conclusion12 / 12
The next Dev Mode may not be a handoff tool.
It could become the system that keeps UX and AXaligned from intent to shipped product.
One strategy. Two horizons.
BUILD FIRST
FIGMA FILE
prove a better first pass
VALIDATE NEXT
CODE-FIRST
prove less product debt
AX
UNDERSTANDVERIFYPRESERVE
SHIPPED EXPERIENCE
what users actually get
Start where Figma already owns differentiated context. Earn the right to expand into code-first coherence.