Prompt Engineering'den Context Engineering'e: Ölçeklenen Kurumsal Prompt Çerçeveleri

TL;DR — 2026'da kurumlarda gördüğüm en net kırılma, "prompt mühendisliği"nden "bağlam mühendisliği"ne (context engineering) geçiş. Gartner Temmuz 2025'te bunu çarpıcı biçimde "context engineering in, prompt engineering out" diye çerçeveledi — ama beni yanlış anlamayın, prompt yazma bireysel kullanımda, prototiplemede ve uç durumlarda hâlâ vazgeçilmez. Bu yazıda RTCF, CO-STAR, CRISPE, SCRIBE, RACE gibi kurumsal çerçeveleri, hangisini nerede kullanacağınızı, few-shot örneklemenin neden hâlâ en yüksek ROI'li teknik olduğunu, öncesi/sonrası somut prompt örneklerini, bir prompt kütüphanesi yönetişim modelini ve tüm bunların KVKK ayağını anlatıyorum. Ana tez: bağlamı bir "prompt dosyası" gibi değil, bir altyapı gibi ele alın.

Yıllardır kurumlara yapay zeka eğitimi veriyorum ve son bir yılda dilin nasıl değiştiğini bizzat gördüm. 2023'te herkes "iyi prompt nasıl yazılır" diye soruyordu. 2026'da olgun ekipler artık başka bir soru soruyor: "Modele doğru bağlamı, doğru anda, doğru biçimde nasıl ulaştırırım?" Bu ince görünen fark aslında devasa.

Gartner'ın Temmuz 2025'te yaptığı çerçeveleme bu değişimi sahiplendi: "context engineering is in, prompt engineering is out." Ben bu cümleyi olduğu gibi almam, çünkü yarısı doğru yarısı yanıltıcı. Doğru olan kısım şu: kurumsal ölçekte asıl kaldıraç, tek bir sihirli cümle bulmak değil; modele hangi verinin, hangi belgenin, hangi geçmişin, hangi kuralın gireceğini sistematik olarak yönetmek. Yanıltıcı olan kısım ise "prompt öldü" izlenimi. Hayır, ölmedi. Bireysel kullanımda, hızlı prototiplemede, uç senaryolarda iyi bir prompt hâlâ altın değerinde. Prompt mühendisliği ortadan kalkmıyor; bağlam mühendisliğinin içine bir alt disiplin olarak yerleşiyor.

Bunu ekiplere şöyle anlatıyorum: prompt yazmak, tek bir yemeği güzel pişirmek gibidir. Bağlam mühendisliği ise bir restoran mutfağı kurmaktır — malzeme tedariki, tarif standardı, hijyen kuralları, tabak sunumu. Bir kez güzel yemek pişirmek başarıdır ama tekrarlanabilir, ölçeklenebilir, denetlenebilir bir mutfak kurmak bambaşka bir iştir. Kurumlar tam da bu ikinciye geçiyor.

Bir veri noktası paylaşayım: sahada gördüğüm ve sektör raporlarının da desteklediği eğilim, veri ekiplerinin ezici çoğunluğunun — yaklaşık yüzde 95'inin — 2026'da bağlam mühendisliği eğitimine yatırım yapmayı planladığı yönünde. Bu tesadüf değil. Ekipler acı deneyimle öğrendi ki, modeller giderek güçlenirken başarısızlıkların çoğu modelin sınırından değil, ona verilen bağlamın belirsizliğinden kaynaklanıyor.

Çerçevelere geçmeden önce, altında yatan ve hiç değişmeyen omurgayı netleştireyim. Bir yapay zeka çağrısı, olgun kurulumda üç parçadan oluşur.

Sistem promptu (system prompt). Modelin rolünü ve kısıtlarını tanımlar. "Sen kurumsal bir müşteri destek asistanısın; nazik ve net konuşursun; asla yasal tavsiye vermezsin; emin olmadığında insana yönlendirirsin." Bu, her çağrıda sabit kalan, davranışı çerçeveleyen katmandır.

Kullanıcı mesajı (user message). O anki görevi taşır. "Şu müşterinin iade talebini değerlendir." Değişken olan, işi tanımlayan kısım budur.

Opsiyonel few-shot örnekler ve enjekte edilen bağlam. İşte kurumsal değerin çoğu burada. Modele birkaç iyi örnek gösterirsiniz (few-shot) ve/veya o an gereken bilgiyi bağlama enjekte edersiniz (ilgili belge, müşteri geçmişi, politika metni).

