Claude Code Kotası Düşüşü: Ajanlar yeni 'Eski Kod Dağları' mı oluşturuyor?

Claude Code haftalık kotası uzatıldıkça ilgi çekiyor, makale Agent programlarının Token tüketim mekanizmasını analiz ediyor. Agent'in uzun süreli çalışması, working set'in sürekli genişlemesine neden oluyor; her adım geçmiş durumları biriktiriyor ve önbellek vuruşu bile context'i işgal etme özelliğinden dolayı hesaplama maliyeti birikimli olarak artıyor. Aşırı temizlik, "anlamsal sayfa hatası"na yol açıyor ve Agent'in bilgileri yeniden almasını gerektiriyor. Makale, bu kod durumu ile tasarım durumunun kaydedilme kesinliği arasındaki tutarsızlığın, AI tarafından oluşturulan "miras kodlarına" neden olabileceğini belirtiyor: Sonraki Agent'ler, erken dönem kodlarının tasarım neden-sonuç ilişkisini anlayamıyor ve nihayetinde queue, bypass, retry'lerin birbirini telafi ettiği karmaşık kodlar oluşuyor.

Yazan ve kaynak: Leifengwang

Kod gerçekten Agent tarafından yazılmıştır, ancak sonraki Agentler, önceki Agentlerin bunu neden yazdığını bilmiyor.

Claude Code, 19 Ağustos'ta sona erecek olan %50 haftalık kota artışı, Anthropic tarafından 31 Ağustos'a kadar uzatıldı. Tam olarak orijinal son tarih civarında, Hacker News'te Claude Code kullanım maliyeti üzerine bir tartışma başladı: Birçok kullanıcı, oldukça basit bir görev için Agent'in birkaç tur çalıştırılmasının kota hızla tükenmesine neden olduğunu fark etti.

Sorun, Claude Code'un yalnızca son üretilen birkaç satır kodu tüketmesi değil; dosyaları okumak, çağrı zincirlerini aramak, testleri çalıştırmak ve günlükleri işlemek gibi her adım, sonraki bağlamda devam ediyor. Görev ne kadar uzunsa, Agent'ın taşıdığı geçmiş o kadar ağırlıyor ve sistem, temizleme ve sıkıştırma işlemine o kadar çok bağımlı hale geliyor.

Kod, deposunda tamamen kalabilir, ancak erken dönem tasarım nedenleri sıkıştırma sırasında giderek zayıflayabilir. Böylece Token tüketimi ve kod yığını aynı yerde birleşmeye başlar.

Normal chat kodlama için hesaplama sınırları nettir. Bir kod parçası girilir, model okuduktan sonra açıklama veya düzeltme önerisi sunar ve bu tur genellikle biter.

Claude Code'un temel birimi agent döngüsüne dönüştü. Model önce mevcut durumu gözlemleyip, hangi dosyayı okuyacağını veya hangi komutu çalıştıracağını kararlaştırır; araçlar sonuç döndükten sonra model bir sonraki kararını verir.

Kaynak kodu okuyun, başvuruları arayın, testleri çalıştırın, Git diff'ini inceleyin, dosyaları değiştirin; bunlar model tarafında aslında bağımsız çıkarım istekleri dizisidir. Claude Code resmi belgeleri, bu "model kararı—araç çağırma—sonuca göre devam eden karar" döngüsünü Agent çalışma şeklinin temelini olarak tanımlar.

Örneğin, oturum durumunun ara sıra sona ermesi sorunu. Agent, giriş noktasını buldu ve durumun servisten geldiğini gördü, bu nedenle servisi daha fazla okudu; önbelleği görünce kimin yazdığını aradı; ardından test çalıştırdı, test başka bir hata ortaya çıkardı, bu nedenle fixture’i inceledi; düzelttikten sonra tekrar doğruladı, eski test tekrar uyumluluk sorununu ortaya çıkardı.

Belki de tam olarak bu noktada, o birkaç satır kodu yazmaya başlamıştır. Bu nedenle,diff boyutu ile hesaplama yükü arasında neredeyse sabit bir oran bulunmamaktadır. 5 satırlık bir düzeltme arkasında sadece 3 kez çıkarım yapılmış olabilir ya da 30 kez araç etkileşimi geçirmiş olabilir.

