From the field #07 - Figma to code that doesn’t hallucinate

Part 3: what it returns, and where it goes

Part 1 made the case for never letting the model guess. Part 2 showed the two public tools that come out of one deterministic core: sdet-figma-kit generates, qa-pack verifies.

This part is about what that buys you, and where the approach goes from here. I am going to be precise about what is built and what is not, because the whole value of this method collapses the moment I start describing things I have not shipped as if they were running.

So here is the line, up front. The generator is real. The verifier is real. The closed loop that wires them together with an automatic fix step is not. That last piece is how I design a system for a client. It is a roadmap, not a repo.

Let me earn that distinction by starting with the part that is already paying off.

The ROI is the absence of a category of work

Go back to the probabilistic 1% from Part 1. A model guesses flawlessly 99% of the time. The other 1% it produces a value that is wrong and looks right. Green preview, plausible CSS, a number off by four pixels.

The expensive part of that 1% is not the bug. It is that the bug is invisible. Nobody hand-corrects a value that looks correct. It ships. It sits in the codebase as hidden debt until a layout change three weeks later detonates it, and now someone is bisecting a regression that traces back to a 16px the model invented from a screenshot.

That is the worst kind of work there is. It is slow. It is unrewarding. And it lands on whoever is closest, usually long after the person who pasted the screenshot has moved on. The cost never shows up on the task that created it. It shows up later, on a different task, attached to a different name.

Deterministic extraction removes that category entirely. There is no hand-correction pass, because there are no invented values to correct. A value is either read exactly from the design or it is absent. There is no third state where a plausible guess hides among the real numbers. RULE ZERO holds the line:

If a property is absent in the extracted design, its value is zero or none. Never estimate it from a screenshot. Absent means zero.

That is the real return. Not “faster”, though it is faster. The return is that you delete the slowest, most demoralizing work in the whole flow: chasing a silent wrong value that already passed review.

Here is the scaling illustration, and I want to be clear this is a generic illustration, not a number from any client engagement.

Take a batch of 100 to 200 design-to-code tasks. A team doing it the classic way, screenshot to model to manual cleanup, spends roughly a week on that. Each task carries its own small cleanup tax, and a fraction of them carry a hidden-debt landmine that surfaces later.

A deterministic pipeline does the same batch in 2 to 3 days. Same Figma node plus same tokens gives byte-identical output every run, so there is nothing to babysit per task. The output is honest by construction, so there is no per-task verification tax beyond the verify step itself, which is also deterministic.

The speedup is real, but it is the second-order effect that matters. You stop paying interest on debt you cannot see.

There is a quieter return too, and it compounds. When the output is deterministic, a regeneration is free. The design changed? Run it again. You get the same skeleton with the new values, byte for byte, with no risk that the model decided to be creative on the second pass. The probabilistic workflow cannot promise that. Re-run a screenshot prompt and you might get a different guess, which means every regeneration is a fresh chance at the 1% catastrophe. Determinism turns “re-run it” from a gamble into a no-op you can trust.

The full loop, as I design it

Now the roadmap. This is the part I will not pretend is shipped.

One deterministic core. Two ends today: generate and verify, both public, both clone-and-run. The third end is the one I build for a client: a closed loop where verification failures feed an automatic fix step, the implementation is regenerated against the design, and the loop runs until the diff is clean.

Here is the loop as designed. Not as running code in a private repo, because that loop does not exist as shipped code anywhere. This is the architecture I wire up for an engagement.

flowchart LR
  A[Deterministic core:<br/>exact values + RULE ZERO] --> B[Generate skeleton]
  B --> C[Verify against design]
  C -->|diff clean| D[Engineer reviews + ships]
  C -->|diff dirty| E[Fix step:<br/>regenerate from design]
  E --> C

The two boxes you can build today are Generate and Verify. sdet-figma-kit is the generate box: parse get_design_context or pull over REST with a FIGMA_TOKEN, map to your design tokens, emit a CSS, Vue, or React skeleton. qa-pack is the verify box: compare a built implementation against the design, measured not eyeballed, across 13 categories, with getComputedStyle read from the deepest text element so inherited defaults never become false positives.

