AI ürün geliştirmede disiplin: 5 alışkanlık

Ekibinizin yaptığı AI demo’su bir mucize gibi görünüyor ama prodüksiyona geçiş haftalarca takılıyorsa, bu yazı sizin için. AI ürünleri klasik web yazılımdan üç noktada ayrılır: belirsiz dış sınırlar, donanım ve maliyet karmaşası, uzun geri besleme döngüsü. Klasik bir SaaS ürününde bir özelliğin ne yaptığı dakikalar içinde test edilebilir; AI’da aynı kalite sorusu haftalara yayılır. Modelin ürettiği çıktının doğru olduğunu otomatik olarak söylemek zor, hata bütçesi açık değil ve maliyet her istekte değişiyor.

Bu üç farklılık, klasik agile ritüellerin işe yaramadığı hissini doğuruyor. Cevap ritüelleri atmak değil; disiplini sertleştirmek. Sprint planlamayı, kod incelemeyi, retrospective’i bırakırsanız ortada sadece “demolar ve umut” kalır. Tutarsanız ama AI’a özgü disiplinleri eklemezseniz, ekibin yarısı 6 ay sonra “neden hâlâ yayında değiliz” sorusunu sorar.

Son 18 ayda 5 farklı AI projesinde — bir churn tahmin modeli, bir müşteri destek asistanı, iki içerik üretim hattı ve bir tedarik zinciri tahmin sistemi — beş alışkanlığın tekrar tekrar fark yarattığını gördük. Bu yazıda her birini sırasıyla açıyoruz: nasıl uygulandığı, hangi anti-pattern’i çözdüğü ve ölçülebilir etkisi. Bunlar yeni AI “best practice’leri” değil; iyi bilinen mühendislik pratiklerinin AI bağlamına uyarlanmış halleri. Yazının sonunda bu disiplinleri kendi ekibinizde nasıl konumlandırabileceğinize dair pratik bir kapanış var.

Alışkanlık 1: “Ne yapmayacağımız” listesi

Her sprint başında üç madde yazıyoruz: bu sprint’te şunlar yapılmayacak. Liste demonstrasyon gerektirmeyen bir karar belgesi. Sprint sonunda kapsamı koruduğu için demoda gurur veriyor; sprint ortasında bir özellik talebi geldiğinde “hayır” demeyi kolaylaştırıyor.

AI ürünlerinde scope creep’in karakteri farklı. Klasik bir web ürününde scope büyüten genellikle yeni bir kullanım vakası oluyor. AI ürünlerinde ise iki yeni vektör daha var: yetenek hayranlığı (“modelimiz bunu da yapabiliyor; ekleyelim”) ve müşteri talebi (“bunu sesli de kabul etsin, görselle de çalışsın”). Modaliteleri çoğaltmak demolarda etkileyici görünür ama her birinin kendi eval setini, prompt versiyonunu ve maliyet profilini gerektirdiği unutulur.

Somut örnek: bir B2C abonelik şirketinde churn tahmin modeli kuruyorduk. Sprint başında “kişiselleştirme motoru” maddesi 6 ay boyunca “yapmayacağız” listesinde kaldı. Önce churn skorunu güvenilir hale getirdik, sonra müşteri destek ekibine atama mantığını oturttuk, en son kişiselleştirme katmanını ekledik. Hesabımıza göre listeyi tutmak yaklaşık 3 ay erken yayına çıkmamızı sağladı; çünkü her sprint’te tek bir meta-karar test ediliyordu.

Listenin uygulanması için PR template’imize tek bir soru ekledik: “Bu PR sprint’in ‘ne yapmayacağız’ listesindeki bir maddeyi geri getiriyor mu?” Cevap evet ise PR sprint planına geri döner, hayır ise reviewer normal akışına devam eder. 30 saniyelik bir kontrol; ama yıl sonunda kapsam kararlarının %90’ından fazlasının izlenebilir olmasını sağlıyor. Listenin sprint sonunda saklanması da önemli: çeyrek retrospective’inde “üç ay önce neye hayır demiştik, kararımız doğru muydu” sorusuyla geri dönmek, sonraki sprint’lerin kapsam tartışmalarını sayı ve örnekle besliyor. Bu disiplini strateji ve içgörü müşterilerimizin ürün roadmap’lerinde de kullanıyoruz.

Alışkanlık 2: Günlük model değerlendirmesi

Her gün 50 üretim örneği elle inceleniyor. Bu, hiçbir AI projesinin ilk haftasında “lüks” olarak görülmemesi gereken bir alışkanlık. Otomatik metrikler iyi; precision, recall, BLEU, evaluation harness skorları hepsi yerinde. Ama dağılım kayması (distribution drift), edge case’ler ve prompt regression genellikle metriklere yansımadan günler önce insan gözüne çarpıyor.