Bir Agent görevi ayrıldığında, iki değişken elde edilebilir: biri adım sayısı, Agent'in görevi tamamlamak için attığı adım sayısı; diğeri çalışma kümesi, şu anki adıma ulaşıldığında modelin hala kaç proje durumunu bilmesi gerektiği.

Sadece adım sayısını artırmak bile tüketimi artırır. Eğer çalışma kümesi hâlâ senkronize olarak büyüyorsa, durum tamamen farklılaşır. 3. adım belki binlerce Token işlemekle sınırlı olabilir, ancak 30. adım zaten proje kurallarını, ilgili kaynak kodunu, test sonuçlarını, değişiklik geçmişini ve araçları taşıyarak yeniden çıkarım yapmaya devam edebilir.

Bu, Coding Agent'in maliyet yapısının değişmeye başladığı noktadır: hesaplama miktarı, yazılan kod satır sayısı yerine "kaç adım atılır × her adımda ne kadar ağırlık taşınır" üzerine dayanmaya başlamıştır.

Agent'in bir model isteği, kaba olarak üç parçaya ayrılabilir. İstikrarlı kısımlar arasında system prompt, CLAUDE.md, araç tanımları ve proje kuralları yer alır; değişken kısımlar ise kod dosyaları, arama sonuçları, test günlükleri, Git diff ve önceki görev geçmişi içerir; son olarak bu turda modelin ürettiği nedenleme, metin ve kod bulunur.

Burada yaygın bir yanlış anlama vardır: önceki içerik zaten okunmuşsa, tekrar fazla maliyet oluşmamalıdır. Sorun, LLM'nin geleneksel bir programda olduğu gibi her an erişilebilen bir dahili belleğe sahip olmamasıdır. Önceki turda bilinen bilgiler, sonraki turda hala bunlara bağlıysa, ilgili durumlar kullanılabilir bağlamda devam etmelidir.

Prompt önbelleği bu sorunu hafifletebilir. Claude Code resmi belgeleri, prompt önbellekleme yoksa her istekte tüm geçmişin yeniden işlenmesi gerektiğini açıkça belirtir; önbellek vurursa, daha önce işlenmiş sabit önekler yeniden kullanılabilir ve bu da tekrarlayan hesaplamaları ve maliyetleri azaltır.

Ancak önbellek, "aynı geçmiş daha ucuzca yeniden kullanılabilir mi?" sorusunu çözer, ancak "bu geçmiş hâlâ var olmalı mı?" sorusunu çözmez. 100K Token'in eski durumu önbelleğe uygunsa daha ucuz olur, ancak hâlâ bağlamı işgal eder ve hâlâ mevcut çıkarımın temelini oluşturur.

Böylece bir uzun görevi şu şekilde özetleyebilirsiniz: t. adımdaki giriş boyutu, sabit önek S'ye, geçerli çalışma kümesi W_t'ye ve bu turda yeni oluşturulan bilgi Δ_t'ye yaklaşık olarak eşittir.

Gerçekten sorunlu olan W_t’dir. Her adımda Agent, kaynak kodu biraz daha fazla okursa, biraz daha fazla günlük alırsa ve bir karar daha bırakırsa ve eski bilgiler zamanında silinmezse, W_t görev ilerledikçe artarak devam edecektir.

Bir uç şekilde basitleştirilmiş, tamamen önbellek ve temizleme olmayan bir modelde, her turda eklenen geçerli durumlar yaklaşık olarak aynıysa, toplam işlem miktarı 1 + 2 + 3 + … + n gibi bir birikim yapısı gösterir. Yani, adım sayısı yalnızca iki katına çıktıysa, tüm görevin işlenen geçmiş durumları daha hızlı artabilir.

Gerçek sistemde önbellek, bağlam düzenleme ve sıkıştırma mevcuttur ve bu artış eğrisini mekanik olarak takip etmez, ancak sorunun şekli değişmez: Agent ne kadar uzun çalışırsa, her yeni eylem o kadar daha ağır bir geçmiş üzerine kurulma olasılığı artar.

