Question. Does AI-generated component code reference a project's design tokens or hardcode the values, and does moving the tokens from pasted prompt context to a referenced file with an explicit usage rule change the share? Tokens keep style values in one governed place (Design Tokens Community Group, 2025), AI coding tools take persistent project rules (Cursor, 2026), and whether generated code respects either is usually asserted, not measured.
Test. One 26-token file in the DTCG 2025.10 format (colors, spacing, radii, typography), exposed as CSS custom properties under a stated naming convention. Ten component briefs, buttons to data table; two Claude models; two conditions: tokens pasted into the prompt as context with no instruction to use them, versus the file referenced plus a rule requiring token use. 40 isolated runs, preregistered and fully logged (Progressive Disclosure, 2026); scored by a deterministic script, manual check 8 of 8.
Observed difference. Adoption was near total either way. Pasted, no rule: 97.5 and 97.1 percent of scoreable style values resolved to tokens (pooled, per model), 14 of 20 runs fully clean. File plus rule: 20 of 20 runs at 100 percent, zero hardcoded values. Across 1291 token references, neither model invented a token name, inlined a token's raw value, or redefined the custom properties. All 17 hardcoded values sat where the token file had no answer: derived hover and active shades, a backdrop overlay, pixel nudges. The rule removed even those; hover shades became color-mix over tokens. Per-run condition difference: not significant (permutation p = 0.21 on both models, at ceiling).
Limit. Both conditions stated the custom-property naming convention; a bare token file with no mapping went untested and is the likelier failure mode. Single-file HTML and CSS components, two models in one agent harness; no claims about real codebases, other tools, or developer behavior.
Takeaway. Hardcoding was not the problem; coverage was. If generated components keep hardcoding, audit what the token file fails to define (state shades, overlays) before blaming the model. Then ship tokens as named custom properties with a one-line usage rule: that took the residue to zero here.
Experiment record (essentials)
Preregistered 2026-10-27 before the first model call (protocol.json, sha256 c60890c655fb6c8ed45f3e7345d6b201f1712eb8be7ffa50223060d531ba266a). Materials: one DTCG 2025.10 token file (9 colors, 6 spacing steps, 4 radii, 1 font family, 4 font sizes, 2 font weights), canonical custom-property names stated in both conditions; ten fixed component briefs. Conditions: 2 Claude models (harness aliases sonnet and haiku, Claude Agent SDK subagents, provider default sampling; exact snapshot IDs not exposed) x 2 token deliveries (pasted context without instruction; referenced file plus usage rule) x 10 briefs = 40 runs, one isolated subagent call each; 40 of 40 delivered, zero retries. Scoring: deterministic script over every CSS declaration in token-covered property families (colors, spacing, radii, typography; box-shadow, widths and line-height excluded as uncovered); token_share = valid token references over token references plus hardcoded units. Manual check on 8 runs: 8 of 8 agreed; four scoring clarifications logged (property-family variants, forced-colors system keywords excluded, var() fallbacks count as references, locally defined aliases resolving to tokens count as references). Results: pasted pooled share 97.46 percent (sonnet, 307 refs, 8 hardcoded) and 97.14 percent (haiku, 306 refs, 9 hardcoded); rule 100 percent on both (333 and 345 refs, 0 hardcoded). Invented token names: 0 in 40 runs. Hardcoded values exactly matching a token value: 0. :root redefinitions: 0. All 17 hardcoded units were off-palette state or overlay values. Exact permutation test on per-run shares, pasted vs rule: p = 0.2105 for each model. Raw outputs, prompts, protocol, scoring script and results stored alongside. No human participants; no claims about developer behavior.