Bu üçlü omurga basit görünür ama gücü de basitliğinde. Kurumların çoğu bunu düzensiz yapıyor: sistem promptunu, görevi ve bağlamı tek bir dağınık metin bloğunda karıştırıyor. Bu dağınıklık hata üretiyor. Ben ekiplere bu üç katmanı bilinçli olarak ayırmayı öğretiyorum; sadece bu ayrım bile çıktı kalitesini gözle görülür artırıyor.

Şimdi sahada işe yarayan çerçevelere gelelim. Piyasada onlarca akronim dolaşıyor; ben size gerçekten kullandığım ve neyin nerede işe yaradığını bildiğim beş tanesini bırakayım.

RTCF — Role, Task, Context, Format. En sevdiğim başlangıç çerçevesi. Dört soruya cevap verirsiniz: Model hangi rolde? Görev ne? Hangi bağlam gerekli? Çıktı hangi formatta? Sadeliği gücü. Rutin, hızlı işler için biçilmiş kaftan.

CO-STAR — Context, Objective, Style, Tone, Audience, Response. Daha ayrıntılı, daha kontrollü. Özellikle üslup, ton ve hedef kitlenin kritik olduğu karmaşık çıktılarda parlıyor. Pazarlama metni, yönetici iletişimi, marka sesi gerektiren işlerde bunu tercih ediyorum.

CRISPE — Capacity/Role, Insight, Statement, Personality, Experiment. Yaratıcı ve keşif odaklı işlerde, birden fazla varyant üretmek istediğinizde işe yarıyor. "Deney" bileşeni sayesinde modele alternatifler ürettiriyorsunuz.

SCRIBE — yönetici iletişimi için. Üst düzey iletişim, kurul sunumu, hassas duyuru gibi tonun ve netliğin çok önemli olduğu işlerde kullandığım disiplinli bir yapı. Yönetici ağzından çıkacak metinlerde tutarlılığı sağlıyor.

RACE — teknik ekipler için. Role, Action, Context, Expectation. Mühendislik ekiplerinin sevdiği, teknik görev tanımına yakın, net beklenti koyan bir çerçeve. Kod, dokümantasyon, teknik analiz işlerinde iyi oturuyor.

Peki hangisini ne zaman? Sahadaki pratik kuralım net.

"

Hız gereken rutin işlerde RTCF veya APE gibi hafif çerçeveler; tutarlılık ve incelik gereken karmaşık çıktılarda CO-STAR veya CRISPE gibi ayrıntılı çerçeveler.

Bu ayrımı yapmayan ekipler ya basit bir e-postaya altı bileşenli devasa bir prompt yazıp zaman kaybediyor, ya da kritik bir yönetici sunumunu iki satırlık özensiz bir promptla geçiştirip kalitesiz sonuç alıyor. Doğru çerçeveyi doğru işe eşlemek, tek başına verimliliği ciddi artırıyor.

Onca yeni tekniğin arasında, size sahadaki en sağlam gözlemimi söyleyeyim: 3 ila 5 çeşitli örnekle yapılan few-shot prompting hâlâ en yüksek getiri sağlayan tekniktir. Karmaşık zincirleme akıl yürütme kurgularından, ağır fine-tuning projelerinden çok önce, önce bunu deneyin.

Neden bu kadar etkili? Çünkü modele "ne istediğinizi" anlatmak yerine "ne istediğinizi gösteriyorsunuz." İyi seçilmiş üç örnek, üç paragraf talimattan daha net iletişim kurar. Ama iki tuzağa dikkat: birincisi, örnekler çeşitli olmalı — hepsi aynı tipte olursa model dar bir kalıba sıkışır. İkincisi, örnekler temiz olmalı — kötü bir örnek, modele kötü davranışı öğretir. Ben ekiplere "örneklerinizi bir sanat eseri gibi seçin" diyorum, çünkü o üç örnek yüzlerce çağrının kalitesini belirliyor.

Bir uyarı daha: few-shot örneklere gerçek kişisel veri koymayın. Sahada en sık gördüğüm KVKK ihlali burada — ekip, "gerçek örnek daha iyi olur" diye promptun içine gerçek müşteri verisi gömüyor ve bu veri log'lara, model sağlayıcısına, belki eğitim setine sızıyor. Örnekleri anonimleştirin veya sentetik üretin. Buna birazdan detaylıca döneceğim.

