Design-to-Code Tools Promise 75 Days Saved. Nobody Tracks the Days Spent Fixing It.

Every design-to-code vendor slide has the same shape: a big number on the left ("75 days of engineering time saved"), a smaller number on the right ("3x faster shipping"), and nothing in between telling you what happened to the code after it got generated. That gap isn't an oversight. It's the whole pitch. The moment you ask "and how much of that output needed to be rewritten before it shipped," the 75-day number stops meaning anything, because nobody selling the tool is measuring rework. They're measuring generation speed and calling it delivery speed, and those are not the same number.

What the demo shows you and what production asks of you are different tasks

Figma's Code Layers, announced at Config in June 2026, joined a field that already includes v0, Lovable, and Banani in promising to collapse the handoff between design and shipped code. The demos are genuinely impressive — a component goes from Figma frame to working React in under a minute, styled, responsive-looking, done. What the demo doesn't show, because demos are built to avoid it, is the version of that same component that has to survive contact with an actual product: a data table that needs to handle zero rows, one row, and ten thousand rows without breaking layout. A form that needs to announce its own validation errors to a screen reader, not just turn a border red. A card component that needs to gracefully truncate a headline in eleven languages, not just the one the design file was written in.

These aren't edge cases in the pejorative sense — they're the actual majority of what makes a component production-grade rather than demo-grade. And they're precisely the category of work these tools handle worst, because they require inferring intent that was never present in the visual design in the first place. A Figma frame shows you what a card looks like with sample content. It doesn't show you what the card is supposed to do when the content breaks the assumptions the sample made. A human engineer fills that gap with judgment. A generation tool fills it with a plausible guess, and plausible guesses are exactly the failure mode that doesn't show up until QA — or worse, until a real user hits it.

The rework number nobody's publishing

Ask engineering leads who've actually shipped design-to-code output to production, off the record, and the number that comes back consistently sits around 30–40% of generated components needing meaningful revision before they're production-ready — not typo-level fixes, but structural changes to responsive behavior, accessibility semantics, or state handling that the generation step got plausibly wrong. That's not a criticism of the underlying models. It's a description of what the input format — a static visual frame — can and can't encode. You cannot generate correct behavior for a state the design file never depicted.

The reason this number stays informal instead of published is structural, not conspiratorial: rework is expensive to track and cheap to ignore. Nobody's instrumenting "percentage of AI-generated component code that survived to merge unmodified" because doing so requires git-blame-level tracking most teams haven't set up, and because the number, once visible, undercuts the pitch that justified the tool's purchase in the first place. This is the same blind spot AI-generated code review speed already exposed in a different part of the pipeline — velocity gets measured because it's easy and flattering; correction cost doesn't, because it's neither.

Context-switching is the cost the ROI math forgets entirely

Even the 30–40% framing understates the real cost, because it treats rework as a discrete, containable task — fix the broken piece, move on — when the actual cost is systemic. A design system is a set of shared assumptions: this is how spacing scales, this is how a disabled state looks, this is the one accessible pattern for a dropdown across the whole product. Generated code doesn't inherit those assumptions from the design file. It infers a plausible implementation independently, component by component, which means a codebase accumulating AI-generated components accumulates plausible-but-inconsistent implementations of the same underlying pattern. The coherence cost of this compounding shows up exactly where you'd expect — more components, less shared logic between them, and an engineer who now has to context-switch between "this button was hand-built to system spec" and "this button was generated and needs a pass to match" without any visible marker distinguishing the two.

That context-switching tax doesn't appear on any vendor's ROI slide because it's a second-order cost — it shows up three sprints later as "why does this section feel slightly off from the rest of the product," not as a line item anyone can point back to the generation tool. But it's real, and it's the actual explanation for something teams keep reporting anecdotally: the tools save time on the first pass and cost time on every pass after, in a ratio nobody's bothering to calculate because the first number is so much easier to screenshot.

What an honest rework metric would actually measure

If you're evaluating one of these tools, the question worth asking your vendor rep isn't "how much time does this save." It's "what percentage of generated output ships unmodified, and how do you know." Push for a number, not a testimonial. If the answer is a case study instead of a metric, that's itself the answer — it means nobody on the vendor side is tracking the thing that would tell you whether the tool is actually net-positive for your team, or just faster at producing the first 60% of a component while quietly transferring the remaining 40% onto an engineer who now has to reverse-engineer intent from output that looks finished but isn't.

The tools aren't worthless. Generation genuinely accelerates first-draft output, and first drafts have real value. But "accelerates first drafts" and "saves 75 days of engineering time" are different claims, and only one of them survives an honest accounting of what happens after the demo ends.