
Handoff in the AI era: from design to code without losing intent
Design handoff changes when an AI agent builds from the design. What a handoff should include, how to mark what is ready and what remains your responsibility.
What is handoff and what should it carry?
Handoff is the moment a design stops being a proposal and becomes instructions. Traditionally it includes measurements, colors, typography, states and notes about behavior. What is almost never documented is intent: why that button is primary and not secondary, or what happens when the list is empty.
A complete handoff answers four questions: what is being built, how it looks in each state, which rules govern it and where the source of truth is. The last one is the most often forgotten, and it is what an agent needs in order not to invent.
What changes with an agent?
Before, the handoff went to a person who could ask in a chat. Now part of the work goes to an agent that can only read what it has. That changes two things:
- Implicit knowledge becomes invisible. A rule that exists only in your head does not reach the agent. An annotation on the frame does.
- Errors multiply. An agent can repeat the same problem across twenty screens before anyone notices.
Figma’s MCP server gives the agent tools to read a design’s context: get_design_context returns code and context for a layer, get_variable_defs lists the variables and styles in use, and search_design_system searches connected libraries for components and variables. More detail in Figma to code with MCP. All of that only works if the file is well structured.
How do you prepare a file for an agent to read?
Figma’s documentation for its MCP server recommends seven practices:
- Use components for anything that repeats (buttons, cards, inputs), so the agent reuses the same code for each instance.
- Connect components to code with Code Connect. Without it, the agent has to guess which code component matches each design component.
- Use variables for spacing, color, corner radius and typography, so the agent references your tokens instead of hardcoded values.
- Give layers and components clear names. Replace “Frame1268” or “Group5” with names that explain their purpose.
- Use auto layout. It shows how the design responds to different sizes and avoids absolute positioning. Resize the frame before generating code to check it.
- Add annotations to explain behavior, alignment or responsiveness that is hard to see.
- Add dev resources in Dev Mode: links to documentation, code or tickets.
Which handoff tools exist in Figma?
According to Figma’s official help center, Dev Mode includes:
- Inspect panel: the layer’s name, type and last-updated date, component information (variants and properties), applied styles and variables, and asset downloads.
- Code snippets: code for a layer, with selectable language and units.
- Code Connect: replaces auto-generated code with your system’s real code.
- Annotations and measurements: text notes and specifications added by the designer.
- Resource links: GitHub, Jira, Storybook or VS Code linked to the layer.
- Dev statuses: Ready for dev marks sections, frames or components as ready for review and implementation. Completed marks development work as finished. Changed is applied only when something already marked is edited.
Dev Mode is available on the Professional, Education, Organization, Government and Enterprise plans. Ready for dev is included on all of them; Completed only on higher plans. Whoever sets the statuses needs a Full or Dev seat, and notifications go to people who have already opened the file in Dev Mode.
What remains your responsibility?
- Deciding what is ready. Marking something Ready for dev while it is incomplete tells the agent the design is finished.
- Keeping the status current. If you change a design that is already marked, Figma flags it as Changed. Select Ready for dev again and write the reason for the change so whoever builds it receives it.
- Documenting the states. Error, empty, loading, disabled and responsive. These are the ones an agent most often invents.
- Keeping the source of truth. If the code has tokens or components, the handoff should point to them.
- Reviewing the result. Compare what was built against the design with a checklist. See reviewing visual fidelity.
When should you NOT write a detailed handoff?
- When the prototype will be thrown away. A fifty-page handoff for a one-day test is wasted work.
- When the engineering team already co-designs with the product team. Sometimes the handoff is a ten-minute conversation.
- When the design changes every hour. Marking something as ready that is going to change creates rework.
Example
Illustrative example: a designer finishes a three-screen flow to request a refund. In Figma they mark the screens as Ready for dev, add an annotation on the confirm button (“Disabled until the terms are accepted”) and link the ConfirmDialog component to its story in Storybook as a dev resource. They pass the file to an agent with instructions to use the existing components.
The agent builds the three screens. The designer reviews the disabled button, which the agent had left enabled, and fixes it using the annotation as the reference. Without the annotation, the error would have reached production.
Common mistakes
- Marking something “ready” before the states exist.
- Keeping the rules in a separate document that nobody links from the file.
- Using generic layer names such as “Frame 427” that the agent cannot interpret.
- Positioning everything absolutely instead of using auto layout, which produces brittle code.
- Assuming the generated code is the team’s final code.
- Doing the handoff in a message instead of in the file. What is not in the file gets lost.