Size sahadaki en çarpıcı gözlemlerimden birini paylaşayım: yapılandırılmış prompt süreçleri, yapılandırılmamışlara kıyasla hataları belirgin ölçüde — bazı ölçümlerde yaklaşık yüzde 76'ya varan oranda — azaltıyor. Bu sayıyı ilk duyduğumda ben de şaşırmıştım, ama sahada tekrar tekrar doğrulandığını gördüm.

Bunun altında yatan gerçek şu: başarısızlıkların çoğu modelin sınırından değil, belirsizlikten kaynaklanıyor. Model aptal olduğu için değil, ne istediğinizi net söylemediğiniz için yanlış yapıyor. "Bana bir özet yaz" dediğinizde model uzunluğu, tonu, hedef kitleyi, formatı tahmin etmek zorunda kalıyor ve tahmini sizinkiyle uyuşmuyor. RTCF gibi bir çerçeve tam da bu belirsizliği ortadan kaldırıyor: rolü, görevi, bağlamı, formatı açıkça söylüyorsunuz ve tahmin payı çöküyor.

Bu yüzden ben "modeli suçlamadan önce promptunu suçla" diyorum. Kurumlarda gördüğüm "yapay zeka işe yaramıyor" şikâyetlerinin büyük çoğunluğu, aslında belirsiz talimat şikâyeti. Yapıyı ekledikten sonra aynı model bambaşka sonuç veriyor.

Soyut kaldığında kimse inanmıyor, o yüzden somut bir örnek vereyim. Diyelim bir müşteri destek ekibinin iade e-postası yazması gerekiyor.

Öncesi (yapılandırılmamış):

"

Müşteriye iade talebiyle ilgili bir e-posta yaz.

Bu promptun sonucu tahmin edilemez: bazen çok resmi, bazen fazla samimi, bazen eksik bilgili, her seferinde farklı. Ekip her çıktıyı elle düzeltmek zorunda kalıyor.

Sonrası (RTCF ile):

"

Rol: Sen deneyimli, empatik bir müşteri destek uzmanısın. Görev: Müşterinin iade talebini onayladığımızı bildiren bir e-posta yaz. Bağlam: Müşteri ürünü 10 gün önce aldı, beden uymadı, iade politikamız 14 gün. Kargo ücreti bizden. İade süreci 3-5 iş günü. Format: Kısa, iki paragraf, nazik ama profesyonel ton, sonda net bir sonraki adım. Selamlama ve imza dahil.

Aradaki fark gece ile gündüz. İkinci prompt her seferinde tutarlı, doğru bilgili, doğru tonlu bir çıktı veriyor. Ekip artık düzeltmiyor, sadece gönderiyor. İşte bağlam mühendisliğinin gündelik değeri budur.

Şimdi tonun ve hedef kitlenin kritik olduğu bir örnek — bir ürün lansmanı için LinkedIn gönderisi.

Öncesi:

"

Yeni ürünümüz için bir LinkedIn paylaşımı yaz.

Sonuç genellikle jenerik, "yapay zeka yazmış gibi", markanın sesini taşımayan bir metin.

Sonrası (CO-STAR ile):

"

Context (Bağlam): KOBİ'lere yönelik yeni bir bulut muhasebe aracı çıkardık; ana faydası zamandan tasarruf. Objective (Hedef): Farkındalık yaratmak ve demo talebi almak. Style (Üslup): Bilgilendirici ama abartısız; somut fayda odaklı. Tone (Ton): Güven veren, samimi, sıcak ama profesyonel. Audience (Kitle): Küçük işletme sahipleri ve mali müşavirler. Response (Yanıt): 120 kelimeyi geçmeyen, 3 kısa paragraf, sonda net çağrı, en fazla 3 hashtag.

CO-STAR'ın gücü, üslup ve tonu açıkça kontrol etmesinde. Aynı ürün için farklı kitlelere farklı ton isterseniz sadece iki alanı değiştiriyorsunuz. Bu, karmaşık ve tekrarlanan içerik işlerinde muazzam bir tutarlılık sağlıyor.

