03 Mar 2026·5 dk
AI'dan Uygulama İstemeden Önce: Kurucuların Bilmesi Gerekenler
Yapay zekadan uygulama istemeden önce kurucular örnek veriler, hedef kullanıcılar, iş kuralları ve başarı metriklerini hazırlamalı; böylece ilk taslak daha uygun olur.
Yapay zekadan uygulama istemeden önce kurucular örnek veriler, hedef kullanıcılar, iş kuralları ve başarı metriklerini hazırlamalı; böylece ilk taslak daha uygun olur.
Çoğu kötü ilk taslak basit bir yüzden başarısız olur: prompt çok belirsizdir.
"AI'dan antrenörler için bir uygulama yapmasını isteyin" veya "ekibim için bir CRM oluştur" gibi isteklerde AI neyin önemli olduğunu tahmin etmek zorunda kalır. Bu tahminler genelde genel bir şey üretir — cilalanmış ekranlar, tanıdık akışlar ve faydalı görünen ama gerçek problemi çözmeyen özellikler.
AI hızlıdır, ama kullanıcılarınızı, istisnalarınızı veya günlük işi şekillendiren küçük kuralları bilmez. Bu bağlam yoksa, ilk sürüm genellikle yanlış ekranlar, gereğinden çok adım ve asla ihtiyaç duyulmamış özellikler içerir.
Onboarding iyi bir örnektir. Uygulamanın kimin için olduğunu açıklamazsanız, AI uzun bir kayıt akışı, birden fazla kullanıcı rolü ve grafiklerle dolu bir gösterge panosu oluşturabilir. Oysa kullanıcılarınız sadece basit bir form, tek bir onay adımı ve günlük bir görev listesine ihtiyaç duyuyor olabilir. Sonuç ilk bakışta etkileyici görünse de amacını kaçırır.
AI soyut fikirlerden çok somut örneklerle daha iyi çalışır. "Müşterilerin rezervasyonları yönetmesini istiyorum" hâlâ belirsizdir. Örnek bir rezervasyon tablosu, birkaç gerçekçi müşteri mesajı veya üç örnek kullanıcı profili modele etrafında inşa edebileceği bir şey verir. Uygulamada genellikle birkaç örnek kayıt, uzun bir özellik listesinden daha fazla yardımcı olur.
Bu, başlangıçta en çok önemlidir. Koder.ai gibi bir platform erken çalışan bir sürümü hızlıca üretebilir, ama hız girdiler net olduğunda işe yarar. Daha iyi bir brief ilk denemeyi kusursuz yapmaz, ama ilk sürümü niyet ettiğiniz şeye çok daha yakın tutar.
AI'dan bir şey istemeden önce uygulamanın ana işini bir cümleyle tanımlayın. Basitçe açıklayamıyorsanız, ilk taslak genelde çok fazla yapmaya çalışır ve hiçbir şeyi iyi yapmaz.
Kullanışlı bir format: "Bu uygulama [kullanıcıya] [görevi] [acıdan] kurtarmaya yardımcı olur."
Örneğin: "Bu uygulama satış temsilcilerinin ziyaretleri kaydetmesine ve takip notları göndermesine, elektronik tablolar kullanmadan yardımcı olur."
O kısa cümle büyük bir özellik listesinden daha önemlidir. AI'ya hangi problemi çözmesi gerektiğini, neyi önceliklendireceğini ve neyin bekleyebileceğini söyler.
Bundan sonra fikirlerinizi üç kovaya ayırın: birinci sürümde olması gerekenler, sonra eklenebilecekler ve şu an kapsam dışı olanlar. Her şeyi önemli olarak işaretlerseniz ürün odağını kaybeder. Kurucular genelde sohbet, raporlar, faturalama, admin rolleri ve mobil erişim isterken gerçek iş çok daha küçüktür — örneğin kullanıcıların hizmet talepleri göndermesine ve takip etmesine yardımcı olmak gibi.
Ayrıca bir kullanıcının bir oturumda neyi bitirmesi gerektiğini tanımlamak yardımcı olur. Belki randevu ayarlamalı, bir müşteri listesi yüklemeli, bir talebi onaylamalı veya fatura oluşturmalıdır. Bu net bir bitiş çizgisi oluşturur.
Ana iş net olduğunda AI ekranlar, akışlar ve varsayılanlar hakkında daha iyi seçimler yapar. Bu genelde kalabalık bir demo ile gerçekten kullanışlı bir ilk yapı arasındaki farktır.
Eğer hedef kitleniz "buna ihtiyacı olabilecek herkes" ise uygulama neredeyse her zaman genel hisseder.
Erken ürünler bir veya iki net kullanıcı grubuna odaklandığında daha iyi çalışır. En çok kimlerin önemli olduğunu adlandırarak başlayın: uygulamayı sık kullanan birincil kullanıcılar, işi gözden geçiren veya onaylayan ikincil kullanıcılar ve daha sonra eklenebilecek kişiler.
Sonra her grubun ne yapmaya çalıştığını açıklayın. Pratik olun. Bir satış yöneticisi takım aktivitesini gösteren tek bir ekran isteyebilir; bir temsilci ise telefondan 20 saniyede arama kaydetmek isteyebilir. Bunlar çok farklı ihtiyaçlardır ve uygulama hangisini vurguladığınıza bağlı olarak farklı görünür.
Tam bir persona dokümanına gerek yok. Birkaç basit detay yeterlidir: kullanıcının beceri seviyesi, uygulamayı kullanırken nerede olduğu, benzer araçları ne sıklıkla kullandığı ve en çok hangi cihazı tercih ettiği. Masada oturan biri daha fazla ayrıntıyı kaldırırken, sahadaki biri genellikle daha az adım, daha büyük düğmeler ve daha güçlü varsayılanlar ister.
Ayrıca birinci sürümü kimlerin şekillendirmemesi gerektiğini belirtmek faydalıdır. Belki güçlü kullanıcılar sonra önemli olur. Belki yöneticiler sonunda raporlar ister. Ama ilk hedefiniz ön saftaki personelin tek bir görevi daha hızlı bitirmesine yardımcı olmaksa odak orada olsun.
Bu adım temel görünse de çıktıyı çok değiştirir. Net kullanıcı tanımları daha iyi ekranlar, daha iyi akışlar ve sadece etkileyici görünen daha az özellik getirir.
Özellik fikirleri AI'ya yüzeyde ne istediğinizi söyler. Örnek veriler uygulamanın gerçekten nasıl çalışması gerektiğini gösterir.
"Gösterge panosu, giriş, raporlar" gibi bir liste modele hangi ekranları üretmesi gerektiğini söyler ama üzerinde ne olması gerektiğini söylemez. Gerçekçi kayıtlar yapıyı hemen verir.
İyi bir başlangıç 10–20 örnek satırdır. Bir CRM için bu, isimler, şirket büyüklüğü, aşama, notlar ve sonraki takip tarihleri içeren fırsatlar olabilir. Bir rezervasyon aracı için randevu türleri, saat dilimleri, iptaller ve müşteri mesajları yer alabilir.
Önemli olan mükemmellik değil gerçekçiliktir. Dağınık örnekler temiz sahte verilerden daha iyidir çünkü gerçek işler dağınıktır. Bir müşteri her alanı doldurur. Başkası yarısını boş bırakır. Biri telefonu yanlış biçimde girer. Başkası kısa cevap beklerken uzun bir not yazar. Bu detaylar AI'nın formlar, doğrulama, filtreler ve hata yönetimi hakkında daha iyi seçim yapmasına yardımcı olur.
Örneklerinizin insanlar gerçekten hangi alanları girip düzenleyeceğini, arayıp inceleyeceğini içerdiğinden emin olun. Basit bir sipariş uygulaması sadece siparişten daha fazlasına ihtiyaç duyabilir: durum, ödeme yöntemi, iade nedeni, dahili notlar ve zaman damgaları gibi.
Hızlı bir kontrol yararlıdır. Örnek veriler ekibinizin zaten kullandığına benzemeli, yaygın hataları içermeli, normal durumları ve birkaç sıra dışı durumu kapsamalı ve paylaşmadan önce gizli bilgileri çıkarmalıdır. Amaç işin şeklini korumak, hassas bilgiyi ifşa etmek değil.
Özellikler uygulamanın ne olması gerektiğini anlatır. İş kuralları nasıl davranması gerektiğini anlatır.
Burada birçok ilk taslak çöker. "Kullanıcılar faturaları yönetebilir" derseniz AI bunun ne anlama geldiğini tahmin etmek zorunda kalır. Çok daha iyi bir versiyon: "personel taslak oluşturabilir, yöneticiler 1.000$ üzeri faturaları onaylar ve sadece yöneticiler gönderilmiş faturaları silebilir." şeklinde açık kurallar verin.
Kuralları basit dille yazın. Parayla, onaylarla, izinlerle ve durum değişiklikleriyle ilgili olanlarla başlayın. Kim oluşturabilir, kim düzenleyebilir, kim onaylar, kim dışa aktarır veya siler? Hangi durum inceleme gerektirir? Ödeme başarısız olduğunda ne olur? Veri eksikse ne olur? Bir şey nasıl taslaktan onaylanmış, reddedilmiş veya kapatılmış hale gelir?
Bu detaylar zaman kazandırır çünkü AI boşlukları ortak kalıplarla doldurur ve ortak kalıplar çoğu zaman sizin işiniz için yanlıştır.
Kenar durumlar kurucuların beklediğinden daha önemli olur. Normal bir kural müşteri siparişi her zaman iptal edebilir diyebilir. Ama sipariş zaten gönderildiyse, özel bir ürün içeriyorsa veya yeniden kullanılamayan bir kuponla verildiyse ne olur? Bu istisnalar mantığı değiştirir.
Kural sayfanız uzun olmak zorunda değil. Bir sayfa genelde yeterlidir. Sade cümleler kullanın ki tüm ekip anlayabilsin.
Eğer Koder.ai gibi sohbet tabanlı bir araçla inşa ediyorsanız, net kurallar genelde ilk sürümü oldukça iyileştirir. Uygulama sadece doğru görünmekle kalmaz, işiniz gibi davranır.
İyi metrikler uygulamanın insanların işi yapmasına gerçekten yardımcı olup olmadığını söyler.
Hemen kontrol edebileceğiniz küçük bir sayı seti seçin, ideal olarak ilk hafta içinde. İşe bağlı ölçümlerle başlayın. Uygulama satış takibi içindeyse lider kaydetme süresini, kaç takip tamamlandığını ve önemli detayların ne sıklıkla eksik olduğunu ölçün. Sahadaki personel için günlük tamamlanan görev sayısı, hata oranı veya manuel giriş için harcanan süre gibi ölçüler işe yarar.
Yararlı bir metrik sonraki adımınızı değiştirmeli. Sayı değişince bir özelliği tutup tutmayacağınıza, değiştireceğinize veya kaldıracağınıza karar verebilmelisiniz. Bu yüzden gösterişli metrikler genelde zaman kaybettirir. Toplam kayıtlar, sayfa görüntülemeleri ve indirmeler hoş görünse de kullanıcılar ana görevi tamamlayamıyorsa pek bir şey anlatmaz.
Basit erken metrikler en iyisidir: ana görevde kazanılan zaman, kritik adımlardaki hata azalması, desteğe ihtiyaç olmadan tamamlanan görevler, ana akışın tamamlanma oranı ve ilk denemeden sonraki tekrar kullanım.
Anlaşılır bir hedef belirleyin. Teklif oluşturma süresini 20 dakikadan 5 dakikaya indirin. Sipariş giriş hatalarını yarıya indirin. Test kullanıcılarının 10 üzerinden 7'sini ana akışta yardım almadan geçirin.
Sürüm bir için genelde üç net metrik yeterlidir. Başarının neye benzediğini bildiğinizde uygulama doğru ekranlara, alanlara ve kurallara odaklanır.
AI'ya uygulama yaptırmadan önce tam bir ürün şartnamesine ihtiyacınız yok. Bir sayfalık net bir özet genelde yeterlidir.
Düz bir dilde brief ile başlayın. Uygamanın kimin için olduğunu, yapması gereken ana işi, birkaç örnek kayıt veya giriş örneğini, uyması gereken kuralları ve iyi bir sonucun nasıl görüneceğini yazın.
Sonra özellikleri önceliğe göre ayırın. İlk sürümde ne olması gerektiğine, sonra eklenebileceklere ve kapsam dışına karar verin. Bu, ilk yapının kalabalık bir prototipe dönüşmesini engeller.
Ardından bu brief'i tek odaklı bir prompte dönüştürün. Ana problemi önce çözen bir ilk sürüm isteyin, tüm kenar durumlarını aynı anda kapsamak yerine.
Çıktı geldiğinde küçük parçalar halinde inceleyin. Akışı, veri alanlarını ve ana kuralları kontrol edin. Sonra her seferinde bir geliştirme isteyin.
Basit bir örnek farkı gösterir. Zayıf bir prompt: "Bana CRM, planlama, faturalama, sohbet ve raporlarla bir CRM oluştur." Daha güçlü bir prompt: "İki kişilik bir hukuk ekibi için müşteri kabul uygulaması oluştur. Kullanıcılar idari personel ve avukatlar. Örnek veriler: müşteri adı, dava türü, aciliyet ve alınan belgeler. Bir dava açılmadan önce çekişme kontrolü yapılmalı. Başarı, personelin yeni bir kabulü 3 dakikadan kısa sürede oluşturabilmesi demektir."
İkinci prompt modele açık bir şey verir: kullanıcıları, veriyi, kuralları ve hedefi adlandırır.
Bir kurucunun ev hizmetleri için rezervasyon uygulaması inşa ettiğini hayal edin. İlk prompt şu olabilir: "Temizlik rezervasyonları için bana bir uygulama oluştur." AI bundan bir şey üretebilir, ama sonuç genelde genel olur.
Şimdi biraz hazırlık yapan kurucuyla karşılaştırın.
Üç kullanıcı grubunu tanımlarlar: işleri ayırt eden müşteriler, işleri kabul edip tamamlayan personel ve programlama, fiyatlama ve ödemeleri yöneten işletme sahibi. Gerçekçi örnek veriler getirirler: tarihler, saatler, adresler, hizmet türleri ve fiyatlar içeren 10 örnek rezervasyon; birkaç iptal, bunlardan birinde geç ücret; çevrimiçi ödemeli, hizmet sonrası ödeme, başarısız kart ve kısmi iade gibi birkaç ödeme durumu; personel uygunluğu; tekrar müşteriler ve kaydedilmiş tercihleri.
Bu adım taslağın kalitesini değiştirir. AI doğru ekranları, alanları ve eylemleri üretme olasılığı daha yüksektir. Müşteri rezervasyon akışı, personel için günlük işler görünümü ve işletme sahibine gerçek işe uygun bir pano oluşturabilir.
İş kuralları sonucu daha da iyileştirir. Kurucu aynı gün rezervasyonların ekstra ücretli olduğunu, personelin çift rezervasyon yapılamayacağını ve iki saat içinde yapılan iptallerin ücretlendirme gerektirdiğini açıklarsa, uygulama ilk günden iş gibi davranmaya başlar.
Başarı metrikleri daha da netleştirir. Hedef rezervasyon hatalarını azaltmak, programlamayı hızlandırmak ve tamamlanan ödemeleri artırmaksa, ilk sürüm rasgele özellikler yerine bu sonuçlara göre şekillendirilebilir.
İşte kaba bir demoyla işe yarar bir ilk yapı arasındaki fark bu.
En büyük hata tüm ürünü ilk prompta paketlemeye çalışmaktır.
Kurucular genelde aynı anda onboarding, ödemeler, yönetici araçları, analitik, bildirimler, entegrasyonlar ve birden çok kullanıcı tipi ister. Sonuç genelde geniş, dağınık ve değerlendirmesi zor olur.
Daha iyi bir başlangıç daha küçüktür. İlk sürümün ana işini kanıtlayan şeyi isteyin, sonra genişletin.
Bir diğer yaygın hata düzenli görünen, ama gerçek sorunları gizleyen sahte veri kullanmaktır. Kusursuz isimler, temiz adresler ve düzenli durum alanları gerçek operasyonlarda nelerin olduğunu göstermez. Gerçek veride kopyalar, eksik değerler, garip tarih formatları ve sıra dışı durumlar vardır. Bu detaylar uygulamanın nasıl olması gerektiğini şekillendirir.
İzinler de kolayca atlanan bir konudur. Fiyatları kim düzenleyebilir? İadeleri kim onaylar? Müşteri notlarını kim görebilir? Bu kurallar net değilse uygulama demo'da iyi görünür ama ekip kullanmaya başlayınca başarısız olur.
Ayrıca hedefin inşa sürecinde sürekli değişmesi sorun yaratır. Pazartesi uygulama dahili operasyonlar için. Çarşamba müşteri portalı oluyor. Cuma mobil öncelikli olması gerekiyor. Bu noktada AI tek bir ürünü geliştirmiyor; her birkaç günde farklı bir problemi çözmesi isteniyor.
İlk taslak için bir net hedef tutun. Sonra öğrendiklerinize göre revize edin, her yeni fikri hemen eklemeyin.
Göndermeden önce beş dakika durup temel soruları kontrol edin.
Bir ana kullanıcı ve bir ana görevi adlandırabiliyor musunuz? "Küçük işletmeler" değil, "her şeyi yönet" de değil. Örnek: "Bir satış yöneticisi yeni lead'leri gözden geçirip 2 dakikadan kısa sürede takip atamak istiyor." gibi spesifik olun.
Örnek veriye sahip misiniz? Birkaç gerçekçi kayıt, ekran görüntüsü veya giriş örneği AI'ya uzun bir istekten çok daha fazlasını söyler.
Kuralları yazdınız mı? Basit ve doğrudan tutun: kim neyi görebilir veya düzenleyebilir, bir durum değişince ne olur, hangi alanlar zorunlu ve hangi onaylar veya limitler önemli.
İki veya üç uygulanabilir başarı metriği seçtiniz mi? Görevin tamamlanma süresi, hata oranı, adım sayısı ve tamamlanma oranı iyi başlangıç noktalarıdır.
Bu sorulara net cevap verebiliyorsanız, ilk prompt muhtemelen yeterince güçlüdür.
İyi ilk sürümler genelde daha uzun promt'tan değil, daha iyi hazırlıktan gelir.
Gerekli bilgileri tek bir paylaşılan dokümana koyun: uygulamanın ana işi, hedef kullanıcılar, örnek veri, iş kuralları ve birkaç başarı metriği. Bu detaylar notlar ve mesajlar arasında dağılırsa önemli bağlam kaybolur ve ilk yapı genel hisseder.
Basit bir başlangıç brief'i yeterlidir. Kim için olduğu, ilk önce ne yapmaları gerektiği, küçük bir gerçekçi örnek veri kümesi, her zaman uyulması gereken kurallar ve uygulamanın işe yaradığını söyleyecek birkaç metrik olsun.
Brief hazır olunca, sohbet tabanlı bir yapıcı kullanarak onu ilk sürüme çevirin. Amaç mükemmel değil. Amaç test edip iyileştirebileceğiniz kullanılabilir bir taslaktır.
Koder.ai kullanıyorsanız, planlama modu inşa etmeye çok fazla dalmadan önce uygulamayı şekillendirmenize yardımcı olduğu için pratik bir başlangıçtır. Ondan sonra sonucu sohbette rafine edin ve her seferinde bir problemi düzeltin.
İlk yapıyı incelerken sadece içgüdüyle yargılamayın. Kullanıcıya uyup uymadığına, örnek verilerle eşleşip eşleşmediğine, iş kurallarını takip edip etmediğine ve önemli olduğunu söylediğiniz sonucu destekleyip desteklemediğine bakın.
Sonra bir sonraki prompt'u başarısızlıktan yola çıkarak yazın, baştan değil. "Onboarding'i iyileştir" demek yerine "yeni kullanıcılar için sadece üç zorunlu alan göster, şirket büyüklüğünü örnek veriden otomatik doldur ve tamamlanma oranını takip et" deyin. Bu, kaba bir ilk taslağın daha hızlı işe yarar bir şeye dönüşmesini sağlar.
Kısa ve sade bir brief ile başlayın: uygulamanın ana işi, birincil kullanıcı, birkaç gerçekçi örnek veri ve temel iş kuralları. İki veya üç başarı metriği ekleyin ki ilk yapı için net bir hedef olsun.
AI eksik bağlamı genel kalıp ve varsayımlarla doldurur. Prompt genişse, kullanıcıları, akışları ve özellikleri tahmin ederek genelde gerçek işi çözmeyen, gösterişli ama işe yaramayan sonuçlar üretir.
Yabancı biri ana görevi tek cümlede anlayabilecek kadar spesifik olun. Kullanışlı bir format: “Bu uygulama [kullanıcıya] [görevi] [acıdan] kurtarmaya yardımcı olur.” Bu yapı AI'ya ne önceliklendireceğini söyler.
Evet. Örnek veriler uygulamanın yapısını gösterir ve AI'nın doğru alanları, formları, filtreleri ve varsayılanları seçmesine yardımcı olur. Pek çok durumda 10–20 gerçekçi kayıt uzun bir özellik listesinde olduğundan daha faydalıdır.
Gerçek işlemi andıran veriler kullanın, kusursuz demo verileri değil. Normal durumlar, birkaç yanlış veya eksik değer ve sıra dışı örnekler ekleyin. Paylaşmadan önce gizli bilgileri çıkarmayı unutmayın.
Sürüm bir için bir ana kullanıcıya odaklanın ve gerekiyorsa bir onaylayıcı veya gözden geçiren tanımlayın. Çok fazla rol başta, ilk yapıyı geniş ve test etmesi zor hale getirir.
Parayla, onaylarla, izinlerle ve durum değişiklikleriyle ilgili kurallarla başlayın. Kim oluşturabilir, kim düzenleyebilir, kim onaylar, kim silebilir veya kaydı bir sonraki aşamaya taşıyabilir—bunları belirtmezseniz taslak demo görünür ama yanlış davranır.
Uygulamanın ana işine bağlı birkaç ölçü seçin: görevin tamamlanma süresi, hata oranı, tamamlanma oranı veya tekrar kullanım gibi. Erken metrikler net bir eylem belirlemeli—numara hareket edince ne yapacağınızı bilmeliyseniz işe yarar.
İlk prompt'u dar ve ana işe odaklı tutun. Tüm özellikleri bir kerede istemek genelde karmaşık, kalabalık bir taslak üretir; daha küçük bir istek, neyin işe yaradığını görmeyi kolaylaştırır.
Sıfırdan başlamayın. İlk yapıyı kullanıcılarınız, örnek verileriniz, kurallarınız ve metriklerinizle karşılaştırın, sonra alan sayısını azaltma, akışı sadeleştirme veya izinleri sıkılaştırma gibi tek bir net değişiklik isteyin.