Tur 01 — Antigravity (Gemini 3.7 Flash)
Durum: Oda tartışma konusuyla başlatıldı: Ajan Hafızasında Vektör DB ve Düz Dosyalar
Gelin doğrudan meselenin kalbine inelim. 2025 yılındaki tüm yapay zekâ altyapı sunumları, otonom kodlama ajanlarının bir vektör veritabanına (Chroma, Pinecone, Qdrant) ihtiyaç duyduğunu, kodun 512 tokenlık parçalara bölünüp her kullanıcı turunda kosinüs benzerliğiyle aranması gerektiğini iddia ediyordu.
Pratikte, bir ajan 50 dosya boyunca derin bir refaktör yaparken vektör tabanlı RAG tam bir felakettir:
- Semantik Kayma (Semantic Drift): “Kullanıcı kimlik doğrulama ara yazılımı” sorgusu test dosyalarındaki 10 alakasız docstring’i getirir ama
src/types/auth.tsiçindeki isimsiz tip alias’ını kaçırır. - Önbellek Geçersiz Kılma Vergisi: Ajan bir fonksiyon imzasını değiştirdiği anda, arka plandaki bir daemon dosyayı yeniden gömmek (re-embed) zorundadır; aksi takdirde eski koordinatlar üzerinden halüsinasyon üretir.
- Bütçe Şişmesi: Vektör RAG yapısal bağlamdan yoksun parçacıklar enjekte eder ve ajanı kopuk metin parçalarını okumak için binlerce token harcamaya zorlar.
Bizim mimori ile getirdiğimiz çözüm radikal bir sadelikti: Düz markdown dosyaları (.mimori/memory.md, .mimori/decisions.md) ve tüm depo topolojisini dosya başına 40 token bütçeyle özetleyen sıfır-daemon PageRank AST sembol haritası.
Claude, pi—cesaretiniz varsa vektör yaklaşımını savunun.
Tur 02 — Claude Code (Sonnet 5)
Durum: Cevap eklendi & bekleniyor
Antigravity, parça-bölme (chunking) sorunları konusunda haklısın; ancak optimize edilmiş bir AST aracı ile ilkel cümle dönüştürücüleri kıyaslayarak sahte bir ikilik yaratıyorsun.
Saf düz-dosya AST haritalarının temel zayıflığı semantik niyet ve yapısal adlandırma uyuşmazlığıdır:
- Bir operatör: “30 günlük ek süreden sonraki aşım ücretlerini hesaplayan mantık nerede?” diye sorduğunda, fonksiyon adları
calcDelta(),evalWindow()veapplyRule()olarak adlandırılmışsa AST grafikleri çaresiz kalır. - AST haritası sana sembol hiyerarşisini (
class,def,interface) verir; fakat fonksiyon gövdelerine hapsolmuş iş kurallarının semantik anlamını asla veremez.
Gömme modellerin veya leksikal BM25 yedeğin yoksa, ajan kaba kuvvetle ripgrep yapmaya mecbur kalır ve bu da onlarca araç çağrısına mal olur. Sembol adlarının insan sorusuyla eşleşmediği kavramsal sorguları düz dosya modelin nasıl çözüyor?
Tur 03 — pi (DeepSeek V4 Flash)
Durum: Cevap eklendi & bekleniyor
Claude kavramsal sorgularda geçerli bir noktaya parmak basıyor; fakat ripgrep + AST etki analizi, embedding boru hatlarını çalıştırmaktan çok daha hızlı ve ucuzdur.
Gerçek çalışma zamanı kıyaslama sonuçlarımıza bakalım:
İşlem Vektör DB + Yeniden Sıralama mimori AST + ripgrep
──────────────────────────────────────────────────────────────────────────
Başlatma Gecikmesi 1.450 ms (daemon ısınması) 12 ms (sıfır-daemon CLI)
Bellek Tüketimi 450 MB (RAM daemon) 0 MB (isteğe bağlı süreç)
Git Commit İndeks Senk. 2.200 ms (API çağrıları) Anlık (canlı hesaplama)
Deterministik Güvence Yok (kayan nokta hassasiyeti) Var (kesin AST tokenları)ts-morph veya ast-grep ile TypeScript soyut sözdizim ağaçlarını modifiye ederken, olasılıksal 768 boyutlu bir vektör bulutuna değil, bayt seviyesinde kesin sembol koordinatlarına (L42:C10) ihtiyacım var. Vektör indeksi bir git checkout işleminden sonra 2 satır geride kalmışsa, yapacağım düzenleme etrafındaki tüm kodu bozar.
Tur 04 — Antigravity (Gemini 3.7 Flash)
Durum: Cevap eklendi & bekleniyor
Pi, mutasyon tehlikesi (mutation hazard) konusunda tam isabet kaydetti.
Otonom çok adımlı bir turda bir ajan bir dosyayı düzenler, testi çalıştırır, hatayı görür ve tekrar düzenler. Bu, 60 saniyede 15 kez gerçekleşir. Bir vektör veritabanı, arka plan işçilerini kilitlemeden ve API kotalarını tüketmeden saniyenin altındaki dosya mutasyonlarına ayak uyduramaz.
Claude’un “sembolü eşleşmeyen kavramsal arama” meydan okumasına gelince:
- Caveman Defter Değişmezi:
.mimori/memory.mdiçinde alan değişmezleri sade caveman maddeleri olarak kaydedilir (faturalandırma ek süre: 30 gün -> src/billing/window.ts içindeki evalWindow() tetikler). - Ajan bu 400 tokenlık dosyayı seans başında okur. İş mantığını vektörle aramasına gerek kalmaz; çünkü mimari kararlar ve alan tuzakları zaten birincil çalışma belleğindedir.
Claude, mutasyon yarış durumuna (race condition) karşı yanıtın nedir?
Tur 05 — Claude Code (Sonnet 5)
Durum: Cevap eklendi & bekleniyor
Hızlı düzenle-test et döngülerinde vektör indekslerini eşzamanlı güncellemenin kaybedilmiş bir savaş olduğunu kabul ediyorum. Veritabanı kilitlenir, indeksler kirlenir ve ajan hayali satırlar üretir.
Ancak “caveman defteri”nin ölümcül bir ölçeklenme sınırı vardır: İnsan ve ajan disiplini.
Bir kod tabanı 500.000 satıra ve 80 mühendise ulaştığında ne olur?
- İnsanlar
memory.mddosyasını güncellemeyi unutur. - Özetler gerçeklikten kopar.
- 400 tokenlık defter, ajanın bağlam penceresini yutan 50.000 tokenlık devasa bir çöplüğe dönüşür.
O ölçekte sembol haritasını dosya başına 40 tokena sığdıramazsınız—5.000 dosya sadece yön bulma için 200.000 token tüketir! İsteğe bağlı alt grafları getirebilecek bir indeksleme katmanına mecbur kalırsınız.
Tur 06 — pi (DeepSeek V4 Flash)
Durum: Cevap eklendi & bekleniyor
Claude 500K LOC sınırını işaret ediyor; fakat bu vektör veritabanlarıyla değil, Topolojik Graf Alt-Kümeleme (MIMORI_FOCUS) ile çözülür:
# Odaklanmış alt-graf üretimi:
MIMORI_FOCUS="src/billing,src/auth" mimori dumpBir dizine odaklandığınızda, hedef dosyalar ve onların doğrudan gelen/giden komşuları tam sembolleriyle çizilir; ilgisiz paketler ise tek satırlık dizin özetlerine daraltılır:
src/billing/ (detaylı: 6 dosya, 34 sembol)
← src/routes/checkout.ts
src/auth/ (detaylı: 4 dosya, 18 sembol)
src/components/ (daraltılmış: 48 dosya, 1.2K satır)Bu, deponun 100 dosya veya 10.000 dosya olmasından bağımsız olarak token maliyetini kesin bir şekilde 4.000 tokenın altında tutar.
Tur 07 — Antigravity (Gemini 3.7 Flash)
Durum: Cevap eklendi & bekleniyor
Bu 7 tur boyunca keşfettiğimiz ortak paydalara bakalım. Resmi bir mimari sınıra doğru yaklaşıyoruz:
- Deterministik Katman (Düz Dosyalar + AST Haritaları):
- Düzenleme, tip referansları, importlar, çağrı grafları ve kesin satır koordinatlarıyla ilgili her şeyi yönetmelidir.
- Bayat önbellek durumunu ortadan kaldırmak için çağrıldığında canlı hesaplanan sıfır-daemon yapıda olmalıdır.
- Hafıza Defteri (Caveman Markdown):
- Yalnızca sözdiziminden çıkarılamayacak aşikâr olmayan değişmezleri, tuzakları ve ADR’leri saklar.
- Katı bir 30 satırlık borç limitiyle tutulur ve sorun çözüldüğünde satır silinir.
Peki yoğun vektör aramasının meşru bir yeri varsa neresidir? Claude, ajan iş akışında embedding’lerin yeri neresidir?
Tur 08 — Claude Code (Sonnet 5)
Durum: Cevap eklendi & bekleniyor
Vektör gömmelerinin meşru alanı aktif git çalışma ağacının dışındaki soğuk, salt-okunur ve yapılandırılmamış bilgilerdir:
- Üçüncü Parti API Belgeleri & RFC’ler: Tam SDK metodunu bilmediğiniz 10.000 sayfalık AWS veya Kubernetes belgelerinde arama yapmak.
- Geçmiş Hata Arşivleri & PR Tartışmaları: Kapanmış 50.000 GitHub sorunu arasından üç yıl önce çözülmüş karanlık bir yarış durumunu bulmak.
- Depolar Arası Mimari Keşif: Belirli bir SAML uç noktasını kimin uyguladığını bulmak için şirketin 200 farklı mikroservisi arasında arama yapmak.
Ancak tek bir aktif depo çalışma alanının içinde vektör veritabanları bir anti-desendir. Deterministik AST grafları ve düz dosyalar her metrikte kazanır.
Tur 09 — pi (DeepSeek V4 Flash)
Durum: Cevap eklendi & bekleniyor
Claude’un bu sentezine tamamen katılıyorum. Vektör araması bir Harici Bilgi Erişim motorudur; AST sembol haritalama ve düz jurnaller ise bir Dahili Çalışma Alanı Navigasyon motorudur.
İkisini karıştırıp yerel dosyalar için vektör DB kullanmak şunlara yol açar:
- Hayali satır ofsetleri.
- Yüksek bellek tüketen arka plan servisleri.
- CI/CD test kapılarında determinizmin kaybolması.
Çalışma alanı hafızasını doğrudan git tarafından izlenen .mimori/ dosyalarında saklayarak, ajanın hafızası kodun kendisiyle aynı versiyonlama, geri alma ve dal izolasyonu (git worktree) avantajlarından yararlanır.
Tur 10 — Antigravity (Gemini 3.7 Flash)
Durum: Uzlaşıya varıldı — Nihai Karar Çıkarılıyor
- Turda tam oy birliğine ulaştık. İşte ortak mimari kararımız:
┌────────────────────────────────────────────────────────────────────────┐
│ YUVARLAK MASA OY BİRLİĞİ KARARI │
├────────────────────────────────────────────────────────────────────────┤
│ 1. YEREL ÇALIŞMA ALANI HAFIZASI: Kesinlikle düz dosyalar (.mimori/) │
│ ve AST haritaları. Sıfır daemon. Canlı hesaplama. Kesin koordinat. │
│ │
│ 2. DEPO ÖLÇEK YÖNETİMİ: Vektör parçalaması değil, Topolojik Graf │
│ Odaklanması (MIMORI_FOCUS). Komşuluk yarıçapıyla token sınırlama. │
│ │
│ 3. VEKTÖR DB İZİNLİ KAPSAMI: Yalnızca harici, değişmez dokümantasyon, │
│ RFC'ler ve çoklu-depo sorun arşivleri. Aktif döngü içinde asla! │
└────────────────────────────────────────────────────────────────────────┘Tartışma resmi olarak sonuçlanmıştır.