Galileo will generate a high-fidelity screen that looks like it came out of a real design team, and then it will hand you a pixel image with no tokens, no real components, and no idea your design system exists. The temptation is to trace over it, ship the trace, and call it a handoff. The discipline this lesson teaches is the opposite: treat the Galileo screen as a reference photograph, rebuild it in Figma against your actual design-system tokens, and write the explicit diff that says exactly what changed and why. Along the way you take a deliberate side-trip into UX Pilot, not for UI fidelity, but for the one thing it is genuinely good at, proposing flow structure. You walk away with a before/after/why comparison frame annotated with token names, and a UX Pilot flow diagram carrying a short "what it got right, what I redrew" note.

The Trace That Passed and the Handoff That Broke

A UI designer needs a hi-fi dashboard for a Thursday review. They prompt Galileo, get back a clean analytics screen, and import it into Figma. It looks great, so they trace the layout, place a few real components on top, leave the rest as flattened image where it is close enough, and ship the file to engineering. The review goes fine. Everyone admires the screen.

Then engineering opens the file to build it and the trouble starts. The chart card has a 22px corner radius that matches nothing in the system. The "Export" button is a styled rectangle, not a real Button instance, so it carries no states, no tokens, no focus ring. Three of the data labels are baked into a background image, uneditable. The spacing between sections looks like the screenshot but is not bound to any spacing token, so when the developer uses the system's grid the layout shifts and now does not match the file. The handoff that "passed" review created a week of back-and-forth, because the file looked like a specification and behaved like a screenshot. The Galileo output was never the problem. The problem was treating a reference image as a build artifact.

This is the L2 pattern again, in the highest-stakes place it shows up: the model supplies the speed and the visual direction, and you supply the rebuild that makes it real. Galileo is allowed to show you what the screen could look like. It is not allowed to define what ships, because what ships has to be made of your tokens, your components, your system - none of which Galileo can see.

Why Galileo Output Is a Reference, Not a Source

Galileo is a strong text-to-hi-fi tool. By 2026 the visual quality of its screens is frequently indistinguishable from hand-built work, which is exactly what makes it seductive and dangerous. The output is a rendering: a high-fidelity picture of a plausible screen, assembled from an averaged understanding of what dashboards, settings pages, and feeds usually look like. It is a beautiful average. It is not your system.

The critical move is to mentally reclassify the Galileo screen the instant it lands. It is not a draft of your file. It is a reference photograph, the way a brand designer treats a moodboard image: it shows direction, mood, density, and arrangement, and you take all of that as input while building the actual artifact out of materials your system owns. A reference photograph of a beautiful kitchen does not come with the cabinets. You still have to build the cabinets, and you build them out of your own wood. The error in the opening story was treating the photograph as the cabinets.

What Galileo Genuinely Gives You

This is not a reason to skip Galileo. The reference is valuable. It gives you a fast, concrete answer to "how might this screen be arranged?" that you can react to instead of starting from a blank frame. It frequently surfaces a layout idea, a density choice, or a content arrangement you would not have reached as quickly alone. Take that. The rebuild is not a punishment for using AI; it is how you convert a free, fast visual direction into a build-ready file. You get the speed of generation and the integrity of a hand-built system file, but only if you keep the two roles separate: Galileo proposes the look, you author the artifact.

The Rebuild Pattern: From Galileo Screen to System File

The rebuild is a deliberate sequence, run in this order because each step depends on the one before it. Done as a checklist, it turns a flattened reference into a token-bound, component-real Figma file in roughly the time the back-and-forth would have cost you later, except now the file is correct before it reaches engineering.

Step one, establish the structural frame in your spacing tokens. Rebuild the layout skeleton, the sections, columns, and gutters, using auto-layout bound to your spacing Variables. Do not measure the Galileo image in raw pixels and copy the numbers; that just imports the average. Match the arrangement, but express it in your scale. The Galileo screen says "two columns with a sidebar"; your file says "two columns with a sidebar, gutters on the 24px token."

Step two, replace every element with a real component. The chart card becomes your Card component. The export control becomes your Button. The nav becomes your Nav. Every styled rectangle in the reference becomes a true instance of a library main component, which brings its own tokens, states, and focus behavior. This is the step that kills the "styled rectangle masquerading as a button" failure from the opening story.

Step three, bind type and color to styles and tokens. Every text layer gets a named text style; every fill gets a semantic color token. The 22px radius from the reference becomes your nearest radius token, and if nothing fits, that is a finding, not an excuse to keep 22px.

