AI, Düzeni ve Niyeti Nasıl Okuyup Tasarımları UI Koda Çevirir

“tasarımdan koda” AI gerçekte ne anlama geliyor

“tasarımdan koda” AI, görsel bir tasarım fikrini—genellikle bir Figma çerçevesi veya ekran görüntüsünü—çalıştırılabilir UI koduna çevirir. Amaç “kusursuz kod” değil; insanın üstünden geçip iyileştirebileceği, yapıyı, stili ve temel davranışı yakalayan kullanılabilir bir ilk taslaktır.

Gerçekte ne çeviriyor

Temelde sistem, gözlemleyebildiği şeyleri UI’ların tipik olarak nasıl kurulduğuna eşler.

• Düzen: Öğelerin nerede durduğu, nasıl hizalandığı, boşluklar, gridler ve konteyner gruplanması.
• Hiyerarşi: Hangi öğe birincil, hangisi ikincil gözüküyor (manşetler vs altyazılar, ana butonlar vs linkler) ve bölümlerin nasıl iç içe geçtiği.
• Niyet: Bir öğenin “ne amaçla” olduğu (gönder butonu, detay kartı, input alanı).
• Bileşenler: Tekrarlayan desenler; yeniden kullanılabilir yapı taşları olabilir (butonlar, nav barlar, kartlar, form satırları).

AI nelerin çıkarımını yapabilir vs neleri belirtmelisiniz

AI yaygın desenleri çıkarabilir: bir ikon sırası muhtemelen bir araç çubuğudur; üst üste gelmiş etiket + input muhtemelen bir form alanıdır; tutarlı stiller yeniden kullanılabilir bir bileşen olduğunu gösterir. Constraintler ve boşluklara dayanarak responsif davranışı da tahmin edebilir.

Ama piksellerin garantileyemediği çoğu şeyi genellikle sizin belirtmeniz gerekir: gerçek bileşen adları, tasarım tokenları (renkler/tipografi ölçekleri), durumlar (hover/disabled/error), breakpoints, veri kuralları ve gerçek etkileşimler (doğrulama, gezinme hedefleri, analitik).

Beklentileri ayarlamak

Çıktıyı bir başlangıç noktası olarak değerlendirin. Yapıyı gözden geçirmek, ad-hoc stilleri tokenlarla değiştirmek, kendi bileşen kütüphanenize uyarlamak ve yinelemek gerekir. “tasarımdan koda” hızlandırma sağlar—tasarım ve mühendislik yargısını ortadan kaldıran bir otomasyon değildir.

AI bir tasarımı anlamak için hangi girdileri kullanır

AI bir “güzel ekran”dan ürün kurallarını çıkaramaz. Çalışmak için verdiğiniz kanıtlara dayanır—bazı girdiler pikselleri tanımlar, bazıları yapıyı tanımlar. Bu fark genelde temiz UI kodu mu yoksa kırılgan mutlak konumlandırma mı alacağınızı belirler.

Ekran görüntüleri ve statik mockuplar: hangi bilgiler eksik

Ekran görüntüsü en sınırlı girdidir: renkler ve şekiller vardır, ama bir şeyin buton mu yoksa etiket mi olduğu, neyin yeniden kullanılabilir olduğu veya düzenin nasıl uyum sağlayacağı açık değildir.

Sadece piksellerden AI, sınırları tahmin etmek zorunda kalır (bir öğe nerede bitiyor diğer hangi öğe başlıyor), metin stillerini, boşluk kurallarını ve bir “kart”ın tek bir bileşen mi yoksa birkaç ayrı parça mı olduğunu belirlemeyi tahmin eder. Ayrıca constraintleri çıkaramaz—dolayısıyla responsif davranış çoğunlukla spekülasyondur.

Figma/Sketch ihracatı: çerçeveler, katmanlar, constraintler, stiller

AI tasarım dosyasına (veya yapıyı koruyan bir ihracata) erişince kritik metadata kazanır: çerçeveler, gruplar, katman adları, Auto Layout ayarları, constraintler ve metin/stil tanımları.

