Getir AI ile Nasıl Ürün Geliştiriyor? — Serhat Çulhalık

Herkes AI'ı chat ekranında kullanıyor. Serhat Çulhalık ise anlaştığı yazışmayı skill'e çevirip aynı derdi bir daha anlatmıyor.

Uzun bir aradan sonra mikrofonun başına döndük — bu kez Alive markasıyla. Üretim Bandı'nda yıllarca "X nasıl ürün geliştiriyor?" diye sorduk. Sene 2026; soru güncellendi: "X nasıl AI ile ürün geliştiriyor?" Çünkü etrafta herkesin sorduğu asıl soru bu. ChatGPT çıkalı üç yıl oldu, AI tool'lar günlük operasyona girdi. Ama çoğu kullanım hâlâ chat bazlı. Verimliliği gerçekten artıran şeyleri kim, nasıl yapıyor?

Serinin ilk konuğu Serhat Çulhalık — Getir'de Head of AI Products. Data science projelerinden product ekiplerinin günlük AI pratiklerine kadar geniş bir alana dokunuyor. Sorular bizden, cevaplar Serhat'tan. Bu yazı o sohbetin düzenlenmiş özeti; bölümün tamamını sayfanın başındaki player'dan izleyebilirsin.

Prototype-first: PRD'yi yazmadan önce tıklat

Getir mobile-first bir şirket; product ekipleri "geliştir, GitHub'a gönder, deploy et" akışının içinde değil. Ama Serhat'ın ekiplerinde iş yapış şeklini değiştiren bir geçiş var: prototype-first PRD. Yani fikir aşamasında uzun bir doküman yazmak yerine, daha PRD oluşmadan Codex'le çalışan bir prototip kurmak.

Akış şöyle işliyor: aklına bir fikir geliyor, brief netleşmeden farklı prototipler üretiyorsun. Tasarım ekibine bile gitmeden interaction'larına bakıyor, stakeholder'lara tıklattırıyor, feedback'i topluyorsun. "Tamam, budur" dediğin noktada detaylı PRD'yi yazıyor ve tasarım sürecini oradan başlatıyorsun. Tasarım ekibinin hazırladığı bir design.md dosyası da var — prototipler Getir'in guideline'larına uygun doğuyor. Google Stitch gibi araçlara bu dosyayı verip marka diline oturan tasarımlar alabiliyorlar.

Değişen şey PRD'nin varlığı değil, feedback'in sıraya girdiği yer.

Kazanç sadece hız değil. Fikir aşamasında "şu mu olsa, bu mu olsa" derken normalde efor maliyeti yüzünden birini seçmek zorunda kalırsın. Prototip ucuzlayınca ikisini de kurup yan yana bakabiliyorsun. Daha önemlisi: prototipe bakıp "Ya, biz bunu niye yapıyoruz?" diyebiliyorsun — PRD'ye haftalar gömmeden önce. User acceptance criteria'lar netleşmiş kapsama yazıldığı için PRD de gereksiz feature'larla şişmiyor.

Skill refleksi: "Bunu da yap" demeye başladıysan sinyal geldi

Sohbetin en somut kısmı burası. Serhat'ın günlük pratiğinin merkezinde skill'ler var — bir agent'ın nasıl çalışacağını anlatan instruction setleri. Peki neyin skill olacağına nasıl karar veriyor? Sinyali net:

Yani skill, baştan tasarlanan bir şey değil; tekrar eden bir yazışmanın kalıcı hale getirilmiş hali. Skill'i de oturup kendisi yazmıyor — "bunun skill'ini yaz" diyor, model yazıyor, o da doğru anlaşılıp anlaşılmadığını kontrol ediyor. Serhat'ın deyişiyle "büyütülecek bir konu değil".

İki örnek, yaklaşımı iyi anlatıyor:

• Problem büyüklüğü skill'i. Yeni bir feature fikrin var; skill'e senaryonu anlatıyorsun. Skill Mixpanel'den ilgili datayı çekip "kullanıcılar bu problemi gerçekten ne kadar yaşıyor?" sorusunu yanıtlıyor. Eskiden bu, bir developer'ın analizini beklemek demekti; şimdi iş developer'ın önüne gitmeden problemin boyu belli oluyor. Skill'in içine çıktı kalitesini ölçen bir rubric da gömülü — geliştirme bitince aynı skill'e sonucu verip "burada hâlâ fırsat var mı?" diye review ettiriyor.
• Recommendation insight skill'i. Getir'de yaklaşık 13 recommendation modülü var ve her ay performans raporu çıkıyor. Normalde manuel olan bu iş — placement performansları, yeni geliştirmeler, arkadaki incident'lar — tek skill'le toplanıyor: executive summary, metrikler arası korelasyon, "şurada düşüş var, muhtemelen şundan, dikkat et" seviyesinde yorum. Saatler süren iş, paylaşılabilir bir çıktıya dönüşüyor.