Şimdi yazının en önemli tezine geldik. Ben kurumlara ısrarla şunu söylüyorum: bağlamı bir prompt dosyası gibi değil, bir altyapı gibi ele alın.

Ne demek bu? Olgunlaşmamış ekiplerde bağlam dağınıktır: birileri Word dosyasında prompt saklar, birileri kendi kafasından bağlam ekler, kimse hangi verinin modele girdiğini bilmez. Bu, ölçeklenmeyen ve denetlenemeyen bir yapıdır. Olgun ekiplerde ise bağlam bir boru hattıdır (pipeline): standartlaştırılmış, denetlenen, loglanan bir sistem.

Sağlam bir bağlam-derleme boru hattının bileşenleri şunlar:

Veri düzenleme (data curation). Modele girecek belgeler, politikalar, örnekler tek elden yönetilir; güncel tutulur; eskiyeni ayıklanır. Bağlama giren her şey bilinçli bir karardır.

Gizlilik kontrolleri. Bağlama kişisel veri girmeden önce bir süzgeçten geçer. PII (kişisel tanımlayıcı bilgi) maskelenir veya çıkarılır. Bu, KVKK açısından hayati.

Loglama. Her yanıtın arkasında hangi token'ların, hangi belgelerin, hangi bağlamın olduğu kaydedilir. "Model bunu neden söyledi" sorusuna cevap verebilmek için şart.

Sürüm yönetimi. Promptlar ve bağlam şablonları kod gibi versiyonlanır. Bir değişiklik çıktı kalitesini bozarsa geri alabilirsiniz.

Bu yapıyı kurmak başta zahmetli görünür, ama size garanti ederim: kurumsal ölçekte tek sürdürülebilir yol budur. Bağlamı dağınık tutan ekipler bir noktada duvara toslar; her yeni kullanım öncekini bozar, kimse neyin neden değiştiğini bilemez.

Bağlamı altyapı gibi ele almanın somut hâli, yönetişimi olan bir prompt kütüphanesidir. Sahada kurdurduğum modeli paylaşayım.

Merkezî depo. Onaylı promptlar ve şablonlar tek bir yerde, sürüm kontrollü olarak tutulur. Kimse kendi "gizli" promptunu kullanmaz; herkes ortak, denetlenmiş kütüphaneden çeker.

Sahiplik ve onay. Her prompt şablonunun bir sahibi vardır. Yeni prompt veya değişiklik bir gözden geçirmeden geçer. Bu, "çöp prompt" birikmesini önler.

Test ve değerlendirme. Kritik promptlar, değişmeden önce bir test setiyle değerlendirilir. Çıktı kalitesi ölçülür, gerilemeye izin verilmez.

Erişim ve izin. Hangi ekibin hangi promptu ve hangi veriyi kullanabileceği tanımlıdır. Hassas veriye erişen promptlar daha sıkı denetlenir.

Dokümantasyon. Her prompt ne işe yarar, hangi çerçeveyle yazılmış, hangi kısıtları var — kısaca belgelenir. Yeni gelen bir ekip üyesi haftalarca değil, dakikalar içinde devralabilir.

Bu yönetişim modeli kulağa bürokratik gelebilir ama abartmayın; amaç hızı kesmek değil, tekrarlanabilir kalite üretmek. İyi kurulmuş bir kütüphane, ekibi yavaşlatmaz, hızlandırır — çünkü herkes sıfırdan başlamak yerine denenmiş, güvenilir yapılardan yola çıkar.

Şimdi çoğu ekibin atladığı ama benim ısrarla öne çektiğim boyuta gelelim. Bağlam mühendisliği, doğası gereği modele veri akıtmakla ilgili — ve bu veri sık sık kişisel veri içerir. Burada KVKK doğrudan devrede.

Bağlam derlemede gizlilik kontrolleri. Modele giden bağlama kişisel veri girmeden önce bir kontrol katmanı olmalı. "Bu belgede müşteri adı, telefon, kimlik numarası var mı?" sorusu otomatik sorulmalı ve gereksiz PII maskelenmeli. Ben bunu boru hattının zorunlu bir aşaması yapıyorum; opsiyonel değil.

Promptlarda PII işleme. Ekipler, hızlı çözüm uğruna gerçek kişisel veriyi promptun içine gömme eğiliminde. Bu tehlikeli çünkü prompt log'lara, model sağlayıcısının sistemlerine ve bazen eğitim süreçlerine gidebilir. Kural net: prompta gerçek PII koymayın; anonimleştirin, tokenlaştırın veya sentetik veri kullanın. Few-shot örneklerinizi mutlaka gerçek kişilerden arındırın.