Burada düzen geometri olmaktan çıkar. Örneğin, Auto Layout kullanan bir Figma çerçevesi “bu öğeleri dikey olarak 16px boşlukla yığın” gibi niyeti ekran görüntüsünden çok daha iyi iletir. Tutarlı katman adlandırma da öğeleri UI rolleriyle eşlemeye yardımcı olur (ör. “Primary Button”, “Nav Item”, “Input/Error”).

Tasarım sistemleri: tokenlar, bileşenler, isimlendirme sözleşmeleri

Bağlı bir tasarım sistemi tahmini azaltır. Tokenlar (renkler, boşluk, tipografi) AI’nın sabit değerler yerine ortak bir kaynağa referans veren kod üretmesini sağlar. Yayınlanmış bileşenler (butonlar, alanlar, modallar) hazır yapı taşları sunar ve yeniden kullanım sınırlarını netleştirir.

Hatta küçük sözleşmeler—variant isimlendirmeleri (Button/Primary, Button/Secondary) ve semantik tokenlar (text/primary) kullanmak yerine #111111 gibi sabit değerler—bileşen eşlemesini iyileştirir.

Yazılı spesifikasyonlar: kullanıcı akışları, kabul kriterleri, kenar durumlar

Speslar UI’nın arkasındaki “neden”i ekler: hover davranışı, loading ve empty durumları, doğrulama kuralları, klavye davranışı ve hata mesajlaşma.

Bunlar yoksa AI genellikle statik bir anlık görüntü üretir. Speslar varsa çıktı etkileşim kancaları, durum yönetimi ve daha gerçekçi bileşen API’ları içerebilir—takımın yayınlayabileceği ve sürdürebileceği bir şeye daha yakın.

AI düzeni ve yapıyı nasıl yorumlar

Design-to-code araçları ekranı bir insan gibi algılamaz; her katmanı düzen kurallarıyla (satırlar, sütunlar, konteynerler, boşluklar) açıklamaya çalışır. Bu kurallar ne kadar netse, çıktı o kadar az kırılgan konumlandırmaya dayanır.

Gridleri, sütunları ve boşluğu tespit etme

Çoğu model tekrar eden hizalamalar ve eşit aralıklar aramakla başlar. Eğer birkaç öğe aynı sol kenarı, baz hattı veya merkez hattını paylaşıyorsa, AI genellikle bunları bir sütun veya grid kanalı olarak değerlendirir. Tutarlı boşluklar (ör. 8/16/24px kalıpları) layout’un stack boşlukları, grid gutters veya tokenize boşluklarla ifade edilebileceğini gösterir.

Boşluklar hafifçe değişiyorsa (burada 15px, orada 17px) AI düzenin “manuel” olduğunu düşünerek piksel-kusursuz mesafeleri korumak için mutlak koordinatlara geri dönebilir.

Konteynerleri ve iç içe grupları tanıma

AI görsel “kapsama” arar: arka planlar, kenarlıklar, gölgeler ve padding benzeri boşluklar bir konteyner olduğunu işaret eder. Arka planı ve iç padding’i olan bir kart, ebeveyn öğe ve çocukları için net bir sinyal verir.

Buradan genelde yapıyı şu temel yapılara eşler:

• dikey stackler (listeler, formlar)
• yatay satırlar (araç çubukları, nav)
• iç içe gruplar (kart → başlık → aksiyonlar)

Tasarım dosyasında temiz gruplanma ebeveynleri kardeşlerden ayırmayı kolaylaştırır.

Constraintleri yorumlama: sabit vs esnek

Tasarımda constraintler (pinleme, hug, fill) varsa AI bunları neyin esnediğini neyin sabit kaldığını belirlemek için kullanır. “Fill” elemanları tipik olarak esnek genişlikler alır (ör. flex: 1), “hug” içerik boyutlu öğelere karşılık gelir.

Neden mutlak konumlandırma görünür (ve neden riskli)

Model akışıyla ifade edilemeyen ilişkileri güvenli şekilde açıklayamadığında mutlak konumlandırma ortaya çıkar—genelde tutarsız boşluklar, örtüşen katmanlar veya hizalanmamış öğeler yüzünden. Bir ekran boyutunda doğru görünen bu yaklaşım, responsivlikte ve metin yeniden boyutlandırmasında bozulur.

