Context engineering nedir, prompt engineering neden yetmez?

Zekice yazılmış bir prompt'la harika bir demo çıkardınız. Ekibe gösterdiniz, herkes alkışladı. Sonra yayına aldınız ve bir hafta içinde bir şeyler bozuldu. Model talimatları görmezden geldi. Kullanıcının üç mesaj önce söylediğini unuttu. Hiç var olmamış bir sipariş numarası uydurdu.

Çoğu yapay zeka ekibinin 2026'da sessizce yaşadığı kriz bu. Notebook'ta çalışan bir prompt, gerçek kullanıcılarla, gerçek araçlarla ve gerçek veriyle karşılaşınca ayakta kalamıyor. Çözüm daha iyi bir prompt yazmak değil. Çözüm context engineering (bağlam mühendisliği).

Context engineering aslında ne demek?

Prompt engineering tek bir soru sorar: Model doğru anlasın diye bu talimatı nasıl yazmalıyım?

Context engineering daha büyük bir soru sorar: Model işini yapmak için tam bu anda gerçekten neyi görmeli?

Fark küçük gibi görünüyor ama canlı ortamda çok büyük. Prompt bir kelime dizisidir. Context ise model çalışırken önüne koymayı seçtiğiniz her şeydir. Buna sistem talimatları, getirdiğiniz belgeler, modelin çağırdığı araçların sonuçları, konuşmanın son birkaç turu ve bazen kullanıcıya dair uzun vadeli bellek dahil.

Context'i bir tasarım problemi olarak ele alan ekipler dayanıklı yapay zeka sistemleri çıkarıyor. Kusursuz prompt'u cilalamakla uğraşan ekipler ise yanmaya devam ediyor.

Prompt'u bir toplantıda söylenen sözler olarak düşünün. Context ise toplantının kendisi: odada kimlerin olduğu, daha önce neler konuşulduğu, masada hangi belgelerin durduğu ve katılımcıların elinin altında hangi araçların olduğu. Kusursuz açılış cümlesini bütün gün prova edebilirsiniz. Ortam yanlışsa toplantı yine de boşa gider.

Ekipler neden bu geçişi 2026'da yaptı?

2026 State of Context Management raporu lafı dolandırmıyor. IT liderlerinin %82'si artık prompt engineering'in tek başına yapay zekayı büyük ölçekte çalıştırmaya yetmediği konusunda hemfikir. %89'u önümüzdeki 12 ayda context altyapısına yatırım yapmayı planlıyor. Bunlar erken benimseyenlerin rakamları değil. Ana akım uyanıyor.

Geçişi iki etken hızlandırdı. Birincisi, yapay zeka ajanı iş akışları oyuncak olmaktan çıktı. Bir modelin beş araç çağırması, üç belge okuması ve kullanıcının dünkü tercihlerini hatırlaması gerektiğinde tek bir prompt yetmiyor. İkincisi, Model Context Protocol ekosistemi on binden fazla herkese açık sunucuya ulaştı; yani tipik bir ajan artık tek çalışmada birçok veri kaynağından besleniyor. Bunun için prompt'u elle yazamazsınız. Prompt'u oluşturan işlem hattını (pipeline) tasarlamanız gerekir.

Bir de daha az konuşulan üçüncü bir neden var. Context pencereleri büyüdü ve ucuzladı; ekipler de daha büyük pencerenin daha iyi cevap demek olmadığını acı tecrübeyle öğrendi. Çöple doldurduğunuz 200.000 token'lık bir pencere yine çöp bir cevap döndürür, üstelik bunun için daha fazla token harcar. Marifet pencereyi büyütmekte değil. Marifet içine neyin gireceğini seçmekte.

Dört sütun, tek tek

Modelin gördüğü context dört kaynaktan gelir. Her biri farklı biçimde bozulur. Her biri ayrı bir ustalık ister.

Eskimeyen sistem talimatları

Klasik hata, sistem prompt'una duvar gibi yığılmış kurallardır. Bu yığın zamanla büyür. Yeni bir uç durum çıkar, biri bir cümle ekler. Bir uç durum daha çıkar, bir cümle daha. Altı ay sonra sistem prompt'u üç bin token olur ve yarısının neden orada olduğunu kimse hatırlamaz.

