Klasörde Yaşayan 25 Sahte Müşteri: AI Persona Simülasyonuyla Fiyat Motorumuzu Test Ettik

Bilgisayarlarımızdan birinde, dışarıdan bakınca sıradan görünen bir klasör var. İçinde 25-30 dosya ve her dosyada bir insan "yaşıyor": pazaryeri kurmak isteyen bir girişimci, üyelik sistemi peşinde koşan bir topluluk yöneticisi, sekiz sayfalık tanıtım sitesi isteyen bir esnaf. Zamanla o klasörü kendi yaşam alanlarına çevirdiler — her personanın kendi dosyası, kendi geçmişi ve kendi günlüğü var. Bu klasör, aynı zamanda bizim AI ile yazılım testi laboratuvarımız.

Bu kasabanın sakinleri boş oturmuyor. Onları belirli aralıklarla "göreve" gönderiyoruz: geliştirdiğimiz ürünlerden birini baştan sona kullanmaya. Görevden döndüklerinde yaşadıklarını günlüklerine işliyorlar ve bir sonraki teste o birikimle gidiyorlar. Temmuzun başında kasabadan bir grup, bir ajansın teklif süreçlerini otomatikleştiren iç ürünümüzü — akıllı bir fiyat teklif motorunu — test etmeye gitti.

Pazaryeri isteyen girişimci beş soruluk akışı doldurdu; motor ona yaklaşık 398 TL'lik bir teklif çıkardı. Aynı motor, sekiz sayfalık basit site isteyen esnafa da 398 TL diyordu. SaaS platformu düşünene de. Oysa test suite'imiz o sırada yemyeşildi, tsc temizdi, akış saat gibi çalışıyordu. AI ile yazılım testi denememiz daha ilk turlarda işin kalbindeki bug'ı bulmuştu: unit testlerimiz bizim düşündüğümüz senaryoları doğruluyordu, müşterilerin yaşayacağı senaryoları değil.

Bu yazı o deneyin hikâyesi — ama bir başarı hikâyesi pazarlaması değil. Kurguyu nasıl kurduğumuzu, literatürün buna ne dediğini, deneyin neyi yakalayıp neyi asla yakalayamayacağını, maliyeti ve sınırlarıyla birlikte anlatacağız.

Klasörde Yaşayan Bir Kasaba: Kurguyu Nasıl Kurduk

Fikir basit bir sorudan doğdu: test kullanıcılarını her seferinde sıfırdan üretmek yerine, onları kalıcı karakterlere çevirsek ne olur? Cevabımız bir klasör oldu. Her persona kendi dosyasında yaşıyor: kim olduğu, hangi sektörden geldiği, ne istediği, bütçe beklentisi, teknik okuryazarlığı ve — en değerli kısım — geçmiş testlerden biriktirdiği deneyimler. Kasabanın nüfusu 25-30 kişi ve herkesin sicili kayıt altında.

Personaları rastgele üretmedik. Geçmiş tekliflerimizin, müşteri görüşmelerimizin ve destek taleplerinin çeşitliliğini yansıtan gerçek arketiplerden türettik; aralarına bilinçli olarak uç senaryolar da serpiştirdik: çoklu dil isteyen marka, harita entegrasyonu bekleyen işletme, "sadece bir sayfa yeter" diyen minimalist. Sentetik kullanıcı testi ancak nüfusu çeşitliyse işe yarıyor; 25 kopya persona, tek personadan daha akıllı değil.

Kasabanın işleyişinde iki kural var. Birincisi: personalar projelere her build'de değil, anlamlı milestone'larda gönderiliyor — yeni bir akış eklendiğinde, fiyatlama mantığı değiştiğinde, canlıya çıkış yaklaştığında. Her commit'te 30 kişiyi sahaya sürmek hem gürültü hem maliyet üretir; biz onları önemli anlarda çağırmayı tercih ediyoruz. İkincisi: her görev dönüşünde persona kendi dosyasını ve günlüğünü güncelliyor. Pazaryeri girişimcimizin günlüğünde artık "teklif akışında proje tipimi sordular ama fiyat sanki hiç umursamadı" gibi notlar var; bir sonraki testte oradan devam edecek.

