Kodlama İçin Prompt Mühendisliği: Claude Code ve Cursor'da Her Gün Kullandığımız 7 Kalıp (2026)

Kodlama için prompt mühendisliği, çalışan bir pull request gönderen ajanla üretimde sessizce bir şeyi bozan ajan arasındaki farktır. Bunu pahalı yoldan öğrendik: kendi pipeline'ımızdaki belirsiz bir talimat, kimse fark etmeden önce 54 kopya canlı sayfa üretmişti. Bugünlerde 16 ajanlı bir Claude Code kurulumu içeriğimizi yazıyor, çeviriyor ve yayınlıyor; bu kurulumu yönlendiren promptlar ise Google'ın ilk sayfasındaki 50 şablonluk listelere hiç benzemiyor. İşte her gün yazdığımız 7 kalıp, her biri gerçek bir öncesi-sonrası örneğiyle.

Kısa cevap: İyi kodlama promptlarının hepsi aynı kalıbı paylaşır. Hedefi ve "bitti" tanımını belirtirsiniz, kapsamdaki dosyaları tek tek adlandırırsınız, her düzenlemeden önce bir plan zorunlu kılarsınız, testleri elden verirsiniz ve "iyi görünüyor" yerine kanıt talep edersiniz. Bunu yaparsanız modern bir ajan (Claude Code, Cursor, GitHub Copilot) incelemeden çok daha sık ilk seferde geçen kod yazar. Atlarsanız kendinden emin görünen ama içi boş bir kod yığını elde edersiniz.

7 kalıp, başvurduğumuz sıraya göre:

1. Görev çerçeveleme: en başta hedef, kısıtlar ve "bitti" tanımı
2. Bağlam seçimi: dosyaları adlandırın, gerisini kapatın
3. Önce plan: düzenlemeden önce önermesini sağlayın
4. Önce test: kabul testlerini prompta koyun
5. Hata ayıklama: hata artı tekrar üretme artı beklenen, düzeltmeden önce kök neden
6. Refactor: yapıyı değiştirin, davranışı koruyun, diff'i gösterin
7. İnceleme: karşılaştırılacak bir kontrol listesi, artı kanıt

Kodlama İçin Prompt Mühendisliği ile Config Dosyaları: Hangisi Nereye Gider

Config dosyaları ile görev bazlı promptlar farklı işler görür ve bu ikisini birbirine karıştırmak bu alandaki en yaygın hatadır. Bir CLAUDE.md veya .cursor/rules dosyası, ajanın her oturumda okuduğu kalıcı politikadır: yığınınız, adlandırma kurallarınız, test komutunuz. Prompt ise o an ajana verdiğiniz somut görevdir. Kalıcı kurallar config'e, görev ise prompta gider.

Çoğu "kodlama promptları" derlemesi bunu birbirine karıştırır ve size dev bir persona promptunu .cursorrules dosyasına yapıştırmanızı söyler. Bu, ajanın her tek görevde yüklediği config'i şişirir ve yine de önündeki tek işi çerçeveleyemez. İkisini ayrı tutun:

Config tarafını iyi yapmak istiyorsanız, bunu CLAUDE.md en iyi uygulamaları ve Cursor kuralları rehberi yazılarımızda derinlemesine ele alıyoruz. Bu yazı ise diğer yarısı: her seferinde yeniden yazdığınız promptlar. Önce temelleri görmek isterseniz ikisi de daha kapsamlı prompt mühendisliği rehberimizin altında yer alıyor.

Kodlama İçin Prompt Mühendisliği: Her Gün Kullandığımız 7 Kalıp

Aşağıdaki her kalıbın, insanların gerçekte yazdığı zayıf versiyonu ve çalışan kod alan güçlü versiyonu var. Zayıftan güçlüye geçiş neredeyse her zaman aynı hamledir: dileği bir şartnameyle değiştirmek.

1. Görev Çerçeveleme: Hedefi, Kısıtları ve "Bitti"yi Belirtin