Disiplinin yapısı basit: bir “günlük inceleyen” rotasyonu var; her gün bir mühendis ya da PM 50 örneğe bakıyor, 30 dakika bütçeli, sonuçlar bir log’a yazılıyor. Şablon her zaman aynı: çıktı doğru muydu, doğru değildiyse neden, hangi kategoride hata yapıldı? Kategori taksonomisi başlangıçta 4-5 maddeyle başlar (yanlış olgu, format hatası, yarım kalan cümle, kullanıcının niyetini kaçırma) ve haftalar içinde olgunlaşır.

Bu noktada araç tartışması erken başlıyor: “PromptLayer alalım mı, LangSmith mi?” Cevabımız: ilk 2-3 ay basit bir spreadsheet’in yeterli olduğu. Google Sheets’te bir Form, satırlarda örnek + not + kategori, sonunda haftalık pivot. Fancy araçlar kategori taksonomisi olgunlaştıktan sonra anlam kazanıyor; öncesinde sadece veri saklıyorlar. Üçüncü aydan sonra bir LLM-as-judge eklemek mantıklı: Claude veya GPT-4 modelini eval setine karşı çalıştırıp insan puanlamasıyla karşılaştırmak otomatik regresyon koruması sağlıyor.

Bu disiplinin pratik faydası şu: üretim metriklerinde sorun görünmesinden 2-3 hafta önce kalite kayması yakalanıyor. Bir müşteri destek asistanında bu disiplin, OpenAI’ın bir prompt formatı güncellemesinden sonra ortaya çıkan format regresyonunu CSAT puanı düşmeden 9 gün önce yakaladı. CSAT düşse, sebebini bulmak haftalar alırdı; günlük inceleme sayesinde sebep ilk PR’la birlikte belgelendi. Disiplinin ekibe yerleşmesi 4-6 haftayı buluyor; ilk haftalarda 30 dakikalık bütçe genelde aşılıyor, sonra örnek seçimi ve kategori taksonomisi olgunlaştıkça süre stabilize oluyor.

Alışkanlık 3: Birinci günden maliyet bilinçli tasarım

Token maliyeti, GPU maliyeti, vector store maliyeti — istek başına maliyet birinci gün izlenmeye başlanmalı. AI projelerinin en sık görülen post-launch krizi şu: ürün çalışıyor, müşteri kullanıyor, hedef marj %30; ama tek bir istek $0,50 maliyet üretiyor ve fiyat $0,30 olarak duyurulmuş.

Disiplin üç parçadan oluşuyor. Birincisi: her prompt’un bir maliyet tavanı var — token sayısı, model seçimi, retry stratejisi. Tavanı aşan istek otomatik olarak fallback yoluna girer; hata atmaz, daha ucuz modeli dener. İkincisi: her model çağrısının bir fallback’i var. GPT-4 yerine GPT-4o-mini, GPT-4o-mini yerine self-hosted Llama. Hangi seviyenin hangi kalite eşiğinde çalıştığı eval setiyle önceden ölçülmüş. Üçüncüsü: caching stratejisi açıkça yazılı. Stable input’lara (prompt template’i, sistem mesajı, dökümantasyon parçaları) agresif cache; kullanıcı içeriğine cache yok. Bu üç katmanlı disiplin tipik olarak fatura toplamını %40-60 azaltıyor.

Somut örnek: bir B2B müşteri destek asistanı önce GPT-4 üzerine kurulmuştu. Ortalama istek $0,12, ölçek arttıkça aylık fatura $90.000’a ulaştı. Eval setiyle yaptığımız analiz şunu gösterdi: tüm isteklerin %80’i orta-zorlukta, GPT-4o-mini bu kategoride %96 başarı oranıyla GPT-4’e yakın çalışıyor. Sadece “complex reasoning” etiketiyle gelen %20’lik dilim için GPT-4’ü tuttuk. Sonuç: aylık fatura $50.000 düştü; kullanıcı tarafında ölçülen kalite farkı CSAT’ta 0,3 puan altındaydı. Anthropic Claude Haiku gibi alternatif sağlayıcılarla benzer tier mantığı kuruluyor; karar prensibi sağlayıcıya değil, eval set + maliyet tavanı çiftine bağlı. Bu tarz operasyonel kararlar martech ve AI operasyonu angajmanlarımızın merkezinde.

Alışkanlık 4: Geri besleme döngüsünün araçlanması

AI ürünlerinde geri besleme döngüsü saniyeler değil haftalar sürüyor. Bir prompt regresyonunu görüp düzeltmek günler; bir fine-tune döngüsünü tamamlamak haftalar. Bu yüzden geri beslemenin araçlanması bir lüks değil, ürünü işletmenin temel altyapısı.

Disiplinin somut hali: her arayüzde açık bir geri besleme kanalı var. Beğen / beğenme butonu en basit hali; ama “yeniden üret”, “bu yanlıştı, çünkü…” gibi yapılandırılmış bir taksonomi çok daha değerli. Yanlış cevap geldiğinde kullanıcıya 4-5 sebep seçimi sunmak (yanlış olgu, kullanıcının niyetini kaçırma, format hatası, eksik bilgi, ton uygun değildi) hem kullanıcının düşünmesini kolaylaştırıyor hem de geri besleme verisinin makine-okunabilir olmasını sağlıyor.

