Read the marketing for any design-to-code tool and you will meet a number that sounds like a promotion: "up to 80% time saved." Builder.io puts it front and center, and it is repeated in pitch decks to justify cutting the design-engineering budget. Here is the thing a senior designer has to understand before that number ends up in a planning doc: it is a time-savings claim, not an accuracy claim, and the two are routinely conflated into a conclusion that does not follow. The honest practitioner number underneath it is a 25 to 40 percent manual-refinement pass that someone, usually you, has to do on every generated file before it ships. This lesson separates the claim from the reality, names exactly what the refinement pass contains, and leaves you a refinement-pattern worklist with an honest savings note you can put next to the vendor's number so nobody plans against a fantasy.

The Number That Ends Up in a Planning Doc

The danger of "up to 80% time saved" is not that it is a lie. For the specific, narrow slice of work the tool measured, generating an initial code scaffold from a design, it may well be true. The danger is what happens to the number on its way through an organization. A VP reads "80% time saved," mentally rounds it to "design-to-code is basically solved," and concludes that the team needs far fewer people to ship the same volume of front-end work. The claim was about one step in a multi-step process; the conclusion treats it as the whole process. That gap, between a measured saving on the generation step and an assumed saving on the entire path to shippable code, is where teams get cut on the basis of a number that was never claiming what the cut assumes.

Your job, the moment that number appears, is to do what you did with the five-categories CEO conversation: not to dispute the vendor, who is probably reporting their measurement honestly, but to locate the number precisely on the path from idea to shipped, and to show the part of the path it does not cover. The vendor measured the first leg of a relay. The race has more legs. Saying so is not anti-tool; it is the difference between a plan that works and a plan that ships broken front-end and blames the team.

Time Saved Is Not Accuracy, and the Difference Is Everything

Hold the two claims apart deliberately, because conflating them is the original sin here. A time-savings claim says: the tool produced an initial result faster than a human starting from scratch would have. A accuracy claim would say: the result the tool produced is correct and shippable as-is. Builder.io's "up to 80% time saved" is explicitly the first kind, and the marketing is careful about that even when the readers are not. Nothing in "time saved" asserts that the output is responsive, accessible, on-token, correctly wired to data, or animated with intention. It asserts that you got to a starting point faster.

This matters because the value of a starting point depends entirely on how much work remains from it. If the generated scaffold is 80 percent faster to produce but requires a refinement pass that adds back a meaningful fraction of the time, the net saving is real but far smaller than the headline, and the output is emphatically not done. The conflation, treating "we got here 80% faster" as "we are 80% done," is precisely the error that turns a useful accelerator into a budget-cutting justification it cannot support. Keep the two words apart and the whole conversation stays honest: faster to a starting point, yes; done, no.

"Up to 80% time saved" is a claim about the speed of the first leg, not the length of the race. It is true and it does not mean what the budget cut assumes it means.

The 25 to 40 Percent Refinement Reality

Across teams actually shipping design-to-code output in 2026, a consistent practitioner number shows up: after the AI pass, roughly 25 to 40 percent of the work remains as manual refinement before the file is shippable. This is not a knock on the tools; it is the structure of the problem. The generation step handles the high-frequency, convergent part of front-end code (the markup skeleton, the obvious styling), which is genuinely most of the typing, and it leaves the low-frequency, high-stakes part (the things that make code correct, accessible, and maintainable) for the human, which is the same generation-versus-understanding split from the very first lesson, now in code.

The refinement percentage is not a fixed tax; it varies with the work. A simple, static marketing section sits near the low end, because little remains beyond cosmetic cleanup. A data-bound, interactive, accessibility-critical application screen sits near the high end or beyond, because the generated scaffold got the easy 60 to 75 percent and left every hard decision. The practical move is to stop quoting a single number and instead estimate the refinement pass per file based on what kind of file it is, which is exactly what the worklist below operationalizes. The honest savings note is always two numbers: the generation speedup the vendor measured, and the refinement pass you will actually pay, with the net stated plainly.

What the Refinement Pass Actually Contains

The reason the refinement pass is non-negotiable is that it is made of exactly the things design-to-code tools reliably get wrong, and they are the things that matter most for a real user. Here are the six that recur on almost every generated file, drawn from real shipped work.