Hızlı kazanım: boşluk tutarlılığı

Küçük bir boşluk ölçeği kullanmak ve net bir ızgaraya hizalanmak, AI’nın flex/grid kodu üretme olasılığını dramatik biçimde artırır. Tutarlılık yalnızca estetik değil—makine tarafından okunabilir bir desendir.

Hiyerarşi görsel ipuçlarından nasıl çıkarılır

AI “anlamaz”; önem derecesini genelde onu işaret eden görsel kalıplardan çıkarır. Tasarım bu sinyalleri ne kadar net iletirse, üretilen UI niyetinize o kadar yakın olur.

Tipografi bir sıralama sistemi gibi

Tipografi en güçlü ipuçlarından biridir. Daha büyük puntolar, daha yüksek ağırlık, güçlü kontrast rengi ve daha cömert satır yüksekliği genellikle daha yüksek öncelik gösterir.

Örneğin, 32px kalın bir başlığın üstünde 16px normal bir paragraf açık bir “başlık + gövde” desenidir. Sorun, stiller belirsizleştiğinde ortaya çıkar—ör. iki metin bloğu sadece 1–2px fark ediyorsa veya aynı ağırlık farklı renklerle kullanılmışsa. Bu durumlarda AI her ikisini de düz metin sayabilir veya yanlış başlık seviyesini seçebilir.

Gruplama: yakınlık ve ortak konteynerler

Hiyerarşi ayrıca mekansal ilişkilerden çıkar. Birbirine daha yakın, hizalanmış ve diğer içerikten boşlukla ayrılmış öğeler grup olarak değerlendirilir.

Ortak arka planlar (kartlar, paneller, renkli bölümler) görsel parantez gibi davranır: AI genellikle bunları section, aside veya bileşen sarmalayıcısı olarak yorumlar. Düzensiz padding veya tutarsız boşluk yanlış gruplaşmaya neden olabilir—ör. bir buton yanlış karta eklenebilir.

Tekrar bileşen olduğunu gösterir

Tekrarlayan desenler—özdeş kartlar, liste öğeleri, satırlar veya form alanları—yeniden kullanılabilir bir bileşen olduğuna dair güçlü kanıttır. Küçük farklar (ikon boyutu, köşe yarıçapı, metin stili) AI’yı tek tek varyantlar üretmeye yöneltebilir; oysa tek bir bileşen ve varyantları daha uygundur.

Vurgu: birincil vs ikincil eylemler

Butonlar boyut, dolgu, kontrast ve konumla niyeti iletir. Dolgulu ve güçlü kontrastlı bir buton genelde birincil eylem olarak değerlendirilir; outline veya metin butonlar ikincil olur. İki eylem eşit vurguda görünüyorsa, AI hangi olanın “birincil” olduğunu yanlış tahmin edebilir.

Görsel hiyerarşiden semantik yapıya

Son olarak AI hiyerarşiyi semantike çevirmeye çalışır: başlıklar (h1–h6), gruplanmış bölümler (section) ve anlamlı kümeler (ör. “ürün detayları” vs “satın alma aksiyonları”). Net tipografik adımlar ve tutarlı gruplaşma bu çeviriyi çok daha güvenilir kılar.

AI kullanıcı niyetini ve etkileşimleri nasıl tahmin eder

Modeller niyeti, çok sayıda UI örneğinden öğrendikleri kalıplarla eşleştirerek tahmin eder: ortak şekiller, etiketler, ikonografi ve yerleşim gelenekleri.

Tanıdık UI kalıplarını tanıma

Belirli düzenler belirli bileşenleri güçlü şekilde işaret eder. Solda logo, üstte yatay şerit ve sağda metin öğeleri bir nav bar; eşit genişlikte öğelerden oluşan bir sıra ve birinin vurgulanmış olması tabları işaret eder; resim, başlık ve kısa metin içeren tekrar eden kutular karttır; hizalanmış başlıklar ve satırlar yoğun gridler genelde tablolar olur.

