Son birkaç aydır üzerinde çalıştığım projelerde bir şeyin farkına vardım: modele ne sorduğum değil, modele ne gösterdiğim sonucu belirliyor. Aynı modeli, aynı promptla, farklı context'lerle çalıştırdığımda tamamen farklı kalitede çıktılar alıyorum.
Bu konuyu araştırmaya başlayınca bir kavramla karşılaştım: Context Engineering. Andrej Karpathy'nin (Tesla AI, OpenAI'ın kurucu ekibinden) ortaya attığı bu kavram, aslında çoğumuzun bilinçsizce yaptığı ama sistematize etmediği bir şeyi tanımlıyor.
Bu yazıda hem kavramı hem de pratikte nasıl uygulandığını anlatacağım. Yazılım geliştiriciyseniz, AI ile proje yapıyorsanız veya ajan sistemleri kuruyorsanız — bu yazı sizin için.
"Context Engineering" Dediğimiz Şey Ne?
Karpathy şöyle tanımlıyor bunu: "Bir sonraki adım için context penceresini tam olarak doğru bilgiyle doldurmanın ince sanatı ve bilimi." Tanım kulağa basit geliyor ama pratikte çok katmanlı bir iş.
Şöyle düşünün. Bir LLM — GPT-4o olsun, Claude olsun, Gemini olsun — temelde süper zeki ama hafızasız bir danışman. Her konuşma sıfırdan başlıyor. Bu danışmanla verimli çalışmak istiyorsanız, her toplantının başında masaya doğru dosyaları koymanız gerekiyor. Yanlış dosyaları koyarsanız yanlış tavsiyeler alırsınız. Çok fazla dosya koyarsanız önemli olanları ıskalarsınız. Hiç dosya koymazsanız uydurmaya başlar.
Context engineering, bu "masaya ne koyacağız" sorusunu bir mühendislik disiplinine dönüştürüyor.
Bilgisayar Analojisi
Karpathy bunu anlatmak için güzel bir analoji kuruyor. Herkesin anlayabileceği bir şey:
Bu analoji neden önemli? Çünkü RAM'iniz ne kadar büyük olursa olsun — diyelim 128K token veya 200K token — o alanı akıllıca yönetmezseniz sorun çıkar. "Hepsini koy, model halleder" diye düşünmek cazip gelebilir. Ama araştırmalar gösteriyor ki context'e anlamlı ama alakasız veri eklediğinizde model performansı %45'in üzerinde düşebiliyor.
Prompt Engineering ile Ne Farkı Var?
Bu soruyu çok duyuyorum, haklı bir soru. İkisi birbirinin alternatifi değil aslında. Prompt engineering, context engineering'in bir parçası.
Prompt engineering: modele ne sorduğunuz, nasıl sorduğunuz. Tekil bir input meselesi.
Context engineering: modelin o soruyu cevaplarken gördüğü her şey. Sistem promptu, geçmiş konuşmalar, veritabanından çekilen veriler, kullanılabilir araçların listesi, kullanıcı profili...
Prompt engineering "doğru soruyu sormayı" optimize eder. Context engineering "doğru sorunun sorulacağı ortamı" inşa eder. Farkı aşağıdaki interaktif örnekte daha net görebilirsiniz:
Gördüğünüz gibi aradaki fark dramatik. İlk yaklaşımda model havadan atıyor çünkü hiçbir şey bilmiyor. İkinci yaklaşımda gerçek bilgilerle donatılmış, hangi aksiyonları alabileceğini bile biliyor.
4 Temel Hareket
Endüstri konsensüsüne göre context engineering dört ana hareketten oluşuyor. Bunları bir pipeline gibi düşünebilirsiniz — her hareket context penceresindeki bilgi kalitesini artıran bir filtre:
Bu dört hareketin hepsini kullanmanız gerekmez, ama bunların farkında olmanız gerekir. Basit bir chatbot için belki sadece "Seç" yeterli. Ama otonom bir ajan inşa ediyorsanız — mesela bir kod asistanı, bir araştırma ajanı, bir müşteri destek botu — dördünü de tasarlamanız gerekecek.
Pratikte Nasıl Görünüyor?
Örnek 1: Kod Asistanı
Diyelim bir bug fix ajanı yapıyorsunuz. Kullanıcı "bu hata neden oluyor?" diyor. Kötü yaklaşım: tüm repo'yu context'e doldurmak. 500.000 satır kod, 2 milyon token. Ne maliyet ne de kalite açısından mantıklı.
İyi yaklaşım: sadece ilgili dosyaları, son commit'leri ve ilgili test dosyalarını çekmek. Bunu programatik yaparsanız her seferinde tutarlı sonuç alırsınız:
Burada dört hareketin üçünü görüyorsunuz. Seç (ilgili dosyalar, commitler, testler), Yaz'dan geri oku (kaydedilen notlar). Daha büyük bir sistemde sıkıştırma ve yalıtım da eklersiniz.
Örnek 2: Konuşma Geçmişi Sıkıştırma
Bir chatbot düşünün. Kullanıcıyla 50 mesaj konuştunuz. Hepsini context'e koyarsanız 20K token harcar. Ve çoğu gereksiz — "merhaba", "teşekkürler", "tamam" gibi mesajlar token harcıyor ama bilgi taşımıyor.
Bu pattern çok yaygın. Anthropic'in kendi SDK'ı bile "conversation compaction" özelliği sunuyor. Mantık basit: eski mesajların özünü koru, detayını at. Son mesajlar tam kalsın çünkü muhtemelen şu an konuşulan konuyu içeriyorlar.
Örnek 3: Çoklu Ajan Yalıtımı
Bir araştırma ajanı düşünün. Web'de arama yapıyor, dökümanları okuyor, sonuçları özetliyor. Bunu tek bir ajan olarak yapmak riskli — web scraping çıktısı onbinlerce token olabiliyor ve özetleme kalitesini düşürüyor.
Yalıtım çözümü: her aşamayı ayrı bir alt-ajan olarak tasarlayın.
Bu mimari sayesinde her ajan sadece kendi işi için gereken bilgiyi görüyor. Web scraper'ın getirdiği tonlarca HTML, analiz ajanının kafasını karıştırmıyor. Analiz ajanının ara çıktıları, yazıcı ajanı yormuyuor. Herkes kendi şeridinde.
Bu İş Nasıl Bozulur?
Context engineering'i iyi yapmak kadar, nelerin işleri bozduğunu bilmek de önemli. Üç büyük hata var ve üçü de üretimde sık karşılaştığım şeyler:
Bu üç hatanın ortak noktası: hepsi context'in kalitesiyle ilgili. Modelin zekasıyla değil. En güçlü modeli alıp zehirli context verirseniz sonuç felaket olur. Orta seviye bir modele temiz, doğru, az ve öz context verirseniz çoğu zaman mükemmel sonuç alırsınız.
Neden Şimdi Bu Kadar Önemli?
2023'te "ChatGPT'ye güzel prompt yaz" yeterliydi. 2024'te RAG çok konuşuldu. 2025'e geldiğimizde mesele tamamen değişti — artık otonom ajanlar inşa ediyoruz. Dosya okuyan, web'de gezen, API çağıran, kendi kendine karar veren sistemler.
Bu sistemlerde basit prompting yetmiyor. Her adımda modelin gördüğü bilgiyi tasarlamanız gerekiyor. Karpathy'nin kendisi bile diyor: "LLM çekirdek zekası etkileyici seviyelere ulaştı. Ama bunu uzun vadeli, çok adımlı ajanlar için yönetecek altyapı — scaffolding — olgunlaşması on yıl daha alabilir."
Yani durum şu: modeller yeterince zeki. Ama o zekayı doğru bilgiyle besleyecek sistemleri henüz tam çözemedik. Context engineering, bu boşluğu dolduran disiplin.
Nereden Başlamalı?
Eğer bu konuya yeni giriyorsanız, herkese üç adım öneriyorum:
Birincisi: bir tane basit RAG pipeline'ı kurun. LlamaIndex veya LangChain ile birkaç dökümanı vektör veritabanına yükleyip sorgulayın. Bu, "Seç" hareketini pratikte görmenizi sağlar. Pinecone, Weaviate veya PostgreSQL'in pgvector eklentisi işe yarar.
İkincisi: konuşma geçmişini sıkıştırmayı deneyin. Var olan bir chatbot'unuza, 20 mesajdan sonra eski mesajları otomatik özetleyen bir katman ekleyin. Token maliyetinin düştüğünü ve kalitezin korunduğunu göreceksiniz.
Üçüncüsü: çoklu ajan deneyin. Tek bir büyük ajan yerine, iki üç küçük ajan tasarlayıp orkestratör bir katmanla birleştirin. LangGraph veya CrewAI bu iş için güzel araçlar.
Son Söz
Context engineering denen şey sonuçta şu: modele ne göstereceğini — ve daha önemlisi ne göstermeyeceğini — tasarlamak. Prompt engineering "doğru soruyu sormak" ise, context engineering "doğru sorunun sorulacağı dünyayı inşa etmek."
Bu yazıyı kendi projelerimde yaşadığım deneyimlerden ve Karpathy, Anthropic, LangChain ekiplerinin yayınlarından derlemeye çalıştım. Umarım faydalı olmuştur. Sorularınız veya eklemek istedikleriniz varsa bana ulaşabilirsiniz.
