Show Your Work: A Real Version Log
Show your work real version log metadata · MD YouTube Metadata Package Primary Title Show Your Work: A Real Version Log
Show your work real version log metadata · MD YouTube Metadata Package Primary Title Show Your Work: A Real Version Log
Alt Title (shorter) Zero Pixels Differ. Only the History Tells the Runs Apart.
Description (paste block below — under 4,500 characters) Hand in the finished design? Better: hand in its dated history too.
Four terms first. Version history: Figma's dated record of a file's saved versions, checkpoints and named ones. A named version: one saved by hand, with a title and a description — the reason. The REST API: Figma's web interface for scripts, outside the editor. A token: a personal access key created for such a script, with a scope like reading versions.
Building on an earlier film's idea — hand in the dated history of a design, with a reason for each change, not just the finished thing — an agent put that to a small test. One flashcard: a term, a definition, one Flip button, three colour variables. Built twice, two ways, in a new Figma file. Run A: one prompt, one write — the whole card, variables and all, in a single script, landing in one call with the file's own render returned alongside it. Run B: five small steps, each its own write, each with a reason written into the script — colours first so every fill points at a variable, then the empty frame for structure, then the words, then the one accent button, then the card turned into a component and checked: five paints, four bound, one not, the white label. Sixty-four seconds, a render after every step.
Comparing the two finished cards pixel by pixel, from Figma's own renders: zero pixels differ, out of sixty-two thousand. The finished design cannot tell a one-prompt job from a worked one. Only the trail can.
So what would Figma's actual history show? Figma checkpoints every thirty minutes, and both runs happened inside two minutes — autosave may well fold them into one checkpoint. The agent couldn't save a named version either: through the MCP server, save_version_history isn't a supported API call, and marking the file ready for dev or writing a comment were both refused in an earlier review pass, so neither was retried. The log this recipe actually wants comes from Figma's REST API: one request for a file's versions returns each version's UTC date (set by Figma's servers), label, description, and who saved it — a small script turns that into a table. A mock version of that table, from the docs, shows what it would look like: six rows with named versions, five carrying a reason; one row with autosave alone, no reasons. Running the real script needs a personal access token with the versions scope, which only the account owner can create — so the real table stays pending.
Two things travel either way: the agent's five scripts, with their reasons and clock times, and the fact that every edit landed under the signed-in human account, not under the agent's name. Verdict tonight: pending. What's settled — the artifact proves nothing about process, and a two-minute job may leave exactly one checkpoint. The trail that actually tells runs apart is the one made on purpose: a named version with a reason at each real step, plus the session transcript beside it.
Your Turn: Paste into Claude: "Here is my Figma file link and my Claude Code session export: [paste both]. Build a dated table of what changed and why, one row per named version or session step, and flag every stretch longer than thirty minutes with no named version." Then check two things yourself: does every row have a reason in your own words, and do the dates come from Figma's server, not from you?
Sources and citations: see the reel's SOURCES.md in the open textbook. An independent series, not affiliated with or endorsed by Figma.
0:00 Introduction: four terms 0:25 One flashcard, built two ways Pixel-identical results, and what only the version log can show 2:43 Your Turn
Series: Figma for Educational AI. @NikBearBrown
Deliberately Not Claimed This video reports one small test — one flashcard, two build methods, one file — and explicitly leaves its main verdict as pending, since the real Figma version-history table requires a personal access token only the account owner can create. It does not claim Figma's checkpoint behavior, MCP API limitations, or version-history mechanics described here will remain unchanged; check Figma's own REST API documentation for current, authoritative details.
SEO Keyword Tags Figma version history REST API, Figma named version, Figma MCP server limitations, evidence of design process, dated version log, Figma personal access token, pixel identical designs, Claude Code Figma test, Figma checkpoint autosave, Figma versions endpoint, AI generated design evidence, Figma education account experiment, version log academic integrity, Figma REST API script, design process documentation
What this video covers
- 0:00 — Introduction: four terms 0:25 One flashcard, built two ways Pixel-identical results, and what only the version log can show 2:43 Your Turn
Transcript
A lightly formatted transcript of the video, with timestamps so you can jump to any section on YouTube.
Introduction: four terms 0:25 One flashcard, built two ways Pixel-identical results, and what only the version log can show 2:43 Your Turn
[0:00] Hey, this is lam in forbear. Hand in the finished design better hand in its dated history too. Four terms version history. Figma's dated record of a file saved versions checkpoints and named ones. A named version when you save yourself with a title and a description. Your reason the rest API Figma's web interface for scripts outside the editor and a token a personal access key you create for such a script with a scope such as reading versions. Bear's idea from an earlier film in this series. hand in the dated history of a design with a reason for each change, not just the finished thing. Tonight, at his request, an agent put that to a small test. One flash card, a term, a definition, one flip button, three color variables built twice in a new Figma file two ways. Run a one prompt, one write, the whole card, variables, and all in a single script. It
Landed at 34 seconds past 150 UTC, and the file's own render came back in the same call. Run B. Five small steps, each its own right. Each with a reason written into the script. Colors first. So every fill points at a variable. Then the empty frame for structure. Then the words. Then the one button. The only accent. Then the card becomes a component and gets checked. Five paints. Four bound one not the white label. 64 seconds. A render after every step. Now compare the two cards pixel by pixel from Figma's own renders. Zero pixels differ out of 62,000. The finished design cannot tell a one prompt job from a worked one. only the trail can. So, what would Figma's history show? Figma records a checkpoint every 30 minutes. Both runs happened inside two minutes, so autosave may well hold them in one checkpoint, and the agent could not name a version through the MCP server
Save version history is not a supported API, nor could it mark the file ready for dev or write a comment. Those were refused in the review pass, so they were not tried again tonight. The log the recipe wants comes from Figma's REST API. One request for files versions and back comes each version's date in UTC set by Figma servers, its label, its description and who saved it. A small script turns that into one table. This is the shape it would take from the docs. A mock not real data with named versions, six rows, five with a reason with autosave alone, one row, no reasons. Running that script needs a personal access token with the version scope which only bear can create. So the real table is pending bear. Two things travel with it either way. The agents five scripts with their reasons and clock times and the fact that every one of those edits
Landed under the signedin account, not under the agents name. So, the verdict tonight is pending. What is settled? The artifact proves nothing about process and a two-minute job may leave one checkpoint. The trail that tells the runs apart is the one the student makes on purpose. A named version with a reason at each real step, plus the session transcript beside it. Nine calls of 12. The log is bears to pull. Your turn. Paste this into Claude. Here's my Figma file link in my cloud code session export. Then paste both. Build a data table of what changed and why. One row per named version or session step and flag every stretch longer than 30 minutes with no named version. Then check two things yourself. Does every row have a reason in your own words? And do the dates come from Figma's server, not from you? Show your work a real version log at Nick Bear Brown.
