Where Agentic Design Is Heading

This is a field note, not a research report, and most of it is opinion. Where we make a claim about what exists today, it is anchored to a published announcement; where we make a claim about the next year, it is our read, and we say so. The honest summary of the moment is this: agentic design stopped being a terminal-tool niche sometime in the last twelve months. Figma — the incumbent canvas — opened its files to agents through a read-and-write MCP server, shipped a design agent that works inside the same files as the team, and connected Figma Make to GitHub so visual edits round-trip with production code as pull requests. Meanwhile the platform layer underneath kept churning: Google is retiring Gemini CLI for individual users on June 18, 2026 and replacing it with Antigravity CLI, barely a year after asking designers to learn it.

Those two facts — the canvas opening to agents, and the platforms refusing to hold still — frame everything else in this note. The first says the convergence of design and code is no longer something you have to squint at terminal demos to believe. The second says that betting your workflow on any single platform is still a mistake, and that the durable investment is the part you can carry between them.

We see three lines of travel worth planning around, with very different amounts of evidence behind each. The diagram below is the whole argument in one picture; the sections after it walk the three lines in order of confidence, and then the counterweight that applies to all of them.

Our read as of June 2026: design/code convergence is shipping, design systems as agent contracts are shipping with a human-approval ceiling, and real-time human-plus-agent collaboration is the bet we are least sure about.

This is the trend with the strongest public evidence, because it is now being driven by the incumbents rather than only by the terminal tools. Figma's MCP server gained write access, which means Claude Code, Codex, Cursor, and any other MCP client can create and edit Figma files using the team's existing components, variables, and styles — the canvas most designers already work in is now an agent-writable surface. Figma's own design agent works beside designers inside the same file. And Figma Make's two-way GitHub integration imports an existing repository, lets you edit it visually, and pushes the changes back as pull requests with governance controls. Press coverage has framed this as designers becoming the new software engineers; we would frame it more modestly as the handoff finally dissolving into a review step.

Our opinion on what this means: the design-to-code handoff — redlines, specs, the lossy translation step that consumed so much of product design's calendar — stops being a phase and becomes a diff. When the design artifact and the production code are connected by agents that can read both and write both, the interesting question is no longer how do we hand this over but who reviews the change and against what. That is a design-process question, and most teams have not answered it yet.

The practical consequence we already act on: design artifacts that cannot be diffed are becoming second-class citizens of this loop. Tokens as JSON, surfaces as text, decisions visible in version control — the case for that is made in the design-as-code article, and every announcement in this paragraph strengthens it. The convergence does not require you to abandon the canvas; it requires the canvas and the codebase to agree on a machine-readable contract, which is the second trend.

The second trend has good evidence and a clear ceiling. Figma's own argument — that MCP servers serving design-system context, variables, and Code Connect mappings are what make agent output usable — is vendor framing, and we attribute it as such, but it matches what we see in practice: agents produce acceptable interface work roughly in proportion to how much of the design system they can read as structured data. Token files, component inventories, usage rules, and anti-patterns are turning into the instruction set agents execute, and drift detection and token sync are becoming routine agent work rather than quarterly cleanup projects.

Call this the autonomous design system trend if you like, but the autonomy has a hard edge, and pretending otherwise is how this trend gets oversold. What agents can already do is mechanical propagation: notice that a token changed, find every surface that consumes it, open the change for review, and document what moved. What stays human — in every credible example we have seen, including our own — is approval, deprecation decisions, breaking-change judgment, and taste. The design system maintains its consistency almost by itself; it does not decide what it should become.

Our read for the next year, marked as opinion: the teams that benefit from this are the ones whose design systems are already legible to machines — tokens in a standard format, components mapped to real code, rules written down rather than tribal. The work of making a design system machine-readable is unglamorous and it is exactly the work we would prioritize this year, because it pays off under every version of this future, including the slower ones.

The third trend is the one that gets the most demo time and has the least evidence behind it: humans and agents working live on one shared surface, the way two designers multiplayer-edit a file today. We want to be precise about what actually exists. Canvas agents now work inside the same file as the team, and concurrent agent runs let several agents produce work in parallel. Both are real, both are useful, and neither is live collaboration in the multiplayer sense — the agent works, then you look. There is, as far as the public record shows, no shipping product where humans and agents co-manipulate a design surface in real time with the fluidity the demos imply.

So this section is opinion, clearly labelled. Our guess is that the live version arrives later than the excitement suggests, and that when it arrives it looks less like a colleague's cursor and more like a fast review loop: the agent proposes in seconds, the human accepts, redirects, or rejects, and the surface updates. The bottleneck is not model latency — it is that real-time collaboration only works when both parties share enough context to act without asking, and giving an agent that context is exactly the harness, brief, and design-system work the rest of this site describes. Teams hoping that a live agent will compensate for an unwritten design system will be disappointed in either order.

What we would not do is plan this year's tooling decisions around this trend. It is the most likely of the three to change shape entirely, and nothing about preparing for the first two trends is wasted if it does.

Every prediction above comes with the same caveat: the platforms delivering this future keep replacing themselves. The cleanest recent example is Google retiring Gemini CLI for individual, Pro, and Ultra users on June 18, 2026, replacing it with Antigravity CLI — a tool many designers adopted barely a year earlier, deprecated mid-stride. We are not singling Google out; pricing reshuffles, repository moves, and product renames have hit most of the platform layer in the last eighteen months. Churn is not an anomaly to wait out. It is a planning constraint.

The counter-trend is just as visible, and it is the one we keep telling readers to invest in: the open standards layer. AGENTS.md as the shared instruction format, Agent Skills as the portable procedure format, and MCP as the connector between agents and design tools are now supported across Claude Code, Codex CLI, OpenCode, and the Gemini-to-Antigravity line. That means the durable asset is not your fluency in any one tool — it is the harness you can carry between them: the DESIGN.md, the instruction files, the skills, the token contract, and the review gates that make any competent agent produce your team's work instead of the genre average.

This is the school's standing position rather than a fresh prediction, and the deep articles carry the mechanics: the platform-choice article covers what ports cleanly and what needs an adapter, and the harness article covers what to build before you prompt at all. The new announcements do not change that advice; they make it cheaper to follow, because every platform now reads the same files.

Field notes should end with something you can act on, so here is ours — four moves that are cheap, low-regret, and useful under every version of the future described above. They are recommendations, not guarantees, and they assume a product team that already ships software.

None of these require believing our predictions. They require believing only the part with receipts: agents can now read and write the surfaces designers care about, the standards for instructing them have stabilized, and the platforms hosting them have not.

• Make your design system machine-readable before making it bigger: tokens in a standard format, a component inventory that maps to real files, anti-patterns written down.
• Put your harness on the open-standards layer — AGENTS.md, Agent Skills, MCP — so the next platform deprecation is an adapter change, not a rebuild.
• Pick one design-to-code round trip and run it end to end with review gates, so your team learns where the loop breaks before it matters.
• Treat real-time agent collaboration as a demo to watch, not a dependency to plan on; revisit when a shipping product survives contact with a real design review.