Bu nedenle uzun görevdeki çok kısa kullanıcı isteği hızla varlığını kaybedecektir. Gerçekten maliyeti yönlendiren, görevin sürekliliğini korumak için modelin sürekli taşıdığı çalışma kümesidir.

Çalışma seti neden bu kadar hızlı genişliyor? Araç çıktısı büyük bir kaynak. Kaynak kodun en azından bir yapısı var, ancak günlükler genellikle yok.

Bir kez grep yüzlerce başvuru döndürebilir, bir derleme büyük miktarda uyarı üretebilir, bir test hatası tam stack trace ile birlikte gelebilir, Docker, derleyiciler ve paket yöneticileri de görevler için uzun vadeli değeri olmayan büyük miktarda metin oluşturur.

10. adım testi 8K Token günlük üretti. Bu günlük ilk kez bağlamda göründüğünde sadece 8K Token idi. Ancak, Agent kaynak kodunu incelemeye, düzeltmeye ve yeniden test etmeye devam edecek; bu günlük geçerli geçmişte kalırsa, sonraki birçok isteğin temel ağırlığını artırır.

Bu, depolama sistemlerindeki write amplification'a çok benziyor: bir mantıksal yazma, daha fazla alt seviye işleme yaratıyor. Agent'da durum şu: bir araç çıktısı yürütme geçmişiyle yazılır ve ardından takip eden akıl yürütmeyle birlikte hareket eder.

Bu nedenle, aynı 8K Token, görevin son bir döngüsünde mi yoksa görevin başlangıcında mı kullanılırsa, toplam etki tamamen farklıdır. Claude Code, şimdi bu kirliliği azaltmak için aktif olarak çalışmaktadır. Resmi öneriler, yüksek çıktı gerektiren görevleri alt-ajantlarla izole etmeyi ve arama sonuçlarını, günlükleri ve büyük dosya içeriklerinin ana oturum bağlamını tükettiğini açıkça belirtmektedir; araç tanımları kendileri de yer kaplar, bu nedenle aşırı büyük bir araç seti de durum yükünü artırır.

Ancak burada ters bir sorun daha ortaya çıkıyor: günlüklerin maliyeti yüksek olduğu için hepsini atmak mümkün değil. 3000 satırlık bir günlükte, kök nedenle ilgili olan sadece 20 satır olabilir. Sistem, hangi 20 satırın ilgili olduğunu önceden bilmez. Eğer erken temizlik yapılırsa, Agent daha sonra bir detaya ihtiyaç duyduğunda, testi yeniden çalıştırmak veya dosyayı yeniden açmak zorunda kalır.

Bu, semantik sayfa hatası olarak adlandırılabilir. Geleneksel sanal bellekte, program bellekte olmayan bir sayfaya eriştiğinde sistem, diskten yeniden yükler; Coding Agent, erken bir kanıtı attıktan sonra benzer bir durum yaşar, ancak bu durum, depoyu yeniden arama, dosyaları tekrar okuma, komutları yeniden çalıştırma veya zaten analiz edilmiş bir soruyu yeniden çıkarılma şeklinde ortaya çıkar.

Bu nedenle uzun görev, fazla geçmiş bırakmak sonraki her adımı daha ağırlaştırırken, aşırı temizlemek Agent'in daha önce gördüğü bilgileri sürekli yeniden almasına neden olur.

Bu, bağlam yönetiminin "daha az token sokmak" şeklinde basitleştirilebileceğini açıklar. Gerçekten çözülmesi gereken, çalışma seti seçimidir: Şu anda çalışma alanına hangi bilgilerin kalması gerekir, hangileri görevini tamamlamış ara ürünlerdir.

Buraya kadar, compaction, memory ve sub-agent'in gerçek bir nedeni oldu.

Claude Code, bağlam sınırına yaklaştığında oturumu otomatik olarak sıkıştırır ve bazı daha eski araç sonuçlarını temizler. Resmi olarak da uzun oturumlardaki ilgisiz diyaloglar, dosya içerikleri ve komut sonuçlarının pencereyi doldurup model performansını bozabileceğine dikkat çekilmiştir.

