Artık Prompt Yazmıyoruz, Kendi Kendine Prompt Yazan Sistemler Kuruyoruz

Geçen hafta sektörde iki şey aynı anda oldu.

Bir yanda "prompt engineering öldü" iddiası viral oldu. Öte yanda Anthropic, Claude için nasıl prompt yazılacağını anlatan yirmi yedi dakikalık bir atölye yayınladı. Aynı hafta, aynı sektör, birbirine tam ters iki mesaj.

Bu çelişki aslında çelişki değil. İkisi de doğru, çünkü ikisi farklı katmandan bahsediyor. Bu yazı hangi katmanda ne olduğunu ayırıyor.

Hızlı Cevap: Prompt engineering kaybolmuyor, katman değiştiriyor. Ölen şey numaralardı: "sen bir uzmansın" rol oyunları, "adım adım düşün" kalıbı, modeli kandırmaya çalışan bahşiş ve tehdit cümleleri. Bunlar 2023'te işe yarıyordu çünkü modeller talimat takibinde zayıftı. Ölmeyen şey ise işin kendisi: modelin ne göreceğine karar vermek. Fark şu ki bu karar artık sohbet kutusunda değil, kod tabanınızda veriliyor. Sistem talimatları, araç açıklamaları, hangi dokümanın ne zaman yükleneceği ve modelin çıktısını neyin denetlediği. Bugün bir ajanın başarısızlığı neredeyse hiçbir zaman "prompt kötüydü" değildir, "bağlam yanlıştı" olur.

İçindekiler

• Viral iddia ve doğrulanamayan alıntı
• Gerçekten ölen numaralar
• Yükselen katman: bağlam mühendisliği
• Biz bunu nasıl yapıyoruz?
• Neyin ölmediği
• Hâlâ elle prompt yazdığınız yerler
• Terimler sözlüğü
• Sık sorulan sorular
• Kontrol listesi

Viral İddia ve Doğrulanamayan Alıntı

Sosyal medyada dolaşan iddianın en bilinen hâli şu: Andrew Ng'ye atfedilen "prompting altı ay içinde ölecek, yerini döngüler ve grafikler alacak" cümlesi.

Bu alıntıyı doğrulayamadık. Cümlenin izini sürdüğünüzde tek kaynak, iddiayı ortaya atan paylaşımın kendisi çıkıyor. Ng'nin gerçekten yazdığı şey ise farklı. Kendi ifadesiyle agentic workflow'lar modele defalarca prompt atar; modelin çıktısını doğrudan almak yerine, adım adım daha iyi bir sonuca ulaşması için birden fazla tur çalıştırılır. Yani belgelenmiş pozisyonu "prompt ölüyor" değil, "daha çok prompt, ama döngü içinde".

Bunu baştan söylüyoruz çünkü bu alanda hype ile veri arasındaki mesafe büyük. Gerçek bir konuşma videosunun üstüne çarpıcı bir alıntı iliştirmek, etkileşim toplayan bir format hâline geldi. Kaynağı takip edilemeyen bir cümle üzerine mimari kararı vermeyin.

Yine de iddianın altında gerçek bir gözlem var. Sadece dozu abartılmış.

Gerçekten Ölen Numaralar

2023'te işe yarayan pek çok teknik bugün ya etkisiz ya da zararlı. Bunlar gerçekten öldü ve prompt'larınızda hâlâ duruyorsa temizlemelisiniz.

Ortak nokta şu: bu numaraların hepsi modelin bir eksiğini telafi etmek için vardı. Eksik kapandığında telafi de gereksizleşti. Dahası, bir kısmı artık aktif zarar veriyor. Talimat takibi güçlü bir modele "ASLA şunu yapma" diye bağırdığınızda, model o kuralı gereğinden fazla ciddiye alıp yapması gereken şeyleri de yapmaz.

Yükselen Katman: Bağlam Mühendisliği

İşin kaybolmadığı, taşındığı yer burası. Sektörde bunun adı bağlam mühendisliği (context engineering) olarak yerleşiyor.

