Tasarımcılar için hazırlanan her yapay zekâ aracı listesinde on beş madde var. Benimkinde bir tane. Claude kullanıyorum ve yanına başka araçlar eklemek yerine onu zaten çalıştığım araçlara bağlıyorum. Bu bir sadelik tercihi değil — tek bir şeyi optimize edince ortaya çıkan sonuç: çıktının doğru olup olmadığını anlayabilir kalmak.
Bir ürün tasarımcısının kaç yapay zekâ aracına ihtiyacı var?
Listelerin önerdiğinden az. O derlemelerin çoğu aynı işi yapan ürünleri karşılaştırıyor — komuttan arayüz üretmek — ve karşılaştırma asıl önemli kısma hiç gelmiyor: beşinci turda, iş yarı yapılmışken ve biri devam edilip edilmeyeceğine karar vermek zorundayken ne oluyor?
Araç biriktirmenin görünmeyen bir maliyeti de var. Her birinin kendi bağlamı, projene dair kendi hafızası ve ne inşa ettiğine dair kendi fikri oluyor. Beş araç, beş yarım resim ve entegrasyonu elle yapan bir tasarımcı demek. Diğerlerine uzanabilen tek bir araç ise tek bir resim demek.
Gerçekte hangi aracı kullanıyorum?
Claude, üç biçimde; hangisini seçtiğimi işin ne kadarının gerçek dosyalara dokunması gerektiği belirliyor.
- Claude Code, bir projeyi değiştiren her şey için: dosya yazmak ve düzenlemek, komut çalıştırmak, sonucu tarayıcıda kontrol etmek. Bu sitenin blogu ve Türkçe sürümü bu şekilde yapıldı.
- claude.ai, tarayıcıdan, sesli düşünmek için — sentez, kurgu, metin, bir yönü hiçbir maliyeti yokken tartışmak.
- Masaüstü uygulaması, aynısı için, elimin altında.
Zaten çalıştığım araçların içine gömülü yapay zekâyı da, gerçekten en kısa yol olduğunda kullanıyorum. Yapmadığım şey, yanına ikinci bir genel amaçlı asistan eklemek.
Buradan başlamadım. Bu site aslında OpenAI'ın Codex'i ile kuruldu ve iş dosyalardan çok analiz ya da yazı olduğunda hâlâ ChatGPT'ye gidiyorum. O geçişi ayrıca yazdım.
Tek araç Figma'ya, GitHub'a ve Vercel'e nasıl bağlanıyor?
MCP — Model Context Protocol üzerinden. Bir yapay zekâ asistanının dış araçlara ve veri kaynaklarına tek bir ortak arayüzden bağlanmasını sağlayan açık bir standart. Pratikte asistanı, içine bir şeyler yapıştırdığın bir kutu olmaktan çıkarıp zaten kullandığın sistemlerde iş yapabilen bir şeye dönüştürüyor.
Benim kurulumum küçük ve sıkıcı, ki mesele de bu:
- MCP üzerinden Figma ve Sketch, böylece tasarım işi ve onun hakkındaki konuşma tek bir bağlamı paylaşıyor; ekran görüntüsü alıp yapıştırarak gidip gelmiyor.
- GitHub, böylece değişiklikler bir dalda, kendini açıklayan bir mesajla gerçek commit olarak duruyor; yerine kopyalanmış dosyalar olarak değil.
- Vercel, böylece bir dal, üretime hiçbir şey ulaşmadan önce telefonda açabileceğim bir preview'a dönüşüyor.
Sonuç şu: yayınlamak, en sonda gelen ayrı bir el işi olmaktan çıkıyor. Bir değişikliği tarif ediyorum, commit oluyor, commit preview oluyor, ben de preview'a bakıyorum. Yolun tamamı tek bağlamlı tek bir konuşma.
Bu, gerçek bir projede nasıl görünüyor?
İki örnek; ikisi de gerçek, hataları dahil.
Bu site. Elle yazılmış statik bir site — framework yok, build adımı yok. Blog, Türkçe karşılığı ve bunların üstündeki arama çalışmaları hep bu döngüde yapıldı: değiştir, commit'le, preview al, telefonda bak, yanlış olanı düzelt. İşe yarayan ayrıntı hız değil. Her adımın doğrulanabilir olması — bir şey yanlış render edildiğinde birinin sözüne güvenmek yerine görebiliyor olmam.
Çok paketli bir mobil ürün. Tek başıma geliştirdiğim bir prototip: Expo üzerinde React Native uygulaması, Next.js panel ve tasarım sistemi, tipler ve doğrulama için ortak paketler. Sabit veriyle çalışıyor, yayınlanmış bir ürün değil. Burada önemli olan ne yaptığı değil — işin birbiriyle tutarlı kalması gereken dört pakete yayılması ve birinde yapılan değişikliğin genelde üçünde birden değişiklik olması. Araç bütün depoyu görebildiğinde tek bir kişi bunu kafasında tutabiliyor. Araç yalnızca yapıştırılmış bir dosyayı gördüğünde tutamıyor. Asistanı projenin yanında sohbet ettirmek yerine projeye bağlamanın bütün gerekçesi bu fark.
Çıktının neden doğru olduğunu söyleyemiyorsam bir şey tasarlamış olmuyorum. Sadece bir şeyi onaylamış oluyorum.
Nerede işe yaramaz hale geliyor?
Cevabı kontrol edemeyeceğim her yerde. Sınır tam olarak bu ve bu konuda açık olmakta fayda var.
Problem seçimi bende kalıyor. Bir model seçenekleri bir ölçüte göre sıralayabilir; ama o ölçütün yanlış olduğunu söyleyemez, çünkü kullanıcılarla tanışmadı, giden müşteriyi kaybetmedi ve gerçek kısıtın bir kez söylenip hiç yazılmadığı toplantıda yoktu.
Ödünleşmeler bende kalıyor, çünkü kayda değer her tasarım kararının bir bedeli var ve neyi harcayacağını seçmek işin ta kendisi. Kapanış kararı da öyle: yayına çıkan şeyden birinin sorumlu olması gerekiyor ve "onu model üretti" hiçbir zaman kimsenin kabul ettiği bir cevap olmadı.
Adını koymaya değer bir hata biçimi de var. Üretilen iş, tam da en zayıf olduğu yerlerde kendinden emin — gerçek alan kurallarına sahip bir akış makul ama yanlış dönüyor ki bu, bariz şekilde bozuk dönmekten daha tehlikeli.
Bir şeyi devretmeden önce uyguladığım ölçüt
Tek bir soru: bu yanlış dönerse, yanlış olduğunu anlayabilecek miyim?
Cevabın evet olduğu yerlerde — ezbere bildiğim bir akış, okuyabildiğim bir işaretleme, kulağımla duyduğum bir metin — araç gerçekten zaman kazandırıyor. Cevabın hayır olduğu yerlerde hız bir kazanç değil; daha erken ve daha özgüvenli yanılmanın bir yolu. Bu ölçütün ekranımda hangi ürünün açık olduğuyla ilgisi yok; araçların sürekli değişip iş bölümünün değişmemesinin sebebi de bu.
Sonraki yazılar