Sistem açısından, compaction, semantik çöp toplama gibi görünür. Sorun, normal çöp toplamanın “bu nesnenin bir referansı var mı” diye karar vermesi whereas, Agent’in “bu bilgi ileride anlam ifade edecek mi” diye karar vermesidir.

Sonraki çok daha zor. Örneğin, erken aşamada şu tasarım sonucu vardı: bir modül, kullanıcı durumunu kendi kendine önbelleğe alamaz, çünkü sistem, durumun yalnızca bir sahibi olmasını ve tüm değişikliklerin servis üzerinden yapılmasını gerektirir.

Yirmi adımdan sonra, bu bilgi şu şekilde özetlenirse: “Durum sorunu, service üzerinden ayarlanarak çözüldü.” Gerçeklik yanlış olmasa da, bilgi değişmiştir. Orijinal içerik bir kısıtlama içeriyordu, ancak sonraki özet yalnızca bir olayı kaydediyor.

Bir sonraki Agent, performans sorunu yaşadığında ve hizmet çağrısının yavaş olduğunu gördüğünde, muhtemelen modüle yeniden önbellek ekleyecektir. Bu, mevcut bilgilerini ihlal etmemektedir; önbellek kullanımının yasaklandığı neden-sonuç ilişkisi artık geçerli değildir.

Claude Code'in bağlam belgesi, belirli yol-odaklı kuralların ve iç içe geçmiş CLAUDE.md dosyalarının oturumla birlikte sıkıştırılmış özetlere dahil edildiğini ve eşleşen dosyaların yeniden okunmasıyla yeniden yüklenmesi gerektiğini açıkça belirtir.

Memory, uzun vadeli bilgi saklama sorununu çözmeyi amaçlıyor. Proje kök dizinindeki CLAUDE.md ve auto memory, build komutlarını, proje spesifikasyonlarını ve hata ayıklama deneyimlerini kısa vadeli diyaloglardan ayırmak ve oturum başlangıcında yeniden yüklemek için kullanılıyor. Ancak Anthropic, bu memory'lerin hâlâ context olduğunu ve zorunlu yapılandırma olmadığını açıkça belirtiyor.

Bu fark çok önemlidir. "Buraya doğrudan veritabanına erişilemez" ifadesi yalnızca bellekte yazılırsa, hâlâ modelin anlayıp uygulaması gereken bir doğal dil cümlesidir. Aynı kural, bağımlılık lint, tip kısıtlaması veya CI kontrolü olarak yazılırsa, kolayca atlanamayan bir yazılım sabiti haline gelir.

Alt ajant, başka bir konuyu çözer: çalışma setini izole etmek. Bağımsız bir ajantın deposunu taramasına veya uzun günlük dosyaları analiz etmesine ve sıkıştırılmış sonucu ana ajanta geri göndermesine izin vermek, orijinal gürültünün ana iş parçacığına girmesini önler. Claude Code, alt ajantların kullanım amaçlarından biri olarak bağlam izolasyonunu sunar.

Bu maliyet de ilginç: Ana Agent, daha temiz bir durum elde etti ancak bazı orijinal kanıtları kaybetti; birden fazla Agent aynı anda çalıştığında, kendi bağlamlarını oluşturur. Bu nedenle compaction, memory ve sub-agent birlikte incelendiğinde, aslında Agent çağının bir bellek hiyerarşisine çok benzer:

Mevcut bağlam, maliyetli bir çalışma belleğidir; compaction, sıkıştırmadan sorumludur, memory oturumlar arası durumu korur, sub-agent ise ayrı bir adres uzayıyla gürültüyü izole eder. Sorun, "bağlam yeterince büyük mü?" yerine başka bir seviyeye geçti:

Hangi durumların yüksek kalitede saklanması gerektiği, hangi durumların yalnızca özetinin bırakılması gerektiği sorusu, sonraki kod kalitesini doğrudan etkileyecektir.