Basit bir oran işi netleştiriyor: çok adımlı bir ajan çalışırken modelin gördüğü şeyin yaklaşık yüzde beşi sizin yazdığınız talimattır. Kalan yüzde doksan beşi bağlamdır. Getirilen dokümanlar, araç tanımları, konuşma geçmişi, ajanın az önce okuduğu kod, çalıştırdığı testin hata çıktısı. O yüzde doksan beşi tasarlamak, bugün kaldıracın bulunduğu yerdir.

Bu yüzden bugün bir ajan başarısız olduğunda sorun neredeyse hiçbir zaman "prompt kötü yazılmıştı" değildir. Model yanlış şeyi görmüştür, ya da görmesi gerekeni görmemiştir.

Sistem talimatları

Modelin kim olduğunu, hangi kurallara uyacağını, neyi asla yapmayacağını tanımlar. Eskiden işin tamamı buydu, şimdi başlangıç noktası.

Araç açıklamaları

Bir ajana araç verdiğinizde, o aracın description alanı bir prompt'tur. Modelin aracı ne zaman çağıracağına karar veren şey odur.

Kurumsal projelerde en sık görülen hata, çelişen araç açıklamaları. Bir aracın açıklaması "müşteri verisi için bunu kullan" derken diğeri "tüm veri sorguları için bunu kullan" diyorsa, model bu çelişkiyi çözemez ve rastgele seçer. Araç açıklamalarını sonradan doldurulacak bir alan gibi değil, birinci sınıf bağlam gibi ele almak gerekir.

Aşamalı açığa çıkarma

Her şeyi baştan yüklemek yerine, modele o an gereken bilgiyi vermek. Yirmi doküman ve elli aracı aynı anda bağlama koyarsanız hem maliyet artar hem model dikkatini dağıtır. Doğru yaklaşım, ilgili olanı ilgili anda getirmektir.

Döngü ve değerlendirme

Tek atışta doğru cevap beklemek yerine, modelin kendi çıktısını kontrol edip düzeltebileceği bir döngü kurmak. Testi çalıştırıp hatayı geri beslemek, bir doğrulayıcı adım eklemek, sonucu bir ölçüte göre puanlamak. Ng'nin gerçekten anlattığı da bu: yansıtma, araç kullanımı, planlama ve çoklu ajan iş birliği.

Biz Bunu Nasıl Yapıyoruz?

Bu bölüm teori değil. Kendi projelerimizde prompt'lar sohbet kutusunda değil, depoda duruyor.

Her projenin kökünde, o projede çalışan her yapay zeka oturumuna otomatik yüklenen bir kural dosyası var. İçinde şunlar yazıyor: yazım kuralları, performans kalıpları, commit davranışı, hangi dosyanın ne zaman okunacağı. Bir örnek:

## Git & Commit Kuralları

**Commit hedefi (ZORUNLU):** "commit at" dendiğinde, o an checkout
edilmiş olan branch'e commit at. Yeni branch AÇMA, branch değiştirme.
`main` üzerindeyken "commit at" denmişse commit doğrudan `main`'e
gider. Bu bilinçli bir tercihtir.

Bu kural Claude Code'un "default branch ise önce branch aç"
şeklindeki varsayılan davranışını EZER.

Bu satırın önemi şurada: burada modelin varsayılan davranışını bilinçli olarak eziyoruz. Bunu her oturumda sohbet kutusuna yazmıyoruz. Bir kez yazdık, sürüm kontrolüne girdi, o depoda çalışan her oturumda geçerli. Kural değiştiğinde pull request açılıyor ve tartışılıyor.

Aynı dosyada bir tablo var: hangi görev için hangi dokümanın okunacağını söylüyor ve açıkça "bu dosyalar otomatik yüklenmez, işe başlamadan önce aç" diyor. Bu, aşamalı açığa çıkarmanın en sade hâli. Bağlamı baştan şişirmiyoruz, gerektiğinde getiriyoruz.

