Figma Version Control Management

Hey, ​@Rita Das. Thanks for your post - this is really great feedback regarding version control with the agent.

Is it fair to say that overall, you’re looking for more detailed version control with agent, similar to Git where ideally each change is its own “commit” that can be selectively undone? You’re also looking for how to best achieve that with the agent as it is now? One thing you could try to get that right now is to do the following:

1. Select as focused a layer as possible for the change within your layer structure. This limits what the agent will affect to as limited a part of your design as possible.
2. Be as specific as possible in what you want as an outcome, and clarify what you don’t want changed. 

I addressed your first point above, but let me address each of the rest of your points now - they’re related as you said, but just to make sure I’m not missing anything.

• Is there an efficient way to compare different versions and identify the most suitable one to move forward with?

  • Not at this time, but great question!

• With the introduction of Code Layers, will there be any limitations on design revisions for a specific component, considering that design changes are expected to reflect in real time?

  • Could you provide a bit more info on what you mean in terms how you expect it might be different from other layers?

• Will there be a structured push/pull mechanism, similar to Git commits, to better manage design and code changes?

  • I don’t have any information right now on implementing a system similar to Git, but I can understand why you’d want that level of control with multiple collaborators and agents working in the same file. I’ll share that feedback with the team!

• In design, we often observe that the agent may not always execute the output exactly as intended. A similar challenge may also occur in coding. In such cases, how can we ensure that the production code remains optimized, clean, and free from clutter after multiple iterations?

  • Hmm… I think you’ll want to incorporate code reviews into your design process for full verification, similar to how you review design changes in other layers. Having said that, this is a concern with any AI tool when used with coding. The Figma agent, however, has the benefit of direct access to your design files, library, etc. See the tips in our article on Best practices to help Figma AI understand your design system for guidance. 

For more info on best practices, our help article on working with the Figma agent in Design files is going to be the best resource on how to work with the agent, and will be updated as we add features. To keep on eye on when features are launched, I recommend bookmarking our Release notes page.

Hey ​@adamsmasher,

Thank you so much for taking the time to respond and share your insights.

I truly appreciate the clarity and perspective provided by you. It really helped in better understanding the current behavior and limitations around version control, Code Layers, and iterative workflows.

1. Is it fair to say that overall, you’re looking for more detailed version control with agent, similar to Git where ideally each change is its own “commit” that can be selectively undone? You’re also looking for how to best achieve that with the agent as it is now?

- Not exactly like Git. My concern is more around managing repetitive design change prompts and understanding how those changes are tracked over time.

Specifically:

• How do we keep track of how many changes have been applied through prompts?
• If we want to go back to a particular state, should we re-prompt the change, or is it better to revert to that specific version?

From a practical standpoint, which approach is more efficient?

If re-prompting is easier—especially since the code may already be updated with additional features—then:

• What is the real need for detailed version tracking in that scenario?
• Will the updated code remain efficient and clean when merging with or aligning to a previous version/state, or could it introduce inconsistencies?

So the core concern is less about Git-like commits and more about choosing the right strategy between re-prompting vs. version restore, while ensuring the design-code integrity remains intact.

2. Please find my query explained in a more detailed manner. I hope this makes it easier to understand.

• With the introduction of Code Layers, will there be any limitations on design revisions for a specific component, considering that design changes are expected to reflect in real time?

  • Could you provide a bit more info on what you mean in terms how you expect it might be different from other layers?

With the introduction of Code Layers, I am trying to understand whether there will be any practical limitations when repeatedly modifying a specific component. Since design updates are expected to automatically reflect in the underlying code in real time, continuous revisions could lead to multiple incremental changes being applied.

In such a scenario:

• Will there be constraints on how many times a component can be revised efficiently before performance, structure, or maintainability is impacted?
• How will Figma manage accumulated changes in the generated code—will it stay clean and optimized, or could it become cluttered over time?
• Will there be a need for a reset, refactor, or version control mechanism to ensure the component remains scalable and production-ready?

Essentially, the concern is whether real-time design-to-code syncing introduces hidden limits or complexity when a component undergoes frequent iterative changes.

Thanks,
Rita

Thank you so much for being so detailed, ​@Rita Das - this is really helpful in understanding your concerns managing Figma as the source of truth for real-world, production-ready code. As I’m understanding your reply, it really boils down to re-prompt versus restore and which preserves design and code integrity better - something that becomes even more apparent with Code Layers and repeated revisions.

Let me back up a bit here with Code Layers first before returning to the more general idea of re-prompt versus restore. With Code Layers being in a closed beta, we don’t have established guidance yet on limits or best practices so I don’t want to try and speculate - I’ve shared this internally, though, since you’ve brought up some really great points. Thank you again!

More broadly, re-prompting is the better way to go for selective reverts and changes to what the agent did, simply because version restore at the moment is holistic to the entire file and not just individual components. The only "revert" that's actually scoped to a single change is the in-chat Undo button (or Cmd/Ctrl+Z), and that only covers the most recent agent turn (disappearing after that turn is done). Past that point, asking the agent directly to fix or undo the specific thing you don't like is your best tool. You’ve already got a good understanding of this, but I included the additional clarification for anyone else reading.

To your question about whether updated code stays clean when you go this route - that's a fair concern, and and it’s a bit of an unknown as far as how "clean" things stay across many rounds of re-prompting. My personal take is treat each round of prompted changes the way you'd treat a code review pass. Check the result before moving on to the next prompt rather than stacking several unreviewed changes on top of each other. That way, you’ll catch drift early rather than needing a big cleanup later.

Cheers!