デザインシステムはバージョニングやセマンティックな命名などソフトウェア開発の慣行を取り込んできた。次に取り込むべきはLLM開発のevalsだ、という主張。AGENTS.mdをどれだけ丁寧に書いても、エージェントが本当にライブラリのコンポーネントを使ったのか、手書きのdivで済ませたのかは分からない。研究でも、最高性能のモデルですら指示の3分の1も完全には守れず、指示が長くなるほど遵守率は下がる。
提案されているのは、エージェントに任せたい仕事をプロンプトのリストとして列挙し、それぞれに2種類のチェックを付ける形。機械的チェックはpropsがコンポーネントAPIに存在するか、色や余白がトークンに解決されるか、ボタンにアクセシブルな名前があるかを検証する。containsやregexの浅いアサーションではなく、自分のシステムを知っているカスタム検証を書くのがポイントで、でっち上げられたpropsや生のhex値を捕まえられる。判断が要るチェック、たとえば汎用モーダルではなく確認ダイアログを選べているかは、llm-rubricで別のLLMに採点させる。
このスイートをCIに置くと、propsをリネームしたときに古い名前を出力するプロンプトが検出され、Code Connectのマッピングを更新するまでPRがマージできなくなる。問題が3スプリント後ではなくその場で見つかる。事例としてIntuitのデザインシステムでは、8エージェントのパイプラインに評価ステージを組み込み、生成コンポーネントのトークンとアクセシビリティを検査している。ツール面ではpromptfooやMetaがオープンソース化したAstryxが挙がる。
evalsは人間のレビューを無くすものではなく、機械的な失敗を先に潰して人間が見る範囲を狭める道具だという整理も実務的。チェンジログと同じように、デザインシステムがリグレッションスイートを備えるのが当たり前になるべきだと締めている。
