Yapay zekanın düz metin talimatları nasıl yorumlayıp UX akışlarını planladığını, arayüz ve kod ürettiğini ve geri bildirimle yineleyerek çalışan özellikler ve ekranlar ortaya çıkardığını öğrenin.
"Yazılı talimatlar", zaten ne inşa edilmesini istediğinizi açıklamak için kullandığınız kelimelerdir—bir AI'nin (ve bir ekibin) harekete geçebileceği bir biçimde yakalanmış metin.
Pratikte amaç mükemmel üslup değildir. Amaç, sistemin tahmin etmek zorunda kalmaması için açık niyet (hangi sonucun istendiği) artı açık sınırlar (neye izin verildiği, neyin yasak olduğu) sağlamaktır.
Bunlar resmi veya gayri resmi olabilir:
Önemli olan, metnin çıktıları ve kısıtları tanımlamasıdır. İkisi beraber olduğunda, AI iş kurallarını uydurmadan ekranlar, akışlar ve uygulama detayları önerebilir.
Çalışan bir özellik sadece bir mockup'tan daha fazlasıdır. Tipik olarak şunları içerir:
Örneğin “kaydedilmiş adresler” sadece bir sayfa değil—bir dizi ekran (liste, ekle/düzenle), kurallar (zorunlu alanlar, varsayılan adres) ve bağlantılar (API çağrıları, durum güncellemeleri) demektir.
Çoğu ekip basit bir döngüye girer:
Açıkla → üret → gözden geçir → iyileştir
Siz spesifikasyonu verirsiniz, AI UI/UX ve uygulama önerir, siz doğruluk ve ürün uyumu için gözden geçirirsiniz, sonra sonuç niyetinize uyan hale gelene kadar gereksinimleri düzeltirsiniz.
Koder.ai gibi bir vibe-coding platformu kullanıyorsanız, bu döngü genellikle daha hızlı hale gelir çünkü tek bir yerde kalabilirsiniz: sohbet içinde özelliği tanımlayın, uygulama değişikliklerini üretin, sonra hedefe yönelik takiplerle hızla yineleyin (ve gerekirse geri alın).
AI ekran taslaklarını oluşturmayı, akışlar önermeyi ve kod üretmeyi hızlandırabilir, ama insanlar hâlâ:
AI'yi metni ilk (ve ikinci) taslağa hızla dönüştüren bir hızlandırıcı olarak düşünün—nihai sonuçtan insanlar sorumludur.
AI formatlar konusunda esnektir ama açıklık konusunda seçicidir. Tek paragraftan madde listesine, bir PRD parçasına veya kullanıcı hikayelerine kadar çalışabilir—yeter ki niyet ve kısıtlar açık olsun.
En faydalı başlangıç noktaları genellikle şunları içerir:
Bu unsurlar AI'ye ne inşa ettiğinizi ve "iyi"nin ne olduğunu söyler; bu da gereksiz tekrarları azaltır.
Gereksinimler eksik olduğunda, AI varsayılanlarla doldurur ve bunlar iş kurallarınızla uyuşmayabilir. Şunları dahil edin:
Belirsiz: “Bir ödeme ekranı ekle ve basit olsun.”
Somut: “Giriş yapmış kullanıcılar için bir ödeme akışı ekle. Adımlar: Adres → Gönderim → Ödeme → İnceleme. Kart + Apple Pay destekle. Kullanıcı başına en fazla 3 adres kaydet. Ödemeden önce vergi ve gönderim göster. Ödeme başarısız olursa, sepete dokunmadan tekrar deneme seçeneği göster. Başarı = sipariş oluşturuldu, makbuz e-posta ile gönderildi ve stok düşüldü.”
Açık girdiler AI'nin ekran, metin, doğrulama ve mantık üretimini gerçek kısıtlarla hizalar. Daha az uyuşmayan varsayım, daha az yeniden tasarım döngüsü ve ilk taslaktan ekiplerin gerçekten inceleyip test edip yayınlayabileceği bir şeye daha hızlı ulaşma sağlar.
AI ekranlar üretmeden veya kod yazmadan önce, ne anlamanız gerektiğini yani ne kastedildiğini anlamalıdır. Bu adım temelde bir ürün yöneticisi gibi spesifikasyonunuzu okumaktır: hedefleri, rol oyuncularını ve özelliğin doğru olması için gerekli kuralları çıkarmak.
Çoğu spesifikasyon birkaç tekrar eden yapı taşına sahiptir:
Bunlar net olduğunda, AI metni akışlara, ekranlara, veri yapılarına ve mantığa çevirebilecek yapılandırılmış bir anlayışa dönüştürebilir.
AI ayrıca yaygın ürün desenlerini tanır ve günlük dili uygulama kavramlarına eşler. Örneğin:
Bu eşleme, belirsiz isimleri tasarımcıların ve mühendislerin kullandığı somut yapı taşlarına dönüştürdüğü için faydalıdır.
İyi spesifikasyonlar bile boşluklar bırakır. AI nelerin eksik olduğunu işaretleyebilir ve şu tür sorular önerebilir:
Bazen cevaplar olmadan ilerlemek istersiniz. AI makul varsayılanlar seçebilir (ör. standart parola kuralları, tipik gösterge panosu bileşenleri) ve aynı zamanda varsayımları inceleme için listeler. Önemli olan şeffaflıktır: varsayımlar net bir şekilde listelenmelidir ki insan onayı alınıp düzeltilsin.
Niyet netleşince sıradaki adım yazılı spesifikasyonu gerçekten inşa edilebilir bir şeye çevirmektir: bir özellik planı. Hedef kod değil—yapının kendisidir.
İyi bir plan cümleleri ekranlar, navigasyon ve kullanıcı yolculuklarına çevirerek başlar.
Örneğin: “Kullanıcılar ürünleri wishliste kaydedebilir ve sonra görüntüleyebilir” genellikle (1) bir ürün detay etkileşimi, (2) bir wishlist ekranı ve (3) ana navigasyondan erişim yolu anlamına gelir.
AI'den ekranları listelemesini ve sonra “mutlu yol” yolculuğunu ve birkaç yaygın sapmayı (oturum açılmamış, ürün kaldırıldı, boş liste) açıklamasını isteyin.
Sonra AI'den özelliği ekiplerin tanıyacağı görevlere bölmesini isteyin:
Bu aynı zamanda belirsiz gereksinimleri açığa çıkarır. Örneğin kullanıcı aynı öğeyi iki kez kaydetmeye çalışırsa ne olacağı belirtilmemişse, plan bunu sorgulamalıdır.
Kabul kriterlerini düz dilde tutun. Örnek:
AI'den öğeleri zorunlu ve iyi-olur olarak etiketlemesini isteyin (ör. “wishlist paylaşma” iyi-olur olabilir). Bu planın başlangıçta genişlemesini engeller.
Bir özellik planıyla AI metni somut bir “ekran haritası”na ve erken bir UI taslağına dönüştürmede yardımcı olabilir. Amaç ilk denemede piksellerin mükemmel olması değil—kullanıcıların ne göreceği ve ne yapacağı konusunda ortak bir model elde etmektir.
İlk olarak mutlu yolu kısa bir hikaye olarak anlatın: kullanıcı ne istiyor, nereden başlıyor, neye tıklıyor ve başarı nasıl görünüyor. Bundan AI minimum ekran setini (her ekranda nelerin olacağıyla birlikte) önerebilir.
Sonra yaygın alternatifleri isteyin: “Eğer oturum açılmamışsa ne olur?”, “Sonuç yoksa?”, “Yarım bırakırlarsa ne olur?”. Bu, sadece demo için çalışan bir UI inşa etmemenizi sağlar.
Eğer spesifikasyonunuz düzen ipuçları içeriyorsa (ör. “başlıkta arama, sonuç listesi filtrelerle, ana CTA altta”), AI şu yapılandırılmış taslağı üretebilir:
En iyi prompt'lar içerik önceliklerini (“fiyat ve stok bilgisini açıklamanın üstte göster”), etkileşim kurallarını (“filtreler oturumlar arasında korunur”) ve kısıtları (“mobil-öncelikli; tek baş parmakla kullanılabilecek”) içerir.
Çalışan bir ürün sadece “normal” ekrana sahip olmamalıdır. AI'den uygulayacağınız durumları sıralamasını isteyin:
Bu durum kararları doğrudan geliştirme çabasını ve kullanıcı güvenini etkiler.
AI, yeniden kullanılabilir bileşenler ve kurallar önererek tutarlılığı destekleyebilir: tipografi ölçeği, boşluk tokenleri, buton stilleri ve form desenleri.
Zaten bileşenleriniz varsa, iç yönergelere (ör. /design-system) referans verin ve AI'den yeni desenler icat etmek yerine bunları yeniden kullanmasını isteyin.
Sonraki adım "uygulamanın ne yapması gerektiğini" hangi verileri saklayacağına ve neye izin vereceğine çevirmektir. Bu, yazılı spesifikasyonun somut bir veri modeli ve iş kuralları setine dönüşmesidir.
AI genellikle metindeki “isimleri” çıkarır ve bunları varlıklar olarak ele alır. Örneğin, “Kullanıcılar Proje oluşturup Görev ekleyebilir, yöneticiler zaman kayıtlarını onaylar” ifadesi User, Project, Task, TimeEntry gibi varlıkları önerir.
Her varlık için AI şu önerileri yapar ve eksikleri işaretler:
Ayrıca “hesap başına bir aktif abonelik” (benzersizlik) veya “sipariş toplamı satır tutarlarının toplamına eşit olmalı” (hesaplanmış doğrulama) gibi örtük kenar durumları da işaretlemelidir.
İyi çıktı kuralları okunabilir tutar, kod içinde gömülmez. Örnekler:
Son olarak kayıtların zaman içindeki değişimini eşleyin: oluştur, güncelle, sil ve silme yerine ne yapılacağı (soft delete). AI ayrıca denetim izleri (kim neyi ne zaman değiştirdi) ve izlenebilirlik gerektiğinde geçmiş/sürümleme önerebilir.
Artık kullanıcıların tıklayacağı UI ve doğru davranmasını sağlayan mantığın “ilk çalışan taslağını” üretebilirsiniz.
Koder.ai kullanıyorsanız, platform genellikle sohbet tabanlı spesifikasyondan tutarlı bir full-stack uygulama (web, backend, veritabanı) üretebilir; daha sonra geleneksel iş akışında devam etmek isterseniz kaynak kodunu dışa aktarma seçeneği sunar.
“Proje Oluştur” ekranı gibi bir spesifikasyondan AI şu iskeleti üretebilir:
Ayrıca tekrar kullanılabilir yapı taşları (örn. \u003cProjectForm /\u003e hem oluşturma hem düzenleme için) oluşturabilir, böylece kod tutarlı kalır.
Sunucu tarafında AI temel “sözleşmeyi” taslaklayabilir:
Anahtar nokta, backend mantığını spesifikasyonun kurallarına bağlamaktır (“sadece adminler görünürlüğü private yapabilir”)—sadece UI'nin gönderdiğini kaydetmek değil.
AI UI'yi API istemcinize (fetch/Axios/React Query vb.) bağlayabilir, uygun durumlar için önbellekleme ve yeniden denemeler ekleyebilir. Ayrıca alan düzeyinde doğrulama hataları ve ağ hataları için kullanıcı dostu hata yönetimi oluşturmalıdır.
// Example: submit handler with loading + error state
async function onSubmit(values) {
setStatus({ loading: true, error: null });
try {
await api.post('/api/projects', values);
router.push('/projects');
} catch (e) {
setStatus({ loading: false, error: 'Could not create project. Try again.' });
}
}
Oluşturulan kod, adlandırmada açıklık, öngörülebilir klasör yapısı, küçük fonksiyonlar ve paylaşılan yardımcılar (doğrulayıcılar, API istemcileri, izin yardımcıları) izlediğinde en faydalıdır.
Bir stil rehberiniz veya tercih edilen desenleriniz varsa, bunlara açıkça referans verin ve dahili dokümanları (ör. /engineering/frontend veya /engineering/api-guidelines) belirtin.
Bu noktada ekranlar, UI bileşenleri, veri şekilleri ve iş kuralları hazırdır. “Bağlama”, bu parçaların gerçekten birbirleriyle konuştuğu yerdir: butonlar eylemi tetikler, eylemler backend endpoint'lerini çağırır, cevaplar UI'yi günceller ve izinler kişilerin neyi görebileceğine karar verir.
AI, yazılı spesifikasyona göre ekranları bağlayabilir: rotalar (URL veya uygulama yolları) oluşturma, kilit eylemler sonrası ne olacağını tanımlama ve sayfalar arasında doğru bağlamı geçirme.
Örneğin: “Kaydettikten sonra listeye dön ve yeni öğeyi vurgula” ifadesi somut bir akış olur—formu gönder → başarı bekle → listeye git → toast göster ve yeni satırı odakla.
Spesifikasyonlar genellikle rollerden bahseder (“Admin düzenleyebilir, Viewer sadece okuyabilir”). Bağlama, bunun birden fazla yerde uygulanmasını gerektirir:
AI burada tutarlı kontroller üretme konusunda yardımcıdır; sadece bir ekran kilitli görünse de endpoint'in hâlâ çalışmadığından emin olmak için sunucu tarafı kontrolleri ekler.
Çoğu özellik yapılandırmaya bağlıdır: API temel URL'leri, analiz anahtarları, feature flag'ler, depolama kovaları vb. AI geliştirme/staging/production için ayrı ayarlar oluşturabilirken sırları kod tabanına koymamalıdır.
Tipik çıktılar:
.env şablonları (güvenli yer tutucular)Amaç tam döngüdür: “tıkla → istek → cevap → UI güncelleme.” AI eksik bağlantı kodunu (yükleme durumları, hata yönetimi, yeniden denemeler) ekleyebilir ve basit kontroller üretebilir:
Bu, bir özelliğin mock olmaktan çıkıp gerçek bir ürün gibi davranmaya başladığı noktadır.
Bir özellik “çalışır” hale geldikten sonra, gerçek bir kullanıcı gibi (ve dağınık gerçek dünya şartlarıyla) test edin. AI kabul kriterlerinden somut kontroller oluşturup hata ayıklamanın sıkıcı kısımlarını hızlandırarak yardımcı olabilir.
Spesifikasyonunuz “Kullanıcı parolasını sıfırlayabilir ve onay mesajı görür” diyorsa, AI bu ifadeye uyan test vakalarını çok seviyeli olarak önerebilir:
Hile, AI'ye kesin kabul kriterlerini ve minimal bağlamı vermektir: özellik adı, ana ekranlar ve mevcut test konvansiyonları.
Spesifikasyonlar genellikle mutlu yolu tarif eder. AI, destek taleplerine yol açabilecek “ya olursa” senaryolarını üretmede iyidir:
Hepsini hemen uygulamanız gerekmez, ama hangi durumların ürün risk düzeyiniz için önemli olduğunu belirlemelisiniz.
Bir test başarısız olduğunda, AI'ye geliştiricinin sorduğu gibi bilgi verin: başarısız olan assertion, ilgili loglar, stack trace'ler ve tam yeniden üretim adımları.
AI sonra:
Önerilerini hipotez olarak değerlendirin; testleri tekrar çalıştırıp UI davranışını kontrol ederek doğrulayın.
Hızlı inceleme döngüleri için kısa bir listede tutun:
AI ile üretilen ilk taslak genellikle "tepki vermeye uygun"tur ama "yayınlanmaya hazır" değildir. Yineleme, gereksinimleri sıkılaştırarak, kenar durumlarını düzelterek ve küçük, gözden geçirilebilir adımlarla değişiklikler yaparak makul bir özelliği güvenilir hale getirir.
Sağlıklı döngü şu görünür: üret → gözden geçir → belirli bir değişiklik iste → ne değiştiğini karşılaştır → tekrarla.
Tüm uygulamayı yeniden sormak yerine hedefe yönelik güncellemeler isteyin. AI'den yalnızca bir parçayı (bir ekran, bir bileşen, bir doğrulama kuralı, bir sorgu) değiştirmesini ve bir diff veya net bir "önce/sonra" döndürmesini isteyin. Bu, değişikliğin problemi çözüp çözmediğini doğrulamayı kolaylaştırır.
İş akışınız destekliyorsa, değişiklikleri küçük commit'ler halinde tutun ve bir ekip arkadaşının pull request'ini inceler gibi diff'i tarayın, uygulamayı çalıştırın ve davranışı doğrulayın.
Koder.ai gibi platformlar için de bu yaklaşım faydalıdır: önce kapsam ve akışlarda anlaşın ("planlama modu"), sonra üretin, dar dilimlerle yineleyin ve deneme sırasında snapshot/rollback'e güvenin.
Belirsiz istekler (“daha iyi yap”, “akışı düzelt”) belirsiz sonuçlar verir. Güçlü değişiklik istekleri şunu belirtir:
Mümkünse kabul kriterleri ekleyin: “Gerekli alanlar doğrulanana kadar ‘Öde’ butonu devre dışı olsun” veya “Gönderim ülkesini değiştirince vergi anında yeniden hesaplansın.”
AI çıktısını kendi kodunuz olarak yönetin. Güncellemelerle kısa değişiklik notları (ne değişti, neden değişti, ne test edilmeli) talep edin.
AI bir refaktör önerecek olursa, amacını açıklamasını ve potansiyel riskleri listelemesini isteyin (ör. “bu doğrulama zamanlamasını değiştirir” veya “bu API yanıt işleme şeklini değiştirir”).
Yineleme, net sürüm kriterleri karşılandığında biter. Sınırlar belirleyin:
Bu noktada spesifikasyonu dondurun, yayınlayın ve bir sonraki yinelemeyi yeni, sınırlandırılmış bir değişiklik isteği olarak planlayın.
AI yazılı spesifikasyonları şaşırtıcı derecede eksiksiz özelliklere dönüştürebilir, ama yargı yerine geçmez. AI çıktısını bir taslak olarak ele alın—özellikle kullanıcı verileri, ödemeler veya izinler söz konusuysa dikkatli olun.
Bir prompt'a yapıştırdığınız her şeyin saklanabileceğini veya incelenebileceğini varsayın. Şunları yapıştırmayın:
Gerçekçilik gerekiyorsa, anonimleştirin: isimleri yer tutucularla değiştirin, ID'leri karıştırın ve ham ihracatlar yerine örüntüleri (“10k kullanıcı, 3 rol”) tanımlayın.
AI temel güvenlik kontrolleri oluşturmakta faydalıdır, ama bunları yine doğrulamanız gerekir.
Kod veya ekran istemeden önce şunları ekleyin:
Bir taslak prototipiniz olduğunda, hızlı bir inceleme planlayın: yol haritasıyla karşılaştırın, şimdi neyin yayınlanacağına karar verin ve değişiklikleri dokümante edin.
Taslakları bir plana dönüştürmenizde yardım isterseniz, /pricing sayfasını inceleyin veya ilgili rehberlere /blog bölümünden bakın. Sohbet odaklı geliştirmeyi keşfediyorsanız, Koder.ai bu iş akışı için tasarlandı: yazılı spesifikasyonları çalışan web, backend ve mobil özelliklere dönüştürün, hızlı yineleyin ve hazır olduğunuzda kaynak kodunu dışa aktarın.
"Yazılı talimatlar" niyeti (istediğiniz sonuç) ve sınırları (kısıtlar, kurallar ve neyin yasak olduğu) açıkça belirten herhangi bir metindir. Bu, hızlı bir Slack mesajı, bir PRD parçası, kullanıcı hikayeleri, kabul kriterleri veya kenar durumlar listesi olabilir—önemli olan biçim değil, açıklıktır.
“Çalışan” bir özellik genellikle görselin ötesinde şeyler içerir:
Bir mockup görünümü gösterir; çalışan bir özellik uçtan uca doğru davranır.
Çoğu ekip basit bir yineleme döngüsü kullanır:
Hız, hızlı taslaklardan; kalite ise disiplinli gözden geçirme ve yinelemeden gelir.
AI hızlı ilerleyebilir ama eğer belirtmezseniz varsayımlar yapar:
Bu öğeleri baştan eklemek yeniden işi azaltır ve işinizle uyuşmayan "makul varsayımları" engeller.
Dört temel öğeyle başlayın:
Bu, AI'ye hem yön hem de bir kalite çıtası verir, sadece bir fikir değil.
Somut spesifikasyonlar şunları tanımlar:
Bu ayrıntılar ekranlara, kurallara ve API davranışına doğrudan çevrilir.
Kod üretmeden önce AI'den bir özellik planı isteyin:
Bu, eksik gereksinimleri erken ortaya çıkarır; değişiklikler ucuzken çözülür.
Her önemli ekran durumu için açık tanımlar isteyin:
Üretim hataları ve kötü UX genellikle mutlu yol eksikliğinden değil, eksik durum ele alımından kaynaklanır.
AI genellikle metindeki "isimleri" çıkarır ve bunları varlıklar olarak ele alır; ardından şunları önerir:
Ayrıca veri yaşam döngüsünü de tarif etmesini isteyin: oluştur/güncelle/soft-delete ve gerekiyorsa denetim izi ya da sürümleme.
AI çıktısını bir taslak olarak görün ve koruyucu önlemler koyun:
AI yinelemeyi hızlandırır, ancak doğruluk, güvenlik ve kalite için insanlar hâlâ sorumludur.