Responsive Breakpoints

Generated code is usually produced against one viewport and looks correct there, then breaks at other widths because the tool did not reason about the breakpoints, the same single-canvas failure we saw in generated mocks. Refinement means actually testing the file across the real breakpoints and fixing the layouts that collapse, wrap, or overflow. This is rarely cosmetic; it is often structural, and it is frequently the largest single chunk of the refinement pass.

Dynamic Data

The tool generates against the placeholder content in the design, so it produces markup that assumes the happy-path string length and the happy-path number of items. Real data is longer, shorter, empty, paginated, and occasionally missing, and the generated file handles none of those states. Refinement means wiring the component to real or realistic data and handling the empty, loading, error, and overflow states the design and the generation both skipped, the edge-case work from the generated-mock lesson, now in code.

Animation Timing

If the file has motion, the generated timing and easing are the flat, generic average we covered in the guarded-tasks lesson. Refinement means tuning the timing to feel intentional and responsive, and crucially adding the reduced-motion handling the generation omitted, which is both a craft and an accessibility fix.

Focus Order and Keyboard Navigation

Generated markup frequently has a focus order that follows the source order rather than the visual and logical order, and interactive elements that are not reachable or operable by keyboard. Refinement means walking the file with the keyboard alone, fixing the tab order, and ensuring every interactive element is reachable and operable, which is invisible to a mouse user and essential to many real ones.

ARIA and Semantics

Tools reach for generic divs and sometimes invent ARIA attributes that are wrong or unnecessary, which is worse than none because incorrect ARIA actively misleads assistive technology. Refinement means replacing generic elements with correct semantic ones, removing fabricated ARIA, and adding the genuinely needed labels and roles, a task that requires knowing the ARIA Authoring Practices, which the tool does not.

Focus-Ring and Design-System Tokens

The generated file uses literal values rather than your design-system tokens, and it routinely drops the focus-ring treatment entirely, the exact 2.4.11 focus-appearance gap from the accessibility lessons. Refinement means swapping literals for tokens so the file inherits the system (and stays maintainable), and restoring the focus-ring token so keyboard users can see where they are. This is where the design-to-code output either joins your system or becomes a parallel one that drifts, which connects directly to the drift-detection lesson.

The Artifact: A Refinement-Pattern Worklist With an Honest Savings Note

Here is the deliverable. For one real file you put through a design-to-code tool, build a worklist that turns the vague "needs polish" into a named, estimable pass. List the six refinement categories above, and for each, write what you actually had to do on this file and roughly how long it took. Then write the honest savings note at the top: the generation speedup you observed, the total refinement time, and the net saving as a plain sentence. For example: "Generation produced the scaffold in about ten minutes versus a hand-build estimate of two hours; the refinement pass (breakpoints, data states, focus order, ARIA, tokens, focus ring) took about fifty minutes; net saving roughly one hour, about 45 percent on this file, not 80 percent, and the file was not shippable until the refinement was done."

That note is the entire point. It is the sentence you put next to the vendor's number in any planning conversation, and it converts a marketing claim into a number a team can actually plan against. Build the worklist on three different kinds of file (a static section, an interactive component, a data-bound accessibility-critical screen) and you have a small, honest table showing how the refinement pass scales with complexity, which is far more useful for capacity planning than any single percentage. The worklist also doubles as a checklist: it ensures the refinement pass actually happens rather than getting skipped under deadline pressure, which is how unrefined generated code reaches production and the "80% time saved" becomes "80% of an accessibility lawsuit's root cause."

A Worked Example: Three Files, Three Very Different Savings

Make the variance concrete by running the worklist across three real files, because the single headline percentage hides exactly this spread. File one is a static marketing section: a hero, three feature cards, a footer, no data, no real interactivity. Generation produced it in eight minutes against a forty-minute hand-build estimate, and the refinement pass was light, a breakpoint fix and a token swap, about ten minutes. Net saving is large, roughly 55 percent, and the file is genuinely close to the headline because this is the kind of file the headline was measured on. Quoting 80% here is almost defensible.

