Cursor'ı Figma MCP ile neden kullanıyorum — ve neden hâlâ kabloyla iPhone'da test ediyorum

"AI destekli frontend" eskiden bir ekran görüntüsünü sohbete yapıştırıp yakın ama hiçbir zaman tam doğru boşluğa, tam doğru griye, tam doğru satır yüksekliğine sahip olmayan bir CSS almak demekti. Model Context Protocol tam da tasarım devrinin bu kısmını değiştirdi. Cursor, Figma'nın MCP sunucusuyla konuşuyor ve bir çerçeveyi modelin tahmin etmesi için piksellere düzleştirmek yerine, gerçek node ağacını alıyor: auto-layout, boşluk değerleri, bağlı değişkenler, bileşen adları, tipografi ölçeği. Her gün gerçekten dayandığım kısım bu.

1. MCP'nin gerçekten doğru yaptığı şey

Figma'da bir çerçeve seçiyorum, bağlantıyı Cursor'a veriyorum ve o, MCP sunucusuna tam o node'u soruyor. Geri gelen şey yapılandırılmış: 8px'lik bir boşluk, bir PNG üzerinde cetvel aracıyla ölçtüğüm bir şey değil, gerçek 8 sayısı. Bir renk, tasarımcının bağladığı tasarım token'ı veya hex değeri, damlalıkla seçip tutmasını umduğum bir değer değil. Font ağırlığı, satır yüksekliği, köşe yarıçapı, gerçek bileşen hiyerarşisi — hepsi veri olarak geliyor, tersine mühendislik yaptığım bir görüntü olarak değil.

• Tahmin ettiğim en yakın yuvarlak sayı değil, tasarım sistemiyle eşleşen boşluklar.
• Renkler ve tipografi token olarak, böylece bir marka yenilemesi bileşenler arasında grep yerine tek bir değişkeni günceller.
• Tasarımcının öğeleri gerçekte nasıl gruplandırdığıyla eşleşen bileşen sınırları — bu da üretilen markup'ı semantik tutmayı kolaylaştırır.

3. Hâlâ elle kontrol ettiğim şey

Yapılandırılmış veri yargı değildir. Bir Figma çerçevesi tek seferde bir kesme noktası gösterir; Cursor'a 768px ile 1024px arasında ne olduğunu ya da tek satırlık yerine iki satırlık başlığı olan bir kartın nasıl göründüğünü söylemez. Boş durum, hata durumu, yükleme iskeleti yoktur, çünkü bunların hiçbirinin bir tasarım çerçevesi olmamıştır. Ve üretilen markup, çerçeveye yapısal olarak sadık kalırken bir button, nav veya başlık etiketinin olması gereken yerde bir div olarak kalabilir — birleştirmeden önce hâlâ her bileşeni anlam ve klavye erişimi için okuyorum.

3. Bir emülatörün neden yetmediği

Chrome DevTools'un cihaz çubuğu, yeniden boyutlandırılmış bir görünüm alanını render eden Chromium'dur. WebKit değildir, iOS Safari'nin dinamik görünüm alanı davranışına sahip değildir ve yalnızca gerçek motorda var olan hataları göstermez. Bu yüzden herhangi bir şey yayına girmeden önceki son adım, gerçek bir iPhone'u kabloyla Mac'ime bağlamaktır. Ayarlar → Safari → Gelişmiş → Web Denetçisi, telefonda bir kez açılır. Ardından Mac'e bir Lightning veya USB-C kablosu, Safari'nin Develop menüsü cihazı algılar ve gerçekten iOS Safari'de çalışan — simülasyonu değil — bir sayfaya bağlı canlı bir Web Denetçisi elde ederim: gerçek DOM, gerçek konsol, gerçek ağ paneli.

İşte tam orada bir emülatörün gizlediği hataları yakalıyorum: DevTools'ta iyi görünen ama gerçek telefonda çentiğin altında kırpılan safe-area-inset dolgusu, Safari'nin adres çubuğu kaydırmada daraldığında sıçrayan 100vh (dvh bunu düzeltir, ama bunu yalnızca canlı test kanıtlar), ekranda sabit bir alt bilgi varken klavye açıldığında giriş odağının sıçraması, tüm düzeni çeken lastik bandı fazla kaydırması ve sayfanın bağımsız bir PWA olarak ana ekrana eklendiğinde gerçekte nasıl davrandığı. Bunların hiçbiri bir emülatörde görünmez. Hepsi, gerçek bir müşteri bağlantıyı kendi telefonunda ilk kez açtığında görünür — bu yüzden önce ben görmeyi tercih ederim.

4. Neden özellikle Safari — gerçekten teslim ettiğim tarayıcı

Bir proje için "doğru"nun ne anlama geldiğine karar vermeden önce analitiklere bakarım. Yaptığım çoğu küçük işletme ve hizmet sitesi için, siteyi açan müşteri telefondadır, Instagram, Telegram, Google Haritalar veya bir metin mesajından gelir — ve bu trafiğin büyük bir kısmı için o telefon bir iPhone'dur. Masaüstü Chrome, geliştirdiğim yerdir. iOS Safari, kredi kartı olan kişinin gerçekten bulunduğu yerdir. Bütün gün baktığım tarayıcı için piksel mükemmelliğini optimize edip müşterimin müşterisinin gerçekten elinde tuttuğu tarayıcıyı atlamak, yanlış kitle için optimize etmektir.

Gerçek döngü

Figma çerçevesi, seçilip MCP aracılığıyla Cursor'a verilir. Tahmin edilen pikseller değil, gerçek token'lardan oluşturulan bileşen. Çerçevenin hiç göstermediği anlam, durumlar ve kesme noktaları için bir geçiş. Sonra iPhone çekmeceden çıkar, Mac'e takılır ve aynı sayfa Safari'nin Web Denetçisi'nde gerçek motor üzerinde canlı çalışır. Ancak ondan sonra bir şey birleştirilir. İki farklı araç, iki farklı görev: biri beni tasarıma hızla yaklaştırır, diğeri müşterimin müşterisinin gerçekten kullanacağı cihaz hakkında bana gerçeği söyler.

Müşterinizin elindeki telefonda gerçekten doğru görünmesini ister misiniz?

Her build'de çalıştırdığım hat bu: gerçek tasarım token'ları girer, gerçek cihaz çıkar. İletişim formundan yazın ve müşterilerinizin gerçekte hangi platformu kullandığını söyleyin — bana uygun tarayıcı için değil, tam olarak o platform için inşa edip test edeceğim.