Dışarıdan kullandıkları da var: product ideation için Grill Me — fikrini ciddi ciddi sorgulayan bir skill. Serhat "Superpower'dır, Get It Done'dır, farklı şeyler denedim; en yalını bu geldi" diyor. Yaptıkları skill'leri ekip içinde ve şirketin ortak ürün kanalında paylaşıyorlar: "Bakın, böyle bir şey yaptık, herkes implemente edebilir."

Skill'in Serhat için asıl anlamı bir araç değil, bir bakış açısı: en basit seviyede, agent mimarilerine girmeden bir delegasyon birimi. Bugün kendi Codex'inde koşan problem büyüklüğü skill'i, Mixpanel MCP bağlantısı geldiğinde şirketin agent platformuna taşınacak — o noktada kişisel bir kısayol olmaktan çıkıp herkesin kullanabildiği, hatta recurring çalıştırılabilen bir agent'a dönüşecek. Delegasyonun ölçeklenme yolu bu: önce yazışma, sonra skill, sonra paylaşılan agent.

PRD'ler neden hâlâ güncellenmiyor?

Sohbette açtığımız yan konulardan biri, her PM'in bildiği bir yara: PRD yazılır, üzerine onlarca toplantı ve revizyon biner, günün sonunda başladığın yerden çok uzaktasındır — ama doküman ilk halinde durur. AI varken bu neden hâlâ böyle?

İdealdeki çözüm belli: issue yorumlarını, Slack yazışmalarını, mail'leri okuyan ve PRD'yi her gün güncelleyen bir scheduled task. Serhat "bunu delege etmeyi çok isterim" diyor ama gerçek hayatın envanterini de dürüstçe çıkarıyor: feedback bazen WhatsApp'tan geliyor, bazen koridorda. Her toplantı kaydedilmiyor; kaydedilen de eksik not alınıyor. Dört stakeholder'la çalışıyorsun — hangi karar hangi kanalda verildi? Üstüne şirket policy'leri var: her tool'u Slack'e bağlamak için özel izinler gerekiyor.

Yani sorun modelin yeteneği değil, context'in dağınıklığı. "Ne kadar delege etmeye cesaretliyiz?" sorusu bölüm boyunca birkaç kez dönüyor — ve Serhat "çok daha cesaretli olmalıyız ama adım adım" diyor.

Araç seti: product'ta Codex, development'ta Cursor

Getir'in tablosu, "tek doğru araç" olmadığını gösteren cinsten:

Serhat'ın kişisel tercihi Cursor: "Planlarımı görsel olarak daha iyi kurabiliyorum, otomasyonları daha kullanıcı dostu. Cursor'da yapabildiğin her şeyi VS Code'la da yaparsın — ama Cursor hepsini önüne hazır çıkarıyor." Sohbetin renkli anlarından biri de şu gözlemimiz: sektörde üç profil oluştu — terminalciler, IDE'ciler, desktop app'çiler. Kimse yüzde yüz tek kampta değil ama herkesin bir ağırlık merkezi var.

Token'ı kim ödüyor: optimizasyon işin kendisi oldu

Getir boyutunda bir şirkette "harcayın, sonra bakarız" dönemi kapanmış. İçeride kurdukları agentic AI platformu bunun altyapısı: herkes kendi agent'ını oluşturabiliyor — knowledge base koyuyor, skill ekliyor, MCP bağlıyor, private ya da public yapıyor, sonra o agent'la doğrudan yazışabiliyor. Bu aslında ikinci nesil: önceki platform "PRD agent" gibi tanımlı işlere input verip output alınan bir yapıydı; yenisi tıklanabilir, herkesin kendi agent'ını kurduğu bir sistem. Platformun içine LiteLLM ile token limitleri gömülü. AI feature geliştirme işi de artık sadece AI ekibinde değil — birkaç aydır ekipler orta seviye AI ve prompting bilgisiyle kendi feature'larını otonom geliştiriyor; limit aşılırsa alert düşüyor ve AI ekibi devreye girip "burada daha iyi bir optimizasyon var mı?" diye bakıyor.