Daha iyi yaklaşım modüler yapıdır. Temel kimlik tanımını kısa ve sabit tutun. Göreve özel kuralları yalnızca kullanıcının niyeti o göreve uyduğunda devreye alın. Sistem talimatlarına, herkesin üstüne bir şey karaladığı yapışkan not gibi değil, sürüm kontrolü ve testleri olan kod gibi davranın.

Sistem prompt'unuzun kontrolden çıktığının basit bir işareti: içindeki hiçbir şeyi silmeye cesaret edemiyorsunuz. Her satır taşıyıcı bir parça gibi duruyor ama kimse emin değil. Bu noktada prompt artık bir tasarım değil, geçmişteki aksaklıkların bıraktığı bir yara izi.

Gürültüsüz bilgi getirme (retrieval)

Çoğu ekip retrieval'ı prompt'a daha fazla belge doldurmakla bir tutar. Daha iyi değil, daha kötü cevaplar böyle çıkar. 2026'daki araştırmalar, context'te alakasız malzeme fazlalaştığında modellerin performansının düştüğünü doğrulamaya devam ediyor. Model sinyali aramak zorunda kalıyor ve çoğu zaman yanlış yerde arıyor.

İyi bir retrieval üç şeyden oluşur. Kaynak belgelerinizin yapısını gözeten akıllı parçalama (chunking). Her parçanın mevcut sorguyla ne kadar alakalı olduğunu puanlayan yeniden sıralama (reranking). Ve görevin gerçekten ihtiyaç duyduğundan fazlasını asla modele geçirmemenizi sağlayan kesin sınırlar. Sohbet botunuz bir kargo sorusunu cevaplıyorsa iade politikasının tamamını görmesine gerek yok.

Context'in asli parçası olarak araç sonuçları

Bir ajan araç çağırdığında çıktı context'e geri döner. Bu çıktıyı nasıl biçimlendirdiğiniz cevabı değiştirir.

Elli alanlık ham bir JSON dökümü çoğu zaman modelin kafasını karıştırır. Kullanıcının sorusuyla ilgili üç alanı içeren kırpılmış bir özet çok daha iyi çalışır. Bir araç hata verdiğinde hata mesajının kendisi de context'tir. Yapılandırılmış hata mesajlarını modele geri veren ekipler, hatadan toparlanma oranlarının hızla yükseldiğini görüyor; çünkü model neyin ters gittiğini değerlendirip farklı bir yol deneyebiliyor.

Şişmeyen konuşma belleği

Context'in sessizce şiştiği yer çok turlu sohbetlerdir. Her kullanıcı turu ve her model cevabı üst üste biner. Yirminci tura gelindiğinde model son soruya odaklanmak yerine kendi geçmişinde debelenir.

Canlı ortamda işe yarayan kalıp seçici bellektir. Eski turları kısa bir özete indirin. Son birkaç turu olduğu gibi tutun. Kullanıcıya dair uzun vadeli bilgileri ayrı bir bellek deposunda saklayın ve yalnızca ilgili olduklarında getirin. Neyi unutacağınıza da burada karar verirsiniz. Kullanıcının geçen haftaki geçici bir tercihi, bugünkü soru için çoğu zaman gürültüdür.

Gizlilik meselesi de bellekte karşınıza çıkar. Kullanıcılar hakkında bilgi saklıyorsanız artık küçük bir kişisel veri sisteminiz var ve bu sistem diğer tüm kullanıcı veritabanlarıyla aynı kurallara tabi. Context engineering ile veri yönetişimi burada buluşuyor; bu konuyu konuşmadan geçen ekipler bedelini genellikle sonradan, bir uyumluluk denetiminde öder.

Gerçek bir örnek: aynı iş, iki yaklaşım

Küçük bir e-ticaret mağazasının destek ajanını düşünün. Kullanıcı soruyor: "Siparişim nerede ve adresi hâlâ değiştirebilir miyim?"

Prompt engineering yaklaşımı uzun bir talimat yazar: yardımsever bir destek ajanısın, kibar ol, siparişi sorgula, kargoya verilip verilmediğine bak, empatiyle cevap ver. Ekip günlerce cümleler üzerinde oynar. Testte çalışır. Sonra bir kullanıcı ortak bir aile hesabındaki bir siparişi sorar ve ajan gönül rahatlığıyla başka birinin bilgilerini ifşa eder. Kimse bunun için bir kural yazmayı düşünmemişti.

