Claude Code'un Hafızasını Kendi Sistemimle Test Ettim: Aynı İşi Yapmıyorlar

Yapay zeka destekli kodlama araçlarının hafıza (memory) yetenekleri geliştikçe, bu mekanizmaların nasıl çalıştığını ve nerede tıkandığını anlamak modern yazılım geliştiriciler için kritik bir mühendislik yetkinliği haline geldi. Kendi inşa ettiğim hafıza mimarisini Claude Code'un yerleşik hafızasıyla karşılaştırdığımda, iki sistemin birbiriyle rekabet etmekten ziyade tamamen farklı ihtiyaçlara yanıt verdiğini gördüm.

İddia Yerine Kanıt: Test Metodolojisi

Aylarca emek verip inşa ettiğim bir özelliğin büyük bir platform tarafından yayınlandığını görmek ilk başta sarsıcıydı. Ancak duygularla hareket etmek yerine sistemi doğrudan test masasına yatırdım. Elde edilen bulgular tek bir geliştiricinin dört sunucusu, özel soru seti ve özgün kod havuzuna dayansa da sunduğu metodoloji genellenebilir bir çerçeve sağlar:

Ölçülebilir Çerçeve: İddialar yerine tekrarlanabilir deneylerle hafızanın kalıcılığını test etmek gerekir.
Kişisel Veri Havuzu: Farklı ortamlarda ve altyapılarda tutarlı davranış analizi yapmak gerçek sınırları gösterir.

Aynı Test, İki Farklı Yanıt

Test kurgusu son derece netti: Modele sadece yerel projenizde geçerli olan bir bilgiyi öğretin, tüm ortamı kapatıp temiz bir oturumla geri dönün ve bilginin hatırlanma sıklığını ölçün.

Yerleşik Hafızanın Başarısı: İlk aşamada her iki sistem de testi geçti; Claude Code'un yerleşik hafızası vaat ettiği oturum devamlılığını sağladı.
Sınırlar Değiştiğinde Ortaya Çıkan Fark: Aynı bilgi farklı bir editörden, farklı bir makineden ve nihayetinde bir ekip arkadaşı tarafından sorgulandığında yerleşik hafıza bilgiyi getiremedi. Bu bir kalite eksikliği değil, sistemlerin sınır (boundary) tanımlarının farklılığından kaynaklanıyordu.

Oturum Hafızası ve Proje Hafızası Farklı Ürünlerdir

Yazılım mimarisi ve ekip çalışması açısından bu iki hafıza türü iki ayrı sorunun cevabıdır:

Oturum Hafızası (Session Memory): Sağlayıcının kendi çalışma kabuğuna (harness) bağlıdır. Tekil bir asistanın kendi geçmişiyle olan tutarlılığını sağlar ("Az önce ne söyledim?").
Proje Hafızası (Project Memory): Doğrudan kod deposuna (repository) bağlıdır. Bilgiyi editörlerden, makinelerden, kişilerden ve model güncellemelerinden bağımsız olarak sürekli kılar ("Bu proje ne biliyor?").
Takım Dinamiği Çıkarımı: Ekip arkadaşlarından biri projeden ayrıldığında oturum hafızası onunla birlikte gider. Proje hafızası ise kod tabanına ait olduğundan projede kalır.

Benzerlik Aramasının Aşamadığı Sınır

Hafızanın nerede tutulduğunun ötesinde, içindeki bilginin nasıl geri çağrıldığı kritik bir sınırdır. Yazılım geliştirirken karşılaşılan bir hata ile haftalar sonra bulunan çözümünü düşünelim:

Hata Belirtisi (Symptom): deploy hangs at "Build image", worker log says nothing
Kök Neden ve Çözüm (Cause): the runner disk was full; docker prune and restart the service

Bu iki kayıt neredeyse hiçbir ortak kelime barındırmaz; biri derleme adımıyla, diğeri disk doluluğuyla ilgilidir. Dolayısıyla standart vektör embedding uzayında birbirlerinden yapısal olarak çok uzakta yer alırlar. Vektör tabanlı bir benzerlik araması (similarity search) bu iki kritik noktayı birbirine bağlayamaz; çünkü semantik yakınlık ile nedensel bağ (causal connection) tamamen farklı ilişkilerdir. Üretim ortamındaki ajan sistemlerinde salt vektör benzerliği yerine nedensel bilgi patikaları kurgulanmalıdır.

Orijinal kaynağa buradan ulaşabilirsiniz.

Bu konuyu derinlemesine öğrenmek isterseniz: Production'da Agent Güvenilirliği modülüne göz atın.