Tasarım handoff'u, dijital ürün geliştirmenin en pahalı ritüelidir ve çoğu ekip bu maliyeti ölçmeye bile kalkmaz. Bir tasarımcı bir ekranı haftalarca cilalar. Bir mühendisin eline bir Figma linki, bir Slack mesajı ve bir teslim tarihi geçer. Altı hafta sonra yayına çıkan şey tasarıma, fotokopinin fotokopisi aslına ne kadar benziyorsa o kadar benzer.

Things olarak sekiz yıldır tasarım ve mühendisliğin kelimenin tam anlamıyla aynı masada oturduğu ürünler geliştiriyoruz. 2018'den bu yana İstanbul ve Elazığ'daki stüdyomuz, Türkiye'nin ve dünyanın önde gelen markaları için elliden fazla ürünü yayına aldı ve duruşumuz hep basit oldu: tasarladığımızı hayata geçiririz. Son iki yılda yapay zeka bunu nasıl yaptığımızı değiştirdi. Handoff'un yerine sihirli bir değnek koyarak değil, tasarım niyetinin eskiden yok olup gittiği boşlukları ortadan kaldırarak.

Bu yazı, yapay zeka ile tasarımdan koda sürecinin gerçekte nasıl işlediğini anlatıyor: araçların neyi iyi yaptığını, nerede yetersiz kaldığını ve kazanan ekiplerin neden yapay zekayı tek bir birim gibi çalışan tasarımcı ve mühendislerle bir araya getireceğini.

Geleneksel tasarım handoff'u neden başarısız olur?

Geleneksel handoff başarısız olur, çünkü farklı diller konuşan iki kişi arasında, kimsenin baştan sona okumadığı çıktılar aracılığıyla yürütülen bir çeviri alıştırmasıdır. Tasarım niyeti zengindir: boşluk ritmi, hareket, durum mantığı, ton. Handoff çıktıları ise sığdır. Çeviride hayatta kalamayan her şey bir hataya, bir tavize ya da bir kavgaya dönüşür.

Bu başarısızlık, kendini tekrar eden üç örüntüde ortaya çıkar:

Kaybolan niyet

Statik bir mockup, tasarımcının aslında verdiği kararların belki üçte birini yakalar. Liste boşken ne olur? İsim 47 karakter uzunluğundaysa? İstek başarısız olursa? Kullanıcı 320px'lik bir ekrandaysa? Tasarımcılar bu soruların cevaplarını kafalarında taşır. Bu cevaplar mühendisin kullandığı bir çıktıya hiç yansımazsa mühendis kendi cevaplarını uydurur; genellikle teslim tarihi baskısı altında ve genellikle tasarımcının yapacağından farklı biçimde.

Spesifikasyon kayması

Tasarım, handoff'tan sonra değişir. Her zaman değişir. Paydaş geri bildirimleri gelir, yasal bir gereklilik ortaya çıkar, tasarımcı bir akışı iyileştirir. Artık iki doğruluk kaynağı vardır (Figma dosyası ve kod tabanı) ve bu ikisi her sprintte birbirinden biraz daha uzaklaşır. Altı ay sonra hangisinin doğru olduğunu kimse söyleyemez.

Kimsenin okumadığı redline'lar

Açıklamalı spesifikasyonlar, boşluk katmanları, padding değerlerini dışa aktaran handoff eklentileri: Bunların hepsi, ekipler niyetin kaybolduğunu bildiği için var. Ne var ki 40 sayfalık bir spesifikasyon dokümanı, yazılan ama okunmayan bir mecradır. Mühendisler ona bir kez göz gezdirir, sonra görsele bakarak çalışır. Redline'lara harcanan emek büyük ölçüde törenseldir: Ürünü korumaktan çok, tasarımcının "spesifikasyonda vardı" diyebilmesini korur.

Üçünün altında yatan kök neden şu: Handoff, tasarım ve mühendisliğin ayrı taraflarca yürütülen ardışık aşamalar olduğunu varsayar. Bu taraflar arasındaki her boşluk, ürünün sessizce kalite kaybettiği bir noktadır.

Yapay zeka tasarımdan koda sürecinde gerçekte neyi değiştiriyor?

Yapay zeka çevirinin ekonomisini değiştiriyor. Eskiden handoff'u pahalı kılan iş, yani görsel ve yazılı niyeti çalışan frontend koduna dönüştürmek, artık büyük ölçüde otomatikleştirilebiliyor; yeter ki yapay zekayı doğru girdilerle besleyin. Burada en çok önem taşıyan dört değişim var.

Ajan tabanlı kodlama araçları