Üçüncü örnek araç açıklamaları. Sitemizde çalışan bir MCP sunucusu var ve dışarı açtığı her aracın açıklaması, modelin o aracı ne zaman çağıracağını belirliyor. Sunucunun tanıtım yanıtına şu cümleyi koyduk:

This server is read-only: it cannot submit contact or quote
requests. To start an inquiry, direct the user to the contact
or quote page returned by get_company_info.

Bu bir prompt. Ama bir sohbette değil, protokolün içinde yaşıyor ve sunucuya bağlanan her ajana otomatik gidiyor. Kısıtı ajana protokol seviyesinde söylüyoruz.

Üçünün ortak yanı şu: hiçbiri bir kereye mahsus yazılmış bir mesaj değil. Hepsi versiyonlanmış, tekrar kullanılan, gözden geçirilen altyapı. Prompt engineering'in gittiği yer burası.

Neyin Ölmediği

Şimdi madalyonun diğer yüzü. "Prompt öldü" diyen içeriklerin atladığı şeyler var.

Talimat yazmak hâlâ yazmaktır. Sistem talimatı da bir prompt'tur, araç açıklaması da. Katman değişti ama beceri aynı: modele ne istediğinizi belirsizlik bırakmadan anlatmak. Kötü yazılmış bir araç açıklaması, kötü yazılmış bir prompt'la aynı sonucu verir.

Anthropic aynı hafta prompt atölyesi yayınladı. Modeli üretenler hâlâ nasıl prompt yazılacağını anlatıyorsa, "prompt öldü" cümlesi en azından erken.

Model geliştikçe prompt'un maliyeti düşüyor, değeri değil. Güçlü modellerde kötü bir talimatı toparlamak kolaylaştı. Ama iyi bir talimatın getirisi kaybolmadı. Aksine, ajan çok adımlı çalıştığında baştaki belirsizlik her adımda çarpılarak büyüyor.

Bazı numaraların ölmesi, hepsinin ölmesi değil. Rol atama öldü, ama çıktı formatını tarif etmek ölmedi. "Adım adım düşün" öldü, ama görevi parçalara ayırmak ölmedi.

Hâlâ Elle Prompt Yazdığınız Yerler

Sistem kurma söylemi, her şeyin otomatikleşeceği anlamına gelmiyor. Şu durumlarda hâlâ oturup prompt yazarsınız:

• Keşif ve prototipleme. Bir fikrin çalışıp çalışmayacağını anlamak için sistem kurmazsınız, denersiniz.
• Tek seferlik işler. Bir metni çevirmek, bir listeyi düzenlemek için altyapı gerekmez.
• Sistem talimatının kendisini yazarken. Sistemi kuran şey de metindir ve onu birinin yazması gerekir.
• Hata ayıklarken. Ajan yanlış davrandığında, sorunun bağlamda mı talimatta mı olduğunu ancak elle deneyerek ayırırsınız.

Yani "artık prompt yazmıyoruz" cümlesi tam olarak doğru değil. Doğrusu şu: tek seferlik prompt yazmayı bırakıp, tekrar tekrar çalışan prompt sistemleri yazmaya geçiyoruz.

Terimler Sözlüğü

• Prompt engineering: Modelden istenen çıktıyı almak için girdi metnini tasarlama pratiği.
• Bağlam mühendisliği (context engineering): Modelin gördüğü her şeyi tasarlama pratiği: talimatlar, dokümanlar, araç tanımları, geçmiş ve araç çıktıları.
• Sistem talimatı: Modelin rolünü, kurallarını ve sınırlarını tanımlayan, konuşmanın başında verilen kalıcı talimat.
• Araç açıklaması: Bir aracın ne işe yaradığını ve ne zaman çağrılacağını modele anlatan metin. Fiilen bir prompt'tur.
• Aşamalı açığa çıkarma: Tüm bilgiyi baştan yüklemek yerine gerektiğinde getirme yaklaşımı.
• Ajan döngüsü: Modelin çıktı üretip, sonucu değerlendirip, gerekirse düzelterek tekrar denediği çalışma biçimi.
• Yansıtma (reflection): Modelin kendi çıktısını eleştirip revize ettiği desen.
• Değerlendirme (eval): Bir prompt veya sistem değişikliğinin işe yarayıp yaramadığını ölçen tekrarlanabilir test.
• Bağlam şişmesi: Gereksiz doküman ve araç tanımlarının bağlam penceresini doldurup performansı düşürmesi.