Kulağa oyun gibi geldiğinin farkındayız. Ama kurgunun pratik bir karşılığı var: kalıcı dosyalar sayesinde her test turu sıfır bağlamla başlamıyor, personalar önceki bulguların üstüne soru soruyor ve biz de "geçen turda ne değişti?" karşılaştırmasını bedavaya alıyoruz. AI destekli QA'in en ucuz hafıza mekanizması, bir klasör dolusu Markdown dosyası çıktı.

Literatürde Bunun Bir Adı Var: Synthetic User Testing

Bu kurguyu biz icat etmedik; hatta kasaba metaforunu literatürden ödünç aldık. Kanonik referans, Stanford'un 2023 tarihli "Generative Agents" makalesi: araştırmacılar 25 AI ajanını Sims benzeri sanal bir kasabaya yerleştirdi ve ajanlar plan yapmak, sohbet başlatmak, ilişki kurmak gibi inandırıcı insan davranışları sergiledi. O makalede ajanların davranışını inandırıcı kılan şey hafıza akışıydı — bizim günlük dosyalarımız, aynı fikrin ev yapımı hâli.

2026'ya geldiğimizde bu yaklaşım bir "hack" olmaktan çıkıp adlandırılmış bir pratiğe dönüştü: synthetic user testing, LLM-as-user ya da persona-based testing. PersonaTester framework'ü (Mart 2026), LLM ajanlarına test zihniyeti, keşif stratejisi ve etkileşim alışkanlığından oluşan üç boyutlu personalar enjekte ederek GUI testi yapıyor; baseline'lara göre %117-126 iyileşme, 100'den fazla crash ve 11 fonksiyonel bug raporluyor.

Daha eski GPTDroid çalışması, LLM'i insan gibi davranan bir test uzmanına çevirip 93 mobil uygulamada en iyi baseline'ı activity coverage'da %32 farkla geçmiş ve %31 daha fazla bug yakalamıştı. DroidAgent ise ajanların kendi test niyetini üretip somut operasyonlara çevirdiği amaç odaklı testin hakemli örneği. Bu ajanların temelde nasıl çalıştığını merak ediyorsanız AI agent nedir yazımızda mimariyi detaylı anlatmıştık.

Bizim kurulumumuz bu çalışmaların yanında mütevazı kalıyor ama kritik bir ortak kararı paylaşıyor: personaların cevaplarını mock'lanmış bir fonksiyona değil, gerçek sisteme karşı koşturduk. Her persona, veri tabanının izole bir test branch'i üzerinde soru akışını gerçekten doldurdu ve quote route'tan gerçek teklif aldı. Mock'lar bizim varsayımlarımızı içerir; bug da zaten varsayımdaydı.

▶ Summit '25 Sahnesinden

“Yarın tester'a, developer'a ihtiyaç olacak mı bilmiyoruz ama test etmeye ve development'a ihtiyaç olacak ve buna adapte olanlar daha önde olacak.”

— Melih Sakarya (Testinium)

Konuşmanın tamamını izleyin →

Vaka: AI ile Yazılım Testi Sahada — Üç Sorunun Cevabı Fiyatı Hiç Etkilemiyordu

Görevden dönen personaların çıktılarını bir matrise döktük: hangi persona, hangi cevabı verdi, ne teklif aldı? Yan yana koyunca belirti hemen göze battı: proje tipleri arasında uçurum olan personalar neredeyse aynı fiyatları alıyordu. Pazaryeri isteyen girişimci ile sekiz sayfalık basit site isteyen esnaf aynı tavana çarpıyordu: taban_ucret + sayfa_8_plus, o günkü placeholder fiyatlarla yaklaşık 398 TL.

Teşhis için personaları bir kenara bırakıp koda döndük. Soru akışı şu sıradaydı: sektor (1) → hedef (2) → mevcut_varlik (3) → sayfa_sayisi (4) → db_yonetimi (5). Kök neden: quote route yalnızca sayfa_sayisi ve db_yonetimi cevaplarını okuyordu. İlk üç sorunun cevabı veri tabanına kaydediliyor ama fiyat hesabına hiç girmiyordu. Kullanıcı "pazaryeri kuracağım" da dese "kartvizit sitesi istiyorum" da dese, motor için fark yoktu.

