Figma’dan Koda: “Vibe Coding” Gerçekten Başladı mı?

Bir ürün ekibinin en pahalı “boşluğu” nerede oluşuyor biliyor musunuz? Tasarım teslim edildiği anda. Figma’da pırıl pırıl duran ekranlar, Jira’da açılan ticket’lar, ardından “bu padding 16 mı 20 mi?”, “bu hover rengi nereden geliyor?”, “mobile breakpoint’te ne olacaktı?” gibi bitmeyen bir çeviri süreci… İşte Anything’nin X’te paylaştığı “design-first vibe coding is here” cümlesi bu boşluğa direkt dalıyor: Figma tasarımını içeri aktar, oradan da doğruca inşa etmeye geç.

Bu iddia ilk kez duyulmuyor ama zamanlaması önemli. Son iki yılda ekiplerin alışkanlığı kökten değişti: Tasarımcılar prototipleri daha interaktif kuruyor, geliştiriciler component kütüphanelerini standartlaştırıyor, ürün yöneticileri de “bir hafta sonra demo” takvimine sıkışmış durumda. Tam bu baskının ortasında “Figma’dan al, build’e geç” vaadi, sadece bir entegrasyon değil; iş yapma biçimi önerisi.

“Design-first vibe coding” tam olarak ne demek?

Vibe coding kavramı genellikle şuna işaret ediyor: Kod yazmayı satır satır kontrol etmekten ziyade niyeti söyleyip, aracı (AI ya da bir builder) yönlendirmek. “Design-first” kısmı ise niyetin metinden değil tasarımdan gelmesi. Yani başlangıç noktası bir prompt değil, Figma’daki gerçek ekranlar.

Anything’nin tweet’indeki vurgu, Figma tasarımını içe aktarıp “go straight to building” diyebilmek. Burada iki kritik beklenti var. Birincisi, görsel hiyerarşiyi ve layout’u kaybetmeden bir arayüz iskeleti çıkarabilmek. İkincisi, bu iskeletin sadece statik HTML gibi kalmayıp gerçek bir ürüne dönüşebilmesi: component mantığı, state yönetimi, veri bağlama, responsive davranışlar ve nihayetinde deploy.

Tasarım-kod çevirisindeki asıl sorun piksel değil, karar

Bu tür araçlar ilk bakışta “piksel-perfect export” gibi algılanıyor. Oysa ekiplerde esas zaman kaybı çoğu zaman pikselde değil, kararda yaşanıyor. Örneğin bir onboarding ekranında “Devam” butonuna basınca hangi validasyon çalışacak? Hata mesajı nerede görünecek? Loading state nasıl görünecek? API gecikirse kullanıcı ne hissedecek? Figma bunları bazen gösteriyor, bazen göstermiyor. Gösterse bile bu davranışlar kod tarafında bir “sistem” ister.

Dolayısıyla Anything’nin iddiasını değerlendirirken soru şu: Figma’dan gelen tasarım, sadece görünümü mü taşıyor, yoksa davranış için de bir çerçeve sunuyor mu? “Doğrudan build” demek, tasarımın ürünleşme yolundaki en çetrefilli kısmını—yani davranış ve veri kararlarını—hızlandırmak demek.

Ürün ekipleri için pratik etkisi: Hız mı, borç mu?

Gerçek hayatta Figma’dan koda giden köprülerin en büyük riski, hızlı demo üretirken uzun vadeli teknik borç biriktirmesi. Bir ekibin tasarımdan otomatik çıkan yapıyı yarın refactor edebilmesi, component’leri tasarım sistemiyle eşleştirebilmesi ve erişilebilirlik (a11y) standartlarını koruyabilmesi gerekir.

Örneğin bir tasarım sistemi düşünün: Primary button, secondary button, danger state, disabled state… Eğer import edilen Figma ekranları bunları “tek tek çizilmiş kutular” gibi alıyorsa, ortaya onlarca birbirine benzeyen ama farklı class’lara sahip buton çıkabilir. Bu da bir ay sonra “neden bu buton başka yerde farklı?” tartışmasına döner.

Öte yandan doğru kurgulanırsa kazanç devasa. Küçük bir SaaS ekibi için 6 ekranlık bir MVP’nin tasarımdan ilk working prototipe dönüşmesi normalde 1-2 hafta sürebiliyor. Bu sürenin 1-2 güne düşmesi, özellikle pazar doğrulama aşamasında oyunu değiştirir. İyi kısım şu: Tasarımcı “yapılabilir mi?” endişesini daha erken görür, geliştirici de “tasarım mantıklı mı?” sorusunu daha hızlı test eder.

Figma import’unda kritik ayrıntılar: Auto Layout, component, token

Figma tarafında Auto Layout kullanımı, gerçek bir arayüzün nefes alıp alamayacağını belirler. Auto Layout’suz bir tasarım çoğu zaman bir poster gibidir; ekran boyutu değişince her şey dağılır. Bu yüzden Anything gibi araçların başarısı, Figma dosyasındaki yapısal ipuçlarını okuyup okuyamamasına bağlı. Component’lerin component olarak kalması, renk ve tipografi token’larının bir sisteme bağlanması, spacing’in rastgele değil ölçekli bir mantıkla çıkması gerekir.

Bir de şu var: Ekipler Figma’da her şeyi mükemmel sistematik çizmez. Gerçek dosyalarda “Frame 132”, “Group copy 4” gibi isimler, yarım kalmış varyantlar ve acil yetişmiş ekranlar bulunur. Araçlar ideal dünyada değil, bu kaosta değer üretir.

“Vibe” kısmı: Tasarımdan sonra hâlâ yönlendirme gerekecek

Tasarımı içe aktarıp arayüzü ayağa kaldırmak başlangıç. Ürünü ürün yapan kısım ise hâlâ sorular sormak ve cevapları sisteme tanımlamak. Kullanıcı girişi nasıl olacak? Yetkilendirme var mı? Loglama, analitik event’leri, hata yakalama? Bir checkout akışında edge-case’ler? Bunlar vibe coding’in “yönlendirme” tarafını canlı tutuyor.

Bu yüzden Anything’nin tweet’ini bir “artık geliştiriciye gerek yok” mesajı gibi okumak yerine, “tasarım ile çalışma arasındaki ilk kilometreyi kısaltma” hamlesi olarak görmek daha gerçekçi. Eğer gerçekten Figma’dan gelen yapı, mantıklı component’lere ayrışıyor ve üstüne veri/logic bağlamak kolaylaşıyorsa, ekiplerin en sık yaşadığı kopukluklardan biri kapanır.

X’teki Anything paylaşımı tam da bunu ima ediyor: Figma tasarımını içeri alıp, prototip değil ürün inşa etmeye yaklaşmak. İddialı. Ama doğru problem seçimi. Çünkü 2026’da hız yarışını kazananlar, sadece daha çok kod yazanlar değil; tasarım, ürün ve mühendisliği aynı “tek kaynak” etrafında buluşturabilenler olacak. Bu paylaşımın işaret ettiği yön de tam olarak orası.