Claude Code gibi araçlar yalnızca satır tamamlamakla kalmaz. Bir kod tabanını okur, projenin kurallarına uyar, birden fazla dosyayı kapsayan değişiklikleri planlar, build'i çalıştırır ve yineleyerek ilerler. Ajan tabanlı bir aracı iyi dokümante edilmiş bir bileşen kütüphanesine ve bir ekranın net bir tanımına yönlendirin; dakikalar içinde çalışan ve proje kurallarına uyan bir implementasyon çıkarabilir. Mühendisin rolü, satır satır yazan kişi olmaktan çıkıp gözden geçiren ve mimariyi kuran kişi olmaya kayar.

Doğruluk kaynağı olarak design token'lar

Yapay zekanın ürettiği kod, ancak girdileri kadar tutarlıdır. Design token'lar (adlandırılmış değişkenler olarak ifade edilen renkler, tipografi ölçekleri, boşluklar, köşe yarıçapları, yükselti ve hareket değerleri), yapay zekaya tasarım sistemiyle birebir örtüşen bir kelime dağarcığı sunar. Token'lar tek doğruluk kaynağı olduğunda "kart, yükseltilmiş yüzey stilini kullansın" talebi hem Figma'da hem de kod tabanında surface-raised karşılığına çözümlenir. Yapay zeka asla kafasından bir hex kodu uydurmaz; tasarım değişiklikleri de ekibe yeniden brief vererek değil, bir token'ı güncelleyerek yayılır.

Yapay zekanın okuduğu markdown tasarım dokümanları

Sessiz devrim tam olarak bu. Ajan tabanlı araçlar, düz metin dokümantasyonu çalışma bağlamlarının bir parçası olarak okur. Bu yüzden tasarım niyetini (bileşen davranışı, durumlar, uç durumlar, içerik kuralları, erişilebilirlik gereksinimleri) kod deposunda kodun hemen yanında duran markdown dosyaları olarak yazıyoruz. "Kimsenin okumadığı spesifikasyon", yapay zekanın her görevde her zaman okuduğu spesifikasyona dönüşüyor. Bir tasarımcı dokümanı güncellediğinde, yapay zeka destekli bir sonraki değişiklik bunu otomatik olarak dikkate alıyor. Dokümantasyon bir tören olmaktan çıkıp altyapıya dönüşüyor.

Figma'dan koda araçları

Figma'nın API'leri, Dev Mode ve MCP tarzı entegrasyonlar artık kodlama ajanlarının gerçek tasarım dosyalarını incelemesine olanak tanıyor: birebir yerleşim yapısı, token bağlantıları, varyantlar ve bileşen özellikleri. Bir mühendisin ekran görüntüsüne bakıp göz kararı çalışması yerine ajan, tasarımcının oluşturduğu yapılandırılmış verinin aynısını okuyor. Ham, tek tıkla "koda aktar" çıktısı hâlâ çöpe gidecek bir markup üretiyor; ama Figma verisi artı ajan tabanlı bir araç artı mevcut bir bileşen kütüphanesi bambaşka bir denklem: ajan piksellerden div üretmek yerine tasarım bileşenlerini kod bileşenleriyle eşleştiriyor.

Yapay zekanın ürettiği frontend kodu gerçekten yayına alınacak kadar iyi mi?

Doğru kurulumla yapay zeka, iyi tanımlanmış işler için canlı ortam kalitesinde frontend üretir; mimari, muhakeme ve son yüzde on için ise hâlâ insan mühendislere ihtiyaç duyar. Bu sınır konusunda dürüst olmak, ürünü yayına çıkaran ekipleri demo yapan ekiplerden ayıran şeydir.

Yapay zekanın ürettiği frontend'in bugün gerçekten güçlü olduğu alanlar:

  • Mevcut, token odaklı bir bileşen kütüphanesiyle ekranları kodlamak
  • Responsive yerleşim, standart etkileşim durumları ve form yönetimi
  • Kod tabanı genelinde tutarlılık için refactoring
  • Okuduğu dokümanlarda açıkça istendiğinde erişilebilirliğin temelleri (semantik markup, odak sırası, ARIA)
  • Tasarım spesifikasyonu ile implementasyon arasındaki kaymayı yakalamak