Burada iki katmanı ayırmak önemli. 398 TL'lik saçma tavan, henüz gerçek fiyatlar girilmemiş placeholder seed verisinin sonucuydu — asıl bug o rakam değildi. Asıl bug, üç sorunun cevabının fiyatı hiç etkilememesiydi; gerçek fiyatlar girilse bile pazaryeri projesi basit site fiyatına sıkışmaya devam edecekti. Dersimiz tek cümle: testler kodun yazdığını doğrular, personalar ise kodun yazmadığını görünür kılar.

Çözüm: "Özel Yapı" Tripwire Sorusu ve Gerçek Fiyat Verisi

Çözüm iki katmanlı oldu. Birincisi yapısal: akışın 5. sırasına ozel_yapi adında bir tripwire sorusu ekledik (db_yonetimi 6. sıraya kaydı): "Projeniz standart bir site mi, yoksa pazaryeri, üyelik sistemi, mobil uygulama, harita entegrasyonu ya da çoklu dil gibi özel bir yapı mı içeriyor?" Cevap ozel_yapi_var ise quote route fiyat hesabına hiç girmiyor; lead needs_custom_quote statüsüne işaretleniyor ve kullanıcıya "Bu proje özel bir teklif gerektiriyor. Ekibimiz en kısa sürede sizinle iletişime geçecek." mesajı dönüyor. Otomatik fiyatlanamayacak projeyi yanlış fiyatlamaktansa hiç fiyatlamamak, verebileceğimiz en dürüst mühendislik kararıydı.

Doğrulamayı personalara bırakmadık: regression testlerinin tamamı geçti, tsc temiz çıktı. Persona bulgusu hipotezdi; kanıtı gerçek testler ve gerçek sorgular üretti.

İkinci katman veriydi: placeholder fiyatları, gerçek geçmiş tekliflerimize dayanan pricing_rules değerleriyle değiştirdik — referans noktalarından biri, altı haneli TL bandında, 8-10 haftalık bir projeydi. Kalem kalem rakamları burada dökmeyeceğiz; yapının mantığı şöyle: taban ücret sembolik denecek kadar düşük tutuldu ve yalnızca tek sayfalık, "olduğu gibi" temel kurulumu kapsıyor. Gerçek maliyet ise dört-beş haneli TL mertebesindeki ek kalemlerde toplanıyor: sayfa paketleri, revizyon talepleri, aylık veri tabanı yönetimi ve saatlik danışmanlıklar.

Saatlik ve talep başına kalemler için per_unit adında üçüncü bir fiyatlama türü ekledik ve fiyatları USD'ye bağladık: her teklifte canlı kur çekiliyor, 24 saat önbellekleniyor.

Personaların Göremediği Bug: SDD Review'ları ve N+1 Avı

İşin ironik tarafı: kasaba halkının test ettiği bu motoru büyük ölçüde AI yazmıştı. Prototip, Claude Code üzerinde subagent-driven development (SDD) akışıyla, vibe coding hızında ama disiplinli kuruldu: plandaki her task için taze bir subagent açılıyor, ardından iki aşamalı review koşuyor — önce spec uyumu, sonra kod kalitesi; kritik bulgular ilerlemeyi blokluyor. Diff review'ları soyut bir vaat değil: paketlerde secret sızıntısı taraması ve metin tutarlılığı kontrolleri gibi somut adımlar koşuldu.

Bu katman, personaların asla göremeyeceği bir bug'ı yakaladı. Oturum kayıtlarını listeleyen bir fonksiyon, 49 kayıt için 1 liste sorgusu + kayıt başına 2 ek sorgu = 99 ardışık HTTP round-trip yapıyordu; test verisi birikince test 20 saniyelik timeout'a çarptı. Fix tek sorguydu: çift LEFT JOIN + GROUP BY + COUNT(DISTINCT) — join fan-out tuzağına karşı bilinçli bir tercih. Süre 20 saniyeden yaklaşık 1,9 saniyeye düştü.

İki katmanın iş bölümü net: personalar ürünün önünden bakar ve "bu çıktı mantıksız" der; SDD review kodun içinden bakar ve "bu sorgu deseni patlayacak" der. N+1'i personalar fark edemezdi çünkü bu bir iç listeleme fonksiyonuydu ve ürün önden sorunsuz çalışmaya devam ediyordu — sadece mimari çürüktü.

Dürüst Değerlendirme: Beş Soruya Beş Cevap

Bu deney ne kadar gerçekçi?