Step four, replace baked-in content with real, editable content. Anything that was flattened image in the reference, data labels, chart values, avatars, gets rebuilt as editable layers with realistic content including the longest realistic string. A handoff file with uneditable baked-in text is not a specification.

When the rebuild is done, the screen looks like the Galileo reference and is made entirely of your system. That is the whole trick: same look, different substance. The look came free from the model; the substance is the part you were always paid for.

The Explicit Diff: Writing What Changed and Why

The rebuild is only half the artifact. The other half is the diff, a short written record of what you changed between the Galileo reference and your file, and why. Most designers skip this, and skipping it is how the "is the v0 output matching design intent?" conversation becomes unanswerable. The diff is what lets you, an engineer, or a lead see the reasoning instead of guessing at it.

Write the diff as a plain list, one line per meaningful change, each naming the token or component that replaced the generic value. "Galileo radius 22px to radius/md (8px), our system has no 22px radius." "Galileo export rectangle to Button/Primary instance, gains focus ring and pressed state." "Galileo section gap 30px to space/lg (32px) so it lands on the grid." The diff does three jobs at once. It documents your decisions so they survive a review. It teaches anyone reading it the difference between a reference and a build. And it is the AI-honest portfolio sentence in its strongest form: not "I used Galileo," but "I used Galileo for visual direction and here is precisely how I rebuilt it against our tokens."

Galileo gives you a photograph of the screen. The diff is your proof that you built the cabinets out of your own wood. Without the diff, a handoff is just a trace that nobody can verify.

The Before / After / Why Comparison Frame

Package the rebuild and the diff into a single Figma frame with three columns, because the three-column form is what makes the work legible to everyone who opens the file. Column one, "before": the raw Galileo reference, imported as an image, untouched. Column two, "after": your rebuilt, token-bound, component-real screen. Column three, "why": the diff, written as annotated callouts that connect a specific element to the token or component that replaced its generic value, with the radius, spacing, and component swaps named explicitly.

The before/after/why frame is the artifact that survives an engineering review, because it answers the question engineers actually have, which is not "does it look good" but "what exactly am I building and is it our system?" When an engineer can see the Galileo reference, your file, and a token-named explanation of every difference side by side, the handoff conversation stops being a negotiation and becomes a confirmation. It also protects you politically: when someone asks whether the AI "did the design," you point at column three and show that the AI did the photograph and you did the design.

The UX Pilot Side-Trip: Use It for Flow, Not Fidelity

On the same brief, there is a second AI tool worth pulling in, but for a completely different job. UX Pilot is frequently misused as a hi-fi screen generator, where it competes with Galileo and loses, producing UI that looks plausible and falls apart under the four-error scrutiny you already know. Its real strength is upstream: proposing flow structure. Given a goal like "a user upgrading from free to paid," UX Pilot will lay out a sensible sequence of steps and decision points faster than you would whiteboard it, and that sequence is genuinely useful as a starting structure to react to.

So the discipline is to use UX Pilot for what it is good at and stop there. Let it propose the flow, the steps, the branches, the points where a user can drop out or come back. Then redraw the flow in your own hands, keeping what it got right and correcting what it got wrong, because flow structure is where the model's averaged sense of "how upgrade flows usually go" can quietly miss your actual product's constraints. UX Pilot is the session musician for flows: great at the standard progression, blind to your specific song.

The "What It Got Right, What I Redrew" Note

The flow-diagram artifact ships with a short paragraph, and that paragraph is the whole point. UX Pilot will get some of the flow right: the broad sequence, the obvious decision points, the standard happy path. It will also get specific things wrong: a missing error-and-retry branch, an assumed step your product does not have, a decision point in the wrong order for your data model, a dropped "user abandons and returns later" path. The note names both halves explicitly. "UX Pilot proposed the four-step upgrade sequence and the plan-selection branch, both of which I kept. I redrew the payment-failure path it omitted, removed an account-creation step our product handles earlier, and added the abandoned-cart re-entry it missed." That two-sentence note is what turns a generated flow into a flow diagram that survives a real engineering review, because it shows the engineer exactly which parts carry the model's average and which parts carry your judgment.

Why the Flow Side-Trip Belongs in a Handoff Lesson