İnsan mühendislerin devreye girdiği alanlar:

  • Mimari. Veri akışı, state yönetimi, önbellekleme, API sözleşmeleri, performans bütçeleri. Yapay zeka bir mimarinin içinde çalışır; o mimariyi deneyimli mühendisler tanımlar.
  • Son yüzde on. Doğru hissettiren easing eğrileri, gerçek cihazlarda kaydırma davranışı, klavye tuzakları, "incelemeden geçer" ile "özenle işlenmiş hissettirir" arasındaki fark. Bu, koda uygulanan zevktir ve hâlâ insan işidir.
  • Yeni örüntüler. Bir ürün, bileşen kütüphanesinde bulunmayan bir etkileşime ihtiyaç duyduğunda birinin onu bilinçli olarak tasarlayıp inşa etmesi gerekir.
  • İnceleme ve sorumluluk. Things'te yapay zekanın yazdığı her satır, bir mühendisin adıyla yayına çıkar. Yapay zeka hızlandırır; sorumluluğu ortadan kaldırmaz.

Yapay zekayı, dokümantasyonunuzu eksiksiz hatırlayan ve revizyonlar konusunda hiç egosu olmayan, çok hızlı bir orta seviye geliştirici olarak düşünün. Kıdemli insanlar yönlendirdiği sürece bu, olağanüstü bir ekip arkadaşıdır.

Yapay zeka çağında tasarım ve mühendisliğin aynı çatı altında olması neden hâlâ önemli?

Çünkü yapay zeka çevirinin maliyetini ortadan kaldırıyor, ortak niyete duyulan ihtiyacı değil. Tasarlayıp dosyaları duvarın üzerinden dış kaynaklı bir yazılım ekibine fırlatan bir ajans artık bunları daha hızlı fırlatabilir; ama boşluklar yerinde durur, çünkü iki taraf hâlâ ne bağlamı ne terminolojiyi ne de sorumluluğu paylaşır.

Tasarımcılar ve mühendisler tek bir stüdyoda çalıştığında, yapay zeka çağının avantajları katlanarak büyür:

  1. Token'lar gerçektir. Token mimarisinin tasarımına mühendisler de katkıda bulunur; böylece mimari, handoff'tan sonra yamanmak yerine ilk günden itibaren koda temiz biçimde karşılık gelir.
  2. Dokümanlar iki okuyucu için yazılır. Things'teki tasarım dokümanları, hem bir mühendisin hem de bir yapay zeka ajanının onları okuyacağı bilinerek yazılır. Bu disiplin onları kesin ve net kılar.
  3. Geri bildirim döngüleri sprintlerde değil, saatler içinde kapanır. Yapay zeka bir ekranı yirmi dakikada oluşturduğunda darboğaz incelemeye kayar. Mühendisin yanında oturan bir tasarımcı build'i aynı öğleden sonra inceler ve kayma birikmeden rotayı düzeltir.
  4. Sonucun tek bir sahibi vardır. "Tasarım şunu dedi / yazılım bunu dedi" diye bir şey yoktur. Tasarladığımızı hayata geçiririz, çünkü ikisinden de aynı ekip sorumludur.

Kendimize ajans değil stüdyo dememizin nedeni bu. Ajanslar işi devreder. Stüdyolar hayata geçirir.

Yapay zeka destekli, pratik bir tasarımdan koda iş akışı neye benzer?

