Cursor’ın “Instant Grep” hamlesi: milyonlarca dosyada ms arama

Bir repo büyüdükçe, en basit sorular bile pahalı hale gelir: “Bu fonksiyon nerede çağrılıyor?”, “Şu flag hangi dosyalarda geçiyor?”, “Bu hata mesajını en son kim ekledi?” Lokal bir projede saniyeler içinde çözülürken, milyonlarca dosyayı konuştuğumuz anda arama, geliştiricinin değil sistemin limitlerine tosluyor. Cursor’ın son paylaşımı tam buraya oynuyor: milyonlarca dosyada milisaniyeler içinde sonuç döndüren yeni altyapıları Instant Grep.

Cursor’ın paylaştığı tweete göre artık “milyonlarca dosyayı arayıp milisaniyelerde sonuç bulabiliyorlar” ve bunun özellikle ajanların görev tamamlama hızını dramatik biçimde artırdığını söylüyorlar. Detaylarını da Instant Grep’i nasıl inşa ettiklerini anlattıkları yazıda paylaştıklarını belirtiyorlar; yani konu “hızlıyız” iddiasından ibaret değil, arkasında algoritma tercihleri ve kaçınılmaz trade-off’lar var. (Paylaşımın kendisi için Cursor’ın Instant Grep duyurusuna göz atabilirsiniz.)

Neden bu kadar önemli: Arama, ajanların görünmez darboğazı

Son bir yılda “kod ajanları” dediğimiz şey, basit bir autocomplete’in çok ötesine geçti. Ajan; bir bug’ı çözmek için kodu tarıyor, ilgili dosyaları buluyor, bağımlılıkları takip ediyor, testleri güncelliyor. Buradaki kritik nokta şu: Ajanların “düşünme” süresi kadar “bakınma” süresi de var. Ve bakınma süresinin büyük kısmı arama.

Bir insan geliştirici, doğru dosyayı bulmak için sezgisel olarak birkaç noktaya bakar: klasör yapısı, isimlendirme, son commit’ler, benzer modüller. Ajan ise bunu sistematik yapar: daha fazla dosya tarar, daha fazla referans toplar, daha fazla eşleşmeyi kıyaslar. Bu da aramayı, ajanların throughput’unu belirleyen temel metriklerden birine dönüştürür. Eğer arama 800 ms sürüyorsa ve ajan bir görevi bitirmek için 80–120 arama yapıyorsa, yalnızca bu katman dakikalara mal olur. Milisaniyelere inince, aynı görev “bekleme” yüzünden şişmez.

“Milyonlarca dosyada ms” iddiasının arkasında ne olabilir?

Cursor’ın “Instant Grep” adını özellikle seçmesi boşuna değil; grep kültürü, düz metin aramanın en çıplak hali. Ama ölçek büyüyünce düz metin arama, I/O ve indeksleme problemine dönüşür. Milyonlarca dosya demek, tek makinede bile dosya sistemi çağrıları, disk erişimi, cache davranışı, hatta küçük ayrıntılarda patlayan latency kuyrukları demek.

Bu seviyede hız için genellikle üç şeyden biri (ya da hibriti) gerekir. Birincisi, ön indeksleme: İçeriği önceden parçalayıp bir indeks tutarsınız, sorgu geldiğinde dosyaları tek tek taramak yerine indeks üzerinden gidersiniz. İkincisi, agresif caching: Popüler sorguların ve sık erişilen dosya bölümlerinin sonuçlarını RAM’de sıcak tutarsınız. Üçüncüsü, sıkı bir sistem tasarımı: Dosya taraması yapacaksanız bile bunu paralelize eder, dosya açma/okuma maliyetini amorti eder, mümkünse memory-mapped okuma ve sıkıştırılmış bloklarla çalışırsınız.

Cursor “algoritmalar ve tradeoff’lar” dediğine göre, büyük ihtimalle klasik arama doğruluğu ile hız arasında verdikleri kararları anlatıyorlar. Örneğin regex desteği, Unicode davranışları, büyük-küçük harf hassasiyeti, token bazlı arama mı düz string mi gibi seçimler, performansı doğrudan etkiler. “Her şeyi destekleyelim” yaklaşımı genelde pahalıdır; “en sık kullanılan %90 senaryoyu roketleyelim” yaklaşımı ise ürün hissini değiştirir.

Kullanıcı açısından hissedilen fark: Akışın bozulmaması

Geliştiriciler için hızın psikolojik bir eşiği var. 200–300 ms civarı, “anında” hissinin başladığı yer. 1–2 saniye gecikmelerde ise beyin başka yere kayıyor; sekme değiştiriyorsunuz, farklı bir iş açıyorsunuz, odağınız dağılıyor. Cursor’ın hedeflediği kitle, zaten editör içinde yaşayan ve akışla çalışan insanlar. Aramanın milisaniyeye düşmesi, sadece zaman kazandırmıyor; dikkat ekonomisini de geri veriyor.

Ajan tarafında da benzer bir etki var. Ajanın “görevi tamamlama” süresini, sadece modelin muhakemesi değil, çevresel araçların gecikmesi belirliyor. Kod tabanı büyüdükçe, iyi bir araç zinciri olmayan ajanlar daha çok tahmin yapmaya başlıyor. Tahmin arttıkça hata riski artıyor; hata arttıkça yeniden deneme döngüsü uzuyor. Hızlı arama, ajanı “tahminden” “kanıta” yaklaştırır.

Bu işin bedeli ne olabilir?

Her hızlanmanın bir faturası var. Milyonlarca dosyada arama için indeks tutuyorsanız, disk alanı ve indeks güncelleme maliyeti gelir. Repo sürekli değişiyorsa, indeksin tutarlılığı ayrı bir problem olur. Eğer arama uzakta (sunucuda) yapılıyorsa, gizlilik ve güvenlik soruları devreye girer: Hangi dosyalar indeksleniyor, hangi veriler saklanıyor, enterprise senaryoda ne garanti ediliyor?

Cursor’ın Instant Grep’i anlatırken “tradeoff” vurgusu yapması bu yüzden önemli. Çünkü bu tarz bir hız, sihir değil; doğru hedefi seçmek, doğru kısıtları kabul etmek ve gerçek dünyada bozulmayan bir mühendislik kurmak demek.

Büyük resim: Editörler yarışmıyor, altyapılar yarışıyor

Bugün bir editörü “AI’lı” yapan şey sadece sohbet penceresi değil. Asıl fark, modelin dokunduğu araçların kalitesinde ortaya çıkıyor: arama, indeksleme, refactor motoru, test koşucu, diff analizi, sembol çözümleme. Cursor’ın Instant Grep hamlesi de bu yarışın tam merkezinde duruyor.

Milyonlarca dosyada milisaniyelik arama, tek başına bir özellik gibi görünse de aslında bir iddia: “Ajanlar burada gerçekten çalışabilir.” Eğer bunu sürdürülebilir biçimde yapabiliyorlarsa, büyük monorepo’larda ve devasa kurumsal kod tabanlarında AI yardımının çıtasını bir seviye yukarı taşıyacaklar. Çünkü o ölçekte kazanan, en zeki modeli değil; en az bekleten sistemi kuran taraf oluyor.