Kendi AI demo ajanınızı vibe coding ile mi geliştirmelisiniz?

Kendi AI demo ajanınızı vibe coding ile yazabilir misiniz? Bir hafta sonunda çalışan bir tane yapabilirsiniz. Onu gerçek alıcıların karşısına, gerçek ürününüzde, her gün çıkarmak ise bambaşka bir proje. Satış hattınız da o ikinci projeye bağlı.

O ikinci projenin neleri kapsadığı ve her bir parçanın ne kadar zor olduğu şöyle:

Konu	Ne gerektirir	Ne kadar zor
Canlı ürününüzü kullanmak	Girişler, doğrulama kodları, bot koruması ve arayüz değişikliklerinden etkilenmeyen akışlar	Çok zor
Gecikme	Yaklaşık bir saniye içinde dinlemek, düşünmek, konuşmak ve tıklamak	Çok zor
Ses teknolojisi	Doğal bir ses, söz sırası, araya girmeler, aksanlar ve gürültü	Zor
Sandbox'lar	Her oturumdan sonra sıfırlanan ve ürününüzle senkron kalan gerçekçi demo verileri	Zor
Prompt yazımı ve güvenlik sınırları	Mesajın dışına çıkmamak; fiyat, özellik ya da güvenlik iddiası asla uydurmamak	Zor
Eval'ler	Sohbetleri puanlamak ve her prompt ya da model değişikliğinden sonra gerilemeleri yakalamak	Zor
CRM ve satış hattı aktarımı	Lead toplama, zenginleştirme, HubSpot veya Salesforce senkronizasyonu ve takip	Orta
Bakım	Yukarıdakilerin hepsini her ürün sürümünde ve model değişikliğinde yeniden kontrol etmek	Hiç bitmez

Karumi'yi değerlendiren ekiplerden bunu sık duyuyoruz: "ekibimizden biri bunu vibe coding ile hemen yazar". Bu içgüdü anlaşılır. Kodlama ajanları artık çok iyi. Bir LLM'i headless bir tarayıcıya bağlayın, bir ses API'si ekleyin, uygulamanıza yönlendirin; pazar akşamına kadar ürününüzde konuşan ve tıklayan bir şeyiniz olur.

Sonrasında ne olduğunu da gördük. Kendi ajanını geliştiren ekipler, sistemin kurulumunun ve ayakta tutulmasının ne kadar zor ve pahalı olduğunu görünce bize geri döndü. Bu yazı, prototip çalıştıktan sonra karşılaştıkları sorunları anlatıyor.

Vibe coding ile yazılmış bir demo ajanı neyi doğru yapar?

Temel döngü artık gerçekten kolay. Bir LLM bir sayfayı okuyabilir, neye tıklayacağına karar verebilir ve gördüğünü açıklayabilir. Bir ses API'si onu konuşturabilir. Bir kodlama ajanı da hepsinin iskeletini birkaç saatte kurar.

Bu, şirket içi bir demo için yeterli. Bir alıcı için yeterli değil, çünkü bir prototipin yalnızca bir kez, çalışmasını isteyen biri için çalışması yeterlidir.

	Hafta sonu prototipi	Alıcıların karşısındaki ajan
Kitle	Sizi alkışlayan ekibiniz	İlk aksaklıkta ayrılan şüpheci alıcılar
Ürün durumu	Bir dizüstü bilgisayarda açık tek bir oturum	Her biri kendi girişi, verisi ve zamanlamasıyla binlerce oturum
Sohbet	Her şeyin yolunda gittiği senaryo soruları	Fiyat, rakipler, güvenlik, "X'i yapabiliyor mu?"
Başarısız olduğunda	Bir kahkaha	Kaybedilen bir anlaşma ve kötü bir ilk izlenim
Ömrü	Tek bir demo	Her gün, her sürümde
Sahibi	Cumartesi günü onu kim yazdıysa	Kalıcı olarak birine ihtiyaç duyar

Bu iki sütun arasındaki fark, asıl projedir. Demo da canlı ortamda başarısız olmayı göze alamayacağınız yerlerden biridir: bozulduğunda, en çok etkilemek istediğiniz alıcının gözü önünde bozulur.

Bir demo ajanını çalıştırmak için nelerde ustalaşmanız gerekir?

Canlı ortamdaki bir demo ajanı tek bir teknoloji değildir. En az dört teknolojidir ve her biri kendi başına bir uzmanlık alanıdır:

• Ses teknolojisi. Konuşmadan metne, metinden konuşmaya, söz sırası, araya girmeler, aksanlar ve arka plan gürültüsü. Bir sesin doğal duyulmasını sağlamak ve alıcının konuşmasını ne zaman bitirdiğini anlamak başlı başına bir alan.
• Sandbox'lar. Ürününüzün, her oturumdan sonra sıfırlanan, yayınladığınız sürümle senkron kalan ve hiçbir gerçek müşteriyi açığa çıkarmayan, gerçekçi verilerle dolu bir kopyası.
• Prompt yazımı. Ajanı, daha önce hiç görmediği binlerce sohbette mesajın içinde, ürününüze odaklı ve güvenlik sınırlarınızın içinde tutan talimatlar.
• Eval'ler. Sohbetleri puanlamanın ve gerilemeleri yakalamanın bir yolu; böylece bir prompt ya da model değişikliğinin işleri kötüleştirmediğini, iyileştirdiğini bilirsiniz.