Sınırlı ölçüde. Personalarımız gerçek müşteri değil; bir LLM'in ürettiği karakterler, modelin eğitim verisindeki "tipik müşteri" imgesine yakınsama eğiliminde — buna dağılım yanlılığı diyebiliriz: sizin gerçek segment dağılımınızı değil, modelin dünyasındaki ortalamayı temsil ederler. Literatür ayrıca sycophancy (yağcılık), mode collapse ve persona istikrarsızlığını belgeliyor; "The Illusion of Intervention" makalesi, LLM simülasyonlu deneylerin nedensel deney değil gözlemsel çalışma sayılması gerektiğini savunuyor. Yani kasaba halkı size "kullanıcılar bunu sever" diyemez; sadece "buraya bir bak" diyebilir. Bizim vakamızda tam olarak bunu yaptılar — ve bu bile yetti.

Ne kadar kolay kurulabilir?

Şaşırtıcı derecede kolay. Adımlar: (1) bir klasör açın ve gerçek arketiplerden beslenen persona dosyaları yazın, (2) her dosyaya bir günlük bölümü ekleyin, (3) görev talimatını tanımlayın — personalar mock'a değil staging'e ya da test branch'ine karşı koşacak, (4) çıktıları "hangi cevap neyi değiştirdi?" matrisine dökün, (5) görevlendirmeyi milestone'lara bağlayın. Bizim kurulumumuz da uzun sürmedi; asıl efor araçta değil, iyi persona yazmakta. Kestirmeden gitmek isteyen, bu akışın tamamını Claude Code gibi bir agent'a da kurdurabilir.

Geliştirme ve işletme maliyeti nedir?

Kesin rakam vermeyeceğiz çünkü maliyet model seçimine, prompt uzunluğuna ve tur sayısına göre değişiyor; ama mertebe fikri verebiliriz. Bu ölçekte bir tam tur — 25-30 personanın akışı doldurması ve günlüklerini güncellemesi — güncel model fiyatlarıyla tipik olarak birkaç doları geçmez; görevlendirme milestone'lara bağlı kaldığı sürece aylık fatura da düşük kalır. Asıl maliyet kalemi insan zamanı: matrisi okumak, bulguları hipotezden kanıta taşımak ve düzeltmeleri yazmak, her turda hatırı sayılır bir mesai istiyor. Bu da yöntemin dürüst özeti: ucuz ama bedava değil.

Kritik noktalar nelerdir?

Üç şey deneyin kaderini belirliyor. Birincisi persona çeşitliliği: uç senaryosu olmayan bir kasaba, tavana çarpan fiyatı asla göremezdi. İkincisi tripwire soruları: sistemin sınırlarını itiraf ettiren, "bu proje otomatik fiyatlanamaz" dedirtebilen sorular akışa bilinçli yerleştirilmeli. Üçüncüsü sonuçları ciddiye alma disiplini: persona çıktısı bir anomali gösterdiğinde onu "AI saçmalamış" diye geçiştirmek de, doğrulamadan bug ilan etmek de aynı derecede tehlikeli. Hipotez → kod incelemesi → gerçek test zinciri kırılırsa yöntem gösteriden ibaret kalıyor.

Nerede fayda sağladı, nerede sağlamadı?

Somut fayda: fiyat tavanı bug'ı. Üç sorunun cevabının sessizce yok sayıldığını, yemyeşil test suite'i değil, kasabadan gelen tutarsız teklifler matrisi gösterdi — canlıya çıkmadan. Genel olarak akış mantığı hatalarında güçlü: okunmayan cevap, imkânsız kombinasyon, sessizce yanlış hesaplanan çıktı. Sağlamadığı yerler de net: N+1 gibi performans sorunlarını, güvenlik açıklarını ve kod kalitesini yakalayamaz — onlar SDD review katmanının işi. "Kullanıcılar bu fiyatı öder mi" gibi davranışsal soruları ise hiçbir persona cevaplayamaz; onun tek kaynağı gerçek müşteri.

Deneyin Özeti: Tek Tabloda

