AIコーディングエージェントがUIを構築する際、デザインシステムに定義されたトークンではなく、もっともらしい値を捏造してしまう問題が広く認識されつつある。Hardik Pandya氏が公開した実践ガイドでは、この課題に対する4層のアプローチを提示している。
LLMが抱える根本的な制約は3つある。第一に「捏造」で、の代わりにのようなハードコードされた値を生成してしまう。第二に「セッション健忘」で、新しいセッションのたびにコンテキストがリセットされる。第三に「意図の不可視性」で、ソースコードからはAPIの使い方は分かるが、モーダルとインラインメッセージの使い分けやスペーシングの慣例といったデザイン哲学は読み取れない。
提案されている解決策は、スペックファイル、トークンレイヤー、監査スクリプト、ドリフト検知の4層構造である。スペックファイルは構造化されたMarkdownドキュメントとして、セッション開始時にLLMが参照する設計指針を提供する。トークンレイヤーは上流トークン、プロジェクトエイリアス、コンポーネント使用の3段階の間接参照をCSS変数で実装し、捏造値の余地を排除する。監査スクリプトはハードコードされた値を自動検出し、CIパイプラインに統合して準拠を強制する。
Atlassianのデザインシステム「Atlaskit」を対象としたテストでは、28ファイルにわたる418のハードコードされたCSS値をゼロ違反にまで削減し、230以上の名前付きトークンと64のスペックファイルを生成したと報告されている。
