Prompt Engineering: Explicit Criteria, Few-shot, Interview Pattern

Bu ders Domain 4’ün (Prompt Engineering and Structured Output, %20) ilk yarısı. Sınavın “kod üretirken hangi promptu kullanırdın?” soruları buradan çıkıyor. Öğreneceğimiz şey: iyi prompt “akıllıca yazılmış cümle” değil, sayısal veya kategorik kriter + 2-4 örnek + belirsizlikte duraklama üçlüsü.

Neden bu konu sınavda çıkıyor

Domain 4 sınavın %20’si; yani 60 sorudan yaklaşık 12’si doğrudan bu dersin kapsamında. Pratik sınav senaryolarından Code Generation ve Multi-Agent Research bu domain’e ağır basıyor. Bir tipik sınav sorusu: “Claude review yaparken false positive üretiyor, hangi prompt değişikliği en etkili?” — doğru cevap severity tablosu gibi kategorik kriter vermek, “be conservative” gibi belirsiz sıfat kullanmak değil.

Temel kavramlar

1. Belirsiz talimat vs kategorik kriter

Kötü prompt: “Be conservative when flagging issues.” Bu cümle iki okuyucu için farklı şey ifade eder — biri “yanlış pozitif verme” der, diğeri “şüpheli olanı da raporla” der. Claude için de aynı belirsizlik var.

İyi prompt: severity tablosu. Her seviye için somut eşik:

Severity kriterleri (kod review):

CRITICAL — Üretimde veri kaybı, güvenlik açığı (auth bypass, SQL injection,
  hardcoded secret, unwrap() panik). Derhal bloke et.

HIGH — Doğruluk hatası, veri bozulması, off-by-one, yanlış hata kodu,
  kısmi başarı döndürme. PR'ı bloklaması gereken, ama release'te skip
  edilebilecek seviyede değil.

MEDIUM — Performans regresyonu (>%20 yavaşlama), eksik edge case (boş input,
  unicode), observability/logging yok. Backlog'a atılabilir.

LOW — Stil (isimlendirme, docstring), küçük refactor fırsatı, açıklayıcı
  yorum eksik. İsteğe bağlı.

Bu tablo verildiğinde Claude’un false positive oranı dramatik düşer, çünkü artık “conservative” kavramını yorumlamıyor — eşikleri sayıyor. Sınavda “aşağıdakilerden hangisi prompt kalitesini en çok artırır?” sorusuna cevap kategorik kriter olmalı; “daha uzun prompt” veya “daha az talimat” tuzak seçenekler.

Yüksek false-positive üreten kategorileri geçici olarak disable et, prompt’u iyileştirdikten sonra geri aç — developer güvenini korumanın en hızlı yolu. Few-shot eklemek, confidence göstermek veya strictness kısmak kök nedeni çözmez; gürültüyü kes, sonra düzelt. (Pratik sınav bunu iki kez soruyor.)

2. Few-shot: 2-4 örnek altın kural

Sınavın en sık düşürdüğü tuzak: “Few-shot için ne kadar çok örnek o kadar iyi.” Yanlış. Az örnek overfit eder (tek pattern ezberler), çok örnek context’i şişirir ve token israfı yaratır. 2-4 örnek, farklı pattern’leri temsil edecek şekilde, optimum nokta.

# Few-shot örneği — 3 kontrast, farklı pattern'ler
few_shot = [
    {
        "input": "fn divide(a: i32, b: i32) -> i32 { a / b }",
        "verdict": "HIGH",
        "reason": "Division by zero panic; sıfır input için explicit kontrol yok."
    },
    {
        "input": "let secret = \"AKIA...\";  // hardcoded",
        "verdict": "CRITICAL",
        "reason": "AWS access key; env var veya secrets manager kullanılmalı."
    },
    {
        "input": "users.iter().map(|u| u.email).collect::<Vec<_>>()",
        "verdict": "LOW",
        "reason": "Stil: turbofish yerine type inference'a izin ver."
    }
]

Neden 2-4? Bir örnek → tek bir pattern. İki örnek → minimum karşılaştırma (iyi/kötü). Üç örnek → üç farklı severity seviyesi gösterebilir. Dört → max çeşitlilik. Beşinci örnek artık yeni bilgi katmıyor, sadece token yakıyor.

Few-shot, extraction görevlerinde halüsinasyonları azaltır ve modelin default’ları tekrarlamak yerine yeni pattern’lere genellemesini sağlar.

Normalization rules — strict JSON schema kullanıyorsan prompt’a açıkça yaz:

• Tarihler: daima ISO 8601 (YYYY-MM-DD); “dün” → mutlak tarih hesapla.
• Para birimi: numerik tutar + currency code; “beş dolar” → {"amount": 5, "currency": "USD"}.
• Yüzde / oran: decimal fraction; “yarısı” → 0.5.

Bu kurallar schema’nın syntax doğrulamasını geçer ama semantik olarak tutarsız değerleri engeller.