Bu tahminler önemli çünkü yapı üzerinde etkisi vardır: “tab”, seçili durum ve klavye navigasyonu gerektirir; “buton sırası” ise aynı şeyi gerektirmez.

Ne kadarının etkileşimli olduğunu çıkarmak

AI genellikle etkileşim ipuçlarını arar:

• Buton benzeri şekiller (dolu arka planlar, yuvarlak dikdörtgenler, güçlü kontrast)
• Link stilizasyonu (mavi, altı çizili) veya nav içindeki yerleşim
• Input göstergeleri (kenarlık, placeholder, imleç)
• Affordance ikonları (chevron, büyüteç, “⋯”)

Bunlara dayanarak davranış atar: tıklama, menü açma, gezinme, gönderme, aç/kapa. Tasarım etkileşimli öğeleri net ayırdıkça çıktı daha doğru olur.

Durumları anlama (ve niyet belirsiz olduğunda)

Tasarım birden fazla varyant gösteriyorsa—hover, seçili, disabled, hata, loading—AI bunları durumlu bileşenlere eşleyebilir. Durumlar görünür değilse AI çoğunlukla bunları atlar.

Belirsizlik sık görülür: bir kart tıklanabilir mi yoksa sadece bilgi mi veriyor? Bir chevron dekoratif mi yoksa disclosure kontrolü mü? Bu durumlarda adlandırma, notlar veya ayrı çerçevelerle etkileşimi belirtin.

Tasarımı UI ilkel ve bileşenlere çevirme

AI düzenin makul bir okumasını yaptıktan sonra bir sonraki adım “göründüğü şey”i “ne olduğu”na çevirmektir: semantik HTML, yeniden kullanılabilir bileşenler ve tutarlı stil.

Katmanlardan yapıya (ve rollere) geçiş

Çoğu araç tasarım katmanlarını ve grupları bir DOM ağacına eşler: çerçeveler konteyner olur, metin katmanları başlık/paragrafa dönüşür, tekrar eden öğeler listeler veya gridler olur.