File two is an interactive settings component with toggles, a dropdown, and a save action. Generation produced the scaffold in twelve minutes against a ninety-minute estimate, but the refinement pass was substantial: focus order was wrong, the dropdown was not keyboard-operable, the toggles had fabricated ARIA, and the save had no loading or error state. That pass took about forty-five minutes. Net saving is real but middling, roughly 36 percent, and the file was genuinely unusable until the pass was done, because an inaccessible settings control is not a settings control. File three is a data-bound, accessibility-critical dashboard screen: generation produced something that looked plausible in fifteen minutes against a four-hour estimate, but the refinement pass (breakpoints across three layouts, empty and error and loading states for every widget, focus management for a complex grid, correct ARIA for the data table, token alignment throughout) took nearly three hours. Net saving is still positive, roughly 35 percent, but the headline would have predicted the file was nearly done at fifteen minutes, when in fact three hours of the hardest work remained. Three files, savings of 55, 36, and 35 percent, none of them 80, and the gap between them is precisely the information a capacity plan needs and the headline destroys.

Why This Protects Both the Budget and the Craft

This lesson does double duty. It protects the budget conversation, because the honest savings note prevents a real but modest acceleration from being mistaken for a headcount-eliminating one, which is the same defensive move as the five-categories stack map at a finer grain. And it protects the craft, because naming the refinement pass as required work makes it visible, schedulable, and respected, rather than invisible unpaid labor that gets squeezed out when the plan assumed the tool did everything. A refinement pass that is in the plan gets done; a refinement pass that the plan assumed away gets skipped, and skipped refinement is exactly how generated code ships inaccessible, off-brand, and unmaintainable.

The deeper point is the one that runs through all of L3: the tool collapses the production, and the human owns the judgment, and the refinement pass is where that judgment lives in design-to-code specifically. The 25 to 40 percent is not waste or friction; it is the part of the work that was always the actual engineering of a correct front end, now concentrated because the typing was automated away. A designer or design engineer who can name that pass, estimate it, and defend it in a planning doc is precisely the person whose value rises as the tools improve, because better generation makes the refinement judgment more central, not less. The vendor's number is about the typing. Your worklist is about the work.

One last reframing makes the whole lesson portable. The pattern here is not specific to design-to-code; it is the shape of every AI-tool ROI claim a designer will meet. The tool measures and markets the step it accelerates, honestly, and the organization reads that measurement as a saving on the entire job. The transferable discipline is identical each time: locate the claim on the full path from intent to shipped, name the human-owned remainder the tool leaves behind, measure that remainder on your own real work, and report net-after-remainder per task type rather than repeating the headline. Whether the claim is "80% time saved" on code, a research-synthesis speedup, or a generation-throughput multiplier, the move is to pair the vendor's measured speedup with your measured remainder and plan against the net. Learn it once here, on the most concrete and measurable case, and you have an inoculation against the time-versus-completion conflation everywhere it will show up for the rest of your career.

Key Takeaways

• "Up to 80% time saved" (Builder.io and others) is a time-savings claim, not an accuracy claim: it says you reached a starting point faster, not that the output is shippable. Conflating the two is how a real acceleration becomes an unjustified headcount cut.
• The honest practitioner reality is a 25 to 40 percent manual-refinement pass on every generated file before it ships, varying from near the low end (static section) to the high end or beyond (data-bound, accessibility-critical screen).
• The refinement pass reliably contains six things the tools get wrong: responsive breakpoints, dynamic-data and edge states, animation timing and reduced-motion, focus order and keyboard operability, correct ARIA and semantics, and design-system tokens plus the focus ring.
• This is the generation-versus-understanding split in code: generation handles the high-frequency typing; the human owns the low-frequency, high-stakes correctness that the refinement pass addresses.
• Build a refinement-pattern worklist with an honest savings note: per file, the six categories with what you did and how long, plus a plain-sentence net saving ("about 45 percent on this file, not 80 percent, and not shippable until refinement was done"). Run it on three file types to show how the pass scales with complexity.
• The worklist protects both budget and craft: it stops a modest acceleration from being misread as headcount-eliminating, and it makes the refinement pass visible, schedulable, and done rather than skipped under deadline (which is how unrefined code ships inaccessible).
• As generation improves, the refinement judgment becomes more central, not less, so the designer who can name, estimate, and defend the pass is the one whose value rises. The vendor's number is about the typing; your worklist is about the work.