Loglama ve hesap verebilirlik. Hangi token'ların hangi yanıta girdiğini loglamak sadece teknik bir iyi pratik değil, KVKK açısından bir hesap verebilirlik aracı. Bir veri sahibi "benim verim bu sistemde nasıl işlendi" diye sorduğunda cevap verebilmelisiniz. Ama dikkat: log'ların kendisi de kişisel veri içerebilir; log'ları da korumak, saklama süresini sınırlamak ve erişimi kısıtlamak zorundasınız.

Veri minimizasyonu — burada da geçerli. Modele gereğinden fazla bağlam vermek hem maliyet hem risk. Bir görevi çözmek için müşterinin tüm geçmişini bağlama koymanıza gerek yok; sadece gerekeni koyun. Az bağlam çoğu zaman daha iyi çıktı ve daha az risk demek. Bu ilkeyi hem mühendislik hem hukuk şapkasıyla savunuyorum.

Sınır ötesi ve model sağlayıcı seçimi. Bağlamınız AB vatandaşlarının verisini içeriyorsa, verinin nereye gittiği (hangi ülkedeki sunucu, hangi sağlayıcı) önemli. KVKK ve GDPR açısından veri transferi kuralları devrede. Model sağlayıcınızın veri işleme ve saklama politikasını okumadan üretim bağlamına gerçek veri akıtmayın.

Size teoriyle bırakmayacağım. Kurumlara verdiğim başlangıç sırası şu.

İlk olarak, dağınık promptlarınızı toplayın ve envanterini çıkarın. Ekipte kimin hangi promptu kullandığını görmek çoğu yöneticiyi şaşırtıyor — genellikle ortada onlarca tutarsız, denetimsiz prompt oluyor. İkinci olarak, en sık kullanılan üç-beş görevi seçip bunları RTCF veya CO-STAR ile yeniden yazın; öncesi/sonrası farkını ekibe gösterin, çünkü inanç sayıyla değil, deneyimle gelir. Üçüncü olarak, bu onaylı promptları merkezî bir kütüphaneye koyun ve basit bir sürüm kontrolü başlatın. Dördüncü olarak, bağlam boru hattınıza bir gizlilik süzgeci ekleyin — PII maskeleme ve loglama en baştan olsun. Beşinci olarak, few-shot örneklerinizi temizleyin, çeşitlendirin ve kişisel veriden arındırın. Son olarak, bunu bir kere kurup unutmayın; prompt kütüphanesi yaşayan bir varlıktır, düzenli gözden geçirin.

Sahadan son bir gözlem: 2026'da kurumsal yapay zeka başarısını belirleyen şey, en yeni modeli kullanmak değil, bağlamı disiplinle yönetmek olacak. En etkileyici sonuçları gördüğüm yerler, en pahalı modele sahip olanlar değildi; bağlamını temiz tutan, promptunu yapılandıran, few-shot örneklerini özenle seçen, gizliliği tasarıma gömen ve her şeyi loglayan ekiplerdi. Prompt yazmak bir beceri, bağlam mühendisliği ise bir mühendislik disiplini — ve önümüzdeki iki yılda bu ikisini birbirinden ayırt edebilen kurumların açık ara öne geçeceğine, sahada gördüğüm eğilime dayanarak, inanıyorum.

Kurumlarda eğitim verirken en çok işe yarayan araç, çerçeveleri yan yana koyan bir karşılaştırma tablosu oluyor. Çünkü ekipler genellikle bir çerçeveye takılıp her işte onu kullanıyor; oysa mesele doğru işe doğru çerçeveyi eşlemek. İşte sahada kullandığım harita.

Çerçeve	Açılım	En iyi olduğu iş	Güçlü yönü	Dikkat
RTCF	Role, Task, Context, Format	Rutin, hızlı görevler	Sadelik, hız	Karmaşık tonda yetersiz kalabilir
CO-STAR	Context, Objective, Style, Tone, Audience, Response	Pazarlama, marka iletişimi	Ton ve kitle kontrolü	Basit işlerde fazla ağır
CRISPE	Capacity, Insight, Statement, Personality, Experiment	Yaratıcı, keşif işleri	Varyant üretme	Öğrenme eğrisi dik
SCRIBE	Yönetici iletişimi	Kurul sunumu, duyuru	Tutarlı üst düzey ton	Dar kullanım alanı
RACE	Role, Action, Context, Expectation	Teknik ekipler	Net beklenti	Yaratıcı işte kısır