Niyet netse AI daha iyi semantik atayabilir—ör. üst çubuk bir \u003cheader\u003e olur, logo ve linkler \u003cnav\u003e olur, tıklanabilir kart \u003ca\u003e veya \u003cbutton\u003e olur. ARIA rolleri bazen çıkarılabilir (modal için role=\"dialog\" gibi) ama desen belirsizse daha güvenli çıktı düz HTML ve erişilebilirlik inceleme TODO’ları olur.

Bileşen sınırlarını çizme

Tek bir devasa dosya üretmemek için AI UI’yi şu parçalara ayırmaya çalışır:

• Atomlar: butonlar, inputlar, ikonlar, etiketler
• Moleküller: arama çubuğu, form satırları, liste öğeleri
• Şablonlar/bölümler: hero blokları, fiyat tabloları, sayfa kabukları

Tekrar eden patternler, tutarlı padding/typografi ve gruplanmış tıklanabilir alanlar bileşen sinyalleridir. Başarısızlık modları aşırı parçalara ayırma veya her şeyi tek seferlik hardcode etme olacaktır.

Stil verme: CSS vs utility vs CSS-in-JS

Generator genelde hedef yığına veya kendi varsayılanına göre bir yaklaşım seçer:

• Düz CSS / modüller: el ile düzenleme kolaylığı
• Utility sınıflar: üretimi hızlı ve tutarlı, ama markupta çok telaffuz gerektirir
• CSS-in-JS: stilleri bileşenle co-locate eder, ama token disiplini yoksa karmaşık olabilir

Piksel yerine tokenlar

Kaliteli çıktı tasarım tokenlarına yaslanır—renkler, boşluk, radius, gölgeler—böylece tasarım değiştiğinde kod da kolayca uyum sağlar. Kesin piksel eşleşmesi genelde tek seferlik değerler üretir ve bakım zorlaşır.

Pratik denge: hiyerarşiyi ve boşluk ritmini koruyun, sonra bunu tokenlara ve tekrar kullanılabilir bileşenlere normalize edin (ve inceleme adımında daha fazla refactor yapın).

Responsiveness: sabit çerçevelerden uyarlanabilir UI’lere

Tasarım dosyaları genelde birkaç sabit frame boyutunda olduğu için (ör. 1440 ve 375). Kod bunu varsayamaz. Design-to-code aracı ara genişliklerde UI’nin nasıl davranacağını, ipuçları ve varsayılanlarla kararlaştırmalı.

Breakpoint’ler nasıl çıkarılır (veya tahmin edilir)

Tasarımınız aynı ekranın birden fazla versiyonunu içeriyorsa (desktop/tablet/mobile) ve yapı tutarlıysa AI bunları hizalayıp hangi kuralların değiştiğini çıkarabilir. Varyant yoksa genelde yaygın breakpointlere döner ve çerçeveyi “temel” kabul eder; bu da garip geçişlere yol açabilir.

Wrap, stack ve reflow kararları

AI şu desenlere bakar: tekrar eden kartlar, eşit boşluk ve hizalama. Buna dayanarak 3 sütunlu bir gridin 2’ye sonra 1’e düşeceğine karar verebilir. Tasarım manuel düzeltmelere dayandıysa—görünüşte hizalanmış ama aslında tutarsız—AI bunun kasıtlı olup olmadığını anlayamaz.

Dinamik içerik: uzun metin ve lokalizasyon

Çoğu tasarım kısa, düzenli metin kullanır. Gerçek ürünler uzun metinler içerir. AI tarafından üretilen UI kodu genelde sabit genişlik/yükseklik koyar veya aşırı kestirir.

Hızlı bir kontrol:

• Başlıkları 2–3× uzatın (Almanca tarzı bileşikler, resmi isimler)
• Çok satırlı butonlar ve hata mesajları test edin
• Daha büyük metin boyutlarıyla (OS erişilebilirlik ayarları) kontrol edin

Responsif resimler ve medya

AI tasarımdaki kırpmayı koruyabilir, ama responsif UIs kurallar ister: en-boy oranını koru, nasıl kırpılacağına karar ver, görüntünün ne zaman küçüleceğini veya yer değiştireceğini belirtin. Tasarım bunu belirtmiyorsa genellikle “fill” davranışı görülür ve önemli kısımlar kırpılabilir.

Pratik kontroller

Çıktıya güvenmeden önce çok küçük genişliklerde, çok büyük monitörlerde ve ara boyutlarda önizleyin. Herhangi bir örtüşme, kırpılma veya okunamazlık varsa sorun genelde eksik düzen niyetidir—bu da tasarımda daha net constraintler eklemeniz gerektiğini gösterir.

Erişilebilirlik: sinyaller, eksikler ve hızlı kazanımlar

AI pikselleri UI koduna şaşırtıcı derecede iyi çevirebilir, ama erişilebilirlik genelde “görünüş doğru” ile “herkes için çalışır” arasında fark yaratır. Birçok gereksinim statik bir çerçevede görünmez; modelin bunları doğru yapması için açık sinyaller gereklidir.

Tasarımdan çıkarılabilecekler

Bazı erişilebilirlik dostu seçimler görsel olarak ortaya çıkar ve AI bunları daha iyi HTML’e çevirebilir:

• Kontrast ve vurgu: büyük, kalın metin başlık olur; yüksek kontrastlı butonlar birincil eylem olarak algılanır.
• Input etiketleri yakınlığı: bir alanın üstünde/solunda bulunan etiket genellikle input etiketi olarak çıkarılır.
• Odak sırası ipuçları: temiz sol-üstten sağa-aşağı düzen makul bir DOM sırası sağlayabilir.

AI’nin güvenilir şekilde çıkaramadıkları

Görünmeyen gereksinimler şunlardır:

• Klavye akışı ve tuzakları: modal, menü ve özel widget’lar odak yönetimi gerektirir.
• Anlamlı etiketler: placeholderdaki “Email” erişilebilir etikete eşdeğer değildir; niyet belirsiz olabilir.
• Durum duyuruları: hatalar, yükleniyor, dinamik güncellemeler ARIA düzenleri ister.

Üretilen kodda sık görülen eksikler

Bekleyin: eksik label/for bağlantıları, yanlış başlık seviyeleri, klavye desteği olmayan tıklanabilir divler, zayıf odak stilleri ve metin alternatifi olmayan ikonlar.

Yayına almadan önce hızlı kontrol listesi

• Başlıklar mantıklı bir sıra oluşturuyor (h1 → h2 → h3).
• Landmarklar mevcut (header, nav, main, footer) ve çoğaltılmamış.
• Görsel/ikonlar uygun alt içeriyor veya dekoratifse alt="".
• Görünür odak stilleri var ve kontrast ihtiyaçlarını karşılıyor.
• Inputların etiketleri ve net hata mesajları var.

Erişilebilirlik spesifikasyonu eklenmesi gereken zaman

Modal, drawer, karmaşık formlar, özel selectler, sürükle-bırak veya çok durumlu öğeler olduğunda kısa bir spes ekleyin. Birkaç not (ör. “modalde odak tuzağı”, “Esc kapatır”, “satır içi hatalar duyurulsun”) üretilen UI kodunu ciddi şekilde iyileştirir.

AI tarafından üretilen UI kodunun sıkça hata yaptığı yerler

AI ilk bakışta yakın görünen UI kodu üretebilir, ama küçük yorumlama hataları biriktikçe sorunlar büyür. Çoğu hata, tasarımda kuralların net kodlanmamasından kaynaklanan “makul tahminler”den gelir.

Tasarımla uyuşmayan boşluklar

Yaygın bir şikayet uyumsuz boşluklardır: butonlar hafifçe kaymış, bölümler çok hava almış veya kartlar sıkışık görünür. Bu, benzer öğeler arasında paddingin tutarsız olduğu ya da auto-layout ile manuel düzeltmelerin karıştığı durumlarda olur. Model ya bir deseni (ör. “her yerde 16px”) uygular ya da kazara olan istisnaları korur.

Aşırı iç içe geçmiş ve karışık DOM

Oluşan markup sıklıkla çok sayıda sarmalayıcı içerir. Her görsel grup yeni bir \u003cdiv\u003e olur. Sonuç, stil vermesi ve debug yapması zor ve bazen render performansı düşen bir yapı olur.

Bileşen ayrımında hatalar

AI bazen çok parçacıklı (her etiket ayrı bileşen) veya çok monolitik (tüm ekran tek bileşen) sonuç verir. Sebep belirsiz sınırlar: tekrarlayan desenler özdeş değilse model ortak bir bileşen çıkarmaya güvenemez.

Tipografi sapmaları

Metin stilleri kodda tam eşleşmeyebilir; satır yüksekliği, harf aralığı veya font fallback’leri farklılık yaratır. Bu yüzden Figma’da sığan bir başlık kodda sarma yapabilir.

Eksik etkileşim durumları

Hover, focus, error, loading veya empty durumları tasarımda yoksa AI genelde bunları eklemez. Statik görüntü doğru görünse de kullanıcı etkileşimi başladığında UI başarısız olabilir.

AI daha iyi kod üretsin diye tasarımları nasıl hazırlamalısınız

AI kod üretecekse tasarım dosyanız katmanlar, constraintler, stiller ve bileşen örnekleriyle temiz olmalı. Yapı ne kadar temizse modelin tahmin etmesi gereken o kadar az olur (ve daha az garip div temizlemeniz gerekir).

1) İsimlendirmeyi işe koşun

