Designing in Figma With an AI Agent: Trust the Screenshot, Not the Node ID

Not all of our agent work was code. For a month, a separate design workspace turned client change requests into screens in Figma. The agent drew through the Figma MCP server's plugin-API tool: about 1,760 scripts and 720 screenshots across 90 working sessions.

Here is what made that reliable enough to put in front of a client.

Requirements become rule files before anything is drawn

Change requests arrive as PDFs. Before drawing anything, the agent splits each one into a requirements folder:

• a README listing the open questions
• one file per requirement, each citing the PDF page it came from
• per-platform scope sheets derived from those rules (the rule is the main axis, not the platform)

Each split ends with a coverage check that every page of the source maps to a rule. When a reviewer later asked "is this field even a requirement?", the agent answered with the rule file and the PDF page.

By the fourth week, a whole new change request took 26 minutes from a single prompt: five rule files, sixteen open questions, and the relevant screens drawn in two Figma files.

Draw the "before" from what is actually running

New designs need a baseline to be argued against. Part of the product had been built before its design files were complete, so the first job was porting the shipped screens into Figma from source code and live screenshots.

When the client's spec and the shipped code used different terms for the same thing, the developer settled it in one line: "follow the source code; it's what's running in production." The agent recorded every such conflict as a DECIDED note and kept a glossary.

Two passes: design the target, then meet the API

The design workspace's instructions split design into two passes:

• Pass 1 designs the target screen and is not allowed to open the API specs or front-end types. Fields the design needs that may not exist yet are written down as "asks".
• Pass 2 runs from the code repository. It reconciles the design with the real API contract and turns the gaps into a request for the backend team.

The rule's own summary: "Drift caught early is an ask; drift caught late is a demolition." The agent named this boundary out loud before every exception. Once, a worker session refused an exception it had heard about second-hand until the developer confirmed it directly.

A craft rulebook the agent reads first

A file called FIGMA.md became the workspace's most-edited file, with 68 edits in a month. It holds the component inventory, chart palettes checked for colour blindness, motion notes, and more than forty numbered "plugin API rules that have actually bitten".

Every time a script rolled back, the agent added the reason. About 3.6% of scripts failed (64 of roughly 1,760). Scripts are atomic, so each failure rolled back cleanly, and the same failure rarely happened twice.

We also kept eight reusable script libraries: a sidebar and shell builder, a list generator that auto-fits columns, a sortable header kit and a sideways-scrolling table. The agent stopped redrawing the same chrome from scratch.

Verify by looking

"Screenshot after every structural change; don't trust node IDs." A script that reports success is not the same as a screen that looks right. One modal passed its ID check while rendering three times too tall.

So the agent downloads the screenshot and looks at it. It also reads prototype links back after writing them and reports a count, such as "143 links, 0 dangling".

Hide, don't delete

"Figma is additive. Never delete without explicit approval." Superseded work is hidden and renamed instead of removed.

That paid off almost at once, because requirements kept changing. An option added one day was removed the next and renamed the day after. A table removed in the morning was restored that afternoon. A hard delete is offered only for clones of something documented elsewhere.

Make change reviewable

Reviews got faster once we made changes easy to see:

• An annotation layer on changed frames, with dashed outlines, numbered badges and a legend. It came straight from the developer asking "could you highlight what changed today?"
• "Full view" boards for wide tables whose columns were hidden by sideways scrolling. The agent used one to show that two "missing" columns had been there all along.
• A "decisions for you" section in every hand-off note.

One correction, one memory

Short corrections became short memories, each with a reason:

• Apply a change to both twin modules (the business-facing portal and the admin portal) by default. That one later earned "Oooh, nice, you applied it to the other portal as well."
• No em dashes in client-facing copy.
• Don't propose concepts that push users to spend more, or that need heavy backend work.
• When a link points at one element, compare the whole board against its twin before asking.

Clarifying question menus dropped from six in the first week to one in the third.

The rhythm that emerged

By mid-month a typical session was /clear, a Figma link and one sentence, finished in about twelve minutes. The developer's most reliable pattern was to ask "is X missing?" first, get an evidence-based audit back with files, pages and frames cited, and then reply "go".

What to copy

• Split requirements into rule files with page references before drawing anything.
• Separate "design the target" from "fit the current API", and write the gap down as asks.
• Keep a craft rulebook that the agent reads first and updates after every failure.
• Check every change with a screenshot, not the tool's success message.
• Hide instead of delete while requirements are still moving.