Geçen sonbahar, İstanbul’da bir toplantı odasında aynı cümleyi üçüncü kez duydum: “Demo çok iyi gidiyor, artık herkes kullanabilir.” İşin aslı şu — iç AI ürünlerinde en tehlikeli an tam da o andır. Gösterim parlıyor, yönetim heyecanlanıyor, ekip kendini alkışlamaya başlıyor (evet, doğru duydunuz). sonra ilk gerçek kullanıcılar geliyor ve ortalık hafifçe dağılıyor.
Ben bu tabloyu iki yıldır farklı ekiplerde gördüm. Bazısı destek ekibi için ajan kuruyor, bazısı satış tarafına özet çıkaran bir yardımcı hazırlıyor, bazısı da şirket içi bilgi aramasını yapay zekâyla hızlandırmaya çalışıyor. Kağıt üstünde hepsi tatlı duruyor. Pratikte ise mesele sadece modelin ne kadar “akıllı” olduğu değil; neyi ölçtüğünüz, nasıl izlediğiniz. Kaç kişiye açtığınız.
Bir dakika — bununla bitmedi.
Bakın şimdi, size süslü bir “AI dönüşümü” masalı anlatmayacağım. Daha çok mutfakta tencereyi kontrol eder gibi bakacağız işe: kaynıyor mu, taşacak mı, altı tutmuş mu? Çünkü iç ürün yayına almak biraz tam olarak bu — önce küçük ateş, sonra kontrollü büyütme.
Neden çoğu ekip ilk haftada tökezliyor?
Şöyle ki, Klasik hata şu: Ekip tek bir metrik seçiyor ve ona sarılıyor. Doğruluk oranı diyorlar mesela… ya da kullanıcı memnuniyeti skoru. Bir sayı iyi görünüyorsa rahatlıyorlar. Sonra ürün 30-50 kişiye açılıyor. Birkaç gün içinde edge case’ler çıkmaya başlıyor — model uyduruyor, yanlış aracı çağırıyor, bağlamı kaçırıyor; ardından herkes “AI bizim işte çalışmıyor galiba” demeye başlıyor. Oysa sorun modelin kendisi değil.
Peki neden?
Tuhaf ama, Sorun gözün kapalı koşmak. Geçen mart ayında Kadıköy’de görüştüğüm bir startup ekibi bunu birebir yaşadı; iç destek ajanını 40 kişiye açmışlardı ve üç gün sonra Slack kanalları şikâyetle dolmuştu. İlginç olan şu: sistem gerçekten kötü değildi, ama kimse hangi isteklerde patladığını göremiyordu. Kısacası ölçemedikleri şeyi düzeltemediler.
Bence, E tabi bir de beklenti meselesi var. Yönetici tarafı genelde “ilk sürüm yüzde (belki yanılıyorum ama) doksanı bulsun” diye düşünüyor — ama AI projelerinde o yüzde doksan hissi biraz aldatıcıdır, çünkü kalan yüzde on tam da üretimi yakar bitiren kısımdır, teslim tarihlerini ateşler ve ekibin moralini çukura çeker. O yüzden ben her zaman şunu söylüyorum: önce geniş kitle değil, önce izlenebilirlik. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Sayıya bakıp rahatlamak kolaydır
Bir dashboard’da yeşil ışık görmek insanı kandırır. Güzel görünür. Ama gerçek kullanımda kullanıcıların yazdığı şeyler bazen eğitim verisinde hiç olmayan garip sorular oluyor… orada modelin omzu düşüyor diyelim. Yeşil ışık hâlâ yanıyor ama altı yanmış. Bu konuyla ilgili Swift’te Global Actor Nedir? Uygulamada Ne İşe Yarıyor? yazımıza da göz atmanızı tavsiye ederim.
Doğru başlangıç kaç kişiyle olur?
Açık konuşayım: Otuz kişiyle başlamak çoğu zaman fazla gürültü demek. Ben olsam ilk turda üç kişiden fazlasına çıkmam — hatta bazı durumlarda iki rol bile yeterli olurdu (şaşırtıcı ama gerçek). Neden? Çünkü az sayıda kullanıcıyla tek tek trace inceleyebilirsiniz ve gerçekten neyin bozulduğunu anlarsınız. Bu kadar.
Küçük cohort dediğim şey ukalalık değil; disiplin meselesi. Destekten biri olsun, operasyonlardan biri olsun, satıştan biri olsun… Hem farklı iş akışlarını görürsünüz hem de birbirine benzemeyen hatalar yakalarsınız. Bir müşteri geçen yıl bunu yaptı; önce 28 kişiyle başladı, sonra bana dönüp “bu kaosmuş” dedi (yanlış duymadınız). Beş kişiye indiğinde bir haftada daha önceki ayın tamamından fazla bug buldu. Ciddi fark var.
| Başlangıç yaklaşımı | Artısı | Eksiği |
|---|---|---|
| 3-5 kullanıcı | Düşük gürültü, hızlı öğrenme | Daha yavaş ölçeklenir |
| 20-30 kullanıcı | Daha fazla geri bildirim | Sinyal kaybolur, takip zorlaşır |
Küçük startup için bu yöntem baya işe yarıyor çünkü takım zaten yakın çalışıyor; herkese tek kanal açıyorsunuz ve geri bildirim elden ele dolaşmıyor. Kurumsal tarafta ise hikâye biraz daha sert oluyor — orada izinler, veri güvenliği ve departman sınırları devreye giriyor. Ama yine de mantık değişmiyor: önce az, sonra kontrollü büyüme (ben de ilk duyduğumda şaşırmıştım). Bitti. Bu konuyla ilgili Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza da göz atmanızı tavsiye ederim.
Gerçek hayatta başarılı rollout’un sırrı modeli parlatmak değil; hangi istekte neden tökezlediğini sakin sakin görmekten geçiyor.
Takip etmiyorsanız aslında körsünüz demektir
Açıkçası, Editör masasında bu haberi ilk okuduğumda hemen not aldım. Konu tam benim geçtiğimiz nisan ayında test ettiğim kurumsal ajan pilotuna benziyordu — Levent’teki ofisteydi. Ekip harika prompt yazmıştı. Ama trace yoktu! Yani sistemin hangi aracı düşündüğü belli değildi, neden o cevabı verdiği görünmüyordu. Sonuçta herkes tahmin yürütüyordu. Hmm, nasıl desem… kör uçuş gibi bir şey.
Lafı gevelemeden söyleyeyim: observability burada opsiyonel değil (ben de ilk duyduğumda şaşırmıştım). Siz query’yi görmelisiniz, ajanın hangi araçları değerlendirdiğini görmelisiniz, hangi context’i taşıdığını görmelisiniz, çıktının kabul edilip edilmediğini bilmelisiniz. Yoksa prompt’u rastgele oynarsınız; deneme yanılma diye sunduğunuz şey aslında sis içinde direksiyon çevirmektir. Durum biraz böyle.
// Minimum trace örneği
interface AgentTrace {
runId: string;
userId: string;
query: string;
toolsConsidered: string[];
}
Bu örnek bilerek sade tutulmuş gibi dursa da fikir net: “Ne oldu?” sorusuna cevap veremiyorsanız ürün yönetmiyorsunuz, hava tahmin ediyorsunuz. LangSmith olur, Langfuse olur, başka bir şey olur… Marka fark etmez. Önemli olan kayıt olmasıdır.
Bence en kritik alanlar neler?
- User query’nin ham hali;
- Ajanın düşündüğü araç listesi;
- Seçilen aracın gerekçesi;
- Kullanıcının çıktıyı kabul edip etmediği;
- Cevabın gecikme süresi; (bu kritik)
- Gerekirse sonradan yapılan düzeltmeler. — bunu es geçmeyin
İlk hafta boyunca trace incelemek niye şart?
Bunu atlayan ekiplerin ortak kaderi var: haftalarca yanlış şeyi optimize ediyorlar. Bir yerde tool selection bozulmuştur. Onlar prompt’u değiştirir; context window doluyordur ama onlar temperature ile oynar; kullanıcı aslında başka iş yapmak istiyordur ama kimse onu sormaz. Sonuç? Haftalar geçer, sistem yerinde sayar. Daha fazla bilgi için Oracle’ın Bloom Hamlesi: Enerji, Veri Merkezi ve Para yazımıza bakabilirsiniz. Bu konuyla ilgili Pixel Referral Program Geri Döndü: 10% İndirim, 50$ Kredi yazımıza da göz atmanızı tavsiye ederim.
Aynen böyle oldu benim Ankara’daki bir danışmanlık görüşmemde de. Ekip chat tabanlı yardımcısını yayımlamıştı ve herkes sisteme bayılmış gibiydi… ta ki ilk hafta sonunda loglara bakana kadar. Asıl problem cevap kalitesi değilmiş; ajan yanlış yerden dosya çektiği için insanlar sonucu güvenilmez buluyormuş (yanlış duymadınız). Şimdi düşünün: kullanıcı haklı olarak kızıyor, ekip prompt’a abanıyor, ama kök sebep başka yerde. İşte o yüzden ilk hafta manuel inceleme şarttır. Evet zahmetlidir. Evet sıkıcıdır. Ama işe yarar.
Birkaç tipik arıza türü var:
- Yanlış araç seçimi;
- Zayıf veya eksik context;
- Kullanıcının kastını yanlış yorumlama;
- Teslim edilen cevabın aşırı uzun ya da aşırı kısa olması;
- Tam doğru görünen ama pratikte kullanılmayan yanıtlar. — bunu es geçmeyin
Kademeli yayılım nasıl yapılmalı?
İnce iş burada başlıyor. Önce dar çevreye verirsiniz — Sonra ikinci halka gelir. Ardından departman genişler — En sona dış kullanıcılar yaklaşır. Kulağa basit geliyor, değil mi? Ama pratikte bu ritmi korumak beklenenden zor.
Kademe kademe ilerlemek ne kazandırır?
Kademeli yayılım size iki büyük avantaj veriyor. Birincisi sinyal-gürültü oranını yükseltiyorsunuz. İkincisi güven inşa ediyorsunuz —. Insanlar kötü deneyim yaşarsa sadece üründen vazgeçmiyor; “AI bize uygun değil” sonucuna gidiyorlar. O etiket yapışınca sökmek zor oluyor açıkçası.
Size bir şey söyleyeyim, Bir de küçük not: kurumsalda rollout hızını belirleyen şey teknik kapasite kadar siyasi dengedir — evet kulağa tuhaf geliyor ama doğru. Mesela finans ekibine yeni ajan verirken compliance takımı ayrı endişe taşır, hukuk bambaşka soru sorar, IT ise erişim modeline takılır. Bunları önceden görmek ciddi vakit kazandırıyor, inanın.
Ben şahsen en sağlıklı planın şöyle olduğunu düşünüyorum: (kendi tecrübem)
- İlk hafta üç ila beş güçlü kullanıcı;
- İkinci hafta iki farklı rol daha;
- Üçüncü-dördüncü hafta hata türlerine göre düzeltme;
- Beşinci haftadan sonra ölçülü genişleme.
Bu ritim hızlı hissettiriyor mu? Belki hayır. Ama sağlam oluyor. Mesela enterprise seviyede sağlam olmak hızdan önemli; küçük startup’ta ise ikisini birlikte tutmaya çalışırsınız, ama gene de aceleyle yüzleri güldüren demo uğruna ürünü yakmamaya dikkat edersiniz.
Neyi iyi yaptığınızda sistem gerçekten öğrenmeye başlar?
Bakın, İlk cevap sıkıcı ama doğru: log toplamak, review yapmak, geri bildirim döngüsü kurmak. Maalesef başka kestirme yok. İkinci cevap daha önemli: her hatayı sınıflandırmak. Bu noktada küçük bir tablo işinizi kolaylaştırabilir:
| Sorun tipi | Nerede görülür? | Müdahale sekli |
|---|---|---|
| Alet secimi hatasi | Trace loglarinda | Tool tanimlarini gözden gecir |
| Context eksikligi | Yanlış veya yarim cevapta | Retrieval katmanını kontrol et |
| Kullanıcı kaynakli | Tutarsiz girislerde | Onboarding metnini yeniden yaz |
- Anlık düzeltme gerektiriyorsa prompt ve araç yönlendirmesi incelenir;
- Sistematikse context tasarımı gözden geçirilir; (bu kritik)
- Kullanıcı davranışı kaynaklıysa onboarding yeniden yazılır.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
