Bir AI ajanına "şunu yap" demek artık yetmiyor. Tek turlu bir prompt, tek seferlik bir görevde hâlâ işe yarar; ama çok adımlı bir kod değişikliği, bir dosya sistemini gezme veya saatlerce süren bir ajan oturumu söz konusu olduğunda mesele kelime seçimi olmaktan çıkıp hangi bilginin ne zaman, hangi biçimde ve ne kadar bağlam penceresi harcayarak modele verildiği sorusuna dönüşüyor. Buna context engineering deniyor ve Anthropic bunu prompt engineering'in yerine değil, doğal devamı olarak konumlandırıyor.
💡 Pro Tip: Context engineering'i "daha iyi prompt yazmak" olarak değil, "her turda modele ne göndereceğine karar veren bir bütçe yönetimi" olarak düşün — soru "ne yazayım" değil "neyi bağlamda tutup neyi dışarıda bırakayım".
İçindekiler
- Prompt engineering neden yeterli olmayı bıraktı
- Neden bu bir mühendislik problemi
- Context engineering'in temel bileşenleri: talimat, bilgi, araç, hafıza
- Bağlam bütçesi: token maliyeti ve dikkat seyrelmesi
- Kalıcı katman: kural dosyaları, örnekler, proje hafızası
- Alt-ajanlara bağlam devri ve verbose işi ana bağlamdan uzak tutma
- Prompt cache'i kırmayan çalışma düzeni
- Kendi projemden gözlem: bağlam disiplini olmadan ne olur
- Güncelleme (Eylül 2026)
- SSS
- Context engineering nedir, prompt engineering'den farkı ne?
- AI kodlama ajanına doğru context nasıl verilir?
- CLAUDE.md dosyası nasıl yazılmalı?
- Prompt engineering öldü mü?
- Bağlam penceresi büyüdükçe context engineering'e ihtiyaç azalır mı?
- Sonuç
- Kaynaklar
Prompt engineering neden yeterli olmayı bıraktı
Prompt engineering, tek bir mesajın ifadesini optimize etmekle ilgilidir: doğru kelimeler, doğru örnekler, doğru format. Anthropic'in kendi konumlandırması net: "At Anthropic, we view context engineering as the natural progression of prompt engineering" — yani biri diğerini iptal etmiyor, üstüne inşa ediyor.
Sorun şu ki prompt engineering çoğunlukla tek turlu etkileşim seviyesinde çalışır. Anthropic bu sınırı kendi makalesinde doğrudan kuruyor: "as we move towards engineering more capable agents that operate over multiple turns of inference and longer time horizons, we need strategies for managing the entire context state". Bir ajan dosya okuyup, test çalıştırıp, hata mesajını yorumlayıp bir sonraki adıma karar verdiğinde, artık "en iyi prompt" diye bir şey yok — her turda hangi geçmişin, hangi tool sonucunun, hangi dosya içeriğinin bağlamda kalacağına karar veren bir _sistem_ var.
Bunu daha da karmaşıklaştıran bir fiziksel gerçek var: context rot. Bağlam penceresine ne kadar çok token doldurursan, modelin o bilgiyi doğru hatırlama kabiliyeti o kadar düşer. Bu, "daha büyük context window = daha iyi sonuç" sezgisinin neden yanlış olduğunu açıklıyor — pencere büyüse de, içine attığın her ilgisiz token bir sonraki gerçekten önemli tokenın "görünürlüğünü" azaltıyor.
Neden bu bir mühendislik problemi
Prompt engineering bir defalık bir yazma işiyken, context engineering yinelenen bir bakım işi: her ajan turunda "bu bilgiyi tutmalı mıyım, özetlemeli miyim, yoksa hiç göndermemeli miyim" kararını veren bir mekanizma kurmak. Bu yüzden tek bir prompt şablonu değil, bir _harness_ (ajanın çalıştığı iskelet: sistem promptu + tool tanımları + hafıza stratejisi + compaction kuralları) tasarlıyorsun.
Bu ayrımı somutlaştırmanın bir yolu, iki farklı soruyu yan yana koymak. Prompt engineering "bu turda modele ne söylemeliyim" sorusuna cevap arar. Context engineering ise "bu ajan oturumu boyunca, hangi bilgi ne zaman bağlama girmeli ve ne zaman bağlamdan çıkmalı" sorusuna cevap arar. Birincisi bir metin yazma becerisi, ikincisi bir sistem tasarımı becerisi — ve ikisi aynı anda gerekli, çünkü en iyi tasarlanmış bağlam yönetimi bile kötü ifade edilmiş bir talimatı telafi edemez.
Context engineering'in temel bileşenleri: talimat, bilgi, araç, hafıza
Anthropic bu bileşenleri kendi terminolojisinde "system prompts, tools, examples, message history" gibi adlarla anıyor; aşağıdaki tabloda onları pratik karşılıklarıyla eşleştiriyorum — eşleştirme bana ait, tarifler Anthropic'in kendi cümleleri.
Anthropic'in bileşeni | Pratik karşılığı | Kaynaktaki tarif |
|---|---|---|
System prompt | Talimat katmanı | "doğru irtifada" olmalı: ne çok katı ne çok belirsiz |
Tools | Araç sözleşmesi | Ajanın ortamla etkileşime girip yeni bağlam çekmesini sağlar |
Examples (few-shot) | Örnek/bilgi katmanı | Kural listesi değil, kanonik ve çeşitli örnekler |
Message history | Hafıza | Konuşma geçmişi + dosya tabanlı kalıcı notlar |
Talimat (system prompt) "doğru irtifada" olmalı. Anthropic'in ifadesiyle: "The optimal altitude strikes a balance: specific enough to guide behavior... yet flexible enough..." Çok katı bir talimat ajanı köşeye sıkıştırır, çok belirsiz bir talimat ise tutarsız davranışa yol açar.
Araçlar bir sözleşmedir, bir özellik listesi değil. En yaygın hata modu, birbirine benzeyen veya iş alanını fazla geniş kapsayan araç setleri kurmak. Anthropic bunu doğrudan söylüyor: "One of the most common failure modes we see is bloated tool sets that cover too much functionality..." Az ve net tanımlı araç, çok ve bulanık araçtan daha güvenilir sonuç verir.
Örnekler kural listesi değil, kanonik vakalar olmalı. "we recommend working to curate a set of diverse, canonical examples..." — yani "şunu yapma, bunu yap" listesi yerine, gerçek ve çeşitli örnek etkileşimler.
Hafıza ise bir sonraki bölümün konusu, çünkü mesaj geçmişinin ötesine geçen kalıcı bir katman gerektiriyor.
Bağlam bütçesi: token maliyeti ve dikkat seyrelmesi
LLM'lerin insanlar gibi sınırlı bir "dikkat bütçesi" var. Anthropic'in tarifiyle: "LLMs have an 'attention budget' that they draw on when parsing large volumes of context." Her yeni token bu bütçeden harcanıyor — bağlama attığın her satır, aslında modelin dikkatinden bir pay alıyor.
Bunun mimari bir nedeni var: transformer mimarisi, n token için n² ikili ilişki üretiyor. Anthropic bunu şöyle özetliyor: "This results in n² pairwise relationships for n tokens." Sonucu da koşuluyla birlikte veriyor: "As its context length increases, a model's ability to capture these pairwise relationships gets stretched thin, creating a natural tension between context size and attention focus." Yani bağlam uzadıkça, modelin her token çiftini birbiriyle ilişkilendirme kapasitesi gerilir — bu "context rot" dediğimiz düşüşün mimari kökeni.
Bu soyut bir endişe değil. MIT NANDA'nın _The GenAI Divide_ raporuna göre (Fortune, 18 Ağustos 2025) kurumsal generative AI pilotlarının büyük çoğunluğu ölçülebilir bir etki üretemiyor: "The 95% failure rate for enterprise AI solutions represents the clearest manifestation of the GenAI Divide." Fortune'un aktardığı kök neden de tanıdık: "The core issue? Not the quality of the AI models, but the 'learning gap' for both tools and organizations." — yani sorun modelin "zekası" değil, ona verilen bağlamın ve bağlanma biçiminin kalitesi.
Pratikte bağlam bütçesini yönetmenin üç somut yolu var:
- Just-in-time retrieval: Her şeyi baştan yükleme, ajan ihtiyaç duyduğunda dosya sistemini gezsin (glob/grep).
- Compaction: Konuşma bağlam sınırına yaklaştığında, ham tool çıktılarını at, mimari kararları ve çözülmemiş sorunları koru.
- Alt-ajanlara devir: Verbose/keşif ağırlıklı işi ayrı, temiz bir bağlam penceresinde çalıştır, ana bağlama yalnız özeti gönder.
bash
1# Kötü örnek: tüm proje dosyalarını baştan bağlama yükleme2find src -name '*.ts' -exec cat {} + > /tmp/full-context.txt # on binlerce token, çoğu ilgisiz3 4# İyi örnek: ajan yalnız ihtiyaç duyduğu anda arar5grep -rn "handleAuthRefresh" src/lib/auth-v2/ | head -206# → yalnızca ilgili birkaç yüz token bağlama girerBu üç yaklaşımın hangisini ne zaman seçeceğine dair kaba bir rehber:
Yaklaşım | Ne zaman uygun | Riski |
|---|---|---|
Preload (baştan yükleme) | Küçük, sık kullanılan, nadiren değişen bilgi (CLAUDE.md, kısa kural listesi) | Büyük dosyada bağlam bütçesini hızla tüketir |
Just-in-time retrieval | Büyük veya nadiren gerekli bilgi (kaynak kod, log, eski konuşma) | İlk turda gecikme; ajan doğru sorguyu bulamazsa eksik kalır |
Alt-ajana devir | Verbose keşif/analiz işi (log tarama, çok dosyalı arama) | Koordinasyon karmaşıklığı; özet kalitesine bağımlılık |
Üçü de birbirini dışlamıyor: pratikte bir görevde kısa kural dosyası preload edilir, kaynak kod just-in-time aranır, uzun bir log analizi ise ayrı bir alt-ajana devredilir. Seçim kriteri her zaman aynı soruya iniyor: bu bilgi her turda mı lazım, yoksa yalnızca bazı turlarda mı?
Kalıcı katman: kural dosyaları, örnekler, proje hafızası
Anthropic, Claude Code'un CLAUDE.md dosyalarını nasıl ele aldığını "hibrit strateji" olarak tarif ediyor: "CLAUDE.md files are naively dropped into context up front, while primitives like glob and grep allow it to navigate its environment..." Yani proje kuralları (kısa, yoğun, sık kullanılan bilgi) baştan yüklenir; ama proje dosyalarının kendisi ajan gerektiğinde arar, hepsi önceden bağlama basılmaz.
markdown
1# CLAUDE.md — iyi bir kural dosyasının anatomisi2 3# Proje özeti4 5- Domain, stack, kritik yollar (2-3 satır, uzun anlatı değil)6 7# Çalışma kuralı8 9- Deploy tek kanonik script; elle komut zinciri yasak10- Kanonik ağaç sunucu, lokal repo bayat — ajan buna güvenmesin11 12# Absolute Prohibitions13 14- Mock data ile yeni modül yapma15- Test data production'da bırakmaBunun ötesinde, yapılandırılmış not tutma (structured note-taking / agentic memory) devreye giriyor: bağlam penceresi dışında kalıcı bir dosyaya ilerleme kaydetmek. Anthropic bunu şöyle tarif ediyor: "this simple pattern allows the agent to track progress across complex tasks, maintaining critical context and dependencies..." Bir NOTES.md veya ilerleme dosyası, ajan compaction'dan geçse veya oturum yeniden başlasa bile hangi kararların alındığını, hangi bug'ların çözülmediğini hatırlamasını sağlıyor.
Bu fikir, Sonnet 4.5 lansmanıyla birlikte resmi bir araca da dönüştü: Anthropic, dosya tabanlı bir memory tool'u Claude Developer Platform'da beta olarak yayınladı: "As part of our Sonnet 4.5 launch, we released a memory tool in public beta on the Claude Developer Platform..." Yani kalıcı hafıza artık yalnızca disiplinli bir pratik değil, platformun kendisinin desteklediği bir birincil sınıf yetenek.
Alt-ajanlara bağlam devri ve verbose işi ana bağlamdan uzak tutma
Tek bir ajanın koca bir projenin durumunu baştan sona kendi bağlam penceresinde tutmaya çalışması ölçeklenmiyor. Anthropic'in önerdiği model, "orkestratör + uzman alt-ajanlar" ayrımı: "Rather than one agent attempting to maintain state across an entire project, specialized sub-agents can handle focused tasks with clean context windows." Ana ajan yüksek seviyeli planı tutar ve koordine eder; alt-ajanlar derin, verbose işi (dosya keşfi, log okuma, uzun log çıktısı yorumlama) kendi temiz pencerelerinde yapar ve ana bağlama yalnız bir özetle döner.
json
1{2 "subagent_task": "changelog-diff-ozet",3 "input_scope": "CHANGELOG.md son 30 sürüm girdisi",4 "context_window": "izole, ana oturumdan bagimsiz",5 "return_to_parent": "≤1500 karakter ozet + dosya yolu",6 "raw_output_kept_in": "scratchpad, ana baglama girmez"7}Bunun tamamlayıcısı compaction: bağlam sınırına yaklaşan bir oturum özetlenip yeni bir pencereyle devam ediyor, ama her şey silinmiyor. Anthropic, Claude Code'daki uygulamasını şöyle anlatıyor: "The model preserves architectural decisions, unresolved bugs, and implementation details while discarding redundant tool outputs..." Yani hangi mimari karar alındığı ve hangi bug hâlâ açık kalıyor, ama bir dosyanın tam ham içeriği veya tekrarlanan bir tool çıktısı atılıyor.
Prompt cache'i kırmayan çalışma düzeni
Bağlam bütçesini yönetmenin bir diğer boyutu, aynı prefiks'i (sistem promptu, araç tanımları, kalıcı kural dosyası) tur boyunca sabit tutmak. Prompt caching, modelin aynı baştaki token dizisini tekrar tekrar "yeniden okumadan" tanımasına dayanır; bu yüzden her turda sistem promptunun başına değişen bir zaman damgası, rastgele bir ID veya farklı sıralanmış bir araç listesi eklemek cache'i kırar ve her turu daha pahalı ve daha yavaş hale getirir.
Pratik kural basit: sabit olanı başa, değişkeni sona koy. Sistem promptu + araç tanımları + kalıcı kurallar en başta ve turlar arasında birebir aynı kalmalı; o turun kullanıcı mesajı, o turun tool sonucu gibi değişken içerik en sona eklenmeli.
ts
1// Kötü: her turda farklı bir timestamp prefiksi cache'i kırar2const systemPromptBad = `Bugün ${new Date().toISOString()} — kurallar: ...`;3 4// İyi: sabit prefiks, değişken içerik ayrı bir mesajda5const systemPromptGood = `Kurallar: ...`; // her turda birebir aynı6 7async function runTool(name: string, pattern: string): Promise<string> {8 return `${name} sonucu: ${pattern}`;9}10 11async function buildTurnContext() {12 const toolResult = await runTool("grep", "handleAuthRefresh");13 return { systemPrompt: systemPromptGood, timestamp: Date.now(), toolResult };14}Bir alt-ajan mimarisinde bu kural daha da kritik: bir alt-ajan yeniden başlatıldığında (fork/resume), aynı araç listesini ve aynı sistem promptu prefiksini kullanmazsa, o alt-ajanın cache'i sıfırdan başlar. Bu kural modelden bağımsız; cache-read ekonomisinin bugünkü haline Güncelleme bölümünde bakıyorum.
Kendi projemden gözlem: bağlam disiplini olmadan ne olur
Rakam paylaşmayacağım çünkü ölçülmüş, doğrulanabilir bir benchmark'ım yok — ama tekrarlayan bir gözlemim var: bir ajana bağlamın ilgisiz kısmını (eski bir dosyanın tamamı, alakasız bir log dökümü) verdiğimde, bir sonraki önerisi genellikle o ilgisiz kısımdan etkilenmiş, konudan sapmış bir öneri oluyor. Bağlamı kısıtlayıp yalnız ilgili dosyayı/fonksiyonu verdiğimde ise öneri daha isabetli ve daha kısa sürede geliyor. Bu benim kişisel çalışma tercihimin nedeni: CLAUDE.md'yi kısa tutmak, ajanlara büyük dosya okutmak yerine ilgili satırları alıntılamak, alt-ajan raporlarını kısa tutmak — hepsi aynı disiplinin farklı yüzleri.
Ben genelde yeni bir görev öncesi "bu ajana gerçekten hangi dosyayı, hangi kuralı vermem lazım" sorusunu, "bu ajana ne kadar bağlam verebilirim" sorusundan önce soruyorum. Sıra önemli: önce kapsam daraltılır, sonra bütçe hesaplanır.
Güncelleme (Eylül 2026)
Bu makalenin gövdesi 9 Aralık 2025 tarihindeki araç ve sürümlere göre yazıldı. Aradan geçen sürede context engineering pratiği birkaç somut noktada ilerledi:
Skills, kurumsal standarda dönüştü. 16 Ekim 2025'te duyurulan Claude Skills, 18 Aralık 2025 güncellemesiyle kurum-çapında yönetim ve bir skill dizini kazandı. Pratik etkisi: "prompt yazmak" yerine "yalnız gerektiğinde yüklenen, yeniden kullanılabilir bağlam paketleri" kurmak artık kurumsal bir disiplin haline geldi. (kaynak: claude.com/blog/skills)
"Context anxiety" belgelendi ve modelle birlikte eskidi. Anthropic, Claude Sonnet 4.5'in bağlam limiti yaklaştığını "hissedince" görevi erken bitirme eğilimi gösterdiğini (context anxiety) dokümante etti ve harness'a context reset ekledi (24 Mart 2026). Ama aynı fix'i daha güçlü bir modelde (Opus 4.5) test ettiklerinde davranış zaten kaybolmuştu — context reset'ler gereksiz "ölü ağırlığa" dönüştü (8 Nisan 2026). Ders: context engineering statik bir reçete değil, model yükseltmesiyle yeniden değerlendirilmesi gereken bir katman. (kaynak: anthropic.com/engineering/harness-design-long-running-apps, anthropic.com/engineering/managed-agents)
Session, harness ve sandbox ayrıştırıldı. Anthropic'in 8 Nisan 2026'da duyurduğu Managed Agents, konuşma günlüğünü (session), karar döngüsünü (harness) ve yürütme ortamını (sandbox) ayrı, değiştirilebilir soyutlamalar haline getirdi — amaç, harness implementasyonu değişse bile bağlam yönetimi sözleşmesinin kalıcı kalması.
Bir ayar eklendi, biri etkisini yitirdi. Claude Code changelog'una göre v2.1.261'de bashOutputMaxChars ve taskOutputMaxChars ayarları eklendi; amaçları komut ve arka plan görev çıktısının dosyaya yazılmadan önce satır içinde ne kadarının modele verileceğini yükseltmek (satır-içi eşik ≤128K karakter). v2.1.277'de ise TaskOutput aracı kaldırıldı; changelog'un ifadesiyle taskOutputMaxChars ayarı ve TASK_MAX_OUTPUT_LENGTH artık "no longer have any effect" — bugün geçerli olan yalnız bashOutputMaxChars.
json
1{2 "bashOutputMaxChars": 40003}Format seçimi ölçülebilir bir maliyet doğurdu. Akademik bir çalışma (arXiv 2602.05447, 9 Şubat 2026'da Simon Willison tarafından özetlendi), 11 model × 4 format (YAML, Markdown, JSON, TOON) üzerinde 9.649 deney yürüttü: TOON formatı dosya boyutunda küçük olmasına rağmen, modellerin formata aşina olmaması yüzünden büyük şemalarda (10.000 tablo) YAML'a kıyasla token tüketimi belirgin biçimde arttı — araştırmacılar buna "grep tax" adını verdi. Ders: "daha küçük dosya" her zaman "daha az token maliyeti" anlamına gelmiyor; format seçimi de bağlam bütçesinin bir parçası.
Cache-read ekonomisi yeni modellerde daha da ucuzladı. Fiyatlandırma sayfasına göre cache-read'in standart çarpanı temel girdi fiyatının 0,1 katı ("All other models use the standard 0.1x multiplier"); yeni varsayılan modellerde bunun da altına iniyor: Claude Opus 5.5'te bir cache isabeti standart girdi fiyatının %5'i ($0,20/MTok), Claude Fable 5.1 ve Claude Mythos 5.1'de %2,5'i ($0,25/MTok). Yani "sabit prefiksi koru" kuralının yalnız hız değil, doğrudan maliyet üzerinde de ölçülebilir etkisi var. (kaynak: platform.claude.com/docs/en/about-claude/pricing)
ALTIN İPUCU
Bu yazının en değerli bilgisi
Bu ipucu, yazının en önemli çıkarımını içeriyor.
Easter Egg
Gizli bir bilgi buldun!
Bu bölümde gizli bir bilgi var. Keşfetmek ister misin?
Okuyucu Ödülü
Bu makaleyi context engineering pratiğine dönüştürmek için kullanabileceğin bir kontrol listesi hazırladım. Her maddeyi bir sonraki ajan görevine başlamadan önce gözden geçir.
SSS
Context engineering nedir, prompt engineering'den farkı ne?
Prompt engineering, tek bir mesajın ifadesini optimize etmekle ilgilidir ve en verimli olduğu yer tek turlu etkileşimdir. Context engineering ise çok adımlı, ajan tabanlı görevlerde her turda modele hangi bilginin (talimat, araç, örnek, geçmiş) hangi biçimde ve ne kadar bağlam harcayarak verileceğine karar veren daha geniş bir disiplin. Anthropic bunu prompt engineering'in "doğal devamı" olarak tanımlıyor — biri diğerinin yerine geçmiyor.
AI kodlama ajanına doğru context nasıl verilir?
Her şeyi baştan yüklemek yerine just-in-time retrieval kullan: ajan ihtiyaç duyduğunda dosya sistemini glob/grep ile gezsin. Sistem promptunu "doğru irtifada" tut — ne aşırı katı ne aşırı belirsiz. Araç setini dar ve net tanımlı tut, bulanık/örtüşen araçlardan kaçın. Verbose işi (log okuma, geniş keşif) alt-ajanlara devret ve ana bağlama yalnız özet dönsün.
CLAUDE.md dosyası nasıl yazılmalı?
Kısa ve yoğun tut: proje özeti, çalışma kuralı, kritik yollar birkaç satırda. CLAUDE.md dosyaları baştan bağlama yüklenir, bu yüzden içine uzun anlatı veya nadiren kullanılan detay koyma — bunlar ajan gerektiğinde glob/grep ile bulacağı ayrı dosyalarda dursun. Kalıcı proje kararları ve çözülmemiş sorunlar için ayrı bir ilerleme/not dosyası (structured note-taking) kullan.
Prompt engineering öldü mü?
Hayır. Tek turlu, basit görevlerde hâlâ en verimli yaklaşım. Ölmeyen şey prompt yazma becerisi; değişen şey, çok adımlı ajan görevlerinde bunun tek başına yetmemesi ve üstüne bir bağlam yönetimi katmanı (araç tasarımı, hafıza stratejisi, bağlam bütçesi) eklenmesi gerekliliği.
Bağlam penceresi büyüdükçe context engineering'e ihtiyaç azalır mı?
Hayır, tam tersi gösterilmiş durumda: daha büyük bağlam penceresinde bile modelin dikkat kapasitesi n² ilişki büyümesi yüzünden gerilmeye devam ediyor (context rot). Daha büyük pencere, daha az disiplin gerektirmiyor — hangi bilgiyi tutup hangisini attığına hâlâ karar vermen gerekiyor.
Sonuç
Context engineering, prompt engineering'i geçersiz kılmıyor; onu bir bağlam bütçesi yönetimi disipliniyle tamamlıyor: talimatı doğru irtifada tutmak, araç setini dar tutmak, örnekleri kanonik seçmek, hafızayı kalıcı bir katmana taşımak ve verbose işi alt-ajanlara devretmek. Bu pratiği prompt tarafındaki temellerle birleştirmek istiyorsan prompt engineering desenleri üzerine 10 yıllık arşiv yazısına bak — bu yazı onun doğal devamı sayılabilir. Büyük bağlam penceresinin context rot'u ortadan kaldırmadığını daha somut örneklerle görmek için Claude'un 1M context window'uyla codebase analizi yazısı iyi bir tamamlayıcı. Ajan mimarisinde hangi aracı (skill, subagent, hook, MCP) ne zaman kullanacağına karar vermekte zorlanıyorsan Claude Code'da skill, subagent, hook ve MCP seçimi yazısı bu makaledeki alt-ajan devri fikrini pratik bir karar ağacına döküyor. Kalıcı hafıza ve proje bağlamı yönetimini derinleştirmek için Claude Projects'te memory ve bağlam yönetimi, prompt cache disiplinini maliyet tarafından okumak için ise prompt caching ile maliyeti 10 kata düşürme yazılarına bakabilirsin.
Kaynaklar
- Effective context engineering for AI agents — Anthropic'in birincil mühendislik makalesi; talimat/araç/örnek/hafıza bileşenleri, context rot, compaction ve alt-ajan mimarisi buradan.
- MIT report: 95% of generative AI pilots at companies are failing — MIT NANDA'nın _The GenAI Divide_ raporunun %95 bulgusu ve "learning gap" kök nedeni.
- Claude Developer Platform fiyatlandırması — güncel cache-read fiyatlandırma tablosu (Güncelleme bölümü için).
- Claude Code CHANGELOG — bashOutputMaxChars/taskOutputMaxChars ve prompt-cache kararlılığı ile ilgili sürüm notları.
- Harness design for long-running application development — "context anxiety" davranışının belgelendiği makale.
- Managed Agents — session/harness/sandbox ayrıştırması ve context-anxiety fix'inin Opus 4.5'te gereksizleşmesi.
- Structured context engineering for file-native agentic systems (özet) — TOON/YAML "grep tax" bulgusunun Simon Willison özeti (orijinal: arXiv 2602.05447).