Asıl öğretici kısım, AI ekibinin bir feature'a nasıl başladığı. Önce ekipten işin sınırlarını alıyorlar: bu çıktı için ne kadar hata payı kabul edilebilir, başarı neye benziyor? Sonra golden set geliyor — beklenen input-output örnekleri. İçeride kullandıkları DSPy library'si bu beklenen çıktıdan yola çıkıp en uygun prompt'u üretiyor; set güncellendikçe prompt yeniden optimize ediliyor. Ve test her zaman en düşük modelden başlıyor: hedef başarıya en ucuz modelle ulaşabiliyorsan, orada durursun.

Getir AI ekibinin feature akışı: optimizasyon sona bırakılmıyor, ilk adımdan başlıyor.

Serhat'ın anlattığı bir sahne, bu disiplinin neden gerektiğini özetliyor. Eskiden sprint planning'e giren CTO'nun klasik şakası vardı: "Bir if değil mi, koyarsınız olur." Şimdi aynı şaka AI için dönüyor: "Bir prompt yazarsın, çıktı verir." Ekipler ChatGPT'de 50 örnekle mini deneme yapıp "bak, çalışıyor" diyor. Aynı işi bin örnekte koşturduğunda sonuçlar dağılıyor. AI ekibinin işi tam da bu farkı kapatmak — ve bu yüzden yazılan şey bir süre sonra "sürekli kod" değil, bir optimizasyon işine dönüşüyor: business'ı anlamak, risk sınırlarını çizmek, modeli ona göre seçmek.

Context'i beslemek: knowledge base var, derin analiz henüz yok

Sohbette sorduğumuz kritik sorulardan biri context yönetimiydi: Getir'e yeni gelen bir PM, bir feature çalışırken dependency'leri, daha önce yapılmış işleri, mevcut servislerin sınırlarını nereden bilecek? Cevap yine dürüst: içeride Getir'in nasıl çalıştığını, business'ını, teknik altyapılarını anlatan knowledge base'ler var ve agent kurarken bunları seçebiliyorsun. Ama "data şemasından codebase'e uzanan derin analizler yapıyoruz" diyemiyor Serhat. O katman henüz birebir öğrenmeyle, insan insana ilerliyor. "Çok iyi adapte olduk filan diyemem — adım adım geliyor."

Vibe coding tuzağı: asıl soru hangi ürün

Ürünü hızlı geliştirmek işin kolay kısmı oldu. Zor kısım hâlâ aynı: hangi ürünü geliştireceğine karar vermek.

Bölümün en dürüst anlarından biri, Serhat'ın öz eleştirisi. PM'ler olarak vibe coding'e — ürünü daha hızlı, daha iyi nasıl geliştiririme — çok odaklandık; asıl işimiz olan "hangi işi, neden, hangi sırayla" kısmında geriden geliyoruz. "Ben de geride hissediyorum, oraya odaklanmak istiyorum" diyor. Hayali de buna uygun: bir tür PM operating system — geliştirme sürecinden çok öncesini (hangi ürün?) ve sonrasını (kullanıcıyı içeri almak, aktive etmek, geri döndürmek) delege edebildiği bir yapı.

Ekip tarafında sihirli bir formül yok: yeni bir konsept çıktığında iç session'lar yapıyorlar, "hangi repetitive işimizi delege edebiliriz?" sorusunu düzenli soruyorlar. Adaptasyon kişiden kişiye değişiyor — bazıları bir buçuk yıldır boş zamanında kendini geliştiriyor, bazıları yerinde sayıyor. Serhat'ın beklentisi net ama beklenti dili değil: "Kendim de çok iyi yapıyorum diyemem. Ama zorluyorum ve ekibe yol gösteriyorum."

Bu seriyi tam da bu yüzden başlattık: herkes hâlâ öğreniyor ve en hızlı öğrenme yolu birbirimize "sen nasıl yapıyorsun?" diye sormak. Dokuz yıl önce Üretim Bandı'nı başlatan soru neyse, bugünkü de o. Sonraki bölümlerde başka ekiplerin mutfağına gireceğiz.

Bölümün tamamı yukarıdaki player'da. Sorularını ve "biz şöyle yapıyoruz" hikayelerini bekliyoruz — belki sonraki konuğumuz sensin. 🧱