Sık Sorulan Sorular

Prompt engineering öğrenmek hâlâ mantıklı mı? Evet, ama tek başına bir meslek olarak değil. Modele ne istediğinizi net anlatma becerisi, sistem talimatı ve araç açıklaması yazarken de aynı beceridir. Değişen şey bu becerinin nerede kullanıldığı.

Prompt engineer unvanı kayboluyor mu? Ayrı bir unvan olarak büyük ölçüde evet. Ama iş kaybolmuyor, yazılım mühendisliğinin içine dağılıyor. Bugün bu işi yapan kişi genelde sistemi de kuran kişidir.

Eski prompt'larımızı temizlemeli miyiz? Evet. Eski modeller için yazılmış rol atamaları, büyük harfli baskı cümleleri ve "adım adım düşün" kalıpları yeni modellerde aşırı tetiklenmeye ve gereksiz uzunluğa yol açıyor. Kaldırıp ölçün.

Kendi kendine prompt yazan sistem ne demek? Bağlamı çalışma anında modelin kendisinin kurduğu yapı. Hangi dokümanın getirileceğine, hangi aracın çağrılacağına ve bir sonraki adımda ne sorulacağına sistem karar verir. Siz tek tek mesajları değil, bu kararların kurallarını yazarsınız.

Küçük bir ekip için bu fazla mı ağır? Hayır, en sade hâli bir metin dosyası. Depoya bir kural dosyası koymak ve araç açıklamalarınızı ciddiye almak, ekip büyüklüğünden bağımsız olarak getirisi olan iki adımdır.

Kontrol Listesi

• Prompt'larınızdaki rol atama, tehdit ve bahşiş cümlelerini kaldırın
• Büyük harfli baskıyı azaltın, kuralı bir kez ve gerekçesiyle yazın
• Düşünen modellerde "adım adım düşün" kalıbını çıkarın
• Sistem talimatlarını sohbetten çıkarıp depoya taşıyın
• Kural dosyanızı normal kod gibi gözden geçirin, pull request'ten geçirin
• Araç açıklamalarını birinci sınıf bağlam olarak ele alın, çelişkileri temizleyin
• Her şeyi baştan yüklemeyin, gerektiğinde getirin
• Bir değişikliğin işe yaradığını iddia etmeden önce ölçün
• Ajan hatalarında önce bağlama bakın, talimata değil
• Model sürümü değiştiğinde talimatlarınızı yeniden gözden geçirin

Kapanış

"Prompt engineering öldü" cümlesi, doğru bir gözlemin abartılmış hâli. Ölen şey numaralardı ve iyi ki öldüler; çoğu zaten modelin eksiklerini gizlemek için vardı.

Ölmeyen şey, modele ne göreceğine karar verme işi. O iş büyüdü ve yer değiştirdi. Artık bir sohbet kutusunda değil, sürüm kontrolündeki bir kural dosyasında, bir araç açıklamasında, bir değerlendirme testinde yaşıyor. Yazdığınız metin hâlâ metin, ama artık bir kere çalışıp gitmiyor; her oturumda tekrar çalışıyor.

Pratik tavsiye sade: eski numaraları temizleyin, talimatlarınızı depoya taşıyın, araç açıklamalarınızı ciddiye alın ve bir değişikliğin işe yaradığını ölçmeden iddia etmeyin. Yapay zeka tarafındaki mimari ve entegrasyon çalışmalarını AI Çözümleri hizmetimiz altında, teknik liderlik ihtiyacını CTO as a Service altında yürütüyoruz. Yapay zekayla kod üretmenin görünmeyen bedeli için Knowledge Debt yazımıza, bu işi sahada yapan role dair Forward Deployed Engineer yazımıza bakabilirsiniz.