- Son dönemde yapay zeka ajanı ekosisteminde dosya sistemleri yeniden ilgi görmeye başladı ve veritabanlarından farklı bir kalıcı bağlam yönetimi aracı olarak öne çıkıyor
- LLM’lerin bağlam penceresi kalıcı bir bellekten çok silinen bir beyaz tahtaya benziyor; dosya sistemi ise bunu çözmenin en basit kalıcı depolama yolu
- Claude Code, Cursor gibi araçlar dosya tabanlı bağlam depolama ile uzun süreli belleği hayata geçiriyor;
CLAUDE.md, aboutme.md gibi dosyalar ajanın kimliği ve ortam bilgilerini taşıyor
- Dosya sistemi tabanlı bağlam yönetimi temel gündem maddesi haline gelirken, LlamaIndex·LangChain·Oracle·Archil gibi önemli şirketler peş peşe ilgili yazılar ve ürünler yayımlıyor
CLAUDE.md, AGENTS.md, .cursorrules gibi ajan bağlam dosyaları çoğalırken, Anthropic’in Agent Skills (SKILL.md) formatı Microsoft·OpenAI·GitHub·Cursor gibi şirketlerce benimsenerek birlikte çalışabilirlik sağlıyor- ETH Zürich araştırmasına göre bağlam dosyaları tersine görev başarı oranını düşürebilir ve çıkarım maliyetini %20’den fazla artırabilir; bu yüzden yalnızca asgari gereksinimler yazılmalı
- Dosyalar belirli bir uygulamaya bağımlı değil; yapay zeka ajanları çağında araçlar arası geçişi, iş akışı birleşimini ve sürekliliği mümkün kılan açık bir arayüz haline geliyor
Everyone is talking about files : Her yerde dosyalar konuşuluyor
Bağlam penceresi bellek değildir
- İnsan belleği uzun süreli depolama, seçici geri çağırma ve gereksiz bilgiyi unutma işlevlerini içerir; LLM’lerin bağlam penceresi ise sürekli silinen bir beyaz tahtaya daha yakındır
- Claude Code kullanırken "context left until auto-compact" uyarısı yaklaştığında, ajanın biriktirdiği kod tabanı, tercihler ve alınmış kararlar gibi bağlam sıkıştırılır ya da kaybolur
- Dosya sistemi bunu en basit şekilde çözer: kayıtları dosyalara yazar ve gerektiğinde yeniden okur
CLAUDE.md, proje hakkında kalıcı bağlam sağlar- Cursor, geçmiş sohbet kayıtlarını aranabilir dosyalar olarak saklar
aboutme.md dosyası; tercihleri, becerileri ve çalışma tarzını içeren taşınabilir bir kimlik tanımlayıcısı işlevi görür ve API koordinasyonu olmadan uygulamalar arasında taşınabilir
ETH Zürich araştırması: bağlam dosyalarının paradoksu
- ETH Zürich’in yakın tarihli makalesi, depo düzeyindeki bağlam dosyalarının gerçekten kodlama ajanlarının görev tamamlama başarısına yardımcı olup olmadığını değerlendiriyor
- Sonuçlar sezgiye aykırı: farklı ajanlar ve modeller boyunca bağlam dosyaları görev başarı oranını düşürüyor, çıkarım maliyetini ise %20’den fazla artırıyor
- Bağlam dosyası verilen ajanlar daha geniş arama yaptı, daha fazla test çalıştırdı ve daha fazla dosya dolaştı; ancak gerçekten değiştirilmesi gereken koda ulaşmaları gecikti
- Dosya, ajanın aşırı ciddiye aldığı bir kontrol listesi gibi çalıştı
- Makalenin vardığı sonuç "bağlam dosyalarını kullanmayın" değil; gereksiz gereksinimlerin görevi zorlaştırdığı ve bağlam dosyalarının yalnızca asgari gereksinimleri anlatması gerektiği
- Sorun, dosya sisteminin kalıcı katmanının kendisi değil;
CLAUDE.md dosyasını 2.000 kelimelik bir onboarding belgesi gibi yazma pratiği
Dosya formatı API’nin kendisi — ama hangi dosya?
- Şu anda
CLAUDE.md, AGENTS.md, copilot-instructions.md, .cursorrules bir arada varlığını sürdürüyor; ajanların kalıcı, dosya sistemi tabanlı bağlama ihtiyaç duyduğu konusunda uzlaşma var ama dosya adı ve içerik formatı konusunda uzlaşma yok
- Dan Abramov’un sosyal dosya sistemi yazısındaki temel tasarım şu: AT Protocol, kullanıcı verisini kişisel repository içindeki dosyalar olarak ele alıyor ve uygulamaların "post"un ne olduğunda anlaşmasına gerek kalmadan alan adı tabanlı namespace ile çakışmaları önlüyor
- Tüm uygulamaların veritabanları türetilmiş veri, yani tüm kullanıcı klasörlerinin önbelleğe alınmış somutlaştırılmış görünümleri haline geliyor
- Anthropic, Agent Skills’ı açık standart olarak duyurdu:
SKILL.md formatı Microsoft, OpenAI, Atlassian, GitHub ve Cursor tarafından benimsendi
- Claude Code için yazılmış bir skill, Codex ve Copilot’ta da çalışıyor — dosya formatı API’nin kendisi
- NanoClaw, hafif bir kişisel yapay zeka asistanı framework’ü olarak "özellik yerine skill" modelini benimsiyor
- Telegram desteği gerekiyorsa, bir Telegram modülü yerine
/add-telegram skill’i (bir Markdown dosyası) Claude Code’a nasıl entegre edileceğini öğretiyor
- Skill’ler dosya olduğu için taşınabilir, denetlenebilir ve birleştirilebilir; MCP sunucusu ya da eklenti pazaryerine ihtiyaç yok
- İşte bu, koordinasyon gerektirmeyen birlikte çalışabilirlik: iki uygulama Markdown okuyabiliyorsa bağlam paylaşabilir;
SKILL.md formatını anlayabiliyorsa işlev paylaşabilir; ortaklık anlaşmaları veya standart kurumu toplantıları olmadan, dosya formatının kendisi koordinasyon işlevi görür
Darboğazın yeri değişiyor
- Geleneksel veri mimarisi, depolamanın darboğaz olduğu varsayımıyla tasarlanmıştı; ancak işlem gücü depolama I/O’sunu aşınca paradigma depolama ile compute’un ayrılmasına (S3 + geçici compute cluster’ları) kaydı
- Benzer bir durum yapay zeka ajanlarında da görülüyor: darboğaz model performansı ya da compute değil, bağlam
- Modeller yeterince akıllı ama unutkan
- Dosya sistemi, ajanın çalıştığı tam noktada — yani geliştiricinin makinesinde, ortamın ve verinin zaten bulunduğu yerde — kalıcı bağlamı yönetmenin en etkili yolu
Dosya sistemi zaten bir grafik
- Twitter’da yapılan şu tespit dikkat çekiyor: "Dosya sistemi kullanırken ajanlar için grafa gerek olmadığını söyleyenler, aslında graf kullandıklarını inkâr ediyor"
- Dosya sistemi; dizinler, alt dizinler ve dosyalardan oluşan bir ağaç yapısıdır, yani yönlü döngüsüz grafik (DAG)
- Ajan
ls, grep, dosya okuma ve referans takibi yaptığında zaten graf üzerinde dolaşıyor
- Oracle yazısından Richmond en keskin ayrımı yapıyor: arayüz olarak dosya sistemi kazanır, temel katman olarak veritabanı kazanır
- Eşzamanlı erişim, büyük ölçekli semantik arama, tekilleştirme, güncellik ağırlıkları gibi ihtiyaçlar çıktığında sonunda kendi indeksinizi kurarsınız; bu da fiilen veritabanıdır
- Dosya arayüzü evrensel olduğu ve LLM’lerin zaten anladığı bir yapı olduğu için güçlü; veritabanı tabanlı altyapı katmanı ise gerçek operasyonda gereken garantileri sağladığı için güçlü
- Gelecek, dosya mı veritabanı mı tartışması değil; insanların ve ajanların etkileşim kurduğu arayüzün dosya olduğu, altında ise kullanım senaryosuna uygun bir temel katmanın yer aldığı yapı
Bu, kişisel bilişimin yeniden tanımlanması
- Dosya sistemi, yapay zeka çağında kişisel bilişimin anlamını yeniden tanımlayabilir
- Veri, bağlam, tercihler, skill’ler ve bellek; kullanıcının sahip olduğu bir formatta bulunur, herhangi bir ajan tarafından okunabilir ve belirli bir uygulamaya kilitlenmez
aboutme.md, bugün OpenClaw/NanoClaw’da da yarın çıkacak yeni bir araçta da çalışır- Skill dosyaları taşınabilir, proje bağlamı ise araçlar arasında korunur
- Bu, her şeyin kapalı SaaS uygulamalarına ve tescilli veritabanlarına taşınmasından önce kişisel bilişimin aslında hedeflediği şeye daha yakın
- Dosyalar orijinal açık protokoldür; yapay zeka ajanları bilişimin başlıca arayüzü haline geldikçe, araç değiştirmeyi, iş akışlarını birleştirmeyi ve uygulamalar arasında sürekliliği kimseden izin almadan mümkün kılan birlikte çalışabilirlik katmanı olurlar
- Yine de bunun idealist bir yanı var: açık formatların tarihinde, kâğıt üzerinde kazanan ama pratikte başarısız olan çok sayıda standart var
- Şirketlerin, geçiş maliyetini korumak için kendi bağlam dosyalarını ince farklarla oluşturma teşviki güçlü
CLAUDE.md, AGENTS.md ve .cursorrules dosyalarının tek bir evrensel format yerine bir arada bulunması bile varsayılan durumun parçalanma olduğunu gösteriyor- ETH Zürich makalesi, bir format var olsa bile iyi bir bağlam dosyası yazmanın zor olduğunu ve kötü bir bağlam dosyasının hiç olmamasından daha kötü olabileceğini hatırlatıyor
- Dan Abramov’un ana mesajı:
> Anılarımız, düşüncelerimiz ve tasarımlarımız onları üreten yazılımdan daha uzun yaşamalı
- Bu teknik bir tez değil, bir değer meselesi; dosya sistemi bu rol için en iyi teknoloji olduğu için değil, zaten kullanıcıya ait olan tek teknoloji olduğu için uygun
1 yorum
Hacker News yorumları
Dosyalar, kullanıcıların veriye doğrudan sahip olabilmesini sağlayan en temel özgürlük biçimidir
Bu, gizlilik, bütünlük ve erişilebilirlik üzerinde egemenlik kurmayı mümkün kılar
Dijital özgürlüğün temel eksenlerinden biri olarak, FOSS lisanslarıyla eşdeğer görülmelidir
Doğal dil zaten dosyanın içinde yer alıyor ve okunabilirlik başlı başına bir spesifikasyon haline geliyor
Okuması kolay olduğu sürece herkes dosyaya yazabilir ve REPL gibi anında çalıştırabilir
Veriyi uygulamalara bağlıyorlar; verinin bağımsız biçimde var olmasını engelliyor ve içe/dışa aktarmayı zorlaştırıyorlar
Ben de bu sorunu çözmek için, yedeklerden veriyi ince taneli dosya birimleri halinde çıkarıp kişisel bir dijital kütüphaneye taşıyan bir araç geliştiriyorum
Değişmez veri için arşivlemek yeterli, ama düzenlenebilir veriyi yeniden uygulamalarda düzenlenebilen ‘canlı’ bir biçime döndürmek en büyük zorluk
Geçici değişiklik yapmak ve paylaşmak kolay, ayrıca ayarların anlamı net biçimde tanımlanıyor
Windows'un dosyalara üçüncü sınıf vatandaş muamelesi yapmasından hoşlanmıyorum
SaaS açısından da aynı şekilde düşünüyorum
Kod ne kadar geçici ve alan-özel olursa olsun, veri (dosyalar) standart ve sıkıcı olacak kadar kararlı olmalıdır
Yalnızca belirli bir uygulamanın okuyabildiği formatlar teknik borçtur ve sonunda projeyi batırır
1995'ten kalma bir JPEG dosyasını bugün hâlâ açabiliyor olmamızın nedeni, onun yazılıma bağımlı olmamasıdır
Bu, defalarca doğrulanmış doğru bir yaklaşım
Google Photos ya da Immich gibi soyutlama katmanları sadece kullanım kolaylığı içindir; özünde önemli olan dosyalardır
İşte de araştırma ve dokümantasyonu markdown ve csv dosyalarıyla yönetiyorum
elodie proje bağlantısı
Platform değiştirince tüm düzenleme geçmişi kayboluyor
Geri alma özelliği kullanışlı olsa da, bu tür değişikliklerin taşınabilir olacak şekilde standartlaşmasını isterim
Bell Labs'in Plan 9'ından söz etmek istiyorum
Plan 9 from Bell Labs
Claude'a önceki çalışmaları sorduğumda Plan 9'u önerdi; tam da bugün ihtiyacımız olan kavram bu
Ajan yetkilerini en aza indirme felsefesi, kurumsal güvenlik modeliyle aynı
Sadece Plan 9 fazla erken ortaya çıktı
Plan 9 ve UNIX'in haklı olduğunu yeniden fark ettiriyor
En güçlü arayüz, dosya sistemi üzerindeki metin dosyalarıdır
Artık 9p2026'yı yeniden yapmanın zamanı geldi
Ancak yazıdaki bazı temel kavramlar yanlış — dosya sistemi bir ağaç değil, döngü içerebilen bir graftır
Bu bana da çok dokunan bir konu
Son 1 yılda 10'dan fazla SaaS hizmetinden kişisel verilerimi tek bir dizin yapısına taşıdım
İyi organize edilmiş bir dosya sistemi, tek kullanıcı için yeterli ve veri parçalanmasını ortadan kaldırıyor
Gelecekte, dosya sistemini opak hale getirmeden güvenli çok kullanıcılı yazmayı destekleyen yeni veritabanları çıkacak gibi görünüyor
QMD'nin arama için oynadığı role benzer bir his veriyor
Şu anda AI kullanımı hâlâ olgunlaşmamış bir aşamada
Üretim sistemleri tutarlı ve ölçeklenebilir veri yapıları üzerinde çalışacaktır, ama bunları inşa eden ajanlar dosya sistemi tabanlı teknolojileri kullanacaktır
UI'ın masaüstünden uzaklaşıp sesli ve görsel arayüzlere evrileceğini düşünüyorum
Örneğin görüntülü görüşmelerde yüz ifadesi ve tonlamayı okuyarak daha fazla bağlam edinmek gibi
Tam anlamıyla multimodal değil ama çok ilgi çekiciydi
Yazmak düşünceleri düzenlemeye yardımcı olur ve konuşma kadar doğaçlama değildir
Konuşma tanıma (STT) ne kadar iyi olursa olsun, insan zekâsı hâlâ yazma merkezli işliyor
Dosyalar ancak bulunabildiğinde faydalıdır
Yani arama ve indeks zorunlu; ama ölçek büyüdükçe bunlar bozulmaya başlar
Bu yüzden asıl soru, ‘ajanın işlediği bilgi tabanı ne kadar büyük olabilir?’
Bu konuyu “a good agentic KB” yazısında birinci ilkeler düzeyinde inceledim
Kod tabanı gibi iyi düzenlenmiş çok sayıda dosyada kodlama ajanları bilgiyi iyi buluyor
Ama dağınık verilerde dosya sistemiyle yapılandırmak çok daha zor
Bu, vektör DB'de anlamsal arama yapmaktan daha karmaşık
Kod tabanları DRY ilkesi sayesinde doğal olarak bir graf yapısını korur, ama kod dışı verilerde bu geçerli değil
Bu yüzden dosya sisteminin uzun vadede iyi bir bağlam yapısı olduğuna katılıyorum, ancak aramanın yerini henüz tamamen alamaz
Dosya sisteminin berbat bir soyutlama olduğunu düşünüyorum
Dosyaları dizin ağacı gibi bilinçli bir yapıya asmak zorunda olmak verimsiz
İlişkisel model ya da benzersiz tanımlayıcı tabanlı yapılar daha iyi olabilir
Bir daldaki değişiklikler diğer dalı etkilemez
Buna karşılık veritabanlarında UPDATE ya da DELETE tüm yapıyı etkileyebilir ve bu yüzden risklidir
Bu nedenle modern işletim sistemlerindeki gibi, ağaç yapısının üstüne DB indeksi ekleyen hibrit yaklaşım idealdir
Dosya adlarını b+tree ile indeksler ve dosya verisini de MFT içinde saklar
Dizinler sadece ‘directory=true’ özniteliğine sahip satırlardır
WinFS gibi tamamen ilişkisel yaklaşım performans sorunları nedeniyle başarısız oldu; onun yerini Skydrive aldı
Bu nokta sık sık unutuluyor gibi görünüyor
Sonuçta yönün, S3 tarzı blob depolamanın üzerine iyi bir indeks koyup dizinleri etiket gibi istek üzerine oluşturulan yapılara dönüştürmek olacağını düşünüyorum
Sonunda geriye sadece “Q3 ile ilgili materyaller bu dizinde” türü gruplama işlevi kalabilir