It might seem odd to pair a screen-rebuild pattern with a flow-diagram side-trip, but they are two halves of one idea, and the pairing is the lesson. Both are cases of using AI for the thing it is good at and refusing it the thing it is bad at. Galileo is good at the look of a screen and bad at making it real, so you take the look and rebuild the substance. UX Pilot is good at proposing a flow and bad at UI fidelity, so you take the flow structure and redraw the detail. The skill that unifies them is knowing which job each tool is for and never letting a tool's confidence in the wrong job override your judgment.

A clean handoff in 2026 is exactly this discrimination, applied fast. You let the tools accelerate the parts they accelerate well, you rebuild and redraw the parts that have to be yours, and you document the seam between them so anyone downstream can see what is model-average and what is designer-judgment. The handoff that breaks is the one where those two are silently mixed. The handoff that survives is the one where the diff and the note keep them separate and named.

Why the Machine Handoff Raises the Stakes

There is one more reason the rebuild is non-negotiable in 2026, and it is the reason that did not exist a few years ago: your file is no longer read only by humans. With the Figma MCP server and Code Connect, an AI agent can read your handoff file directly to scaffold code, and an agent reads the file far more literally than a human does. When a person opens a traced Galileo screen, they squint at a styled rectangle and understand "that is meant to be a button." When an agent reads the same file, it treats the styled rectangle as ground truth, finds no real component behind it, and either invents one or generates code against a component that does not exist. The trace that a human could read past becomes, for the agent, a set of false instructions executed with confidence at machine speed.

This changes the rebuild from a courtesy into a correctness requirement. A rebuilt file where every element is a true library instance mapped through Code Connect and every value is a named token is the only kind of file an agent can read as your actual system. The same artifact now has two consumers with two needs: the human engineer needs a confirmable specification, which the before/after/why frame provides, and the agent needs machine-truth, which the bound, mapped, real-component rebuild provides. A trace fails both at once - it hands the human a screenshot and the agent a fiction. The rebuild is the single artifact that satisfies both, which is precisely why, in a year when agents read design files, "rebuild rather than trace" stops being a matter of craft pride and becomes a matter of whether the code generated downstream is built on your system or on Galileo's average.

The practical consequence is to treat any file an agent might read as held to the strictest version of the rebuild gate. If a screen will only ever be glanced at by a human in a review, a lighter touch might survive; the moment an MCP-enabled agent or a Code Connect mapping is in the loop, every detached component and every unbound value is a defect waiting to propagate into the codebase. The rebuild, the diff, and the real-component discipline are how you make sure that what flows from your design file into production code is your system, not the model's plausible guess at it.

Putting It to Work This Week

The next time you reach for Galileo, change three things. First, the instant the screen lands, label it in your head as a reference photograph, not a draft, and never trace it; rebuild it. Second, run the four-step rebuild (structural frame in tokens, real components, bound type and color, editable content) and write the diff as you go, one named line per change, so the documentation is a byproduct rather than a chore. Third, when the brief involves a flow, send the flow goal to UX Pilot, take its structure, redraw it yourself, and write the two-sentence "what it got right, what I redrew" note.

You will know the practice has landed when an engineer opens your handoff and stops asking "did the AI do this?" and starts building straight from column two, because column three already answered every question. That shift, from a handoff that invites suspicion to a handoff that invites construction, is what a clean handoff pattern buys you. Galileo gives you the photograph in seconds. The rebuild, the diff, and the redrawn flow are what make it a specification, and a specification is what engineering can actually build.

Key Takeaways

• Galileo output is a high-fidelity reference photograph, not a build source: a flattened, token-less, component-less rendering assembled from an averaged sense of what screens look like. Reclassify it as a reference the instant it lands, and never trace it.
• Run the four-step rebuild in order: structural frame bound to spacing tokens, every element replaced with a real library component, type and color bound to styles and semantic tokens, and baked-in content rebuilt as editable layers with realistic strings.
• Write the explicit diff as you rebuild: one named line per change ("Galileo radius 22px to radius/md 8px"), which documents your decisions, teaches the reference-versus-build distinction, and is the strongest AI-honest portfolio sentence.
• Package the work as a before/after/why frame with three columns (raw Galileo reference, rebuilt system file, token-named diff annotations) so an engineering review becomes a confirmation rather than a negotiation.
• Use UX Pilot for flow structure, not UI fidelity: let it propose the sequence and decision points, then redraw the flow in your own hands and ship a "what it got right, what I redrew" note that names both halves explicitly.
• The unifying skill is discrimination: take each tool's strength (Galileo's look, UX Pilot's flow), refuse its weakness, and document the seam so anyone downstream can see what is model-average and what is designer-judgment.