Önceki yürütme yapısını anladıktan sonra, Claude Code'un haftalık kotasına bakıldığında, platformun Agent'ları "mesaj sayısı" ile ölçmeye devam etmesi zorlaşacaktır, çünkü bir mesajın sabit bir anlamı kalmamıştır.

Değişken adını değiştirmek bir istek, tüm kimlik doğrulama modülünü yeniden yapılandırmak da bir istek. İlk durum birkaç adımda bitebilir, ikincisi ise onlarca döngü çalışabilir, onlarca dosya okuyabilir ve birden fazla Agent’i başlatabilir. Aynı bir istek olsa bile, arka planda gerekli kaynak talepleri tamamen farklı boyutlarda olabilir.

Claude Code, kaydırma sınırları ve haftalık kota ile paketlenmiştir; Codex, artık giriş token, önbelleğe alınmış giriş token ve çıkış token bazında kredileri hesaplamaktadır; Cursor'un paketleri, Agent için farklı kullanım havuzları sunar, üçüncü taraf modellerin tüketimi, model API fiyatlarından etkilenir.

Üç ürünün arayüz dilleri farklıdır, ancak temelde çözülmesi gereken sorular oldukça yakındır: Çalışma yolunu başlangıçta belirleyemeyen bir akıllı program için nasıl bir çıkarım kaynağı atanır? Bir Coding Agent, görev başlangıcında ne kadar süre çalışacağını belirlemek zordur.

Model, kök nedeni hızlıca bulabilir veya ardışık birkaç yanlış varsayımda bulunabilir; bir testte geçebilir veya uzun bir hata ayıklama döngüsüne girebilir; yalnızca bir Agent yeterli olabilir veya birden fazla alt-agent'e ayrılabilir.

Geleneksel API'ler, bir isteğin kaynak dalgalanmasını belirli bir sınırla kontrol edebildiği için istek bazlı ücretlendirme yapmayı sever. Agent, bu kararlılığı dağıttı. Bu nedenle burada Token biraz CPU süresi hissi veriyor.

Bu benzetme eşitlik olarak çizilemez. Farklı modeller, aynı sayıda Token’i işlemek için farklı hesaplama maliyetlerine sahiptir; input, önbelleğe alınmış input ve output’un da farklı maliyetleri vardır. Ancak geliştirici tarafında bakıldığında, görevin devam etmesi için ne kadar hesaplama kaynağı tükettiğini tanımlama işlevleri giderek daha benzer hale gelmektedir.

Anthropic, bu yıl Claude Code kullanım limitini artırırken, kredilerdeki artışı ve artırılan hesaplama kapasitesini doğrudan ilişkilendirdi. Bu, ilginç bir endikatör değişikliğine yol açacaktır. Daha önce Coding Agent’ları değerlendirirken, “aynı soruda kim bir seferde daha iyi yazıyor” karşılaştırması yapmak kolaydı. Bundan sonra daha anlamlı olabilecek şey: aynı mühendislik durumu değişikliğini tamamlamak için kim daha az etkili hesaplama kaynakları tüketiyor?

Bir Agent, dosyaları tekrar açıp, testleri yeniden çalıştırıp, kaybedilen bağlamı tekrar geri yüklemek için büyük miktarda Token harcarsa, bu Token'lar karşılığında mühendislik ilerlemesi sağlanmaz.

Bu verimsiz durum geri yükleme, tam olarak teknik borçla alt katmanda karşılaşır.

Burada bir Coding Agent tarafından yönetilen bir yazılım, aynı anda gelişen iki duruma soyutlanabilir. Birisi kod durumu R_t. Dosyalar, türler, arayüzler, testler, Git commit'leri tümü bu katmana aittir. Agent'ın 20. adımda eklediği bir retry satırı silinmediği sürece, 100. adımda dosya açıldığında hâlâ tamamen mevcuttur. Kod, geçmiş değişiklikleri çok yüksek bir doğrulukla korur.

Diğer biri tasarım durumudur M_t. Burada neden retry gerekiyor, neden bu önbellek yalnızca serviste tutulmalı, neden bu durumun iki sahibi olamaz, neden görünüşte gereksiz gibi görünen bu kontrol şu anda silinemez—bu bilgiler tasarım neden-sonuç ilişkisine aittir.