Backend tarafında pipeline net olmalı: kullanıcının “bu yanlıştı” işaretlemesi → eval set’e otomatik aday → manuel inceleme sonrası eval set’in kalıcı parçası → bir sonraki training veya fine-tune döngüsünün girdisi. Bu pipeline kurulmadan toplanan geri beslemeler zamanla bir “veri kaynağı” değil, “veri çöplüğü” oluyor.

Kültürel boyut belki teknik boyuttan daha önemli: PM’ler ve mühendisler haftalık olarak ham geri besleme okumalı. Sadece dashboard’a bakmak yetmez; rastgele 30-40 örnek üzerinde gözlerini gezdirmeli. Bu, ürüne dair “feel”i koruyor. Müşteri destek ürünlerinde gördüğümüz pattern: PM 4 hafta üst üste geri beslemeyi okumadığında, ürün yol haritası üzerine yapılan tartışmaların kalitesi ölçülebilir şekilde düşüyor — ekip dashboard sayılarına atıfta bulunuyor ama “bu kullanıcı neden bu tepkiyi verdi” sorusuna cevap veremiyor. Bu disiplin, müşteri tarafına en yakın çalışan ekiplerin hala manuel okumayı sürdürmesini gerektiriyor. Pratikte bunu Cuma sabahı 30 dakikalık bir “feedback hour” olarak takvime sabitliyoruz; toplantı değil, sessiz ve ortak bir okuma seansı.

Alışkanlık 5: Sürümlü prompt’lar (kod gibi)

Prompt’lar config değil, kod. Tartışmalı görünebilir ama her ekibin operasyonel olgunlaşma yolu bu noktadan geçiyor. Prompt değişikliği bir özellik değişikliği olduğunda, PR review süreci, regresyon testi ve sürüm kontrolü zorunlu hale geliyor.

Disiplin şöyle çalışıyor: her arayüzün (chatbot, sınıflandırma, özetleme, churn skoru için context generation) bir prompt registry dosyası var. Tipik olarak prompts/customer-support/v3.2.yaml gibi, semver ile sürümlenmiş, içinde sistem mesajı, few-shot örnekleri, output schema, eval reference set’i. Her PR’da prompt değişikliği bir “prompt review” etiketi alır, ikinci bir reviewer prompt’a özel olarak bakar, regresyon testi CI’da çalışır.

Tooling tarafında basit başlamak iyi sonuç veriyor: yaml dosyaları repo’da, vitest testleri her PR’da eval set’in en az %95’inde önceki sürümle benzer veya daha iyi performans bekliyor. Threshold geçilmezse PR bloklanır, mühendis fail eden örneklere bakar. Daha gelişmiş ekipler PromptLayer, LangSmith veya Anthropic Console kullanıyor; ama bu araçlar yapısal disiplinin yerine geçmiyor, üzerine biniyor.

Bu disiplinin gizli faydası operasyonel: bir gün ürünün davranışı değiştiğinde, git bisect ile hangi prompt sürümünün regresyonu getirdiğini dakikalar içinde bulabiliyorsunuz. Config olarak saklanan, runtime’da set edilen prompt’larda bu mümkün değil — kullanıcıya yansıyan davranış değişikliklerini sebebe bağlamak detective work gerektiriyor. Sürümlü prompt’lar, martech yığını mimarisi yazımızda tartıştığımız “ortak veri katmanı” disiplininin AI tarafındaki karşılığı: gerçek kaynağın tek bir yerde, sürümlü ve auditable olması.

Kapanış: Yeni değil, sertleştirilmiş

Bu beş alışkanlık AI’a özgü “best practice” değil. “Ne yapmayacağımız listesi” sprint disiplininin daha sıkı bir uygulaması. Günlük model değerlendirmesi QA pratiklerinin yoğunlaştırılmış bir formu. Maliyet bilinçli tasarım performans bütçelerinin AI bağlamına uyarlanması. Geri besleme döngüsünün araçlanması ürün analytics’inin doğal devamı. Sürümlü prompt’lar config-as-code ilkesinin yeni bir alana taşınması.

AI projeleri klasik mühendislik disiplinlerini kıran yeni bir paradigma gerektirmiyor; aksine eski disiplinlerin daha az tolerasla uygulanmasını gerektiriyor. Hızlı iterasyon disiplini bırakma bahanesi değil — disiplin olmadan hızlı iterasyonun adı kontrolsüz değişimdir. Ekipler genelde bunu altıncı veya yedinci ayda öğreniyor; biz bu öğrenme eğrisini kısaltmaya çalışıyoruz.

Bir AI ürün ekibini kuruyorsanız veya mevcut ekibinizi olgunlaştırmak istiyorsanız, bu disiplinleri martech ve AI operasyonu angajmanlarımızın bir parçası olarak ekiplere koçluyoruz. Bağlamınızı dinleyip uygun seviyede bir başlangıç noktası önermek için bize ulaşın — [email protected].