03 May 2025·8 dk
Niyetten Uygulamaya: Yapay Zeka UI, Durum ve API'leri Oluşturduğunda
Bir mobil uygulama fikrinin, AI'nin UI oluşturduğu, durumu yönettiği ve backend hizmetlerini uçtan uca bağladığı süreçte çalışan bir ürüne dönüşme hikayesi.
Bir mobil uygulama fikrinin, AI'nin UI oluşturduğu, durumu yönettiği ve backend hizmetlerini uçtan uca bağladığı süreçte çalışan bir ürüne dönüşme hikayesi.
Bir kurucu, çeyrek sonu telaşından sonra geriye yaslanır ve der: saha temsilcilerinin ziyaretleri hızlıca kaydetmesine ve takipleri ayarlamasına yardım edin, böylece idari iş yükü artmasın ama hiçbir şey aksamasın.
O tek cümle gerçek bir kullanıcı sorununu barındırır: notlar geç (veya hiç) kaydediliyor, takipler kaçıyor ve gelir sessizce sızıntıya uğruyor.
Bu, AI destekli bir yapının vaadi: niyetle başlarsınız ve her ekranı, durum güncellemesini ve API çağrısını baştan elle örmeden telefon üzerinde çalışır bir mobil uygulamaya daha hızlı ulaşırsınız. "sihir" değil, anında kusursuzluk değil—ama fikirden birinin eline koyabileceğiniz bir şeye giden yol kısalır.
Bu bölüm (ve ardından gelen hikaye) teknik bir eğitim değil. Ne söyleyeceğiniz, erken neyi kararlaştıracağınız ve gerçek kullanıcılarla akışı test edene kadar neleri açık bırakacağınız konusunda pratik çıkarımlar içeren bir anlatı.
Basitçe söylemek gerekirse, niyet, istediğiniz sonuçtur, belirli bir kitle için, açık kısıtlar içinde.
İyi niyet bir özellik listesi değildir. "Bana bir mobil CRM yap" demek değildir. Başarıyı hem insanlar hem AI için neyin olduğunu söyleyen cümledir.
Niyet net olduğunda, tıklanabilir ekranlardan daha fazlasını hedefleyen bir MVP amaçlayabilirsiniz. Hedef, gerçek akışları ve gerçek verileri olan gönderilebilir bir uygulamadır: kullanıcılar oturum açabilir, bugünün hesaplarını görebilir, bir ziyareti kaydedebilir, not/fotoğraf ekleyebilir, bir sonraki adımı belirleyebilir ve yaygın istisnalarla başa çıkabilir.
Sonrasında gelen her şey—gereksinimler, bilgi mimarisi, UI, durum, backend entegrasyonu ve yineleme—o tek cümleye hizmet etmelidir.
Maya bu projenin PM'si ve kazara kurucusudur. Mobil uygulamaları yeniden icat etmeye çalışmıyor—çeyreklik bir son tarih fırsatı ortadan kaldırmadan önce bir uygulama yayınlamaya çalışıyor.
Takım bir takvim davetinde sığıyor: Maya, haftada birkaç saat ayırabilecek bir tasarımcı ve zaten iki uygulamayı bakımını yapan tek bir mühendis. 40 sayfalık bir spes yazmak, frameworkler tartışmak veya bir aylık atölye çalışması yapmak için zaman yok. Yine de beklentiler gerçek: liderlik kullanılabilir bir şey istiyor, sadece demo değil.
Maya'nın başlangıç materyalleri mütevazı:
Ayrıca notlarında kritik bir cümle var: Kullanıcı ana görevi bir telefonda iki dakikadan kısa sürede bitiremiyorsa, doğru şeyi inşa etmedik.
Bu MVP için "bitti", uçtan uca çalışan tek bir kullanıcı yolculuğudur:
Gösterişli panolar yok. Gizli menüler yok. Akışı engelleyen "sonra düzeltiriz" ekranları yok.
Uygulama mevcut bir backend'e bağlanmak zorunda—mobil için tasarlanmamış ve belgelemesi düzensiz API'ler. Bütçe kısıtlı, bu yüzden her yeni ekran kendini haklı çıkarmalı.
Bazı kılavuzlar vazgeçilmez: denetim kayıtları, gerekli yerlerde açık onam ve cihazda hassas verilerin gelişi güzel saklanmaması.
Ve burada gerilim var: Maya'nın on iyi fikri ve belki on çalışma günü var. Alternatifleri tartışmaya harcanan her saat, çekirdek yolculuğu birinin eline ulaştırmamak demek.
Amaç mükemmel bir spes yazmak değil. Hızlıca test edilebilir netliğe ulaşmak—hangi problemi çözdüğümüz, kimin için olduğu ve işe yarayıp yaramadığını nasıl bileceğimiz.
Bir dağınık cümle ile başlarsınız:
I want an app that helps our field reps log visits and follow up.
Sonra AI'dan onu sıkılaştırmasını istersiniz:
İstem: bu cümleyi problem bildirgesi olarak yeniden yaz ve 3 başarı metriği ekle. Kısa tut.
AI çıktısı (düzenlenmiş):
Problem bildirgesi: Saha temsilcileri ziyaret notlarını geç (veya hiç) kaydettiği için takipler kaçıyor; bu da kaybedilen gelir ve tutarsız müşteri deneyimine yol açıyor.
Başarı metrikleri:
Artık ekip hedefleyebileceği bir hedefe sahip, sadece bir özellik dileği değil.
Eğer bir vibe-coding iş akışı (örneğin Koder.ai gibi chat'te ürünü tanımlayıp yineleyerek çalışan bir platform) kullanıyorsanız, bu an büyük değer katar: sıkı niyet + metrikler, sistemin sonraki her şeyi üretmesi için "gerçek kaynak" olur.
Sonra roller ve görevleri çıkarın:
Kullanıcı rolleri:
En önemli görevler:
Bunları birkaç kullanıcı hikayesine kabul kriterleriyle çevirin:
İlk sürümü korumak için:
Her kararı tek bir akışa sabitleyin:
Open app → Log Visit → müşteri seç → not/fotoğraf ekle → sonraki adımı + vade seç → kaydet → takipler “Bugün”de görünür.
Bir istek bu akışı desteklemiyorsa, bir sonraki sürümü bekler.
Kuzey yıldızı akışı netleşince, AI onu herkesin okuyabileceği bir bilgi mimarisine (IA) çevirebilir—wireframe veya mühendislik diyagramlarına atlamadan.
Çoğu MVP için, birincil işi tam olarak destekleyen küçük bir ekran seti istersiniz. AI genellikle aşağıdakine benzer kısa bir liste önerir (ve siz düzeltebilirsiniz):
Bu liste iskelet olur. Dışındaki her şey sonraki sürüm veya ikincil akıştır.
Kalıpları soyutça tartışmak yerine, IA navigasyonu doğrulanabilir cümlelerle belirtir:
Onboarding varsa, IA onun nerede başlayıp Ana'da bittiğini tanımlar.
Her ekran için hafif bir taslak:
Boş durumlar genellikle uygulamaların kırık hissettiği yerlerdir; onları kasıtlı yazın (ör. "Bugün henüz ziyaret kaydedilmedi" ve açık bir sonraki adım).
IA koşullu görünümleri erken işaretler: "Yöneticiler ekstra bir sekme görür" veya "Sadece Operasyonlar hesap detaylarını düzenleyebilir." Bu, izinler ve durum uygulanırken sürprizleri önler.
Çıktı genellikle tek sayfalık bir akış ve ekran başına madde listeleridir—teknik olmayan bir paydaşın hızla onaylayabileceği: hangi ekranlar var, aralarında nasıl hareket ediliyor ve veri eksikse ne oluyor.
Akış kabul edildikten sonra, AI her adımı "ekran sözleşmesi" olarak ele alıp ilk taslak wireframeleri üretebilir: kullanıcı ne görmeli, bir sonraki adım ne olmalı ve hangi bilgiler toplanıp gösterilmeli.
Çıktı genelde kaba başlar—gri bloklar ve etiketler—ama zaten içerik ihtiyaçları etrafında yapılandırılmıştır. Karşılaştırma gerekiyorsa grid veya kart düzeni; ilerleme gerekiyorsa net bir birincil eylem ve hafif bir özet görürsünüz.
Bileşen seçimleri rastgele değildir. Göreve dayalıdır:
AI genellikle bu kararları niyetteki fiillerden türetir: browse, choose, edit, confirm.
Bu aşamada iyi jeneratörler ekranların "AI kokmamasını" sağlayan temel kısıtları uygular:
Kopya taslakları UI ile birlikte görünür. "Submit" yerine "Ziyareti kaydet" veya "Takvimi ayarla" gibi işe uygun düğmeler görülür.
Burada bir ürün sahibi, tasarımcı veya pazarlamacı devreye girer—her şeyi yeniden çizmek için değil, tonu ve netliği ayarlamak için:
Sadece resimlerle bitmez. Teslim genellikle bir tıklanabilir prototip (geri bildirim için ekranlar arası gezinme) veya takımın üzerinde yineleme yapabileceği üretilmiş ekran kodu olur.
Koder.ai gibi bir platformda çalışıyorsanız, UI genellikle çalışan bir uygulamanın parçası olarak hızla somutlaşır (web için React, backend Go + PostgreSQL, mobil için Flutter) ve gerçek ekranları bir yerde inceleyebilir, akış dokümanını kılavuz olarak tutabilirsiniz.
UI taslağı hazırlandıktan sonra soru basitleşir: uygulamanın neyi hatırlaması gerekiyor ve neye tepki vermeli? Bu "hafıza" durumdur. Bir ekran sizi isimle karşılayabilmesi, bir sayacı tutması, yarım kalan formu geri getirmesi veya sonuçları tercihlerinize göre sıralaması için durum gerekir.
AI genelde uygulama boyunca geçen küçük bir durum nesne seti tanımlar:
Anahtar nokta tutarlılık: aynı nesneler (ve isimler) onlarla etkileşen her ekranı güçlendirir, her ekran kendi mini modeli icat etmez.
Formlar sadece girdiler değildir—görünür kurallardır. AI, ekranlar arasında tekrar eden doğrulama desenleri üretebilir:
Her asenkron eylem (giriş, öğe alma, ziyaret kaydetme) için uygulama tanıdık durumlar arasında döner:
Bu desenler ekranlar arasında tutarlı olunca uygulama tahmin edilebilir olur ve gerçek kullanıcılar beklenmedik şekillerde dokunduğunda daha az kırılgan hissedilir.
Bir akış, okuma ve yazma gerçek verilerle olunca gerçek olur. Ekranlar ve durum kuralları oluşturulduktan sonra, AI kullanıcının ne yaptığını backend'in ne desteklemesi gerektiğine çevirir—sonra uygulamayı prototip olmaktan ürüne dönüştürecek bağlantıları üretir.
Tipik bir kullanıcı yolculuğundan backend gereksinimleri genelde birkaç somut başlıkta düşer:
AI bunları doğrudan UI niyetinden çıkarabilir. "Kaydet" düğmesi bir mutasyonu ima eder. Liste ekranı sayfalı bir fetch demektir. Filtre chip'i sorgu parametrelerini gerektirir.
Uç noktaları izole bir şekilde kurmak yerine, eşleme ekran etkileşimlerinden türetilir:
POST /visitsGET /accounts?cursor=...PATCH /visits/:idPATCH /followups/:idZaten bir backend'iniz varsa AI buna uyar: REST endpointleri, GraphQL işlemleri, Firebase/Firestore koleksiyonları veya özel bir iç API ile. Yoksa, UI ihtiyaçlarına uyan ince bir servis katmanı üretebilir (ve fazlasını yapmaz).
AI, UI kopyası ve durumdan modeller önerecektir:
Visit { id, accountId, notes, nextStep, dueAt, createdAt }Ama insan yine doğrular: hangi alanlar zorunlu, hangileri nullable, hangi alanlar indekslenmeli ve izinler nasıl çalışmalı. Bu hızlı inceleme, "neredeyse doğru" veri modellerinin ürüne katılaşmasını engeller.
Entegrasyon, hata yollarını birinci sınıf ele almadan tamamlanmaz:
AI sıkıcı parçaları hızlandırır—tutarlı istek sarmalayıcıları, typed modeller ve öngörülebilir hata durumları—takım doğruluk ve iş kurallarına odaklanır.
İlk gerçek test simülatör ekranı değil—bir telefonda birinin elindedir, zayıf Wi‑Fi üzerinde. Erken çatlaklar orada hızlıca görünür.
Genelde manşet özellik değil, dikişler bozulur:
Bu yararlı bir başarısızlıktır. Uygulamanın gerçekte neye bağımlı olduğunu söyler.
Bir şey bozulduğunda, AI en faydalı şekilde katmanlar arası bir dedektif olur. Sorunu UI, durum ve API'de ayrı ayrı kovalamak yerine, uçtan uca yolu izleyip tek bir düzeltme önerebilir:
profile.photoUrl beklerken backend avatar_url döndürüyor.AI akış, ekran haritası ve veri sözleşmeleri bağlamında bu bilgileri bildiği için doğru yerleri değiştiren tek bir düzeltme önerebilir—alanı yeniden adlandır, bir yedek durum ekle ve endpoint yanıtını ayarla.
Her test derlemesine başarı kriterinize bağlı küçük bir olay seti ekleyin, örneğin:
signup_started → signup_completedfirst_action_completed (aktivasyon anınız)error_shown ile neden kodu (timeout, doğrulama, izin)Artık geri bildirim sadece görüş değil—ölçülebilir bir hunidir.
Basit bir ritim işleri stabil tutar: günlük derleme + 20 dakikalık inceleme. Her döngü bir veya iki düzeltme seçer ve UI, durum ve uç noktalarını birlikte günceller. Bu, ekran doğru görünüp gerçek dünyadaki zamanlama, eksik veri veya kesintili izinlerle toparlanamayan “yarı düzeltilmiş” özellikleri önler.
Mutlu yol çalıştıktan sonra, uygulama tüneller, düşük pil modu, eksik izinler ve öngörülemeyen veriler gibi gerçek hayat koşullarında ayakta kalmalı. Burada AI, "bozulma"yı ekip inceleyebileceği somut davranışlara çevirerek yardımcı olur.
Her eylemi çevrimdışı-güvenli veya bağlantı-gerektirir olarak etiketleyin. Örneğin önceden yüklenmiş hesapları gözatma, taslak düzenleme ve önbellek geçmişini görüntüleme çevrimdışı çalışabilir. Tam veriyle arama, senkronizasyon ve kişiselleştirilmiş öneriler genelde bağlantı gerektirir.
İyi bir varsayılan: önbellekten oku, değişiklikleri outbox'a yaz. UI değişikliğin "Yerel olarak kaydedildi" mi yoksa "Eşlendi" mi olduğunu açıkça göstermeli ve bağlantı geri geldiğinde basit bir "Tekrar dene" sunmalı.
İzinleri gerektiği anda sorun:
Niyet, alternatifler sunmak; çıkmaz yollar değil.
AI kenar durumları hızlıca sıralar, ama takım ürün duruşunu seçer:
Güvenlik temelleri: tokenları platformun güvenli deposunda sakla, en az ayrıcalık ilkesi uygula ve güvenli varsayılanlarla gönder (ayrıntılı log yok, şifrelenmemiş "beni hatırla" yok).
Erişilebilirlik kontrolleri: kontrast, minimum dokunma hedefleri, dinamik metin desteği ve ekran okuyucu etiketlerini doğrula—özellikle yalnızca ikon içeren düğmeler ve özel bileşenlerde.
Yayınlama, umut vadeden bir prototipin gerçek bir ürüne dönüşmesi ya da sessizce durması arasındaki noktadır. AI UI, durum kuralları ve API bağlantılarını ürettiğinde, hedef bu çalışan derlemeyi gözden geçirip kullanıcıların güvenle kurabileceği bir hâle getirmektir.
"Yayın"ı kahramansı bir sprint yerine küçük bir kontrol listesi olarak ele alın:
MVP basit olsa bile meta veriler beklentileri belirlediği için önemlidir.
Lansmanı bir deney gibi planlayın.
İlk önce iç test kullanın, sonra kademeli dağıtım ile patlama yüzeyini sınırlayın. Çökme oranı, onboarding tamamlama oranı ve ana işlem dönüşümünü izleyin.
Geri alma tetiklerini önceden tanımlayın—örn. çökme oranı eşik değerin altına düşerse, giriş hataları artarsa veya ana huni adım oranı ani düşüş gösterirse geri alma tetiklenir.
Eğer build sistemi anlık görüntüler ve hızlı geri alma destekliyorsa (örneğin Koder.ai dağıtım ve barındırma ile birlikte anlık görüntü/geri alma sunuyorsa), geri almayı normal bir parça olarak ele alabilirsiniz.
Eğer MVP kontrol listenizi tekrar uygulanabilir bir yayın hattına dönüştürmek istiyorsanız, /pricing veya /contact üzerinden destek alabilirsiniz.
AI ekranları taslaklayıp, durum ve API entegrasyonlarını çizebildiğinde, iş ortadan kalkmaz—kayar. Takımlar niyeti tekrardan çeviren bürokratik işi daha az yapar ve neyi, kim için ve hangi standa getireceklerine karar vermeye daha fazla zaman harcar.
AI akış net olduktan sonra katmanlar arası tutarlı çıktılar üretmede güçlüdür:
AI önerir; insanlar karar verir.
Hız, kod okunabilir kaldığı sürece yardımcı olur.
Eğer ilk versiyonu Koder.ai gibi bir platformda üretiyorsanız, pratik bir sürdürülebilirlik faydası kaynak kodu dışa aktarımıdır: "hızlı üretim"den "takım sahipliğindeki kod tabanına" geçiş yaparken yeniden yazma yapmak zorunda kalmazsınız.
MVP yayınlandıktan sonra sonraki yinelemeler genelde performans (başlangıç süresi, liste render), kişiselleştirme (kaydedilmiş tercihler, daha iyi varsayılanlar) ve daha derin otomasyon (test üretimi, analitik enstrümantasyonu) üzerine odaklanır.
Daha fazla örnek ve ilgili okumalar için /blog'a göz atın.
Niyet, şunu netleştiren tek cümledir:
Bu bir özellik listesi değildir; UI, durum ve API'lerin hizalanmasını sağlayan başarı tanımıdır.
İyi bir niyet cümlesi spesifik ve test edilebilirdir. Bu yapıyı kullanın:
Örnek: Help small clinic managers confirm appointments automatically so no-shows drop without adding admin work. (Bu örnekte sayısal değerleri kendi bağlamınıza göre düzenleyin.)
“Gönderilebilir” olmak, uygulamanın tek bir çekirdek yolculuğu gerçek veriyle tamamlaması demektir:
Eğer kullanıcı ana görevi telefonda hızlıca tamamlayamıyorsa hazır değildir.
AI'den, fikrinizi şu iki çıktıya dönüştürmesini isteyin:
Sonra çıktıyı kendi alan gerçekliğinizle düzenleyin—özellikle sayıları—böylece faaliyet değil sonuçlar ölçülür.
Şuna odaklanın:
Kabul kriterlerini gözlemlenebilir tutun (ör. "kaydedilen zaman damgası", "bir sonraki adım gerekli VEYA not gerekli") ki mühendislik ve QA hızlıca doğrulayabilsin.
Kuzey yıldızı akışını desteklemeyen her şeyi kesinlikle çıkarın. İlk sürüm için yaygın dışarıda bırakmalar:
Açık bir “kapsam dışı” listesi yazın ki paydaşlar neyin kasıtlı olarak ertelendiğini bilsin.
Ana işi tamamen destekleyen 3–7 temel ekran ile başlayın:
Navigasyonu düz metinle tanımlayın (sekme mi yoksa stack mi) ve boş durumları belirtin ki uygulama veri yokken kırılmış hissetmesin.
Durum, uygulamanın neyi hatırlaması ve neye tepki vermesi gerektiğidir. Ortak MVP durum nesneleri:
Ekranlardan geriye doğru çalışın:
GET /items (sayfalanmış) anlamına gelirPOST veya PATCH gerektirirDELETE anlamına gelirHer eylemi çevrimdışı güvenli veya bağlantı gerektiren olarak etiketleyin. Pratik bir varsayılan:
İzinler için ihtiyacın olduğu anda sor (ör. kamera 'Fotoğraf ekle'ye dokununca). Reddedilirse, dosya yükleme veya manuel giriş gibi alternatifler sunun; çıkmaz yollar yerine nazik geri dönüşler sağlayın.
Ayrıca async durumları standartlaştırın: loading → success → failure, ve hata halinde kullanıcı girdisini saklayın.
AI şemalar önerebilir, ancak gerekli alanları, izinleri ve isim uyuşmazlıklarını (örn. photoUrl vs avatar_url) insan onayıyla netleştirin.