The box that does not exist as shipped code is Fix. There is no auto-fix engine in any repo of mine. Zero patch code. The arrow from verify back into a regeneration step is a design decision I make per client, not a feature I am quietly running.

Why is it honest to even draw it? Because the hard parts are already proven. Both ends already share one deterministic core and one RULE ZERO. The fix step is not a new source of truth. It is the same extraction feeding the same generator, triggered by the same verifier that already knows exactly which properties drifted. The loop is unbuilt, and I am not going to imply otherwise. What makes it tractable rather than a research problem is that the two ends it would connect are already built and tested. The fix step itself, and the orchestration that closes the loop, are net-new work I do per engagement, not code I am running.

And the hard part of the fix step is not the regeneration. The generator already does that. The hard part is the policy around it. Which drifts get fixed automatically and which get escalated to a person. What counts as a clean diff for a team that uses one set of tokens versus a team that allows literal values in places. Where the human gate sits, and what it sees when it opens. None of that is code I can ship blind. All of it is a conversation with the team that owns the pipeline.

That is precisely why it belongs in a commercial engagement and not in a free repo. The public halves teach the method. The closed loop, tuned to one team’s stack, their tokens, their framework, their definition of a clean diff, is the work.

AI does the dirty work, the engineer decides

The reprise from Part 1, because it is the spine of the whole approach and it does not change when the loop gets longer.

AI still does the dirty work. It reads the design context, maps values to tokens, drafts the skeleton, and runs the comparison, all shipped today. In the loop I design for a client, not shipped, it would also propose the regeneration. That is a lot of grunt work taken off a person.

But every step runs on deterministic data, and the engineer has the final say. The verifier does not auto-approve. The fix step does not silently rewrite production. A clean diff is a signal to a human, not a green light to merge. The model never gets to decide that a value is correct. It only gets to act on values that were read, never guessed.

This is the part that makes the loop safe to even consider closing. A feedback loop built on a probabilistic engine that guesses is a machine for amplifying that 1% catastrophe. Every pass through the loop is another chance to invent a value, and the loop runs until something looks clean, which means it will happily converge on plausible fiction and call it done. A feedback loop built on deterministic extraction with RULE ZERO has nothing to amplify, because there is no guess anywhere in the data path. The engineer reviews honest output, not plausible fiction.

This is why I will not sell a loop on top of a screenshot pipeline. It is not a smaller version of the same thing. It is the opposite thing. Automating a process that guesses does not save time, it scales the cost of the guesses and buries them deeper. The only loop worth closing is one where every value in motion was read, not imagined.

That is not a limitation I am apologizing for. It is the reason the whole thing works.

The method is public. The system is the offer.

Here is the commercial framing, plainly.

The two public halves are the method, and they are education. sdet-figma-kit and qa-pack are both real, both tested, both open. Clone them and run them today. Generate with one, verify with the other. You will see the discipline working on your own designs, in your own stack, without me in the room. That is deliberate. The method should stand on its own.

What I sell is the system the method enables. The full generate-verify-fix loop, wired into a real pipeline, tuned to your tokens and your framework, with the fix step built and the human review gate placed where your team actually wants it. That is the part that does not come in a repo, because it only makes sense built around one team’s reality.

If you want the public halves, they are public, link in the first comment. Take them.

If you want the closed loop in production, that is the work I do. Let us talk.

sdet.it/services

Series wrap

Three parts, one idea.

The data layer is where design-to-code breaks, so the fix is to never let the model guess. Read exact values from the design, enforce RULE ZERO, and a property the design never specified can never appear in the output. That single core does two jobs, generate and verify, and both are honest for the same reason: nothing in the pipeline ever guessed.

Everything I claimed is built sits in two public repos you can run yourself. Everything I described as a loop is a roadmap I named as a roadmap. That distinction is the whole point of this series. A tool you can trust is one that tells you what it knows and stays silent about what it does not, and the same standard applies to the person describing the tool.

From the Field is what I actually build, what breaks, and what I learn. Real projects, real numbers, real bugs. No tutorials.