Andrej Karpathy, LLM bilgi tabanı iş akışını 3 Nisan 2026'da yayımladığında tartışmaların büyük bölümü bunu kişisel araştırma verimlilik sistemi olarak ele aldı. Bu okuma çok dar.
Altta yatan mimari — ham materyali biriktir, yapılandırılmış markdown'a derle, LLM ile sorgula ve bakımını yap — coding agent'larını oturum ölçeğinde çalıştıran herkesin zaten çarptığı bir soruna doğrudan uyuyor: context sıfırlaması.
Bu yazı Karpathy'nin pattern'ini özellikle mühendislik iş akışlarına uyguluyor. Hobi olarak bilgi yönetimi değil, çok agent'lı coding seansları için altyapı olarak bilgi yönetimi.
LLM Bilgi Tabanı Gerçekte Nedir? (RAG Sistemi Değil)
Karpathy Pattern'i: Raw → Compile → Lint → Query
Sistemin sürekli çalışan dört aşaması var. Ham kaynak materyali — Karpathy'nin durumunda makaleler, araştırmalar ve veri setleri; coding bağlamında mimari belgeler, karar günlükleri, API sözleşmeleri ve kod yorumları — raw/ dizinine geliyor. Ardından bir LLM bunu yapılandırılmış bir wiki'ye "derliyor": kavrama göre düzenlenmiş markdown dosyaları koleksiyonu, özetler, ilgili fikirler arasında geri bağlantılar ve LLM'nin sorgu zamanında gezinmesine yardımcı olan index dosyaları. Derleme adımı mimari yenilik. LLM yalnızca indekslemekle kalmıyor — sentezliyor, kategorilendiriyor ve kaynakta açıkça mevcut olmayan bağlantılar kuruyor.
Lint geçişleri periyodik çalışıyor: LLM wiki'yi eski bilgi, iç tutarsızlık, eksik bağlantı ve yeni bağlantı fırsatları için tarıyor. Karpathy bunu "wiki'yi artımlı temizleyen ve genel veri bütünlüğünü güçlendiren" sağlık kontrolleri olarak tanımlıyor. Her sorgu sonucu, her üretilen çıktı wiki'ye geri ekleniyor. Sistem birikim yapıyor, sıfırlanmıyor.
Karpathy'nin tanımladığı ölçekte — yaklaşık 100 makale ve 400.000 kelime civarında — vector veritabanı gerekmiyor. LLM'nin context penceresine yüklenen index dosyaları ve özet sayfaları, gezinme için yeterli. LLM ihtiyacı olanı embedding benzerliğiyle değil, yapı üzerinden buluyor.
RAG Neden Her Seferinde Sıfırdan Bilgiyi Yeniden Keşfediyor?
Standart RAG — Lewis ve arkadaşlarının temel 2020 makalesinde tanımlandığı üzere — belgeleri parçalara böler, bunları vector embedding'lere dönüştürür ve sorgu zamanında benzerlik araması yapar. Parçalar birbirini bilmiyor. Mart'ta alınan bir karar ile Ocak'ta belgelenen bir kısıtlama arasındaki bağlantılar, her ikisi de aynı retrieval geçişinde yüzeye çıkmıyorsa index'te mevcut değil. Her sorgu sıfırdan başlıyor.
Karpathy'nin ifadesi kesin: "LLM her soruda sıfırdan bilgiyi yeniden keşfediyor. Birikim yok." Kişisel bilgi tabanları ve küçük-orta büyüklükteki codebase'ler için bu yanlış araç. RAG, tahmin edilemez erişim pattern'larıyla milyonlarca belge üzerinde retrieval'ı ölçeklendirmek için tasarlandı — Agentic RAG araştırması bu sorunu otonom agent'ları retrieval pipeline'ına gömerek çözmeye çalıştı, ama çok daha fazla altyapı karmaşıklığı pahasına. Derlenmiş markdown wiki her ikisini de gerektirmiyor.
Ayrım coding agent'ları için önemli çünkü projenin mimarisi keyfi değil, kasıtlı olarak gelişiyor. Codebase'in hakkında bilgiyi zaman içinde biriktiren ve geliştiren bir sistem, her çağrıda ham dosyalardan yeniden türetilenlerden çok daha kullanışlı.
Coding Agent'lar İçin Gerçek Problem: Context Sıfırlamaları
Çok Agent'lı Seans Context Limitine Çarptığında Ne Oluyor?
Çok agent'lı bir coding kurulumunda — paralel worktree'ler, ayrı görevleri üstlenen izole subagent'lar — her agent verdiğin context'le başlıyor ve tamamlanana veya bir context sınırına çarpana kadar çalışıyor. Bir seans sıkıştırıldığında veya yeni bir agent başlatıldığında, o agent'ın sahip olduğu proje bilgisi yok oluyor. Geriye yalnızca diskteki dosyalar kalıyor.
Pratik sonuç: sonraki agent veya aynı agent'ın sonraki seansı codebase'i soğuk okuyor. Kodu okuyabilir, ama akıl yürütmeyi okuyamaz. Auth modülü neden JWT yerine özel bir token formatı kullanıyor? Payment servisi neden ana repo'da yaşamak yerine kendi worktree'sinde izole edilmiş? Neden design-v1.md belgesinde tanımlanan ve hâlâ orada duran mimariden vazgeçildi? Bunların hiçbiri kodda değil. Konuşmadaydı.
Derlenmiş bir wiki'yle, dosyalarda. Agent architecture/decisions/auth-token-format.md'yi okuyor, değerlendirilen takasları anlıyor ve sana yeniden açıklatmak zorunda kalmadan ilerliyor.
Agent'a Mimariyi Yeniden Açıklamak: Gizli Token Vergisi
Her yeni agent seansı için context yeniden kurduğunda, iş yerine tarihe token harcıyorsun. Birden fazla aktif alt sistemi, önemsiz olmayan bir tech stack'i ve önemli olan birkaç mimari kısıtı olan orta karmaşıklıkta bir projede, gerçek görev başlamadan önce bu yeniden kurulum geçişi 5.000–15.000 token alabilir. Günde 10 agent seansıyla çarp ve yük gerçek oluyor — hem maliyet hem gecikme açısından.
Daha derin problem ise yeniden açıklamanın kayıplı olması. Bellekten özetliyorsun, geçen hafta üzerinde çalıştığın edge case'i atlıyorsun, agent eksik bağlamla devam ediyor ve nüanslı biçimde yanlış bir şey üretiyor. Düzeltiyorsun. Bu düzeltme kalıcı olmalı. Çoğu agent iş akışında değil.
LLM Bilgi Tabanı Context Problemini Nasıl Çözüyor?
Kalıcı Markdown Wiki Agent'ın Bellek Katmanı Olarak
Mekanizma basit: codebase'inin yanında yaşayan bir wiki dizini. Agent seans başında okuyor, kararlar alınırken güncelliyor ve sonraki seans kaldığı yerden devam ediyor. Embedding yok, vector index yok, ayrı altyapı yok. Plain markdown, versiyon kontrolünde, hem insanlar hem agent'lar tarafından okunabilir.
Claude Code bunu doğrudan destekliyor. Claude Code'un resmi bellek dokümantasyonuna göre, CLAUDE.md dosyaları seans başında otomatik olarak context penceresine yükleniyor. CLAUDE.md'nin kendisinde barındırılamayacak kadar ayrıntılı içerik için @path import sözdizimi harici markdown dosyalarına referans vermenizi sağlıyor — CLAUDE.md içerik tablosu gibi davranıyor, wiki sayfaları talep üzerine yükleniyor. Resmi Claude Code belgeleri CLAUDE.md'yi 200 satırın altında tutmayı ve daha büyük talimat setlerini ilgili dosya yollarına kapsamlı .claude/rules/ alt dizin dosyalarına bölmeyi öneriyor. Wiki doğal olarak bu yapıya uyuyor: etki alanına özgü bilgi, yalnızca agent codebase'in ilgili bölümünde çalışırken yükleniyor.
Codebase'e Uygulanmış Ingest → Compile → Query Döngüsü
Mühendislik bağlamına uyarlandığında döngü şöyle görünüyor:
Ingest: Yeni mimari kararlar, API sözleşmesi değişiklikleri, bağımlılık güncellemeleri, post-mortem'ler ve tasarım tartışmaları raw/'a gidiyor. Commit mesajlarındaki yorumları, PR açıklamalarını veya hafif bir günlük günlüğünü kullanabilirsin. Ham katman kasıtlı olarak yapılandırılmamış — tek gereksinimi var olması ve tarihlenebilir olması.
Compile: Agent yeni ham girdileri okuyup wiki'yi güncelliyor. Veri servisinde REST'ten gRPC'ye migration kararı, etkilenen servislere geri bağlantılar ve değişikliği motive eden gecikme benchmark'larına çapraz referansla architecture/protocols/grpc-migration.md güncellemesi haline geliyor. Agent yazıyor, sen inceliyorsun.
Query: Seans başında, agent CLAUDE.md import'ları aracılığıyla ilgili wiki bölümlerini yüklüyor. Auth sisteminin neden o şekilde çalıştığını anlaması gerektiğinde sana sormak yerine wiki'yi okuyor. Çıktılar — refactoring önerileri, tasarım alternatifleri, debug hipotezleri — yeni ham girdiler veya doğrudan wiki güncellemeleri olarak dosyalanıyor.
Lint: Periyodik olarak bir bakım geçişi çalıştır. Agent'dan artık mevcut olmayan kod yollarına referans veren wiki sayfalarını taramasını, gerekçesi eskimiş kararları işaretlemesini ve yeni ham materyalin henüz derlenmediği boşlukları tespit etmesini iste.
Bu Yaklaşımın RAG'ı Geçtiği ve Geçemediği Yerler
Bu pattern RAG'dan daha iyi çalışıyor: bilgi corpus'un sınırlı olduğunda (yüzlerce belge, yüz binlerce değil), içerik kasıtlı olarak gelişiyorsa ve birikimli anlayıştan yararlanıyorsa, ve birden fazla oturumdaki agent'ların proje üzerine tutarlı bir görüş paylaşmasına ihtiyaç duyuyorsan.
RAG'dan daha kötü çalışıyor: corpus gerçekten büyük olduğunda (milyonlarca token, heterojen erişim pattern'larıyla binlerce belge), retrieval gereksinimleri tahmin edilemez olduğunda, veya embedding tabanlı aramanın gecikme maliyeti ölçek karşılığında kabul edilebilir olduğunda. Birden fazla büyük repo ve yüzlerce servisi olan büyük mühendislik organizasyonları için muhtemelen her ikisi de gerekiyor — geniş retrieval için RAG katmanı, projeye özgü bağlam için derlenmiş wiki.
Eski içerik problemi her iki durumda da gerçek. Güncel tutulmayan bir wiki, wiki'nin olmamasından daha kötü — agent'a güvenle yanlış bilgi veriyor. Lint geçişleri yardımcı oluyor, ama önemli mimari değişiklikler için insan incelemesinin yerini tutmuyor.
Coding Projesi İçin Pratik Kurulum
Dizin Yapısı: raw/, wiki/, Index
Minimal kurulum:
proje-kökü/
├── CLAUDE.md # Wiki index'ini yükler; 200 satırın altında kalır
├── .claude/
│ └── rules/
│ ├── backend.md # src/api/**'ye kapsamlı
│ └── frontend.md # src/ui/**'ye kapsamlı
└── wiki/
├── INDEX.md # Üst seviye wiki navigasyonu
├── architecture/
│ ├── overview.md
│ ├── decisions/ # ADR'ler — karar başına bir dosya
│ └── protocols/
├── domains/ # İş alanı sözlüğü
├── ops/ # Deployment, ortam, bağımlılıklar
└── raw/ # Derlenmemiş kaynak materyalCLAUDE.md, @wiki/INDEX.md içeriyor ve proje düzeyinde kurallar barındırıyor. Index dosyası alt sistemleri wiki bölümlerine eşliyor. Agent yapıyı bir insan mühendis gibi aynı şekilde geziyor.
Hangi Araçlar Uyuyor: Obsidian, Claude Code, Yerel Script'ler
Obsidian, insan odaklı frontend olarak iyi çalışıyor: grafik görünümü bağlantı yoğunluğunu gösterip yetim sayfaları ortaya çıkarıyor, web kırpıcı harici referansları doğrudan markdown olarak alıyor ve wiki'yi sunucu bağımlılığı olmadan yerel render ediyor. Karpathy bunu bu şekilde kullanıyor — yazma katmanı değil, okuma/gezinme katmanı olarak. Yazmayı agent yapıyor.
Claude Code derleme ve bakım motoru. raw/'a "raw/'daki yeni girdileri wiki'ye derle, etkilenen index sayfalarını güncelle ve uygun yerlerde geri bağlantılar oluştur" gibi bir prompt'la yönlendiriyorsun. Verdent'in paralel agent kurulumunda, diğer agent'lar izole worktree'lerde coding çalışmasına devam ederken wiki bakımını ayrı bir worktree'de arka plan görevi olarak çalıştırabilirsin.
Yerel script'ler ingest tarafını otomatikleştirebilir: önemli PR açıklamalarını raw/'a ekleyen bir git hook'u, arch-decision etiketli yeni issue'ları raw/'a çeken bir cron, veya terminalden hızlı bir not kaydetmene izin veren basit bir CLI. Ingest sürtünmesi ne kadar az olursa wiki o kadar tutarlı besleniyor.
Wiki'ye Ne Koyulur, Codebase'de Ne Bırakılır
Wiki, koda ait olmayan akıl yürütme için. Kod sistemin ne yaptığını belgeliyor. Wiki neden o şekilde yaptığını, hangi alternatiflerin değerlendirildiğini ve kararı şekillendiren kısıtlamaları belgeliyor.
Wiki için: Mimari kararlar ve gerekçeleri. Alan terminolojisi ve varlık ilişkileri. Dış bağımlılık notları (neden bu kütüphane, bilinen limitleri neler, ne zaman yeniden gözden geçirilmeli). Geliştirme kararlarını etkileyen ortam ve deployment kısıtlamaları. Bilinen zor problemler için tekrar eden debug pattern'ları.
Codebase için: API sözleşmeleri, tip tanımları, açık olmayan mantığı açıklayan satır içi yorumlar, test case'leri, yapılandırma. Yeni bir mühendisin kodun kendisinden öğrenmesi gereken her şey.
Wiki'ye gerçekte bir docstring veya satır içi yorum olması gereken açıklayıcı bağlam eklediğini fark edersen, kod daha iyi dokümantasyon gerektiriyor, daha iyi wiki değil.
Kurmadan Önce Bilmen Gereken Limitler ve Takaslar
Bakım Maliyeti: Wiki'yi Kim Lint'ler?
Güncel tutulmayan bir wiki aktif olarak yanıltıyor. Lint geçişi yardımcı oluyor — agent iç tutarsızlıkları, ölü bağlantıları ve deprecated kod yollarına referansları tespit edebilir — ama altı ay önce doğru olan bir mimari varsayımın artık yanlış olduğunu, çünkü dış kısıtlamanın değiştiğini bilemez. Bu insan yargısı gerektiriyor.
Pratikte bu, ekipten birinin wiki'ye kimin mimariye sahip çıktığı gibi sahip çıkması anlamına geliyor. Tam zamanlı iş değil, ama tekrar eden bir sorumluluk: derlenmiş girdileri incelemek, önemli değişikliklerden sonra lint geçişleri çalıştırmak ve zaman zaman mevcut gerçeklikten çok fazla sapan bölümleri yeniden yazmak. Kimse sahip çıkmazsa değer biriktirmekten daha hızlı bozuluyor.
Ölçek Tavanı: Tatlı Nokta Milyonlarca Değil, Yüzlerce Belge
Karpathy kurulumunu yaklaşık 100 makale ve 400.000 kelime civarında tanımlıyor — VentureBeat'in haberi, bu ölçekte LLM'nin özetler ve index dosyaları aracılığıyla gezinme yeteneğinin vector veritabanı altyapısı olmadan "fazlasıyla yeterli" olduğunu not ediyor. Bu ölçekte index dosyaları ve LLM context pencereleri embedding altyapısı olmadan gezinmek için yeterli.
Bunun ötesinde — birden fazla büyük repo, yıllarca karar geçmişi, ekipler arası bilgi — context penceresi yaklaşımı gerilmeye başlıyor. Özetler ve index'ler aracılığıyla gezinme, index'in kendisi zahmetli hale gelene kadar çalışıyor. Bu pattern'in başarısızlığı değil, kapsam sınırı. Daha büyük codebase'ler için en güncel ve en sık erişilen bağlamı üstlenen derlenmiş wiki, daha geniş retrieval için bir RAG katmanıyla birleşerek daha gerçekçi mimari.
Bu ölçek tavanı topluluk gözlemi, resmi olarak yayımlanmış bir benchmark değil. Projenin bilgi yoğunluğu, wiki bölümlerine ne sıklıkla erişildiği ve index'i ne kadar agresif bakımda tuttuğun, pratikte tavanın nerede oturduğunu etkiliyor.
Uygun Codebase Dokümantasyonunun Yerini Tutmuyor
Wiki dokümantasyonun yerini almıyor, yanında çalışıyor. İyi yapılandırılmış bir README, kapsamlı API dokümanları ve açık satır içi yorumlar, agent'ın codebase'i anlamak için daha az wiki'ye ihtiyaç duyması anlamına geliyor. Kodun ifade edemediğini kapsayan bir wiki ise agent'ların ve mühendislerin arkeoloji için daha az token harcaması demek.
Wiki'yi kod dokümantasyonunun yerine kullanmaya çalışmak, tek yerine iki hareketli parçalı bir bakım problemi yaratıyor. Sorumluluk ayrımını net tut: kod ne için, wiki neden için.
Sık Sorulan Sorular
LLM Bilgi Tabanı ile RAG Arasındaki Fark Ne?
RAG, embedding benzerliği kullanarak sorgu zamanında bir belge koleksiyonundan ilgili parçaları retrieval ediyor — her sorgu temiz başlıyor, bilgi birikmez. Bir LLM bilgi tabanı, LLM'nin ham kaynakları aktif olarak yapılandırılmış, birbiriyle bağlantılı markdown'a derlediğini, zaman içinde kademeli olarak anlayış inşa ettiğini içeriyor. Derlenmiş wiki sentezlenmiş bilgiyi yansıtıyor; RAG indexlenmiş belgeleri yansıtıyor. Bağlamın kendi üzerine inşa edildiği sınırlı corpus'larda, derlenmiş wiki yaklaşımı daha tutarlı agent davranışı üretiyor. Herhangi bir belgenin herhangi bir sorguyla alakalı olabileceği büyük, heterojen belge setleri için RAG daha uygun.
Bu Claude Code veya Diğer AI Coding Agent'larıyla Çalışıyor mu?
Evet, doğrudan. Claude Code'un CLAUDE.md sistemi seans başında markdown dosyaları yüklüyor ve @path import sözdizimi CLAUDE.md'nin wiki sayfalarına tam içeriklerini ana dosyaya gömmeden referans vermesine izin veriyor. .claude/rules/ dizini yalnızca agent codebase'in eşleşen bölümlerinde çalışırken yüklenen yol kapsamlı kuralları destekliyor — alt sisteme özgü wiki sayfaları için doğal uyum. İzole git worktree'lerinde çalışan Verdent agent'ları, yazma erişimi özel bir derleme agent'ı aracılığıyla koordine edilmişse, çakışan yazmalar olmadan proje bağlamının tutarlı görünümünü paylaşabiliyor.
Bir Proje Bu Kurulumu Hak Etmek İçin Ne Kadar Büyük Olmalı?
Başabaş noktası kabaca şu: seans başında proje bağlamını yeniden açıklamak wiki'yi bakımda tutmaktan daha uzun sürdüğünde. Tek odaklı projede solo geliştirici için iyi yapılandırılmış bir CLAUDE.md yeterli olabilir. Birden fazla alt sistemli, birkaç aktif agent'lı ve birkaç haftayı geçen önemsiz mimari kararları olan bir proje için, context yeniden kurulumunun birikimli maliyeti wiki'yi değerli kılıyor. Kurulum yükü düşük — dizinler ve markdown dosyaları oluşturuyorsun, altyapı deploy etmiyorsun. Küçük başla: bir mimari kararlar dizini, bir alan sözlüğü ve onlara işaret eden CLAUDE.md.
Birden Fazla Agent Aynı Bilgi Tabanını Paylaşabilir mi?
Evet, koordinasyonla. Wiki diskteki dosyalar — dosya sistemi erişimi olan herhangi bir agent okuyabilir. Yazma erişimi dikkat gerektiriyor: birden fazla agent'tan eşzamanlı derleme geçişleri çakışan düzenlemeler üretebilir. Pratik yaklaşım, wiki'ye yazma erişimi olan atanmış bir derleme agent'ı; görev agent'larının yalnızca okuma erişimi olması (veya yalnızca raw/'a yazma erişimi, derlemeyi ayrı adım olarak bırakarak). Git worktree kurulumlarında wiki kendi worktree'sinde yaşayabilir, görev agent'larının süregelen derlemeye müdahale etmeden temiz okumalar çekmesini sağlıyor.
Kod Değiştiğinde Ama Wiki Güncellenmediğinde Ne Oluyor?
Agent güvenle yanlış bağlam alıyor, bu da bağlam olmamasından daha kötü. Bu pattern'in merkezi bakım riski. Azaltma stratejileri: önemli kod değişikliklerinden sonra lint geçişleri çalıştır, değiştirilen veya kaldırılan kod yollarına referans veren wiki sayfalarını işaretlemek için agent'ı kullan; wiki girdilerini implementasyon detaylarından çok kararlar ve gerekçe üzerine kapsamlandır (gerekçe koddan daha yavaş eskir); ve wiki uygunsuzluğunu pattern'in projen için çalıştırmaya değip değmediğini değerlendirirken gerçek bakım maliyeti olarak gör. Net bir sahibi ve düzenli lint kadansı olan wiki güzellikle bozuluyor. Yalnızca hevese dayalı bakım yapılan wiki hızlıca bozuluyor.
İlgili Okumalar
- Claude Code vs Verdent: Çok Agent'lı Mimari Karşılaştırması — Paralel agent yürütmesinin context yönetimini nasıl etkilediği ve paylaşılan bilgi tabanının worktree izolasyonlu iş akışına nereye oturduğu.
- Claude Code Auto Mode ve Cloud Auto-Fix — Kalıcı proje bağlamını en değerli kılan otonom yürütme pattern'ları.
- Model Context Protocol Nedir? — MCP araç entegrasyonunun agentic iş akışlarındaki daha geniş context yönetimi problemiyle ilişkisi.
- Lark CLI: AI Agent'larıyla Dev Bildirimlerini Otomatikleştir — Çok agent'lı iş akışları için operasyonel katman — seans çıktılarını ekip iletişimine nasıl bağlarsın.
- Claude Code Fiyatlandırma 2026: Her Plan Açıklandı — Context yeniden kurulumu seansları yutuyorken token maliyetleri önem taşıyor; faturalandırma modelini anlamak takas optimizasyonuna yardımcı oluyor.
Net konuşmak gerekirse: bu pattern'i hak eden projeler küçük değil ama büyük de değil. Birden fazla alt sistemi, birkaç aktif agent'ı ve gerçekten alınmış mimari kararları olan projeler için, context yeniden kurulumunun birikimli maliyeti bakım yatırımını haklı kılıyor. Altyapı yok — dizinler ve markdown. Küçük başla ve büyü.
Verdent'i dene — kredi kartı gerekmeden 100 ücretsiz kredi. Git worktree izolasyonuyla paralel agent'lar çalıştırıyor; ortak wiki dizini, çakışan yazmalar olmadan agent'lar arası proje bağlamının tutarlı görünümünü paylaşmak için doğal bir uyum. Ücretsiz başla →
İyi kodlamalar.
