Bir Yapay Zekâ Ürününün Neredeyse Hiç Görünür Yüzeyi Yoktur. O Yüzeyi Demo İnşa Etmelidir.

Normal bir SaaS demosunda arayüz ürünün kendisidir. Bir iş akışını kaydedersiniz ve o iş akışı argümanın kendisi olur: Tıklarsınız, durum değişir, görev tamamlanır. İzleyici neden-sonuç ilişkisini takip eder, çünkü ikisi de görünürdür. Bir yapay zekâ ürünü bunu üç şekilde bozar.

Birincisi, ekranda ilerleme hissi veren hiçbir durum değişikliği olmaz. Metin kutusunda bir imleç yanıp söner. İkincisi, etkileyici kısım tek seferde, en sonda, bir beklemenin ardından gelir. Kademeli bir yükseliş yoktur. Üçüncüsü ve en kötüsü, izleyici gerçekten iyi bir çıktıyı yalnızca makul görünen bir çıktıdan ayırt edemez.

Üstelik alışılmadık derecede şüpheci bir salon için çekim yapıyorsunuz. Dünya genelinde insanların yalnızca %46'sı yapay zekâ sistemlerine güvenmeye istekli (KPMG ve Melbourne Üniversitesi, 2025, 47 ülkede 48.000 kişiyle yapılan anket). Geliştiriciler arasında tablo daha da kötü: %46'sı yapay zekâ araçlarının doğruluğuna güvenmiyor, güvenenlerin oranı ise %33 (Stack Overflow, 2025 Developer Survey, bu soruya verilen 33.244 yanıt).

İzleyicinin bunu cımbızla seçilmiş bir örnek sandığını varsayın. Etkilemek için değil, bu düşünceyi çürütmek için çekin.

Cevap kategoriye göre değişir ve bunu yanlış yapmak, bir yapay zekâ demosunun zayıf kalmasının en yaygın nedenidir.

İki kural beşi için de geçerlidir. Karenin merkezinde çıktı durabilecekken oraya asla modeli koymayın. Ve bir yapay zekâ özelliğini, neyin yerini aldığını göstermeden asla göstermeyin.

Altı şey, önem sırasına göre.

• Girdinin tamamını gösterin. Prompt'tan başka bir görüntüye kesmeyin ve onu kırpmayın. Prompt ekranın dışındaysa, izleyici onun üzerinde yirmi dakika çalışıldığını varsayar.
• Üretim anını tek bir kesintisiz çekimde tutun. Gerekiyorsa beklemeyi kesin, ama asla olayın kendi içinde kesme yapmayın. Üretimin ortasındaki bir kesme, montaj gibi görünür.
• Çıktıyı hayranlıkla izlenirken değil, kullanılırken gösterin. Bir yapay zekâ demosundaki en güçlü sahne, çıktının sonuç doğuran bir yere ulaşmasıdır: açılan bir pull request, yapılan bir sunum, kapatılan bir destek talebi. Üretilmiş metinden oluşan bir duvar, müzik eklenmiş bir ekran görüntüsüdür.
• Bir şeyin kusurlu ve görünür olmasına izin verin. Kaynak veride dağınık bir satır. Kullanıcının elle düzelttiği bir alan. Kusursuz girdiler, her şeyin kamera için kurulduğunu ele veren ipucudur.
• Gerçek yapıyı kullanın. Müşteri isimlerini değiştirin, dağınıklığı koruyun. Gerçek veride yinelenen kayıtlar, boş alanlar ve tutarsız tarih formatları vardır. Bunların hiçbirini içermeyen bir demo, gerçek işin demosu değildir.
• En iyi sonucu değil, ortanca sonucu kullanın. Aynı prompt'u üç kez çalıştırın ve ortadaki sonucu alın. Bu, bir deneme sürecinden sağ çıkan demo ile bir iade görüşmesine yol açan demo arasındaki farktır.

İddiayı değil, kontrolü gösterin.

Modelin yüksek doğrulukla çalıştığını söyleyen bir seslendirme cümlesinin hiçbir değeri yoktur. Kullanıcının kaynak bağlantısını açtığı, kaynağı okuduğu ve kapattığı bir sahne ise bütün bölüme bedeldir. Birleştirmeden önce incelenen bir diff ya da üretilen kod eklendikten sonra yeşil yanan bir test paketi için de aynısı geçerlidir.

Bu bir üslup tercihi değildir. Geliştiricilerin %66'sı, yapay zekâ araçlarında en büyük sıkıntının neredeyse doğru ama tam doğru olmayan çözümler olduğunu söylüyor (Stack Overflow, 2025). Kıl payı kaçırmaları yok sayan bir demo, var olmayan bir kitleye konuşuyordur. İzleyiciniz sizin işinizi de kontrol edecek: Satın alma yolculuğunda yapay zekâ kullanan B2B alıcılarının %94'ü, en azından zaman zaman yapay zekânın yanıtlarını teyit ediyor (TrustRadius, 2026 B2B Buying Disconnect Report, 1.862 alıcıyla yapılan anket).

Pratik kurallar. Değerlendirme rakamlarınız varsa, bunları benchmark adı ve tarihiyle birlikte, okunabilecek kadar uzun süre ekranda tutun. Yoksa, doğruluğu hiç ima etmeyin. Ürün bir güven sinyali sunuyorsa, güven düzeyi düşük bir örnek de gösterin. Her zaman yeşil yanan bir gösterge, süsten ibarettir.

