Vibe Coding Dünün Haberiydi!

Müşterinizin mevcut design sistemine nasıl sadık kalabiliyorsunuz?

Ben sunumda yeni proje, sıfırdan kurulum senaryosunu anlattım. Ama haklısınız, çoğu projede zaten bir sistem var. Şöyle ayırmak lazım: Design Token Generation Skill'i biz yeni proje başlangıçları için kullanıyoruz. Mevcut, olgun bir design sistemi olan bir projede skill'i çalıştırıp her şeyi ezmiyoruz. Bu zaten yanlış olur.

Mevcut sistemi olan projelerde devreye giren başka tool'lar var: Design System Audit Skill mesela. O mevcut sisteme bakıp 'şu tokenlar standart dışı, şu isimlendirme tutarsız, şurada contrast problemi var' diye bir rapor çıkarıyor. Yani var olan sistemi yok saymıyor, denetliyor.

Skill'lerin agentic olmasının güzelliği de burada: skill'e 'bu projenin mevcut token yapısını oku, benim standardımla karşılaştır, sadece eksikleri tamamla' diyebiliyorum. Sıfırdan kurmak zorunda değil. Mevcut sisteme saygı duyup üstüne ekleme yapabiliyor.

Kısacası yeni projede kuruyoruz, mevcut projede denetliyor ve tamamlıyoruz.

LLM yapıları görsel kaynaklardan beslenebilir mi, yoksa sadece text-based mi olmalı?

İkisi de mümkün, ama bizim yaklaşımımız çoğunlukla text-based ve bu bilinçli bir tercih.

Şöyle: modern LLM'ler artık görsel okuyabiliyor, bir ekran görüntüsü verip 'bunu analiz et' diyebiliyorsunuz. Ama görselden beslenmek belirsizlik taşıyor. AI bir ekran görüntüsüne bakıp rengi tahmin ediyor, 'mavi tonlarında bir renk' diyor. Bu bizim için yeterince kesin değil.

Bu yüzden biz Figma MCP kullanıyoruz. MCP ile AI görsel tahmini yapmıyor; Figma dosyasının verisine doğrudan erişiyor. Rengin tam değeri, token'ın tam adı, component'ın gerçek property'leri. AI'ı doğrudan gerçek değerlerle besliyoruz.

Kısaca LLM görselden beslenebilir, ama hassasiyet gerektiren design system gibi bir işte biz yapısal, text-based veriyi tercih ediyoruz.

Tasarım sistemi oluşturmak için Codex mi kullandınız?

Evet, demoda Codex'i gösterdim ama aslında skill araçtan bağımsız çalışıyor, fark burada.

Skill dosyası Anthropic'in 'Agent Skills' spec'ine uygun. Bu da şu demek: Claude Code'da da çalışıyor, Codex'te de, Cursor'da da, Windsurf'te de. Skill desteği olan herhangi bir agentic ortamda aynı skill'i çağırabiliyorsunuz.

Aslında bu, sunumdaki ana fikirle de bağlantılı: tool değişiyor, yaklaşım kalıyor. Skill'i bir araca bağımlı yazmadık. Bu yüzden süreç içerisinde hangi araç öne geçerse onunla çalışmaya devam edebiliyoruz.

AI'ı tasarım süreçlerine katmak isteyen biri için öncelikle öğrenilmesi gereken keyword'ler nelerdir?

MCP (Model Context Protocol): AI'ın dış dünyayla, Figma'yla, Notion'la konuşmasını sağlayan şey. Bunu anlamadan agentic tarafına geçmek zor.

Skill: AI'a kalıcı beceri kazandırma yöntemi. Bir kez yazıyorsun, sürekli kullanıyorsun.

Agent / agentic: Agent, belirli bir hedef için çevresini anlayıp karar alabilen ve aksiyon üretebilen yapı; agentic ise bu yapının daha otonom, amaç odaklı, plan yapabilen ve gerektiğinde araç kullanarak ilerleyebilen çalışma biçimi.

Context / context window: AI'a ne kadar bilgi verebileceğin, neyi hatırladığı. Prompt yazarken bunu anlamak önemli.

Ama en önemlisi bir keyword değil: prompt yazma disiplini. Net, yapılandırılmış istek yazmayı öğrenmek, herhangi bir spesifik tool'dan daha kalıcı bir beceri.

Pratik tavsiyem: bir LLM aboneliği alın, günlük işinizden küçük bir problemi seçin, onu çözmeye çalışın. Kavramları teoride değil, problem çözerken öğrenmek çok daha hızlı olacak.

Skill ve AI kullanımını 75 kişilik ekibe nasıl öğrettiniz ve aynı çıktıyı nasıl sağladınız?

75 kişinin tamamına aynı anda öğretmedik. Öyle bir şey zaten gerçekçi değil.

Bizde şöyle ilerliyor: önce bir grup early adopter var, yeni bir şey çıktığında genellikle ilk onlar deniyor. Onlar olgunlaştırdıktan sonra ekibin geneline yayılıyor. İç dokümantasyon, kısa paylaşım oturumları, örnek kullanımlar vs. bu şekilde.

'Aynı çıktı' kısmı ise işin en güzel tarafı, çünkü onu insanlar sağlamıyor, skill sağlıyor. Düşünün, 75 kişiye 'şöyle bir token sistemi kurun' diye eğitim verseniz, 75 farklı yorum çıkar. Ama skill'i 75 kişi de çalıştırsa, çıktı aynı standartta olur. Çünkü kurallar skill'in içinde sabit.

