Tasarım sistemi hep iki şeydi: bir bileşen kümesi ve o bileşenlerin ne zaman kullanılacağına dair bir anlatı. Anlatı Storybook sayfalarında, Notion'da, Figma açıklamalarında dururdu ve muhatabı insandı. Şimdi sistemi bir model okuyor ve iki yarı birbirinden ayrıldı. Makine bileşenleri alıyor, anlatıyı hiç görmüyor.

Model tasarım sisteminden ne görüyor?

Somut konuşalım. Figma'nın Dev Mode MCP sunucusu bir ajana yirmi dört araç açıyor. İkisi bu yazının konusu:

  • get_variable_defs, Figma'nın kendi tarifiyle "seçiminizde kullanılan değişkenleri ve stilleri" döndürüyor: renkler, boşluklar, tipografi.
  • get_code_connect_map, Figma düğümlerini kod tabanınızdaki bileşenlere eşliyor; bileşen adını, kaynak dosyayı ve snippet'i veriyor.

Sketch'in sunucusu da aynı şekli taşıyor: get_design_assets, get_libraries, get_symbol_overrides.

Listeye dikkatli bakın. Ajanın gördüğü şey isimler, değerler ve eşleşmeler. Kullanım kılavuzunuz orada yok. "Bu bileşeni yalnızca üç maddeden azsa kullan" diye düştüğünüz nota oradan erişilmiyor. Tasarım sistemini okunur kılan yüzey daraldı ve daralan yüzeyde ayakta kalan tek şey adlandırma.

Bir insanın tasarım sisteminden okuduğu uzun listenin yanında modelin okuduğu üç araç çağrısı
Soldaki sütun yazdığınız her şey. Sağdaki sütun sunucunun döndürdüğü her şey. Uydurma, aradaki boşlukta oluşuyor.

Bir token'ın adı neden birden önem kazandı?

Eskiden color-brand-500 yazmak bir zevk meselesiydi. Ad bir şey anlatmıyorsa insan yanındakine sorardı, Slack'e yazardı, bir örneğe bakardı. Modelin soracağı kimse yok. Onun için ad, talimatın kendisi.

color-brand-500 bir modele o rengin ne zaman kullanılacağını söylemez; yalnızca bir tonu adlandırır. color-action-primary-bg tam olarak söyler. Semantik isimlendirme yıllardır önerilen bir iyi uygulamaydı ve çoğu ekip bunu bir üslup tartışması gibi ele aldı. Artık üslup tartışması değil: adın taşımadığı her bilgi, çıktıda tahmine dönüşüyor.

Burada dürüst olalım. Yapay zekâ bu kuralı icat etmedi, yalnızca yanlış yapmanın bedelini görünür hâle getirdi.

Kapsam boşluğu eskiden tutarsızlık üretirdi. Şimdi uydurma üretiyor.

Sisteminizde boş durum bileşeni yoksa ne olurdu? Tasarımcı benzerini elle kurardı, gözden geçirmede fark edilirdi, bir sonraki sürümde sisteme girerdi. Kusur görünürdü.

Model aynı boşlukta başka türlü davranıyor. Sizin sisteminize benzeyen, sizin renklerinizi ve boşluklarınızı kullanan, ama kütüphanede karşılığı olmayan bir şey üretiyor. Sonuç bariz şekilde bozuk değil, makul. Gözden geçirmede yakalanması en zor olan da tam olarak makul olan.

Belgelenmemiş bileşen, model için var olmayan bileşendir

Kod tabanında duran ama kütüphaneye hiç girmemiş, Code Connect ile eşlenmemiş bir bileşen ajan için görünmez. Ajan onu atlamaz, yeniden kurar. Sonunda elinizde birincinin işini yapan ikinci bir bileşen olur.

İki yıl önce bu dikkatsizlikten olurdu. Şimdi sistemin kendini göstermemesinden oluyor. Kapsam, hoş bir metrik olmaktan çıkıp görünürlük meselesine dönüştü: sistemin dışarıya açmadığı her şey yeniden icat ediliyor.

Yani tasarım sistemi bir prompt mu?

Tam olarak değil ve bu farkı korumakta fayda var. Prompt sizin yazdığınız şeydir; tasarım sistemi modelin çağırdığı şey. Biri talimat, öteki kaynak.

Ama işlevi bakımından prompt'un durduğu yerde duruyor: çıktıyı sınırlayan bağlam artık o. Bu da tasarım sistemi işini kısmen bağlam mühendisliğine çeviriyor — modelin neyi, hangi kelimelerle görebildiğine karar vermek.

Bir token'ın adı artık bir tercih değil, bir talimat.

Tasarımcı ne yapmalı?

  • Semantik isimlendirme artık üslup değil, işlev. brand-500 bir tonun adı; action-primary-bg bir kararın adı. İkincisini yazdığınızda kararı siz veriyorsunuz, birincisinde model sizin yerinize veriyor.
  • Kapsam, görünürlük demek. Kütüphanede olmayan, eşlenmemiş ya da açıklaması boş bırakılmış her bileşen sıfırdan yeniden üretilecek. Kapsamı "yüzde kaçı hazır" diye değil, "ajan neyi görebiliyor" diye ölçün.
  • Gerekçeyi makinenin ulaşabildiği yere koyun. Bileşen ve değişken açıklamaları MCP sunucusunun döndürdüğü alanlar; doküman siteniz ise ajanın hiç açmadığı bir yer. Kuralı ikisine birden yazın.

Sistem artık yapım sürecinin parçası

Tasarım sistemi, ürün hakkında yazılmış bir doküman olmaktan çıkıp ürünün nasıl yapıldığının parçası hâline geldi. Bu, insanlar için yazmayı bırakmamız gerektiği anlamına gelmiyor; yalnızca tek okuyucunun onlar olmadığı anlamına geliyor.

Bir sistemin gerçekte ne söylediğini, onu ilk kez okuyan birine bakarak anlarsınız. Model tam olarak öyle bir okuyucu: bağlamı yok, sorusu yok ve yalnızca yazdığınız kadarını biliyor.

Sonraki yazılar

Halil Eren Çelik

Halil Eren Çelik

Lead Product Designer · AI-Native Product Creation

On beş yıldır karmaşık gereksinimleri insanların gerçekten kullanabildiği ürünlere çeviriyor; son dönemde yapay zekâyı rakip değil ortak olarak kullanıyor. Hobi olarak fotoğraf çekiyor.