Katman adları niyet ve bileşen eşlemesi için güçlü sinyallerdir. Aşağıdaki gibi tutarlı, açıklayıcı kalıplar kullanın:

• Button/Primary, Button/Secondary
• Card/Product, Card/Article
• Form/Input/Text, Form/Checkbox

“Rectangle 12” veya “Group 5” bırakmayın—bu AI’yi generic sarmalayıcılara iter.

2) Auto Layout ve constraintler kullanın (piksel koreografisi değil)

Manuel konumlandırma genelde koddaki mutlak koordinatlara dönüşür. Flex/grid çıktısı istiyorsanız tasarımınızın flex/grid gibi davranması gerekir:

• Satır/sütun, boşluk, hizalama ve padding için Auto Layout kullanın.
• Öğelerin öngörülebilir şekilde yeniden boyutlanması için constraintler uygulayın (ör. metin genişlesin, butonlar sabit kalsın, kartlar esnesin).

Tasarım araçlarında iyi davranan bir yapı, üretilen UI’nin varsayılan olarak daha responsif olmasını sağlar.

3) Tokenları tanımlayın ve stilleri tekrar kullanın

Tek seferlik renkler, font boyutları ve boşluklar tek seferlik CSS üretir. Bunun yerine:

• Tipografi ve renk stilleri (veya değişkenler) oluşturun ve tekrar kullanın
• Boşluk adımlarını standardize edin (ör. 4/8/12/16)