Bir de dördünü birden etkileyen gecikme var. Sesli bir sohbette bir saniyeyi aşan bir duraklama bozukluk gibi hissettirir ve ajan bu süre içinde dinlemek, düşünmek, konuşmak ve canlı bir üründe tıklamak zorundadır. Bu süreyi kısaltmak; her aşamada streaming kullanmak, modelleri kalitenin yanı sıra hız için de seçmek ve sayfaları alıcı sormadan önceden yüklemek demektir. Kritik bir konudur ve doğru yapılması en zor kısımlardan biridir.

Canlı bir ürünü kullanmak neden işin zor kısmı?

Kendi mühendislik zamanımızın büyük kısmı sohbete değil, buraya gidiyor. Bir kayıt yerine gerçek ürününüzü göstermek, şunların hepsini çözmek demektir:

• Direnen girişler. SSO, önce e-posta isteyen ekranlar, sihirli bağlantılar, doğrulama kodları ve demonun ortasında süresi dolan oturumlar. Hata çoğu zaman başarı gibi görünür: ajan bir giriş sayfasında beklerken içeride olduğunu sanar.
• Bot koruması. Cloudflare, Akamai ve benzeri araçlar otomatik tarayıcıları engellemek için vardır. Kendi uygulamanızda bir betiği çok sık çalıştırırsanız demo hesabınız kilitlenebilir.
• Güvenli demo verileri. Alıcılar gerçek müşteri kayıtlarını görmemeli ya da paylaşılan bir hesabı bozmamalı. Gerçek görünen, temiz biçimde sıfırlanan ve canlı ortama asla dokunmayan bir sandbox'a ihtiyacınız var.
• Sürekli değişen bir arayüz. Her sürüm butonların yerini değiştirir ve sayfaları yeniden adlandırır. Sabit kodlanmış tıklamalar sessizce bozulur; bu yüzden bozuk bir akışı alıcıdan önce yakalayan kontrollere ihtiyacınız var.
• Hız. Her sayfa için sekiz saniye bekleyen bir demo bozukmuş gibi hissettirir. Önceden yükleme, önbelleğe alma ve anlatımı sayfa yüklemeleriyle zamanlamak, her biri ayrı bir iştir.
• Araya girmeler. Gerçek alıcılar "dur, geri dön" diye araya girer. Ajan durmalı, yanıt vermeli ve kaldığı yerden devam etmelidir.

Bunların hiçbiri bir prototip videosunda görünmez. Hepsi bir alıcının karşısında ortaya çıkar.

Sohbeti güvenilir kılmak için ne gerekir?

Bir demo ajanı markanız adına konuşur. Bir alıcının karşısında ürününüz hakkında bir şeyler uyduran bir ajan, hiç ajan olmamasından daha fazla zarar verir. Onu güvenilir tutmak süregelen bir iştir:

• Kaynağa dayalı yanıtlar. Belgelerinizden, müşteri hikâyelerinizden ve konumlandırmanızdan yanıt vermeli; fiyat ya da yol haritası hakkında tahmin yürütmek yerine konuyu ekibinize devretmeli.
• Güvenlik sınırları. Rakipler, indirimler, hukuki ya da güvenlik iddiaları hakkındaki sorular ve ajanı jailbreak etme girişimleri bilinçli biçimde ele alınmalı.
• Doğal ses. Düşük gecikme, araya girmeler, sessizlikler ve ekrandakiyle senkron kalan bir anlatım.
• Diller. Birden fazla pazarda satış yapıyorsanız her senaryo, akış ve yanıt her dilde çalışmalı.
• İnceleme. Birinin her hafta sohbetleri okuması, puanlaması ve zayıf yanıtları düzeltmesi gerekir. Aksi halde kalite kimse fark etmeden düşer.
• Güvenlik soruları. Güvenlik ekibiniz transkriptlerin nereye gittiğini ve hangi model sağlayıcılarının onları gördüğünü soracak. Onlar sormadan yanıtlarınız hazır olmalı.

Ajan, ürünün tamamı değil mi?

Hayır. Bir demo ajanının değeri, satış hattınıza kattıklarıdır ve şirket içinde geliştirilen botlar genellikle sohbette durur. Satış ve pazarlamanın, sohbetin etrafındaki her şeye ihtiyacı var:

