The question every design handoff ends with is simple: does the site match the design? Answering it by hand means opening both side by side and checking section by section, which is exactly the kind of patient, mechanical work humans are bad at sustaining. So we built it into layernote: link a Figma frame to a live URL, press Compare to live, and get back a list of every difference.
This post explains what actually happens when you press that button, because the answer is more interesting than "AI finds the differences". Most of the pipeline is deliberately not a model, and the reasons why shaped the whole feature.
Step 1: the design becomes measurements
The layernote Figma plugin walks the frame you sync and extracts what each element is supposed to be: fill and text colors, the full typography stack (family, size, weight, line height, letter spacing, alignment), auto-layout padding and gaps, corner radii, borders, shadows, and where every element sits in the frame. Not a screenshot of the design; the design's actual values.
Step 2: the live page becomes measurements too
When a comparison runs, layernote loads your live URL at the exact width of the design frame and takes a structural snapshot: every element's position, text content, and computed styles as the browser resolved them. Computed styles matter because they are the truth after the whole CSS cascade has argued itself out. A screenshot can tell you something looks wrong; computed styles tell you the heading rendered at weight 400 while the design says 600.
Step 3: matching, the part that has to be humble
Now two lists of measurements need pairing up: this Figma text node is that DOM element. Text content is the primary anchor, and geometry breaks the ties. The matcher is deliberately conservative: below a confidence floor it refuses to match at all, and it never assigns one page element to two design nodes. A missed match costs one finding. A wrong match poisons the diff with nonsense, so when in doubt, it stays out.
Step 4: the diff is arithmetic, with taste
Each matched pair gets compared property by property against tolerances tuned on real projects. Colors are compared in a perceptual color space, so a difference the eye cannot see is not a finding. Font sizes get a pixel of slack, spacing two, positions more, because browsers and design canvases legitimately disagree at that scale. Whole rows that drifted together collapse into a single "this section shifted" finding instead of forty separate pins. And findings are ranked by measured severity, capped by match confidence: the engine does not shout about things it is not sure it matched correctly.
The result of a run is a match score and a list of differences, each one carrying the element, the expected value, the actual value, and a recommendation.
The part where we removed the AI
An earlier version of this feature sent screenshots to a vision model and asked what differed. It demoed beautifully and worked badly. The model noticed things that were not different, described real differences too vaguely to act on, and gave different answers on different days. Worst of all, its findings had no stable identity, so there was no way to re-check later whether a specific difference was actually fixed.
The deterministic engine flips every one of those properties. Every finding is a measurement you can reproduce. "Expected #05131A, found #1A2B36" is not an opinion, and it does not change on a second run. And because every difference gets a stable identity, something better than resolving by hand becomes possible: verification. After a fix deploys, layernote re-captures the page, re-runs the same diff, and closes the finding only if the difference is measurably gone. That loop runs from your coding agent over MCP, or automatically on every deploy via a webhook. None of it would be trustworthy with a model guessing in the middle.
You stay in the loop
Nothing gets pinned to your project automatically. A run ends in a review screen that groups the differences by category, and you decide what becomes an annotation. Negligible findings arrive unchecked, and the review warns you when something smells off, like a match score so low you probably compared the wrong page, or a design frame whose width does not fit the captured viewport. On the next run, differences you already accepted or dismissed stay handled; only new findings surface.
This step exists because not every difference is a bug. Sometimes the build is better than the file, and the right fix is updating the design. The engine measures; you judge.
The practical details
Comparisons run per device frame, so a page with desktop and mobile designs gets checked at both widths, and one click sweeps every linked page in the project. The feature is part of the Studio and Team plans, with no cap on how many comparisons you run. Setup is: sync frames with the plugin, put a live URL on the page, press the button. If you want to see your own site's match score, the trial takes a few minutes.