Bu tutarlılığı artırır ve ileride design system’e refactor etmeyi kolaylaştırır.

4) Durumları, varyantları ve kısa niyet notlarını ekleyin

AI bulunmayanı çıkaramaz. Önemli varyantları (hover/pressed/disabled), input hata durumlarını, loading ve empty durumlarını ekleyin.

Davranış önemliyse kısa bir not bırakın: “opens modal”, “server-validated”, “shows toast on success”. Bir bileşenin yanında birkaç kelime yanlış etkileşim kodunu önleyebilir.

Ekip standardı oluşturuyorsanız bunları hafif bir kontrol listesinde toplayın ve iç dokümana referans verin.

Üretilen çıktıyı gözden geçirip refactor etme

AI tarafından üretilen UI kodu en iyi ilk taslak gibi ele alınır: saatler kazandırır ama yine de insan eliyle düzeltilmeli, sürdürülebilir hale getirilmeli ve ürün standartlarına uyumlu hale getirilmelidir.

1) Piksellerden önce semantiği doğrulayın

Markup’u bir ekran okuyucu gibi okuyormuş gibi başlayın:

• Başlık sırasını kontrol edin (bir \u003ch1\u003e, sonra mantıklı \u003ch2\u003e/\u003ch3\u003e).
• Listelerin gerçek listeler (\u003cul\u003e/\u003col\u003e) olduğundan emin olun, yığın \u003cdiv\u003eler olmasın.
• Formları inceleyin: her inputun bir labelı olmalı ve hata/yardım metni ilişkilendirilmeli.
• Etkileşimli öğelerin türü doğru mu: eylemler için button, gezinme için link.

Semantik yanlışsa CSS ile düzeltmek erişilebilirlik veya kullanılabilirlik sorunlarını çözmez.

2) Düzeni stabil hale getirmek için refactor edin

Çoğu generator piksel-kusursuzluğu korumak için mutlak konumlandırma veya derin sarmalayıcılar kullanır. Bu içerik değiştiğinde bozulur. Flex/grid kurallarını tercih edin ve gereksiz katmanları kaldırın. Eğer birçok yerde style={{ left, top, width, height }} görüyorsanız ilk önce orayı yeniden yazın.

3) Bileşenleri ve tokenları çıkarın

Tekrarlayan desenleri (kartlar, input satırları, nav öğeleri) bileşene dönüştürün. Ardından sabit değerleri tokenlar ile değiştirin: boşluk, radius, tipografi ve renkler. Eğer ekibinizin mevcut token rehberi varsa ona uyun; yoksa küçük bir setle başlayıp kademeli genişletin.

4) Regresyonları önleyecek hızlı kontroller ekleyin

Ağır test yazmanıza gerek yok:

• Önemli bileşenler için Storybook hikâyeleri ve snapshot/visual kontroller
• Küçük QA: klavye navigasyonu, odak durumları, responsif kırılma noktaları, uzun metin senaryoları

5) Varsayımları belgeleyin

Generatorlar niyet tahmininde bulunur. Yaptığınız düzenlemeleri (etkileşim kuralları, breakpoints, bileşen eşlemeleri) kaydedin ki bir sonraki jenerasyon veya geliştirici bunları geri almasın.