Red Hat'in 219 gerçek dünya oturumu üzerine yaptığı analize göre, Claude Code token bütçesinin dörtte üçünü sadece kod tabanını okumaya harcıyor. Bu bulgu, yapay zeka destekli kodlama ajanlarının kod üretirken zaman kaybettiği yönündeki alışılagelmiş varsayımı tersine çeviriyor ve geliştiricilerin sadece model hızına değil, bağlam yönetimi (context-management) sorununa odaklanması gerektiğini gösteriyor.
İddianın arkasındaki veriler
Red Hat, Anthropic'in Claude Code ile yapılan 219 etkileşimini inceledi ve her bir turdaki token kullanımını hesapladı. Örneklem genelinde, medyan bir turda tokenların %75'i çevredeki kodun ve dokümantasyonun içeri alınmasına (ingesting) ayrılırken, sadece %25'i yeni satırlar üretmeye ayrıldı. Çoğu yapay zeka sağlayıcısı giriş (input) ve çıkış (output) tokenlarını aynı oranda ücretlendirdiğinden, işlemin "okuma" kısmı maliyetin büyük kısmını oluşturuyor.
Okuma maliyeti neden önemli?
Optimizasyon stratejisi
Birçok ekip, hız artışının her üretimden birkaç saniye tasarruf etmesini umarak daha hızlı veya daha büyük modellere kaynak aktarıyor. Eğer işin dörtte üçü sadece bağlamı (context) içeri çekmekten ibaretse, daha hızlı bir model toplam süreden yalnızca küçük bir kısmını tasarruf ettirir. Asıl kaldıraç, modelin her turda ne kadar bağlamı işlemesi gerektiğidir.
Maliyet kontrolü
Bir yapay zeka asistanı her istekte aynı depo (repository) durumunu yeniden okuduğunda, giriş tokenları şişer. Üretilen kod miktarı mütevazı kalsa bile, geniş bağlam pencerelerine (context windows) sahip projelerin faturaları çarpıcı biçimde artabilir.
Mühendislik odağı
Araç geliştiricileri, istemlerin (prompts) nasıl oluşturulduğunu gözden kaçırarak genellikle daha yüksek model kalitesinin peşinden koşuyor. Analiz, modele beslenen kodun budanması, önbelleğe alınması ve özetlenmesi gibi "bağlam mühendisliğinin" (context engineering), kademeli model güncellemelerinden daha büyük bir yatırım getirisi (ROI) sağladığını gösteriyor.
Okuma yükünü azaltmak için pratik adımlar
- Alakasız dosyaları budayın – Mevcut görevin ihtiyacı olmayan dosyaları istemden çıkarın. Daha küçük istemler, daha az giriş tokenı demektir.
- Tekrarlanan okumaları önbelleğe alın – Kod tabanının sabit kısımlarının model tarafından yorumlanmış halini saklayın ve aynı metni tekrar göndermek yerine bunu turlar arasında yeniden kullanın.
- Araç çıktılarını sıkıştırın – Harici araçlar büyük veri blokları (örneğin lint raporları) döndürdüğünde, bunları Claude'a geri beslemeden önce özetleyin.
- Artımlı farkları (incremental diffs) kullanın – Dosyanın tüm içeriği yerine yalnızca son turdan bu yana yapılan değişiklikleri gönderin.
Bu taktikler, yapay zekanın her etkileşimde aynı depo anlık görüntüsünü (snapshot) yeniden okumasını durdurmayı, böylece hem gecikmeyi hem de maliyeti düşürmeyi amaçlar.
Karşı argüman: hız hâlâ önemli
Bazı geliştiriciler, daha hızlı bir modelin hâlâ önemli olduğunu, çünkü üretilen %25'lik token kısmının gecikmesini azalttığını savunuyor. Anında yanıt vermesi gereken IDE eklentileri gibi gecikmeye duyarlı ortamlarda her milisaniye önemlidir. Okuma odaklı profil, daha hızlı bir modelin faydasını ortadan kaldırmaz; sadece onun göreceli etkisini azaltır.
Sırada ne var?
Red Hat'in çalışması sınırlı sayıda oturuma dayanıyor, bu nedenle daha geniş kapsamlı örneklemler diğer diller veya proje boyutları için farklı token dağılımları ortaya çıkarabilir. Eğer gelecekteki veriler %75'lik okuma rakamını doğrularsa, bağlamı otomatik olarak budayan ve önbelleğe alan araçlara veya hatta hızlı bağlam alımı için optimize edilmiş model mimarilerine doğru bir kayma görebiliriz.
Özetle: Yapay zeka destekli kodlama için en ucuz performans artışı, modele daha hızlı yazmasını söylemekten değil, ona daha az veri beslemekten gelir. Red Hat'in rakamları durumu net bir şekilde ortaya koyuyor: İstemlerinizi budayın, önbelleğe alın ve özetleyin; böylece hem zaman hem de para açısından somut tasarruflar göreceksiniz.