私たちはまた「Dreamweaverの過ち」を繰り返そうとしている

AIは、デザインが再びコードを支配する状況を作り出そうとしている。

20年もの間、私たちはこれらの役割を分離するために努めてきました。デザイナーはデザインし、デベロッパーは構築する。その間、人間が架け橋として機能してきました。

AIはこれを変えます。モデルにデザインファイルを読み込ませれば、コンポーネントが生成されます。デザインが再びコードを駆動するのです。

これは効率的に聞こえますが、リスクを孕んでいます。

かつてのDreamweaverの時代には、中央に人間がいました。その人間が品質を担保していました。しかしAIの場合、誰もハンドルを握ることなく、デザインが直接コードへと変換されてしまいます。

理解しておくべきことが2つあります。

  • デザインファイルはデザインシステムではありません。ファイルは「見た目」で判断されますが、システムは「再利用性」「耐久性」「状態（ステート）」で判断されます。AIはこの境界線を曖昧にします。
  • AIは静的なサイトには適しています。単なるスナップショットが必要なだけなら、活用すればよいでしょう。問題は、カスタムCMSや動的なUIのような、再利用可能なシステムを構築しようとする時に始まります。

真の失敗は、細部に宿ります。

チームはしばしば、Figmaの変数名（variable names）に基づいてコードパイプラインを構築してしまいます。命名はデザイン上の選択ですが、AIはそれを厳格な「契約」に変えてしまいます。デザイナーが変数を一つリネームしただけで、パイプライン全体が壊れてしまうのです。

デザインは静的なスナップショットです。それはある状態の、ある一つの画面を示しているに過ぎません。以下のものは示されていません：

  • ローディング状態やエラー状態。
  • コンテンツ駆動型か、固定レイアウトか。
  • CMSがどのようにデータを供給するか。

そうしたコンテキストは、デザインファイルではなく、デベロッパーの頭の中に存在するのです。

業界のリーダーたちは、この問題の解決に取り組んでいます。GoogleはAIにより多くの構造を与えるためにDESIGN.mdをリリースしました。Fixelのようなツールは、コードをFigmaに対して検証することで、デザインの乖離（design drift）を防ぐのに役立ちます。

しかし、どんなに優れたツールにも限界があります。ピクセルやトークンを抽出することはできても、アーキテクチャ上の決定を下すことはできません。既存のコンポーネントを再利用すべきか、新しいものを構築すべきかを判断することはできないのです。

未来は「デザインがコードを駆動する」ことではありません。それは「中間領域」にあります。

私は、この中間領域には以下が必要だと考えています：

  • ビルド時の型定義されたCSS入力。
  • デザインを既存のシステムにどうマッピングするかをAIが提案すること。
  • 振る舞いや意味に関する最終決定をUXエンジニアが行うこと。

AIは、デザイナーに対してコードの品質への責任をより重く課すことになります。デザインがそのままコードになるため、変換プロセスを管理する者がいなくなってしまうからです。

UXエンジニアをプロセスから排除してはなりません。デザインとシステムの間のマッピングと契約を管理する人間が必要なのです。

AIの提案を受け入れるものと、自分たちで決定し続けるもの、その境界線をどう決めますか？

出典: https://dev.to/slafleche/were-making-the-dreamweaver-mistake-again-on-purpose-this-time-ema