M_t Git gibi doğal olarak kayıp olmayan bir depolama yoktur. Bu, diyaloglarda, akıl yürütmede, araç dönüşlerinde, bellekte, kural dosyalarında ve sıkıştırma özetinde dağılmıştır. Görev ilerledikçe bazı kısımlar temizlenir, bazıları özetlenir, bazıları yeniden aranmalıdır.

Bu nedenle, sonuçların yüksek doğrulukta birikmesiyle birlikte, bu sonuçların oluşturulmasındaki neden-sonuç ilişkilerinin sürekli olarak alt örnekleme alınması gibi kritik bir asimetri oluşur. Bu, sadece “Ajanın şeyleri unuttuğunu” söylemekten çok daha ciddidir.

Bir paralellik sorununda, Agent analiz ettikten sonra bir kuyruğa eklendi. O anda elinde tam sonuç olarak şuydu: yalnızca A yazma yolu rekabet içeriyordu, bu nedenle kuyruk yalnızca A'yı kapsayabilirdi; B yazma yolu düşük gecikme gerektiriyordu ve bu kuyruğa giremezdi.

Kod, queue'yu tam olarak kaydetti. Uzun süre çalıştırıldıktan sonra, tasarım durumu sadece "burada queue ile race condition çözülür" haline gelebilir.

Daha sonra B de rastgele bir hata ortaya çıktı. Agent, kodu tekrar okuduğunda, B'yi doğal olarak mevcut kuyruğa ekledi.

Daha sonra gecikme arttı, bu yüzden bypass eklendi. Bypass, ara sıra durum tutarsızlığına neden oldu, bu yüzden dışarıda retry eklendi. Buraya kadar yapılan her değişiklik kesinlikle saçma değildi. Her bir düzeltme, o anki yerel duruma göre hatta oldukça mantıklı görünebilirdi. Ancak kod, “net bir eşzamanlı model”den, queue, bypass ve retry’nin birbirini tamamladığı bir yapıya dönüşmüştü.

AI kod çöpü muhtemelen tam olarak böyle oluşur. Modelin aniden bir çöp yazmasıyla değil, kısmen doğru olanların birikmesi ve genel modelin yavaşça kaybolmasıyla ortaya çıkabilir.

Geleneksel yazılımlarda bu tür sorunlar genellikle personel devralmalarıyle yavaşça oluşur. Orijinal yazar ayrıldığında, yeni geliştiriciler eski kodu görür ama neden var olduğunu bilmez ve bunun dışına uyumluluk mantığı ekler.

Coding Agent, "personel devir" ifadesini "bağlam devri" olarak çevirdi. 20. ve 100. adımlar hâlâ aynı Claude Code oturumu gibi görünüyor, ancak elde ettikleri tasarım durumu artık tamamen aynı değil. Bilgi açısından, bu, sürekli küçülen bir devir belgesiyle aynı deposunu sürdüren iki mühendis gibi.

Testler yalnızca bunların bir kısmını çözebilir. Testler, davranışları korumada yeteneklidir: arayüzlerin ne döndürmesi gerektiği, belirli bir girdinin çökmemesi, geçmiş hataların tekrar ortaya çıkmaması. Ancak birçok mimari kısıtlama, doğal olarak girdi-çıktı olarak ortaya çıkmaz.

Durumun yalnızca bir sahibi olabilir, alan katmanı UI'ye ters bağımlılık oluşturamaz, belirli bir paket doğrudan veritabanına bağlanamaz, yazma işlemleri tekil işlem sınırları üzerinden yapılmalıdır; bu kısıtlamalar sadece belgelerde veya Agent belleğinde varsa, yerel onarım sırasında kolayca gözden kaçırılabilir.

Sonuç olarak, testler hâlâ yeşilken kodun açıklanması giderek daha zor hale gelen karmaşık bir mühendislik durumu ortaya çıkar. Daha da tehlikeli olan, burada geri besleme döngüleri bulunmasıdır.