Görev çerçeveleme, ajan tek bir satıra dokunmadan önce hedefi, kısıtları ve "bitti"nin neye benzediğini yazmak demektir. Bir ajan tam olarak ne istediyseniz onu optimize eder, bu yüzden bulanık bir istek bulanık bir yama kazandırır. Dosyayı, istediğiniz davranışı, kabul kontrolünü ve değişmemesi gereken şeyleri adlandırın.

Bize 54 sayfaya mal olan kalıp tam olarak buydu. Eski çeviri talimatımız aslında bir dilekten ibaretti:

Zayıf: Bu yazıyı Almancaya yeniden çevir ve marka isimlerini koru.

Bunun içinde bir slug'ın ne yapmasına izin verildiğine dair hiçbir şey yok. Bu yüzden bir yeniden çalıştırmada ajan URL slug'ını "iyileştirdi" ve yeni bir slug yeni bir doküman anlamına geldiği için aynı yazı için iki canlı Almanca sayfayla sonuçlandık. Bunu dillere ve eski yazılara katlayınca 54 kopya ve bir yığın yinelenen içerik dışlaması ortaya çıkıyor. Çözüm daha güzel bir dilek değil, bir şartnameydi:

Güçlü: Bu yazıyı Almancaya yeniden çevir.
- Eğer bir Almanca dosya zaten varsa, mevcut slug'ını harfiyen kopyala.
  Asla yeniden türetme veya "iyileştirme."
- Herhangi bir doküman oluşturmadan önce, mevcut olanı canonical referansıyla
  bul ve o kaydı yeniden kullan.
- Üreteceğin slug canlıdakinden farklıysa DUR ve bana söyle. Değişen bir
  slug, aynı sayfa için ikinci bir canlı URL yaratır.

Güçlü prompt, hata modunu açıkça adlandırır. Ne olmaması gerektiğini ve nedenini söylemek gibi tek bir alışkanlık, çoğu ekibin yapabileceği en değerli tek değişikliktir. Ayrıca her görev promptunu açık bir çıktı sözleşmesiyle bitiriyoruz ("son mesajın kelime sayısını, doğrulama puanını ve dokunulan dosyaları raporlaması gerekir"); böylece ajan sadece ne yapması gerektiğini değil, "bitti"nin ne üreteceğini de bilir.

2. Bağlam Seçimi: Dosyaları Adlandırın, Gerisini Kapatın

Bağlam seçimi, ajanın etrafta grep yapıp penceresini gürültüyle doldurmasına izin vermek yerine, tam olarak hangi dosyaları okuyacağını ve hangilerine dokunmayacağını söylemek demektir. Anthropic'in kendi rehberliği bunun nedeni konusunda açık sözlü: bağlam penceresi hızla dolar ve dolduğu ölçüde kalite düşer, bu yüzden en iyi uygulamaların çoğu onu korumak için var (Claude Code en iyi uygulamalar).

Zayıf: Ödeme akışındaki hatayı düzelt.

Güçlü: Sadece src/checkout/cart.ts ve src/checkout/tax.ts dosyalarını oku.
$1,000 üzerindeki siparişlerde vergi yuvarlaması yanlış (sipariş toplamı
yerine her satır kalemini yuvarlıyor). Yuvarlamayı düzelt. src/checkout/
dışındaki hiçbir şeye dokunma.

Sıkı sınır çiziyoruz. Ajan promptlarımızdan gerçek bir satır şöyle: "url-mapping.json, pipeline.md veya config.json dosyalarına yazma ve scratchpad dizinin dışındaki hiçbir dosyaya asla dokunma." Bu tek cümle, sonradan yapılan her türlü temizlikten daha fazla kazara hasarı önledi. Görev gerçekten canlı dokümanlara veya ek araçlara ihtiyaç duyduğunda, ajanın doğru dosyaya rastgele denk gelmesini ummak yerine bunları MCP sunucuları üzerinden bilerek ekliyoruz. Ve bu bağlamın herhangi bir kısmı repo'nuzun dışından geliyorsa, onu güvenilmez sayın: kazınmış bir sayfayı bir kodlama ajanına yapıştırmadan önce prompt injection prevention notumuza bakın.

3. Önce Plan: Düzenlemeden Önce Önermesini Sağlayın

