DentalBulut'ta çalışırken bunu bizzat yaşadım.
AI destekli tedavi notu özelliği üzerinde çalışıyorduk. Prompt iyiydi. Model iyiydi. Haftalar geçirdik, farklı formatlar denedik, tonu ayarladık. Ama çıktı hâlâ berbattı.
Sorun neydi? Model hiçbir şey bilmiyordu.
Hastanın geçmiş tedavileri yoktu. Önceki muayene notları yoktu. Aktif tanılar yoktu. Biz "bu hastanın tedavi notunu yaz" dedik; model boş bir odada bağırdığımızı duydu. Güzel cümleler kurdu, jenerik şeyler yazdı. Klinik anlamda işe yaramaz.
İşte o an her şeyi yeniden çerçeveledi.
Prompt mühendisliği, modele nasıl sorduğunuzu optimize etmekti. Context mühendisliği ise model görevi yaparken ne bilmesi gerektiğini tasarlamak. Ve bu fark, kimin sorumlu olduğunu tamamen değiştiriyor.
Gartner 2026'yı "Context'in Yılı" ilan etti. Biraz dramatik bir çerçeveleme. Ama yerinde.
Araştırmalara göre BT liderlerinin %82'si artık prompt mühendisliğinin tek başına yeterli olmadığı görüşünde. Kişisel görüşüm: zaten hiçbir zaman yeterli değildi. Sadece bunu geç fark ettik.
Context engineering şunu soruyor: model bu görevi yaparken ne bilmeli?
- Hangi verilere erişebilmeli?
- Hangi araçları kullanabilmeli?
- Önceki konuşmayı hatırlıyor mu?
- Kullanıcının kim olduğunu biliyor mu?
- Ne zamana kadar hatırlıyor?
Bu sorular PM soruları. Dev soruları değil.
Somut örnek vereyim. Muayene sırasında hekime AI desteği sağlayan bir özellik yapıyorsunuz diyelim. Modele "bu hastanın durumunu özetle" diyebilirsiniz.
Ama asıl soru şu: model bunu iyi yapabilmesi için ne bilmeli?
- Hastanın yaşı, kronik hastalıkları, aktif ilaçları
- Son 3 muayenenin özeti
- Bekleyen tetkik sonuçları
- Hekimin önceki notları
- Hekimin not yazma tercihi — kısa mı, detaylı mı?
Bu listeyi kim çıkarıyor?
Çoğu şirkette: API endpoint'ini yazan backend developer, "mantıklı ne varsa gönderelim" diyerek bir şeyler koyuyor. Ve geçiyor.
Bir PM kararı, mühendis tarafından salı öğleden sonra alınıyor.
Context mühendisliği neden PM'in işi? Dört neden:
Maliyet. Her token para. Context ne kadar büyük olursa API maliyeti o kadar artar. Bu bir iş kararı.
Kalite. Yetersiz context jenerik çıktı demek. Daha kötüsü: yanlış context, modelin özgüvenle yanlış şeyler yazması demek. Bu bir ürün kalitesi kararı.
Güvenlik. Yetki sınırlarını aşan bir context, veri ihlali demek. Bu bir uyumluluk kararı.
Kullanıcı deneyimi. Model ilk sorguda "bu hasta hakkında bilgim yok" derse kullanıcı güveni bir daha tam geri gelmez. Bu bir UX kararı.
Dört kriter de — mühendislik değil — ürün kararı alanında.
Context engineering aslında karmaşık bir disiplin. RAG var, hafıza yönetimi var, araç orkestrasyonu var, token bütçe yönetimi var. Teknik altyapısı gerçekten derin.
Ama kararlar — hangi veriyi dahil edeceksiniz, hangisini dışarıda bırakacaksınız, hafıza ne zaman sıfırlansın, hangi kullanıcı bilgisi modele açık olsun — bunlar teknik kararlar değil.
Bunlar, teknik bir kaba doldurulmuş ürün kararları.
Ve en hızlı ilerleyen ekiplerde şunu görüyorum: PM context stratejisini sahipleniyor, implementasyonu mühendise devrediliyor.
Aklıma UX/UI ayrışması geliyor.
Başta hepsi "tasarım" dı. Sonra iki farklı disipline bölündü. Farklı araçlar, farklı beceriler, farklı sahipler.
Prompt engineering → context engineering ayrışması tam şu an yaşanıyor.
Soru şu: ürün organizasyonunuzda context tasarımını kim yapıyor?
Cevabınız net değilse, cevap muhtemelen "kimse."
Ve bu, AI özellikleriniz platoya vurmadan kapatmanız gereken bir boşluk.
Ben DentalBulut'ta bu soruyu sormaya başladıktan sonra işler değişti. Artık "prompt iyi mi?" diye değil, "model bu görev için neyi bilmeli, neyi bilmemeli?" diye soruyoruz.
Kulağa küçük bir fark gibi geliyor. Pratikte her şeyi değiştiriyor.
Sizin ürününüzde context'i kim tasarlıyor?