Mimari karışmaya başlıyor, Agent'in bir sonraki anlama işlevi daha fazla dosya okumayı gerektiriyor; bağımlılıklar ne kadar karmaşıksa, çalışma seti o kadar büyük oluyor; çalışma seti ne kadar ağırsa, sistem o kadar çok temizleme ve sıkıştırma gerektiriyor; tasarım neden-sonuç ilişkisi ne kadar ince tutulursa, sonraki değişiklikler o kadar çok mevcut kod ve yerel testlere bağımlı oluyor.

Bu nedenle kod karmaşıklığı arttıkça Token maliyetleri yükseliyor ve Token baskısı, daha kısa durum tutma ve daha yerel düzeltmeler yapmayı teşvik ediyor. Bu, Agent kodlamada “ne kadar iterasyon yaparsanız, o kadar çok sorun çıkar” arka planında dikkat edilmesi gereken mekanizmadır.

Bu, tek bir model yeteneği sorunu değil, kod durumu ve tasarım durumu arasındaki doğruluk tutarsızlığı olan bir sistem sorunudur.

Coding Agent, giderek daha uzun süre harekete geçebiliyor, ancak "saatlerce çalışabilme" kendisi mutlaka iyi bir performans göstergesi değildir.

Bir Agent 3 saat çalıştıktan sonra, 2 saat önce değiştirdiği dosyayı yeniden okumalı, soyut bir şeyin neden var olduğunu yeniden çıkarmalı ve daha önce zaten çalıştırılmış bir testi tekrar çalıştırmalıysa, bu 3 saat içindeki hesaplamanın önemli bir kısmı durum yeniden başlatmaya harcanmıştır.

Sonraki soru şu hale gelecek: Bir Agent, 50 adım ve 100 adım geçtikten sonra, sonraki kararlar için ne kadar neden-sonuç bilgisini koruyabiliyor.

Buna durum doğruluk oranı diyebilirsiniz.

Çünkü bu, context'e kaç Token sığdırılabileceğini değil, araç çağrısı, sıkıştırma, arası session ve bellek araması sonrası hangi kritik tasarım bilgilerinin hala kullanılabilir formda kaldığını ölçer. Bu, Agent'in uzun vadeli belleğinin yalnızca daha uzun bir contexte dayanamayacağını da anlamına gelir.

Bazı bilgiler, proje oluşturma yöntemleri ve geliştirme alışkanlıkları gibi, bellekte tutulmalıdır; bazı kararlar yapılandırılmış ADR'lere veya kod endeksine alınmalıdır; sistem mimari sınırlarını ihlal ederse, bunlar doğrudan türlerde, testlerde, lint kurallarında, bağımlılık kurallarında ve CI'da yazılmalıdır.

Bir kural, yazılım tarafından uygulanabilir bir kısıtlamaya dönüştürüldüğünde, Agent'in onu "hatırlamasına" gerek yoktur. Bir sonraki turda Agent, bir diyalogu unutabilir, ancak derleyiciyi ve testleri kolayca aşamaz.

Düşük doğruluk oranına sahipse, Agent ne kadar uzun çalışırsa, sistemde o kadar çok mayın yerleştirir.

Bu, Coding Agent'in "kod yazabilme" den "yazılımı uzun vadeli olarak koruyabilme" aşamasına geçmek için aşması gereken bir sınır olabilir: tasarım bilgilerini olasılıksal dil hafızasından, aranabilir, doğrulanabilir ve yürütülebilir yazılım durumlarına yavaşça taşıma.

Aksi takdirde, kendiliğinden çalıştırma süresi ne kadar uzun olursa, çok tuhaf bir senaryo ortaya çıkar. Agent, kod yazma hızı giderek artar ve projeler hızla değişir, ancak belirli aralıklarla, önceki dönemde bırakılmış dünyayı yeniden anlamak zorunda kalır.

Geleneksel miras kodunda sıkça rastlanan bir ifade: "Bu kısmı dokunmayın, neden patladığını bilmiyorum."

Yapay zeka miras kodu daha çılgın olabilir: Kod gerçekten Agent tarafından yazılmıştır, ancak sonraki Agent'lar önceki Agent'ın bunu neden böyle yazdığını bilmiyor.