Yani biz 'herkese aynı şeyi nasıl yaptırırız' problemini eğitimle değil, standardı araca gömerek çözdük. Eğitim, aracı kullanmayı öğretiyor; tutarlılığı aracın kendisi getiriyor.

Renk, font gibi parametreler dışında, markanın ruhunu nasıl adapte ediyorsunuz?

Haklı bir endişe. Token üretmek mekanik bir iş, ama marka ruhu mekanik değil.

Biz burada skill ile markanın ruhunu üretmiyoruz, ruhun altyapısını üretiyoruz. Yani renk skalası, spacing ritmi, tipografi hiyerarşisi vs. bunlar marka ruhunun taşıyıcı parçaları, ama ruhun kendisi değil.

Tüm bu token'ları nasıl kullanmak gerektiği tasarımcıya kalıyor. Marka ruhu dediğimiz şey mikro etkileşimlerde, hareket karakterinde, ton of voice'ta, boşluğun nasıl kullanıldığında bir bütün olarak ortaya çıkıyor. Ve bunlar hâlâ tasarımcının işi. Skill bize ilk birkaç günü geri veriyor; biz de o zamanı markanın gerçekten ayırt edici olan kısmına harcayabiliyoruz.

Yani skill markanın ruhunu adapte etmiyor; tasarımcıya bunun üzerinde çalışacak daha fazla zaman ortaya çıkarıyor. İşin mekanik kısmını o alıyor, yaratıcı kısmı bize kalıyor.

Terminal zorluğundan bahsettiniz. React'a karar verme süreciniz nasıl oldu?

Açıkçası React'a 'oturup karar verdik' demek doğru olmaz. Daha çok süreç bizi oraya götürdü. Biz Figma'daki ekranları çalışan bir deneyime dönüştürmeye başladığımızda, kullandığımız AI araçlarının en rahat, en tutarlı ürettiği yer React ekosistemiydi. React Native ile birlikte Expo üzerinden projenin kolayca paylaşılabilmesi de bizim için bir artı oldu. Yine şirket içerisinde React kullandığımız altyapılardan birisi; gerektiğinde destek alabilecek olmamız da önemliydi. Yani teknik tercihi baştan biz yapmadık; AI araçlarıyla en az sürtünmeyle ilerlediğimiz yer neresiyse oraya yöneldik.

Bence buradaki asıl nokta şu: terminal olsun, framework seçimi olsun, bunlar eskiden 'tasarımcının işi değil' dediğimiz şeylerdi. Ama çalışan ürüne kadar ilerlemeye başlayınca bu kararlar da masamıza geldi. Biz de tek tek uzmanı olmaya çalışmak yerine, AI'a danışarak, dev ekiple yakın çalışarak ilerledik. Yani teknik kararı tek başımıza vermiyoruz ama artık o konuşmanın içindeyiz. Eskiden değildik.

Design system çok yaygınlaştığında yanlış bir müdahale olursa, hata için bir planınız var mı?

Bizde tek bir merkezi, paylaşılan tasarım sistemi yok. Her projenin token sistemi kendi içinde, kendi dosyasında bağımsız bir kütüphane olarak yaşıyor. Ortak olan şey sistem değil, kurallar. Skill bütün projelere aynı kuralları, aynı standartları taşıyor; ama her proje kendi ayrı kopyasında çalışıyor. Bunun sonucu öncelikle şu: bir projede yanlış bir müdahale olursa, o hata o projede kalıyor.

Bu durum genelde kullanıcıların yeni bir component'a ihtiyacı olduğunda ya da mevcut bir component'ı detach ederek kullanmak istediğinde ortaya çıkıyor. Bunu süreç içinde çok fazla engelleyemiyoruz. Buradaki yaklaşımımız, tasarım sisteminin düzenli bakımını yapmak ve projelerdeki arkadaşların düzenli review session'ları düzenlemesi yönünde. Böylece bu tür durumları çok ilerlemeden fark edip düzeltebiliyoruz.

Ayrıca UI ve UX review süreçlerimiz için kullandığımız skill'ler de var; onlar da bu tür hataları yakalıyor. Hataların daha fazla yayılmasının önüne bu şekilde geçebiliyoruz.

Her müşteri için ayrı skill mi oluşturuyorsunuz? Skill oluştururken çok gelgit oluyor mu?

Hayır, her müşteri için ayrı skill yok. Olsa zaten ölçeklenmezdi.

Tek bir Design Token Generation Skill var. İçinde Commencis'in genel kuralları, isimlendirme standartları, mimari kararları sabit duruyor. Müşteriye özel olan şey skill'in kendisi değil, ona verdiğimiz girdi: marka rengi, font, tema kapsamı. Skill aynı, girdi değişiyor.

Bu zaten skill'i seçmemizin sebebiydi: her müşteriye ayrı tool yazmak yerine, kuralı bir kez yazıp girdiyle özelleştiriyoruz.

'Gelgit' kısmına gelince, evet, skill'i geliştirirken çok iterasyon oldu. Şu an kullandığımız versiyon ilk versiyon değil, defalarca revize edildi. Her yanlış çıktı bir iyileştirme fırsatıydı. Ama bir kez oturduktan sonra kullanımda gelgit yok, istikrarlı çalışıyor. Yani gelgit geliştirme aşamasında, kullanım aşamasında değil.