Token'larla başlayın, niyeti markdown olarak yazın, ajanların bileşen kütüphanenizi temel alarak implementasyon yapmasına izin verin ve incelemeyi tasarımcıları sürece dahil ederek yapın. Her ekibin benimseyebileceği iş akışı şöyle:

  1. Design token'ları tek doğruluk kaynağı olarak belirleyin. Onları Figma değişkenlerinde tanımlayın ve koda aktarın (Style Dictionary ya da benzeri bir araçla). İki tarafta da sabit kodlanmış değer olmasın.
  2. Bileşen kütüphanenizi oluşturun ya da denetleyin. Yapay zekanın ürettiği ekranlar, bir araya getirdiği bileşenler kadar iyidir. Her bileşenin prop'larını, varyantlarını ve durumlarını dokümante edin.
  3. Tasarım dokümanlarını markdown olarak, kod deposunda yazın. Her özellik için: amaç, durumlar, uç durumlar, içerik kuralları, erişilebilirlik gereksinimleri, responsive davranış. Kısa ve güncel tutun; bunlar evrak işi değil, yapay zekanın bağlamıdır.
  4. Tasarım dosyanızı kodlama ajanınıza bağlayın. Figma'nın yapılandırılmış verisini (Dev Mode, MCP entegrasyonları) kullanın ki ajan, ekran görüntülerinden tahmin yürütmek yerine yerleşimi ve token bağlantılarını okusun.
  5. Ajana, kıdemli bir mühendisin orta seviye bir mühendise brief verdiği gibi brief verin. Dokümana, bileşenlere ve kabul kriterlerine atıfta bulunun. Küçük, incelenebilir görevler "uygulamayı yap" talimatından daha iyi sonuç verir.
  6. İkili olarak inceleyin. Mühendis kodu inceler; tasarımcı build'i inceler. Aynı gün. Sistemin öğrenmesi için her sapmayı tasarım dokümanına geri işleyin.
  7. Kaymayı bir hata olarak ele alın. Tasarım ve kod birbirinden ayrıştığında yalnızca belirtiyi değil, doğruluk kaynağını (token'ları ya da dokümanı) düzeltin.

Things bu süreci gerçek projelerde nasıl yürütüyor?

Things'te her ürün ekibi ilk günden itibaren bir tasarımcı-mühendis ikilisidir. Bu, yapay zekadan çok önce, 2018'den beri böyle. Değişen şey, ikisini birbirine bağlayan doku. Tasarım sistemlerimiz token öncelikli ve doğrudan her kod tabanına aktarılıyor. Tasarım niyeti, kod deposunda markdown olarak, tarif ettiği kodla birlikte versiyonlanarak yaşıyor. Claude Code gibi ajan tabanlı araçlar bu dokümanları bağlamında tutarak bileşen kütüphanelerimiz üzerinde implementasyon yapıyor; mühendislerimiz de her build'i inceliyor, sağlamlaştırıyor ve tamamlıyor. Tasarımcılarımız bir tasarım kararından birkaç saat sonra çalışan yazılımı görüyor. Bu da bize Red Dot ödülü kazandıran araştırma odaklı titizliğin web, native ve hibrit mobilde canlı ortama kadar korunması anlamına geliyor.

Sonuç daha az insan değil. Aynı kıdemli insanların zamanlarını çeviriye değil muhakemeye, zanaata ve ürün düşüncesine harcaması. Design. Code. Mastery. Ve nihayet ilk ikisi arasındaki boşluk kapandı.

Sıkça Sorulan Sorular

Yapay zeka Figma tasarımlarını doğrudan canlıya hazır koda dönüştürebilir mi? Doğrudan ve körü körüne, hayır; ham dışa aktarımlar bakımı yapılamayan markup üretir. Ancak Figma'nın yapılandırılmış verisini okuyan ve bunu mevcut, token odaklı bileşen kütüphanenizle eşleştiren ajan tabanlı bir kodlama aracı, mühendislerin inceleyip tamamladığı, canlı ortam kalitesinde implementasyonlar üretebilir.

Yapay zeka frontend geliştiricilerin yerini alacak mı? Hayır. Yapay zeka, frontend işindeki çeviri emeğinin yerini alır. Mimari, performans, yeni etkileşimler, erişilebilirlik konusundaki muhakeme ve zanaatın son katmanı insanın sorumluluğunda kalır; yapay zeka çıktısını iyi incelemek de tam olarak bu kıdemi gerektirir.

Yapay zeka destekli tasarımdan koda sürecini benimsemeden önce neyin hazır olması gerekir? Üç şey: Figma ile kod arasında paylaşılan design token'lar, dokümante edilmiş bir bileşen kütüphanesi ve yapay zekanın okuyabileceği yazılı tasarım dokümanları. Bunlar olmadan yapay zeka, yüksek hızda makul görünen bir tutarsızlık üretir.

Design token'lar yapay zeka ile kod üretimine nasıl yardımcı olur? Token'lar yapay zekaya tasarım sisteminizle örtüşen kapalı bir kelime dağarcığı verir; böylece yapay zeka keyfi değerler uydurmak yerine sistemdeki adlandırılmış değerlere başvurur. Tasarım değişiklikleri de ekranları yeniden yazarak değil, token'ları güncelleyerek yayılır.

Yapay zekanın ürettiği frontend erişilebilir mi? Okuduğu dokümanlarda gereksinimler açıkça belirtildiğinde erişilebilirliğin temellerini karşılayabilir; ancak erişilebilirlik insanlar tarafından tanımlanmalı, test edilmeli ve incelenmelidir. Bu bir model özelliği değil, bir iş akışı disiplinidir.

Tasarladığınızı hayata geçirin

Ürününüz Figma dosyası ile yayın build'i arasında hâlâ bir şeyler kaybediyorsa sorun tasarımcılarınızda ya da mühendislerinizde değil. Sorun, ikisinin arasındaki boşlukta. Biz kendi boşluğumuzu kapattık. Sizinkini kapatmanıza da yardımcı olabiliriz.

Things ile konuşun: ajans değil, Türkiye'de ve dünyada markalar için yapay zeka destekli tasarım ve mühendislik yapan bir stüdyo. Bize hello@things.ist adresinden yazın ya da things.com.tr adresini ziyaret edin.