3. Interview pattern — Claude ne zaman soru sormalı?

Çoğu prompt “hadi yap” diye başlar; ama gerçek production task’larında belirsizlik kaçınılmaz. Interview pattern = Claude’un belirsizlik tespit ettiğinde tahmin yürütmek yerine netleştirici soru sormasını söyleyen prompt deseni.

Eğer istekte şu 3 bilgi yoksa DUR ve SOR (tahmin yürütme):
  1. Hedef kullanıcı (yeni müşteri / mevcut müşteri / internal tool)
  2. Çıktı tipi (production data / test data / anonymized)
  3. Dil / locale (Türkçe karakter korunsun mu)

Sor formatı: "X için iki seçenek var: (a) ..., (b) ... Hangisi?"

Sınav tuzağı: “Claude her zaman tek seferde cevap vermeli, soru sormak verimsizlik.” Yanlış. Bir kez yanlış üretip düzeltmek, iki tur netleştirme turlarından belirgin biçimde daha pahalı. Coordinator’lar için bu özellikle kritik: alt-agent’a yanlış spec göndermek tüm pipeline’ı bozar.

Ne zaman interview? Rehber 6.4 tetikleyicileri: tanıdık olmayan domain (fintech, healthcare, legal), örtük gereksinimli görevler (cache invalidation stratejisi, failure mode’ları), ve netleştirme maliyetinin yanlış üretim maliyetinden ucuz olduğu her yer.

4. Test-driven iteration

Promptu production’a salmadan önce 5-10 temsili örnek üzerinde dene. Bunlar sadece rastgele örnek değil, en zor case’ler olmalı (edge case, bilinen false positive, kültürel locale).

Pratik workflow:

1. Severity tablosunu yaz
2. 3 few-shot örneği ekle
3. 5 hard-case eval set oluştur (her severity’den en az bir tane)
4. Her örneği manuel etiketle (doğru cevap ne olmalı)
5. Prompt’u çalıştır, sonuçları karşılaştır
6. Çıkan yanlışlara göre promptu güncelle (eval set’i değiştirme!)

📝 Rehber kapsamı dışında (pratik öneri): Eval set’i değiştirmek overfit demektir — test’i geçecek diye promptu eğritirsin. Sınavda “iterasyon sırasında ilk önce ne değiştirilir?” sorusuna cevap prompt olmalı; eval set’i sabit kalır.

5. Interdependent vs independent issue’lar — mesaj yapısı

Bir code review turunda Claude’a birden fazla issue’yu nasıl gruplayacağını söylemek, çıktı kalitesini belirgin artırır. Kural:

• 📝 Rehber kapsamı dışında (pratik öneri): Interdependent issue’lar (bir fix diğerini etkiler) → tek mesajda birlikte
• 📝 Rehber kapsamı dışında (pratik öneri): Independent issue’lar (birbirine dokunmayan) → sıralı, paralel işlenebilir mesajlar

# Doğru yapı

Mesaj 1 (interdependent — birlikte değerlendirilmeli):
  - Auth middleware'de token validation eksik
  - Token validation olmadan session check anlamsız

Mesaj 2 (independent):
  - Login endpoint'inde rate limiting yok
  - Password strength validator'da unicode kontrolü yok

Mesaj 3 (independent):
  - README'de env variable listesi güncel değil

Bu gruplama neden önemli? Claude interdependent issue’ları birlikte düşününce daha isabetli çözüm üretir (auth + session birlikte fix). Independent’ları ayırmak ise paralel sub-agent’lara delege etmeyi kolaylaştırır (hub-and-spoke pattern, Domain 1).

6. Prompt Chaining (Ch 6.3)

Öngörülebilir, tekrarlanabilir çok-adımlı işlerde işi sabit adımlara böl:

Adım 1: auth.ts dosyasını analiz et (sadece local issue'lar)
        -> Çıktı: auth.ts issue listesi
Adım 2: database.ts dosyasını analiz et (sadece local issue'lar)
        -> Çıktı: database.ts issue listesi
Adım 3: cross-file integration pass (modül sınırları, veri akışı)
        -> Çıktı: modül arası issue'lar

Neden bu önemli? Tüm dosyaları tek seferde vermek attention dilution yaratır — model bazı dosyaları atlayıp diğerlerine yüzeysel yorum yapar. Ders 07’deki multi-pass review (per-file + integration) tam bu pattern.

Prompt chaining vs dynamic decomposition:

• Prompt chaining = predictable pipeline (code review, file migration).
• Dynamic decomposition = open-ended iş; alt görevler ancak execution sırasında netleşir.

Sınav “bu hangisi?” diye sorar: kriter tekrar edilebilirlikse chaining, scope keşif sırasında genişliyorsa dynamic decomposition.

7. Self-review sınırı (Ch 4.6)

Model kendi ürettiği kodu review ederken kendi akıl yürütme context’ini taşır, kendi kararlarına meydan okuma olasılığı düşüktür → bağımsız ikinci instance (generation context’i olmadan) daha güvenilir. Sınav “kendi kodunu eleştirmesi için generation prompt’una talimat ekle” seçeneğini yanlış sayar; doğru cevap fresh instance’tır.

8. Anti-pattern: keyword-based tool routing

⚠️ Anti-pattern. System prompt’a “kullanıcı X kelimesini geçirirse Y tool’unu çağır” türü keyword kuralları koymak, tool description’ları net olsa bile modeli yanlış tool’a yönlendirir. Rehber Q56 vakası: “account” kelimesi geçen mesajlarda get_customer %78, geçmeyenlerde lookup_order %93 oranla seçiliyordu — kök neden prompt’taki keyword routing’di. Routing’i description’lara bırak; prompt’ta niyet tanımla, kelime değil.

Sınav tuzakları

• “Few-shot için ne kadar çok örnek o kadar iyi.” → Yanlış. 2-4 optimum. Az örnek overfit, çok örnek context şişirir. Sınav bunu “Best practice” gibi sunar.
• “Claude her zaman tek seferde cevap vermeli, interview pattern verimsiz.” → Yanlış. Tek seferde yanlış cevap, iki tur netleştirmeden belirgin biçimde pahalı. Coordinator-subagent handoff’larında özellikle kritik.
• “‘Be conservative’ gibi kısa talimat yeterli, severity tablosu gereksiz detay.” → Yanlış. Belirsiz sıfat yorumlamaya açık; tablo sayısal/kategorik eşik verir. False positive oranını dramatik düşürür.
• “Promptu geliştirirken eval set’i de genişlet.” → Yanlış. Eval set sabit kalmalı; genişletmek overfit’e yol açar. Prompt güncellenir, eval set’i değil.
• “Belirsizlik gördüğünde Claude tahmin yürütsün, sonra düzeltiriz.” → Yanlış. Production’da bir kez yanlış üretmek, düzeltme maliyetinden belirgin biçimde daha pahalı. Interview pattern bunu önler.

Hands-on

Bir code review agent’ı için prompt v1 — sonra neden v2’ye geçtiğimizi göreceğiz:

# v1 — belirsiz
PROMPT_V1 = """
You are a code reviewer. Review the diff.
Be conservative when flagging issues.
List every concern.
"""

# v2 — kategorik + few-shot + interview
PROMPT_V2 = """
Sen kıdemli bir Rust code reviewer'ın. Aşağıdaki diff'i incele.

## Severity kriterleri
- CRITICAL: Prod'da veri kaybı, güvenlik açığı (unwrap panic, SQLi,
  hardcoded secret). Derhal bloke et.
- HIGH: Doğruluk hatası, off-by-one, yanlış hata kodu.
- MEDIUM: Performans regresyonu (>%20), eksik edge case.
- LOW: Stil, docstring eksikliği.

## Format
Her issue için: dosya:satır — severity — tek cümle açıklama.
Severity atamaktan çekinme; kriter netse MEDIUM/LOW da yaz.

## Eksik bilgi
Şu üçü diff'ten anlaşılmıyorsa DUR ve SOR (tahmin yürütme):
  1. Bu yeni feature mı yoksa refactor mı?
  2. Performans kritik mi (hot path / cold path)?
  3. Backward-compat gerekiyor mu?

## Örnekler
İyi review:
  src/auth.rs:42 — HIGH — Token validate edilmeden session lookup
    yapılıyor; süresi dolmuş token geçerli sayılır.
Kötü review:
  "Güvenlik riski var" — severity yok, konum yok, kanıt yok.
"""

Aynı diff’i iki promptla çalıştır: v1 genelde 15+ false positive verir (her şeyi “concern” olarak listeler), v2 tipik olarak 3-5 gerçek issue verir — hepsi severity’li, lokasyonlu, kanıtlı. Bu fark sınavda “hangi prompt daha iyi?” sorusunun somut cevabı. Filtreleme istenmiyorsa bile her finding’e rationale + confidence eklemek inceleme süresini düşürür — developer tıklayıp okumadan neyle uğraştığını görür.

Özet

• Kategorik kriter (severity tablosu) belirsiz sıfattan (conservative, careful) üstündür.
• Few-shot 2-4 örnek optimum; 1 overfit, 5+ token israfı.
• Interview pattern Claude’un belirsizlikte tahmin yerine sormasını sağlar; coordinator-subagent handoff’larında kritik.
• Test-driven iteration: eval set sabit, prompt güncellenir.
• Interdependent issue’lar tek mesajda, independent olanlar ayrı mesajlarda gruplanır.
• Sınav formülü: “kategorik kriter + few-shot 2-4 + interview + TDD” dörtlüsü = prompt kalitesinin temel taşları.

Kaynaklar

• Anthropic Prompt Engineering Overview
• Anthropic Prompt Library — Few-shot examples
• Anthropic Engineering — Be clear and direct