Boyut	Bizim deneyimimiz
Kurgu	Klasörde yaşayan 25-30 kalıcı persona; kendi dosyaları ve günlükleri var, milestone'larda göreve gidiyorlar
En büyük kazanım	398 TL tavan bug'ı: üç sorunun cevabı fiyata hiç girmiyordu — canlıya çıkmadan yakalandı
Kalıcı çıktı	Tripwire sorusu + needs_custom_quote bayrağı + gerçek tekliflere dayalı pricing_rules
Yakalayamadığı	N+1 performans sorunu (SDD diff review yakaladı), davranışsal sorular, güvenlik
Gerçekçilik sınırı	Dağılım yanlılığı, sycophancy, mode collapse; gözlemsel çalışma gibi ele alınmalı
Maliyet mertebesi (tahmini)	Tur başına birkaç dolarlık token maliyeti + matrisi okuyup doğrulayan insan mesaisi

Sıkça Sorulan Sorular

ChatGPT veya Claude ile gerçekçi test personası nasıl oluşturulur, prompt'a neler yazmalıyız?

Prompt'a ürününüzün ne yaptığını, gerçek müşteri segmentlerinizi ve her persona için zorunlu alanları (sektör, hedef, bütçe beklentisi, proje tipi, teknik okuryazarlık) yazın. En önemli talimat çeşitlilik: "birbirinden belirgin şekilde farklı 25 persona, en az 5'i uç senaryo olsun" gibi. Geçmiş tekliflerinizi ve destek taleplerinizi referans verin; gerçek veriden beslenen persona, hayalî personadan her zaman daha keskin sorular sordurur. Personaları tek seferlik üretmek yerine dosyalara kaydedin — kalıcılık, ikinci turdan itibaren kendini amorti ediyor.

AI persona simülasyonu gerçek kullanıcı testinin yerini tutar mı, hangi durumlarda yanıltıcı olur?

Tutmaz — ve literatür bunu açıkça belgeliyor: sycophancy, mode collapse ve kimlik gruplarının düzleştirilmesi bilinen sorunlar. LLM simülasyonları gözlemsel çalışma gibi ele alınmalı; "kullanıcılar bu fiyatı öder mi" gibi davranışsal sorularda yanıltıcı olabilir. Güçlü olduğu alan mantık ve akış hataları: cevabı hiç okunmayan soru, imkânsız kombinasyon, sessizce yanlış hesaplanan çıktı. Personalar hipotez üretir; kanıtı yine gerçek sistem, gerçek sorgu ve gerçek kullanıcı üretir.

Personaların kalıcı dosya ve günlük tutması ne kazandırıyor, her testte sıfırdan üretmek yetmez mi?

Sıfırdan üretim ilk tur için yeterli, ama her turda aynı yüzeysel bakışı tekrarlar. Kalıcı dosyalar üç şey kazandırıyor: personalar önceki bulguların üstüne soru soruyor ("geçen sefer fiyat tavana takılmıştı, düzeltilmiş mi?"), turlar arası karşılaştırma bedavaya geliyor ve nüfusun çeşitliliği bilinçli olarak yönetilebiliyor. Günlükler ayrıca ekip için okunabilir bir test arşivi oluşturuyor: hangi milestone'da neyin bulunduğu, karakterlerin ağzından yazılmış duruyor.

Sonuç: Kasaba Halkı Bir Sonraki Görevi Bekliyor

2026'da AI'a kod yazdırmak artık marifet değil; asıl fark, aynı AI'a ürününüzü sorgulatmakta. AI ile yazılım testi de tam burada devreye giriyor: bizim motorumuzda yemyeşil test suite'i "kod doğru çalışıyor" diyordu; klasörde yaşayan 25-30 sahte müşteri ise "kod yanlış soruyu cevaplıyor" dedi. İkisi de gerekliydi, ama ikincisini soracak bir mekanizmamız yoktu — persona simülasyonu o mekanizma oldu.

Açık kalan kısımları saklamıyoruz: bu yöntem bir sigorta değil, ek bir fener; personaların bulamadığı bug'lar olduğuna eminiz ve davranışsal sorulara cevabı hâlâ gerçek müşteriler verecek. Ama küçük bir klasör kasabasının, fiyatlandırma gibi işin kalbindeki bir hatayı müşteri görmeden yakalaması, o feneri her milestone'da yakmamız için yeterli sebep. Kasaba halkı şimdi dosyalarını güncellemiş, bir sonraki görevi bekliyor. Sizin ürününüze de uğrayabilirler: bir klasör açın, 25 kişi taşıyın ve onları işe koşun.