Bu tabloyu her eğitimde gösteriyorum çünkü tek bakışta anlaşılıyor: tek bir "en iyi çerçeve" yok. En iyi çerçeve, elinizdeki işe uyandır. RTCF'yi bir yönetici sunumuna zorlamak da, basit bir e-postaya CO-STAR'ın altı bileşenini yüklemek de israftır. Olgun bir ekip, işin türüne bakıp uygun çerçeveyi seçer — tıpkı bir marangozun doğru aleti seçmesi gibi. Ben ekiplere "çerçeve dininiz değil, aletiniz" diyorum; birine körü körüne bağlanmayın, işe göre değiştirin.

Bir not daha: bu çerçeveler birbirinin rakibi değil, çoğu zaman iç içe. CO-STAR'ın "Context" bileşeni ile RTCF'nin "Context"i aynı fikri taşır; SCRIBE'ın disiplini RACE'in netliğiyle akrabadır. Yani onlarca akronimi ezberlemek zorunda değilsiniz. Aslında hepsi aynı temel sezgiyi farklı ambalajlarla söylüyor: modele rolünü, görevini, bağlamını ve beklediğiniz çıktı biçimini net söyleyin. Akronimlerin altındaki bu ortak sezgiyi kavrarsanız, hangi çerçeveyi kullandığınızın önemi azalır.

Yıllar içinde kurumlarda aynı hataların döndüğünü görüyorum. En yaygın olanları ve pratik çözümlerimi bırakayım.

Tuzak 1: Çerçeve fetişizmi. Bazı ekipler bir çerçeveyi öğrenip her işe zorla uyguluyor. İki cümlelik bir soruya altı bileşenli CO-STAR yazmak zaman kaybı. Çözüm: işin karmaşıklığına göre çerçeve seçin; basit iş, basit çerçeve.

Tuzak 2: Belirsizliği modelin suçu sanmak. "Yapay zeka saçmalıyor" şikâyetlerinin çoğu aslında belirsiz talimat. Model uzunluğu, tonu, formatı tahmin ediyor ve ıskalıyor. Çözüm: tahmine yer bırakmayın; RTCF gibi bir yapı ile her şeyi açıkça söyleyin.

Tuzak 3: Few-shot örnekleri özensiz seçmek. Aynı tipten üç örnek modeli dar kalıba sokar; kötü bir örnek kötü davranış öğretir. Çözüm: örnekleri çeşitli ve temiz seçin, sanki bir eğitim seti kuruyormuş gibi.

Tuzak 4: Promptlara gerçek kişisel veri gömmek. "Gerçek örnek daha iyi" mantığı KVKK ihlaline giden en kısa yol. Çözüm: anonimleştirin, tokenlaştırın veya sentetik veri kullanın; boru hattına zorunlu PII süzgeci koyun.

Tuzak 5: Bağlamı dağınık tutmak. Word dosyalarında saklanan, kimsenin denetlemediği promptlar bir noktada duvara toslar. Çözüm: merkezî, sürüm kontrollü bir kütüphane ve yönetişim modeli kurun.

Tuzak 6: Loglamayı atlamak. "Model neden bunu dedi" sorusuna cevap veremeyen ekip, hem hata ayıklayamaz hem de KVKK karşısında hesap veremez. Çözüm: her yanıtın bağlamını en baştan loglayın.

Teknik ve hukuki tarafı konuştuk ama işin en ihmal edilen yanı insan tarafı. Bir prompt kütüphanesi ve bağlam boru hattı kurmak, aslında bir kültür değişimi. Ekipler yıllarca "herkes kendi promptunu kendi yazsın" özgürlüğüyle çalıştıysa, merkezî bir yönetişime geçiş başta direnç doğurur. "Benim promptum daha iyiydi" diyen kıdemli bir çalışan her ekipte vardır.