Context engineering yaklaşımı işe tersten başlar. Modelin güvenle cevap verebilmesi için neyi görmesi gerekir? Kimliği doğrulanmış kullanıcının ID'sini görmesi gerekir. Siparişi görmesi gerekir, ama yalnızca o kullanıcıya ait siparişlerle sınırlı olarak. Lojistik aracından kargo durumunu görmesi gerekir. Mağazanın güncel adres değişikliği politikasını görmesi gerekir. Tüm ürün kataloğuna, pazarlama metinlerine ya da bu kullanıcıya ait olmayan hiçbir siparişe ihtiyacı yok.

İkinci yaklaşım daha kısa prompt'lar ve daha güvenli cevaplar üretir. Ustalık en üstteki kelimelerde değil, context'i oluşturan pipeline'da.

Kod açısından context engineering sürümü neredeyse sıkıcı görünür. İyi adlandırılmış birkaç fonksiyon. Biri oturumdan kullanıcıyı belirler. Biri kapsamı daraltılmış siparişi getirir. Biri araç çıktısını kısa, etiketli bir bloğa dönüştürür. En sondaki prompt şablonu belki on satırdır. Zeka paragrafta değil, pipeline'dadır.

Küçük ekipler için ne değişiyor?

İş ilanlarında yeni bir rol görünmeye başladı: context engineer. Küçük ekiplerde bu genellikle yeni bir işe alım değil, mevcut mühendislerin düşünme biçiminde bir değişim anlamına geliyor. Nasıl ki birisi veritabanı şemasından sorumluysa, birisi de context pipeline'ından sorumlu oluyor.

Başlangıç için gereken araç seti gösterişli olmak zorunda değil. Bilgi getirme için bir vektör veritabanı. Parçalama ve yeniden sıralamayı üstlenen bir retrieval framework'ü. Canlı ortamdan gelen gerçek izleri (trace) yeniden oynatmanızı ve hatalı bir çağrıda modelin tam olarak hangi context'i aldığını incelemenizi sağlayan bir gözlemlenebilirlik (observability) katmanı. En çok atlanan ama en değerli parça bu sonuncusu. Modelin ne gördüğünü göremiyorsanız sorunu düzeltemezsiniz.

Her ekibin bunu şimdiden yapması gerekmiyor. Yapay zeka özelliğiniz temiz girdiyle çalışan tek turlu bir özetleyiciyse prompt'u ayarlamaya devam edin ve yayınlayın. Araç, çok turlu sohbet ya da retrieval eklediğiniz an, planlasanız da planlamasanız da context engineering yapıyorsunuz demektir. Bunu bilerek yapmak daha iyi.

Burada kısa bir işaret listesi işe yarar. Aşağıdakilerden biri doğruysa muhtemelen context engineering'e ihtiyacınız var. Yapay zeka özelliğiniz tek turda birden fazla araç çağırıyor. Kullanıcılar çok turlu konuşuyor ve bu konuşmalarda önceki context bazen unutuluyor. Retrieval ile getirdiğiniz belgeleri modele veriyorsunuz ama hangi parçaların kullanıldığını kolayca açıklayamıyorsunuz. Token faturanız kullanımınızdan daha hızlı büyüyor. Canlı ortamdaki bir hatayı notebook'ta tekrarlayamıyorsunuz, çünkü modelin hangi context'i gördüğünü bilmiyorsunuz. Bunlardan ikisi ya da daha fazlası tanıdık geliyorsa, atacağınız en ucuz adım yeni bir model değil. Elinizdeki context pipeline'ını daha iyi görebilmek.

Özetle

Prompt engineering ölmedi, context engineering'in bir alt kümesi. Context'in en üstündeki kelimeler hâlâ önemli. Yalnızca artık işin tamamı değiller.

Yapay zeka sisteminiz demoda çalışıp canlı ortamda bozuluyorsa, sorun neredeyse hiçbir zaman prompt değildir. Sorun, context'i oluşturan pipeline'ın daha önceki bir adımındadır. İşe, hatalı bir çağrıda modelin gerçekte ne gördüğüne bakarak başlayın. Önce en zayıf sütunu düzeltin. Çoğu zaman bu retrieval ya da bellektir, prompt değil.

Yapay zekanızı kelimelerin değil, context'in etrafında kurun. Geçiş dediğimiz de bu.