• Her kampanya için ayrı giriş noktaları: LinkedIn, etkinlikler, web siteniz ve outbound her biri kendi bağlantısını, karşılama mesajını ve başlangıç akışını alır; hangi kanalın işe yaradığını görürsünüz.
• Lead toplama ve zenginleştirme: ziyaretçinin kim olduğu, hangi şirketten geldiği ve ICP'nize uyup uymadığı.
• Kullandığınız araçlara aktarım: nitelikli oturumlar bir özetle birlikte HubSpot veya Salesforce'a düşer, doğru satış temsilcisine bildirim gider ve takip mesajı kendiliğinden gönderilir.
• İçgörü: alıcıların en çok sorduğu sorular, nerede ayrıldıkları ve hangi itirazların gündeme geldiği.
• Kodsuz düzenleme: pazarlama ekibi ve satış mühendisleri, talep açmadan senaryoları ve akışları değiştirebilir.

Bunların her biri başlı başına küçük bir ürün. Hepsini şirket içinde geliştirirseniz demo botunuz kendi yol haritası olan bir iç platforma dönüşür.

Kendiniz geliştirmenin gerçek maliyeti nedir?

Vibe coding ilk sürümü neredeyse bedava yapar. Sonraki yüz sürümü bedava yapmaz; asıl maliyet de oradadır.

• Her ürün güncellemesi bir demo güncellemesidir. Her sürüm bir butonun yerini değiştirebilir, bir sayfayı yeniden adlandırabilir ya da bir akışı değiştirebilir. Her yeni sürüm çıkardığınızda birinin yolculukları yeniden kontrol etmesi, sandbox'ı yenilemesi, senaryoları güncellemesi ve eval'leri yeniden çalıştırması gerekir.
• Birinin sahiplenmesi gerekir. Onu geliştiren kişi ana ürüne döndüğünde ya da şirketten ayrıldığında bot sessizce bozulur. Kimsenin tam olarak anlamadığı, yapay zekâyla üretilmiş kodu devretmek zordur.
• Alttaki teknoloji yığını sürekli değişir. LLM, ses ve tarayıcı otomasyonu sağlayıcıları birkaç ayda bir modellerini, fiyatlarını ve API'lerini değiştirir. Her değişiklik yeni bir test turu, çoğu zaman da yeniden yazım demektir.
• Yol haritanızla rekabet eder. Demo botuna harcanan her mühendislik haftası, gerçekten sattığınız ürüne harcanmayan bir haftadır.
• Değer üretme süresi. Çalışan bir iç sürümün alıcılara gösterilecek kadar güvenli hale gelmesi genellikle aylar sürer. Projeyi gerekçelendiren satış hattı da bu arada bekler.

Yani dürüst karşılaştırma, bir abonelik ile bir hafta sonu kodlama arasında değil. Bir abonelik ile süresiz çalışan yarı zamanlı bir mühendislik ekibi, artı geliştirme sürerken kaybettiğiniz anlaşmalar arasında.

Kendiniz geliştirmek ne zaman mantıklı?

Şu üç koşulun hepsi doğruysa geliştirmek doğru karardır:

1. AI demo ajanı sattığınız şeyin merkezinde, başka bir şeyi satmak için kullandığınız bir kanal değil.
2. Ona tek bir sprint için değil, kalıcı olarak özel bir ekip ayırabiliyorsunuz.
3. Alıcıların onu görmesi için aylarca beklemek sizin için sorun değil.

Değilse, ekibinizin vibe coding ile yazabileceği en faydalı şey, istediklerinin bir prototipidir. Bu istek listesini girişleri, sandbox'ları, güvenlik sınırlarını, sesi, analitiği ve CRM aktarımını zaten yöneten bir platforma verin ve mühendislik zamanınızı kendi ürününüze harcayın.

Karumi tam olarak bunu yapar. Ajan ürününüzü keşfederek öğrenir, alıcıyla konuşurken ürünü canlı olarak kullanır ve her oturumu CRM'inize gönderir. Çoğu ekip iki haftada yayına girer, bakımı da biz üstleniriz.

SSS

Bir prototiple başlayıp sonra geçiş yapamaz mıyız?

Yapabilirsiniz; prototip ne istediğinizi netleştirmenin iyi bir yoludur. Yalnızca geçiş için bütçe ayırın: maliyetin çoğu prototipten sonraki işte yatar ve bozuk bir demo gören alıcılar ikinci kez bakmaya gelmez.

Ürünümüz her hafta değişiyorsa ne olacak?

Bu, sabit kodlanmış akışlara karşı en güçlü argüman. Karumi ürününüz değiştikçe onu yeniden öğrenir; böylece yeniden adlandırılmış bir sayfa ya da yeri değişmiş bir buton demoyu çökertmez.

Kendimiz geliştirmezsek kontrolü kaybeder miyiz?

Hayır. Senaryoları ekibiniz yazar, akışları ekibiniz seçer, güvenlik sınırlarını ekibiniz belirler. Devrettiğiniz şey altyapıdır: tarayıcılar, girişler, ses, sandbox'lar ve entegrasyonlar.

İkisini adil biçimde nasıl karşılaştırırız?

Alıcılarınızın önem verdiği temel bir akış seçin ve bir hafta boyunca ikisini de bu akışta çalıştırın: prototipiniz ve bir Karumi ajanı, aynı sorularla. Her birinin demoyu kaç kez aksaklık olmadan tamamladığını sayın.