Önce-plan yaklaşımı, ajanın herhangi bir şeyi düzenlemeden önce size bir yaklaşım sunmasını sağlar. Claude Code'da Plan Modu, modelin yanından geçip gidebileceği kibar bir "önce düşün" değil, sert ve zorunlu kılınan salt okunur bir durumdur; yani siz planı onaylayana kadar ajan gerçek anlamda yazamaz. Araştırma ve planlamayı uygulamadan ayırmak, Anthropic'in yanlış problemi çözmekten kaçınmak için en çok dayandığı tek uygulamadır.

Zayıf: API'ye rate limiting ekle.

Güçlü: Herhangi bir kod yazmadan önce bana numaralandırılmış bir plan ver:
hangi middleware, sayaçların nerede tutulacağı, 429 yanıtını ve header'ları
nasıl ele alacağın ve hangi testleri ekleyeceğin. Düzenlemeden önce onayımı
bekle.

Neden işe yarar: planı okumak ucuz, düzeltmek de ucuzdur. Yanlış bir planı düzeltmek bir cümleye mal olur; yanlış kodu düzeltmek ise bir inceleme döngüsüne mal olur. Bu, modelden önce adım adım akıl yürütmesini istemekle doğal olarak eşleşir (chain-of-thought prompting'e bakın) ve önemsiz olmayan her şey için çalıştırdığımız çok adımlı Claude Code workflows'un omurgasıdır.

4. Önce Test: Kabul Testlerini Prompta Koyun

Önce-test yaklaşımı, kabul kriterlerini somut girdi ve çıktılar olarak prompta koyar; böylece ajan tahmin ettiği değil sizin tanımladığınız bir hedefe karşı kod yazar. Başarısız olan testi veya beklenen sonuçların küçük bir tablosunu yapıştırın ve "testi değiştirmeden bunu geçir" deyin.

Zayıf: ISO 8601 tarihlerini parse eden bir fonksiyon yaz.

Güçlü: Testi değiştirmeden bu başarısız testi geçir:

  parseIso("2026-07-20T15:00:00Z")   -> Tam olarak o UTC anındaki Date
  parseIso("2026-07-20")             -> 2026-07-20T00:00:00Z anındaki Date
  parseIso("not-a-date")             -> RangeError fırlatır
  parseIso("")                       -> RangeError fırlatır

Sadece fonksiyonu ve import'larını döndür.

Somut örnekler her zaman sıfatları yener. "Uç durumları ele al" bir umuttur; dört girdi-çıktı satırı ise modelin gerçekten karşılayabileceği bir şartnamedir ve kod geldiği anda bunları çalıştırabilirsiniz.

5. Hata Ayıklama: Hata, Tekrar Üretme, Beklenen, Düzeltmeden Önce Kök Neden

Bir hata ayıklama promptu, ajana hata metnini, onu tetikleyen girdiyi ve ne beklediğinizi verir, ardından herhangi bir düzeltmeden önce nedeni sorar. Bunu atlarsanız ajan belirtiyi yamar ve hata sadece daha sessiz bir yere taşınır.

Zayıf: Bu bir hata fırlatıyor, düzelt.

Güçlü: Bu, ödeme sırasında hata fırlatıyor. İşte stack trace: [yapıştır].
Bu sadece sepette hem bir indirim kodu HEM DE bir hediye kartı olduğunda
oluyor (tekrar üretme: ikisini de ekle, sonra ödemeyi tamamla). Beklenen:
ikisi de uygulanır, hediye kartı en son. Kök nedeni bul ve herhangi bir
şeyi değiştirmeden önce tek cümlede açıkla. Hatayı gizleyen bir try/catch
içine sarma.

Önce "nedeni tek cümlede açıkla" satırı gerçek bir iş görüyor. Model, mantığını hiç görmediğiniz bir düzeltmeyi göndermek yerine, sizin akıl sağlığı kontrolü yapabileceğiniz bir teşhise bağlanmaya zorlanır. "Try/catch içine gizleme" satırı ise en yaygın kaçış kapısını kapatır.

6. Refactor: Yapıyı Değiştirin, Davranışı Koruyun, Diff'i Gösterin

Bir refactor promptu kapsamı sıkı şekilde kısıtlar: yapıyı değiştir, davranışı aynı tut ve diff'i göster. Bir sınır olmadan ajanlar hiç istemediğiniz şeyleri "düzenler" ve önemli olan değişikliği inceleme yeteneğinizi kaybedersiniz.

Zayıf: Bu dosyayı temizle.

Güçlü: Doğrulama mantığını submitOrder() içinden saf bir fonksiyon olan
validateOrder()'a çıkar. Her public signature'ı ve tüm davranışı aynı tut.
Bu dosyada başka hiçbir şeyi değiştirme. Bana bir öncesi/sonrası diff'i ve
her değişikliğin neden davranışı koruduğuna dair tek satır göster.

Bu, daha önceki config-ile-prompt ayrımının diğer yüzüdür: kalıcı stil kurallarınız Cursor kuralları'nda yaşar, ama bu refactor'ın kapsamı prompta ait. "Başka hiçbir şeyi değiştirme" refactor'ları incelenebilir tutan ifadedir.

7. İnceleme: Karşılaştırılacak Bir Kontrol Listesi, Artı Kanıt

Bir inceleme promptu, ajana karşılaştırılacak bir kontrol listesi verir ve bir hüküm değil kanıt talep eder. "İyi görünüyor" değersizdir; çalıştırdığı komut ve aldığı çıktı ise değildir. Anthropic bunu açıkça koyuyor: ajanın başarıyı iddia etmesi yerine kanıt göstermesini sağlayın (test çıktısı, komut ve sonucu), çünkü kanıtı okumak kendiniz yeniden doğrulamaktan daha hızlıdır.

Zayıf: PR'ımı incele.

Güçlü: Bu diff'i tam olarak şu beş maddeye karşı kontrol et:
1. Hiçbir gizli anahtar veya API key eklenmemiş
2. Her yeni fonksiyonun bir testi var
3. src/checkout/ dışında davranış değişikliği yok
4. Hata yolları string değil, tipli hatalar döndürüyor
5. Geride hiçbir console.log kalmamış
Her madde için, onu karşılayan veya ihlal eden satırı alıntıla. Sonra test
suite'ini çalıştır ve çıktıyı yapıştır. "Bitti" deme; bana göster.

Bizim inceleme kapımız tam olarak bu şekilde kurulmuş. Bir ajanın bir yazıyı yayınlandı olarak raporlamasına izin verilmeden önce, taslağı yasaklı kelime listesine karşı grep'ler (sert bir engelleyici, sıfır tolerans) ve doküman gövdesinin boş olmadığını doğrulamak için bir sorgu çalıştırır. Ajan başarıyı iddia edemez; kontrol çıktısını üretmek zorundadır. Çokça tekrar kullandığınız incelemeci rolleri için kontrol listesini kayıtlı bir personaya yükseltin; system prompt examples tam da burada devreye giriyor.

Claude Code, Cursor ve Copilot: Her Kalıp Nerede Yaşıyor

2026'nın üç büyük ajanı da yukarıdaki her kalıbı destekliyor, ama yüzey farklı. Claude Code, Plan Modu ve subagent'lara dayanıyor; Cursor, Agent modu ve Agents penceresine; GitHub Copilot ise agent modu artı instruction dosyalarına. Ekibinizin yaşadığı aracı seçin; kalıplar sorunsuzca taşınır.

Bilinmesi gereken birkaç güncel detay var. Claude Code'un Plan Modu gerçek bir salt okunur kilittir ve subagent'ların her biri kendi araçlarıyla izole bir bağlamda çalışır (subagent dokümanları). Cursor'ın 2026 hattı, her biri kendi git worktree'sinde paralel ajanlar başlatan bir Agents penceresi ekledi (Cursor 2.0). GitHub Copilot'un agent modu, özel talimatları .github/copilot-instructions.md dosyasından ve applyTo alanına sahip yol bazlı .instructions.md dosyalarından okur (Copilot özel talimatları). Cursor günlük aracınızsa, Cursor'ı daha verimli kullanma yazımıza bakın.

Techsy'de Kodlama Ajanlarımızı Nasıl Yönlendiriyoruz

Bir içerik pipeline'ını, görev mesajlarıyla koordine edilen 16 kişilik bir Claude Code ajan ekibi olarak yürütüyoruz: bir araştırmacı, bir brief yazarı, bir içerik yazarı, dokuz çevirmen, bir doğrulayıcı ve bir yayıncı. Bu sistemden gelen iki kural, herhangi bir kodlama ekibine de uyarlanabilir.

Birincisi, her görev promptu bir çıktı sözleşmesiyle biter. Son satır her zaman "son mesajın X, Y ve Z'yi raporlaması gerekir" ifadesinin bir versiyonudur. "Bitti"nin tam şeklini bilen bir ajan, sadece neyle başlayacağı söylenen bir ajana göre çok daha az savrulur.

İkincisi, bir ajanın kendi ödevini düzyazıyla notlamasına asla izin vermeyiz. Üretim ve doğrulama ayrı adımlardır ve doğrulama bir fikir değil, çıktısı olan bir komuttur. Bu inşa-ve-kontrol ayrımı, Anthropic'in building reliable agents çerçeveleme biçiminin özündedir ve inceleme kapımızın "iyi görünüyor"a güvenmek yerine grep'lemesinin ve sorgulamasının nedeni budur.

Bu aynı zamanda asıl işimiz. Techsy'de B2B ekipleri için yapay zeka ajanları ve otomasyon inşa ediyoruz ve böyle bir prompt disiplini, bir demoyu bir müşterinin önüne koyabileceğiniz bir şeyden ayıran şeyin büyük kısmıdır. Bir kodlama veya ajan iş akışının doğru şekilde kurulmasını istiyorsanız, tam olarak bunu yaptığımız yer yapay zeka entegrasyon hizmetimizdir; yığınınızı konuşmak için ücretsiz bir danışmanlık randevusu alabilirsiniz.

Uyarlayabileceğiniz Kopyala-Yapıştır Prompt Şablonu

Önemsiz olmayan herhangi bir kodlama görevi için başladığımız iskelet burada. İhtiyacınız olmayan bölümleri silin ama sırayı koruyun, çünkü bu sıra yedi kalıbı yansıtıyor.

HEDEF
Tek cümle: bittiğinde ne doğru olmalı.

BAĞLAM
Sadece şunu oku: <tam dosyalar>. Geri kalan her şeyi yok say.
İlgili gerçekler: <kısıtlar, versiyonlar, hatanın tetikleyicisi>.

ÖNCE PLAN
Düzenlemeden önce bana numaralandırılmış bir plan ver ve onay bekle.

TESTLER / BİTTİ
Bitti demek şu demek: <başarısız testi veya girdi->çıktı satırlarını yapıştır>.
Testleri değiştirme.

KISITLAR
Aksi belirtilmedikçe tüm public signature'ları ve davranışı aynı tut.
<dosyalara/alanlara> dokunma. Yaptığın her varsayımı adlandır.

ÇIKTI
Bir öncesi/sonrası diff göster, testleri çalıştır ve çıktıyı yapıştır.
"Bitti" deme; kanıtı göster.

Bunu bir snippet olarak kaydedin, ya da daha iyisi ikiye bölün: kalıcı kısıtlar config dosyanıza, hedef, bağlam ve testler ise prompta gitsin. Asıl mesele bu ayrım.

Sıkça Sorulan Sorular

Kodlama için prompt mühendisliği nedir?

Kodlama için prompt mühendisliği, bir yapay zeka ajanının doğru ve incelenebilir kod üretmesini sağlayan talimatlar yazma pratiğidir. Pratikte bu, hedefi ve "bitti" tanımını belirtmek, kapsamdaki dosyaları adlandırmak, düzenlemeden önce bir plan zorunlu kılmak, testler sağlamak ve kanıt talep etmek anlamına gelir. Zekice bir cümle yazmaktan çok bir şartname yazmaya yakındır.

Bir CLAUDE.md veya .cursor/rules dosyası yazmaktan nasıl farklıdır?

Config dosyaları, ajanın her oturumda okuduğu kalıcı politikayı tutar: yığınınız, kurallarınız ve test komutunuz. Görev bazlı bir prompt ise o an ajana verdiğiniz somut görevdir. Kalıcı kuralları config'e, görevi ise prompta koyun. Bütün görev promptlarını bir config dosyasına yapıştırmak her oturumu şişirir ve yine de bireysel görevi çerçeveleyemez.

Yapay zeka kodlama ajanları için en iyi prompt yapısı nedir?

Tek bir paragraf yerine etiketlenmiş bölümler kullanın: HEDEF, BAĞLAM, PLAN, TESTLER, KISITLAR ve ÇIKTI. Ajanlar, yapılandırılmış promptları düz metin duvarlarından daha güvenilir şekilde ayrıştırır. Başarı kriterlerini en başta belirtin, sıfatlar yerine bir ila üç somut örnek verin ve geri istediğiniz kesin çıktı formatını belirtin.

İyi bir hata ayıklama promptu nasıl yazılır?

Ajana dört şey verin: tam hata veya stack trace, onu tekrar üreten girdi, ne beklediğiniz ve herhangi bir düzeltmeden önce kök neden talebi. Teşhisi kontrol edebilmeniz için "herhangi bir şeyi değiştirmeden önce nedeni tek cümlede açıkla" ekleyin ve hatayı maskelemek yerine düzeltmesi için "try/catch içine gizleme" ekleyin.

Kodlama promptlarıma test eklemeli miyim?

Evet, elinizden geldiğince. Başarısız testi veya girdi-çıktı satırlarından oluşan küçük bir tabloyu yapıştırmak, bulanık bir isteği modelin gerçekten vurabileceği bir hedefe dönüştürür ve sonucu hemen çalıştırabilirsiniz. Ajana testleri değiştirmeden geçirmesini söyleyin, böylece kendi kodunu doğru göstermek için hedefi kaydıramaz.

Bu promptlar Cursor ve GitHub Copilot'ta da işe yarıyor mu?

Evet. Kalıplar araçtan bağımsızdır. Claude Code bunları Plan Modu ve subagent'lar üzerinden, Cursor Agent modu ve ajan başına worktree'ye sahip Agents penceresi üzerinden, GitHub Copilot ise agent modu artı .github/copilot-instructions.md üzerinden sunar. Yüzey değişir; görev çerçeveleme, bağlam seçimi, önce-plan ve kanıta dayalı inceleme değişmez.

Bir kodlama promptu ne kadar uzun olmalı?

Bir şartname olacak kadar uzun, odaklı kalacak kadar kısa. Bağlam dolduğunda akıl yürütme kalitesi düşer, bu yüzden hacim yerine yapıyı tercih edin: doğru dosyalara ve testlere sahip, etiketlenmiş 150-300 kelimelik bir prompt, dağınık bir promptu her zaman geçer. Her göreve uygulanan her şeyi tekrar etmek yerine config dosyanıza taşıyın.

Bir yapay zeka ajanının sormadığım kodu değiştirmesini nasıl engellerim?

Kapsamı promptta sınırlayın. Tam olarak hangi dosyaları düzenleyebileceğini söyleyin, "başka hiçbir şeyi değiştirme" ekleyin ve "ben aksini söylemedikçe tüm public signature'ları ve davranışı aynı tut" şartını koyun. Refactor'lar için, her değişikliğin neden davranışı koruduğuna dair tek satırlı bir öncesi/sonrası diff isteyin; böylece istenmemiş herhangi bir düzenleme incelemede belli olur.

Kopyala-yapıştır prompt kütüphaneleri buna değer mi?

Bir başlangıç noktası olarak bazen evet. Bitmiş bir araç olarak nadiren. 50 promptluk bir kütüphane size ifade biçimi verir ama doğruluğun gerçekten yaşadığı yer olan dosyalarınızı, testlerinizi veya kısıtlarınızı bilemez. Kalıpları öğrenin, uyarlanabilir tek bir şablon tutun ve önünüzdeki görevin ayrıntılarını siz doldurun.