Bu direnci yönetmenin yolu, yönetişimi bir kısıt değil, bir hızlandırıcı olarak konumlandırmak. İnsanlara "artık sıfırdan başlamayacaksınız, denenmiş yapılardan yola çıkacaksınız" mesajını verin. En iyi promptları yazan kişileri kütüphanenin sahibi yapın; böylece kısıtlanmış değil, yetkilendirilmiş hissederler. Ben her kurumsal projede birkaç "prompt şampiyonu" belirliyorum — bunlar hem kütüphaneyi zenginleştiren hem de ekibe öğreten insanlar oluyor. Kültür, tepeden inen kuralla değil, içeriden gelen sahiplenmeyle değişiyor.

Bir de beklenti yönetimi var. Yöneticiler çoğu zaman "yapay zeka her şeyi çözer" beklentisiyle geliyor, sonra ilk hatada hayal kırıklığına uğruyor. Ben baştan net konuşuyorum: yapay zeka bir sihir değil, disiplin gerektiren bir mühendislik pratiği. Bağlamı düzgün kurarsanız muazzam değer üretir; özensiz kurarsanız tutarsız ve riskli sonuç verir. Bu gerçekçi çerçeveyi baştan koymak, projeyi ortada çöken hayal kırıklığından kurtarıyor.

Son olarak ölçümü unutmayın. Bir prompt kütüphanesinin ve bağlam disiplininin değerini yönetime göstermek için somut metrik gerekir: düzeltme oranındaki düşüş, çıktı kalitesindeki tutarlılık, bir görevi tamamlama süresi, hata oranındaki azalma. Bu sayıları biriktiren ekipler yatırımı sürdürebiliyor; "iyi hissettiriyor" diyen ekipler ise ilk bütçe kısıtında projeyi kaybediyor. Bağlam mühendisliği bir mühendislik disiplini olduğuna göre, tıpkı diğer mühendislik disiplinleri gibi ölçülmeli ve iyileştirilmelidir — ben sahada bunu yapan ekiplerin diğerlerinden açık ara ayrıştığını her seferinde gördüm.

Genel geçer prompt tavsiyelerini her yerde bulursunuz; ben Türkiye'de kurumlarla çalışırken gözlemlediğim özgün noktaları bırakayım. Birincisi dil: bu çerçevelerin çoğu İngilizce içerikle test edilerek yaygınlaştı, ama Türkçe çıktı istediğinizde ton ve üslup daha da kritik hâle geliyor. Türkçede "siz" ve "sen" ayrımı, resmiyet dereceleri, kurumsal nezaket kalıpları İngilizceden farklı işliyor. CO-STAR'ın "Tone" ve "Audience" bileşenlerini Türkçe çıktıda özellikle titizce doldurun; yoksa model garip biçimde ya fazla resmi ya fazla senli benli bir metin üretiyor. Ben Türkçe promptlarda tonu bir örnekle sabitlemeyi öneriyorum — bir cümlelik bir few-shot bile modeli doğru registere oturtuyor.

İkincisi KVKK'nın kurumsal ciddiyeti. Türkiye'de veri koruma denetimi giderek sıkılaşıyor ve kurumlar artık bunu bir formalite değil, gerçek bir risk olarak görüyor. Bu yüzden bağlam boru hattınıza gizlilik süzgeci eklerken "yeter de artar" demeyin; PII maskeleme, loglama ve saklama süresi sınırlamasını en baştan kurun. AB'ye hizmet veya ürün satan Türk kurumları için GDPR ve EU AI Act de aynı anda masada; iyi haber, sağlam bir KVKK uyumu sizi bu iki rejime de yaklaştırıyor, çünkü temel mantık ortak.

Üçüncüsü olgunluk farkı. Türkiye'deki kurumların bir kısmı hâlâ "prompt yazmayı yeni öğreniyor" aşamasında, bir kısmı ise doğrudan bağlam mühendisliğine geçmeye hazır. Sizin ekibiniz hangi aşamadaysa oradan başlayın; olgun olmayan bir ekibe ağır bir yönetişim modeli dayatmak direnç doğuruyor, çok olgun bir ekibi basit prompt eğitimiyle oyalamak ise zaman kaybı. Ben her kurumda önce bir olgunluk değerlendirmesi yapıyorum ve yol haritasını buna göre çiziyorum. Bu değerlendirme olmadan atılan adımlar çoğu zaman ya fazla iddialı ya fazla temkinli oluyor; doğru başlangıç noktası, kurumun gerçek olgunluğuyla uyumlu olandır.