Denemelerin çoğu aynı şekilde başarısız olur: Ekrandaki çok adımlı otonomi, hızlıca rastgele şeyler yapan bir bilgisayar gibi görünür.

Ajana kalıcı bir görsel omurga verin. Tüm sekans boyunca karede kalan, adımların tek tek işaretlendiği bir plan paneli. Böylece izleyici her zaman nerede olduğunu bilir. Sonra bunu iki katman olarak kadrajlayın: bir yanda niyet, diğer yanda etki. Plan güncellenir, uygulama değişir. Neden ve sonuç yeniden görünür hâle gelir.

Kanıt sahnesi, sapma anıdır. Ajanın beklemediği bir durumla karşılaştığı anı bulun: başarısız bir test, eksik bir alan, bir hız limiti. Ve planını ekranda yeniden yazdığını gösterin. Bu tek an, inandırıcılığa beş temiz adımdan daha fazla katkı sağlar, çünkü senaryosu önceden yazılmış sahte bir demonun içermeyeceği tek şey budur.

İki kural daha. Zaman sıkıştırmasını, gözle görülür şekilde sıçrayan bir süre sayacıyla ya da ne kadar zaman geçtiğini söyleyen bir kartla belli edin. Ve her adımı anlatmayın. Kararı anlatın, sonra adımların müzik eşliğinde akmasına izin verin.

Gerçek düşünme süresi ölü zamandır. Onu sıfıra indirirseniz bu kez kayıt önceden render edilmiş gibi görünür. Cevap, dikiş yerleri görünür bırakılmış bir sıkıştırmadır.

• Herhangi bir şeyi sıkıştırmadan önce gerçek beklemenin 0,5 ila 1,5 saniyesini koruyun. Bu an, işin şu anda yapıldığını gösterir.
• Hız değişimine yumuşak bir geçişle girin ve çıkın. Hareketin ortasındaki sert bir sıçramalı kesme, hata gibi görünür.
• 10 saniyeden uzun her çalıştırmaya, ekranda bir süre sayacı koyun. Bu, ölü zamanı bir geri sayıma çevirir ve dürüsttür.
• Beklemeyi saklamak yerine kullanın. Akan token'lar, beliren kaynaklar, tamamlanan plan adımları. Ürününüz 20 saniyelik bir bekleme boyunca hiçbir şey göstermiyorsa, bu, ürün yöneticinize iletmeye değer bir ürün bulgusudur.
• Beklemenin tamamını içeren kesintisiz bir çekimi saklayın. Satış ekibi bunu, gerçekte ne kadar sürdüğünü soran şüpheci için isteyecektir.

Evet. İki dakikadan uzun her demoda, bilinçli olarak yerleştirilmiş bir tane.

Gösterdiğiniz hata bir çökme değildir. Modelin bir şeyi yanlış yapması ve ürünün bunu yakalamasıdır: düşük güven uyarısı, insan onayı (human-in-the-loop), farklı bir araçla yeniden deneme ya da temiz bir ret. Bu, ürün olgunluğuna dair bir iddiadır. Koruma mekanizmaları yalnızca gerçek kullanıcılarla karşılaşmış ürünlerde bulunur.

Yerleşim önemlidir. Bunu ikinci ya da üçüncü dakikaya, ürün bu hakkı kazandıktan sonra koyun. Asla 30 saniyelik bir kısa format versiyona koymayın, çünkü orada bunu çözüme kavuşturacak yer yoktur.

Arayüzümüz gerçekten yalnızca bir metin kutusu. Çekilecek bir şey var mı? Evet, ama metin kutusunun içinde değil. Çevresindeki işi çekin: kullanıcının daha önce neyi açık tuttuğu, çıktıyla ne yaptığı, haftasında neyin artık yaşanmadığı. Ürün o sekansın konusu değil, menteşesidir.

Gerçek bir müşterinin verisini kullanmalı mıyız? Kimlik bilgileri değiştirilmiş gerçek yapıyı kullanın ve bunun onayını kurgudan sonra değil, kayıt seansından önce yazılı olarak alın. Hukuk ekibi bir veri setini reddettiği için demoyu yeniden kurmak, bu kategorideki en kolay önlenebilir gecikmedir.

Demonun altı hafta içinde eskimesini nasıl önleriz? Modüler çekin. Her iş akışı için ayrı kayıt, her bölüm için ayrı seslendirme, üç özelliği kapsayan kesintisiz bir çekim yok. Navigasyon değiştiğinde videonun tamamını değil, 15 saniyeyi değiştirirsiniz.

Video, modelin nasıl çalıştığını anlatmalı mı? Bir demoda neredeyse asla. Mimarinin yeri bir açıklayıcı video ya da teknik bir uzun format içeriktir. Bilgi getirme (retrieval) sürecini anlatmak için duran bir demo, kendisi için yapıldığı değerlendiriciyi kaybetmiştir.

Geliştiriciler için ayrı bir versiyona ihtiyacımız var mı? Genellikle evet ve bu farklı bir çekim değil, farklı bir kurgudur. Geliştiriciler isteği, yanıtı ve hata senaryosunu görmek ister. Daha az seslendirme, kod üzerinde daha fazla ekran süresi. Aynı kayıt, farklı kurgu.