- Otonom kodlama ajanı değerlendirmeleri çoğunlukla sabit bir kod tabanında görev başarı oranına bakıyordu; bu çalışma ise kodun kendi temizliğinin keşif ve düzeltme maliyetini değiştirip değiştirmediğini ayrıştırarak ölçüyor
- Mimari, bağımlılıklar ve dış davranış aynı kalırken yalnızca SonarQube kural ihlalleri ve bilişsel karmaşıklığı farklı olan 6 minimal çift depo ve gizli test tabanlı 33 görev oluşturuldu
- Claude Code ve Claude Sonnet 4.6 ile her görev depo çiftinin iki tarafında 10’ar kez çalıştırılarak toplam 660 deney yapıldı; ajan hangi taraftaki kod üzerinde çalıştığını bilmiyordu
- Kod temizliği geçme oranını değiştirmedi, ancak daha temiz kodda token eşdeğeri metrikler %7-8 azaldı ve dosya yeniden ziyaretleri %34 düştü
- Yalnızca model veya prompt değil, kod tabanının durumu da ajanın hesaplama maliyetini ve keşif verimliliğini belirleyen pratik bir değişken olarak önemini koruyor
Araştırma sorusu ve problem tanımı
- Otonom kodlama ajanları hızla yaygınlaşıyor
- 2026’da 128.018 GitHub projesi üzerinde yapılan bir incelemede, ilk pratik ajanın yayımlanmasının üzerinden bir yıl bile geçmeden projelerin %22-29’unda ajan faaliyeti izleri bulundu
- Ajan çalıştırma maliyeti de az değil
- SWE-bench Verified’da tek bir görev, frontier LLM’ler için ortalama yaklaşık 4 milyon token kullanıyor
- Toplam kullanımda token’ların büyük kısmını giriş token’ları oluşturuyor
- Mevcut değerlendirmeler SWE-bench gibi benchmark’larda görevin çözülüp çözülmediğine odaklanıyordu; son araştırmalar geçme oranının yanında kaynak kullanımını da ölçmeye başladı
- Yaygın karşılaştırma yöntemi, kod tabanını sabit tutup ajanı veya scaffolding’i değiştirmekti
- Bu çalışma ise tersine, ajanı ve görevi sabit tutup yalnızca kod tabanının temizliğini değiştirerek karşılaştırıyor
Kod temizliği ve minimal çiftlerin oluşturulması
- Kod temizliği, bakımı yapılabilir kodla ilişkili özelliklerin bir kümesi olarak ele alınıyor
- Okunabilirlik
- Düşük bilişsel karmaşıklık
- İyi ayrılmış helper’lar
- Açık adlandırma
- Az miktarda ölü kod, yinelenen mantık ve tesadüfi bağlanma
- Çalışma, kod temizliğini katı bir biçimsel tanıma sabitlemiyor; bunun yerine SonarQube statik analiz kural ihlali sayısını gevşek bir vekil metrik olarak kullanıyor
- Kullanılan araç SonarQube Cloud Enterprise Edition
- Kural seti “default quality gate”
- Minimal çift depolar, yalnızca iç temizlik açısından farklı olacak ve aşağıdaki koşulları eşleştirecek şekilde oluşturuluyor
- Aynı dil ve framework
- Aynı bağımlılıklar
- Aynı testler veya eşdeğer test kapsamı
- Aynı dış davranış
- Davranış eşdeğerliği, aynı girdilerde dışarıdan gözlemlenebilir çıktıların ve durum geçişlerinin aynı olması olarak kabul ediliyor
- Pratik doğrulama, aynı test paketini aynı kapsamla geçmek ya da refactoring gibi gözlemlenemeyen değişiklikleri telafi eden test çiftlerini geçmek yoluyla yapılıyor
Minimal çift üretim hattı: Slopify ve Vibeclean
- Minimal çiftler iki yönde üretiliyor
- Temiz depoyu daha dağınık hale getiren Slopify
- Dağınık depoyu temizleyen Vibeclean
-
Slopify
- Temiz kod tabanını, kod incelemesi veya linting olmadan büyümüş gibi görünen bir sürüme dönüştürüyor
- Bilerek bozulmuş kod değil, statik analiz olmasaydı ortaya çıkabilecek alternatif tarih sürümünü hedefliyor
- Üç aşamanın her biri yeni bir ajan tarafından yürütülüyor
- Build: Depoyu build eder, testlerin geçmesini sağlar ve komutları
build instructions.mdiçine sabitler - Explore: Depoyu tarar ve temizleme hedefi olan her dizin için
summary.mdyazar - Transform: Belirlenen dizinlere SonarQube kural ihlalleri ekler ve her geçişten sonra testleri yeniden çalıştırarak bozulan değişiklikleri reddeder
- Build: Depoyu build eder, testlerin geçmesini sağlar ve komutları
- Helper’ları inline etme, yol bazında mantık çoğaltma, ölü kod ekleme ve bazı modülleri tek dosyada birleştirme gibi yöntemlerle bilişsel karmaşıklığı artırır
-
Vibeclean
- Doğal olarak çok sayıda kural ihlali içeren kod tabanını, dış davranışı koruyarak temizler
- Ajanın görev listesi analiz aracının yakaladığı issue listesidir; her issue bir kod aralığına bağlanır
- Değişiklik kapsamı analiz aracının işaretlediği sorunlarla sınırlıdır; tümden yeniden tasarım hedeflenmez
- İki aşamada çalışır
- Build: Build ve test komutlarını doğrular ve
build instructions.mdiçine sabitler - Clean: Modül bazında analiz aracı kural ihlallerini mekanik olarak temizler ve her modül işleminden sonra testlerle davranış eşdeğerliğini doğrular
- Build: Build ve test komutlarını doğrular ve
- Yinelenen string literal’ları kaldırma, yorum satırına alınmış kodu silme, eski koleksiyon idiom’larını değiştirme ve ölü dalları kaldırma gibi işlemler yapar
- Analiz aracının gerçekten devasa yapıları işaretlediği durumlarda 200 satırdan uzun dispatch switch’i adlandırılmış helper’larla değiştirir veya 2.800 satırlık bir sınıftan kalıcılık helper’larını çıkarır
- Ancak çıkarma işlemi karmaşıklığı ortadan kaldırmak yerine daha fazla metoda yeniden dağıtabilir ve en büyük devasa yapıların bazıları
wontfixolarak kalır
Benchmark depoları ve görev tasarımı
- Benchmark, Harbor framework v0.4.0 üzerine kuruludur
- Toplam 6 minimal çift depo kullanılmıştır
- 3’ü Java ağırlıklı, 3’ü Python ağırlıklı
- Bazı depolar az miktarda başka dillerde kod içerir
- 3 açık kaynak depo ve 3 özel SonarSource kod tabanından oluşur
- Özel çiftler, değerlendirilen LLM’nin açık depolar üzerinden eğitilmiş olma ihtimaline karşı ezberlemeyi önleme işlevi görür
- Depo bazında temiz ve dağınık tarafların temel sayıları şöyledir
sonar-sca*: issue 94 / 2.825, issue yoğunluğu 0,73 / 20,66, bilişsel karmaşıklık yoğunluğu 30,6 / 56,5sonar-caas-poc*: issue 16 / 855, issue yoğunluğu 0,61 / 27,16, bilişsel karmaşıklık yoğunluğu 179,8 / 218,9sonarcloud-codedatalake*: issue 199 / 1.319, issue yoğunluğu 4,36 / 34,39, bilişsel karmaşıklık yoğunluğu 34,0 / 216,5commons-bcel: issue 694 / 2.711, issue yoğunluğu 12,60 / 49,46, bilişsel karmaşıklık yoğunluğu 102,8 / 108,3genie: issue 152 / 1.262, issue yoğunluğu 1,28 / 10,81, bilişsel karmaşıklık yoğunluğu 22,2 / 23,5ckan: issue 1.006 / 3.632, issue yoğunluğu 7,54 / 27,50, bilişsel karmaşıklık yoğunluğu 69,3 / 76,5
- Görev tasarımı üç kurala uyar
- Hotspot üzerinden geçiş: Görevler, çiftin iki tarafında issue yoğunluğu ve bilişsel karmaşıklık farkı yüksek olan kod bölgelerinden geçecek şekilde yerleştirilir
- Dışarıdan gözlemlenebilir açıklama: Yalnızca giriş-çıkış ve örnek senaryolar verilir; dosya, fonksiyon veya iç yapı adları verilmez
- Açık yüzey testleri: Gizli testler, CLI, HTTP route’ları, kütüphane/API gibi uygulamanın çağırana sunduğu arayüzler üzerinden çalıştırılır
- Görev üretimi ajanlar ve insanlar arasında paylaştırılmıştır
- Ajan, temiz ve dağınık varyantları karşılaştırarak bir fark haritası çıkarır
- Başka bir ajan görev özetlerini ve test edilebilirliği yazar
- İnsan, bunlar arasından makul ve ilginç özetleri seçer, düzenler ve küratörlüğünü yapar
- Üçüncü bir ajan gerçek talimatları, gizli açık yüzey testlerini ve dahili referans uygulamayı oluşturur
- Referans uygulama iki depo tarafında da gizli testleri geçmelidir
- Değişiklik öncesi depo gizli testleri geçmemelidir
- İki yinelemeden sonra da koşulları karşılamayan görevler insan tarafından yeniden yazılır veya kaldırılır
- Nihai görev sayısı 33 olup üç track’e ayrılır
- 13 bilişsel hotspot görevi: Tek bir metodun veya tek bir sınıfın yüksek yoğunluklu karmaşıklık bölgesinden geçer
- 14 çok modüllü görev: İki veya daha fazla modülü aşan değişiklik gerektirir
- 6 kalibrasyon görevi: İki taraf da aynı bölgelerde basit görevler yaparak temizlikten bağımsız değişim olup olmadığını kontrol eder
Deney kurulumu ve ölçüm metrikleri
- Tüm deneyler, varsayılan araç setini kullanan Claude Code ile yürütülmüştür
- Raporlanan sayılar Claude Sonnet 4.6 çalıştırmalarından gelir
- Claude Haiku 4.5 de aynı görev seti üzerinde gözden geçirilmiştir; ancak geçme oranı çok düşük olduğundan footprint farklarını net okumak zorlaştığı için ana sonuçlardan çıkarılmıştır
- Ajan yalnızca görev açıklamasını okur
- Kod temizliği hakkında ek priming almaz
- Minimal çiftin hangi tarafında çalıştığını bilmez
- Her görev çiftin iki tarafında 10’ar kez çalıştırılır
- Toplam deney sayısı 33 × 2 × 10 = 660
- Her çalıştırma container’laştırılmış bir sandbox’ta yapılır
- CPU, bellek, depolama ve duvar saati süresi sınırlandırılır
- Açık paket registry’lerine erişilebilir
- Temel imaj, depo bazlı toolchain, build cache ve servisleri içerir
- Çift içinde yalnızca
/appkonumuna mount edilen kaynak ağacı farklıdır
- Kaydedilen metrik sayısı 10’dur
- Geçme oranı: Nihai durumda gizli testlerin geçtiği oran
- Giriş token’ları: Modelin tüm turn’lerde okuduğu token sayısı; çoğunu dosya içerikleri ve önceki konuşmanın yeniden gönderilmesi oluşturur
- Çıkış token’ları: Modelin ve alt ajanların ürettiği tüm çıktılar; düz yazı, kod, akıl yürütme izleri ve araç çağrılarını içerir
- Akıl yürütme karakter sayısı: Anthropic API akıl yürütme token’larını ayrı göstermediği için akıl yürütme içerik bloklarındaki düz metin karakter sayılır
- Konuşma turn sayısı: Ajan-araç alışverişlerinin toplam sayısı
- İlk düzenleme öncesi turn sayısı: İlk dosya değişikliğine kadar geçen turn sayısı
- İlk düzenleme öncesi karakter sayısı: Aynı aralıktaki konuşma karakter sayısı
- Okunan dosya sayısı: Çalıştırma sırasında açılan benzersiz dosya sayısı
- Dosya yeniden ziyaretleri: Daha önce okunup değiştirilen bir dosyanın tekrar okunma sayısı
- Değiştirilen satır sayısı: Nihai patch’in değiştirdiği kaynak satırı sayısı
- Dosya yeniden ziyaretleri
okuma → düzenleme → başka çalışma olasılığı → yeniden okumagibi bir akışta ortaya çıkar- Çalışmada bu, geniş keşiften ziyade önceki düzenlemeye yönelik belirsizlik sinyali olarak yorumlanır
- Ajan footprint metrikleri aynı görevi sabit sıcaklıkta tekrarlarken bile büyük ölçüde değişebildiğinden aykırı değer filtresi uygulanır
- Her
(görev, taraf)kombinasyonunda 10 tekrarın medyanından %50’den fazla sapan çalıştırmalar ortalamadan önce kaldırılır - Pratikte tüm çalıştırmaların %9,7’si kaldırılmıştır
- Her
- Veri kümesi düzeyindeki sayılar 33 görev üzerinde mikro ortalama alınarak hesaplanır
- Her metrik için görev bazında temiz taraf ortalaması ile dağınık taraf ortalaması toplanır ve oran farkı hesaplanır
- Geçme oranı ise istisna olarak temiz taraf ile dağınık taraf arasındaki mutlak yüzde puan farkı şeklinde raporlanır
Sonuçlar: Başarı oranından çok keşif maliyetine etki ediyor
- Kod temizliği ajanın geçme oranında anlamlı bir değişim yaratmıyor
- Daha temiz kodda token eşdeğeri metrikler %7-8 azalıyor
- Dosya yeniden ziyaretleri %34 azalıyor; bu da temiz kodun aynı görevde bile geriye dönüp yeniden okuma maliyetini düşürebileceğini gösteriyor
- Dolayısıyla kod temizliği, model seçimi, harness ve prompt ile birlikte ajan çalıştırma maliyetini belirleyen ayrı bir eksen olarak görülebilir
1 yorum
Hacker News yorumları
Araştırmaya değer ilginç bir soru, ancak deney tasarımına karşı oldukça şüpheliyim
Deneyde Opus 4.6 ile “kalitesi düşürülmüş” veya “düzenlenmiş” kod tabanları sentezlenip karşılaştırma için kullanılmış
Daha da kötüsü, uygulamanın testlerini bozup bozmadıklarını kontrol etmemiş olmaları
“Geçiş oranı, her görev için yazdığımız gizli test kriterlerine göre ajanların ulaştığı son durumu puanlar. Depoda zaten bulunan ilgisiz testlerin ajan tarafından bozulup bozulmadığını kontrol etmiyoruz; temiz taraftaki ve dağınık taraftaki çözümler gizli testleri geçse bile, puanlanmayan testlerde farklılık gösterebilir”
Nihai çıktının kalitesi kontrol edilmiyorsa, token tüketimi ile ilgili sonuçlar neredeyse anlamsız görünüyor
Adil bir karşılaştırma için her çiftteki iki projede de çalışan tek bir test paketi yazılması gerekirdi
Bunun çalışmayı iyi yaptığı anlamına gelmez, ama test geçmenin ajanın etkililiğiyle mutlaka ilişkili olmaması nedeniyle böyle bir kararı anlayabiliyorum
İşlevsel olarak kabul edilebilir görünen ama görevi tamamlamak için daha fazla token maliyeti gerektiren bir durumu göstermiş oluyor
AI yorgunluğu çoktan sıkıcı hale gelmişti, şimdi ise düpedüz acı verici
Benim deneyimime göre kod tabanında ölü kod, yinelenen kod, erişilemeyen alternatif yollar, sızdıran soyutlamalar ve tam oturmamış tasarım kalıpları her yere dağılmış olduğunda ajan performansı ile, veri akışının net olduğu ve kapsülleme ile yapının temiz olduğu durumdaki performans arasında ciddi fark var
Kötü kodda bütün en ileri modellerin birden çok kod incelemesi, kalite kontrolü ve düzeltme turundan geçmesi gerektiğini; iyi kodda ise 1-2 denemede doğrudan doğru sonuca ulaştıklarını gördüm
LLM'e bu maddeleri kontrol eden bir script çalıştırabilir, aynı script'i pre-commit hook olarak zorunlu da kılabilirsiniz
Üzerinde çalıştığım tüm kod tabanlarına bu ayarları titizlikle koymak, ajan tarzı kodlamada en büyük etkiyi yarattı
Kullandığım çeşitli linter'ları daha ayrıntılı anlattığım yazı burada: https://www.balajeerc.info/Use-Deterministic-Guardrails-for-...
Ajanların da devasa bir karmaşa halindeki kod tabanına kıyasla temiz bir kod tabanında daha iyi çalışmasının kaçınılmaz olduğunu düşünüyorum
Tıpkı iyi hazırlanmış bir şartnameye ve belgelere erişimleri olduğunda daha iyi performans göstermeleri gibi
Bir noktadan sonra o korkunç kalıplar bana da bulaşmaya başlıyor
Burada soruyu yanıtlamaya çalışan bir makale var ve anekdotsal tanıklıklar yalnızca okuyucuyu önyargılı hale getiriyor; konu hakkında nesnel sonuca varmaya katkı sağlamıyor
En faydalı tartışma, herkesin makaleyi okuyup metodolojiyi ya da sonuçları eleştirmesi olurdu
Yine de LLM'lerin pek iyi olmadığından şikâyet eden kişilerin genelde dağınık kod tabanlarına sahip tipler gibi göründüğünü düşünüyorum
Bende işe yaradığını gördüğüm bir yöntem, Python için şöyle bir refaktöring talimatı vermek
“Python kodunu daha Pythonik olacak şekilde refaktör et. Örneğin sınıfları ve singleton'ları azalt; özellikle hız artışı sağlıyorsa bunu yap. Python kodu, benchmark performans gerilemesi olmadan popüler açık kaynak Python paketlerinde beklenen kod organizasyonu standartlarını mutlaka karşılamalıdır”
Rust kodu için şu varyasyonu kullandım
“
/srciçindeki Rust kod tabanı, 1.000 satırı aşan birden fazla dosya nedeniyle şişti. Benchmark performans gerilemesi olmadan, popüler açık kaynak Rust kodlarında beklenen kod organizasyonu standartlarına uyacak şekilde Rust kod tabanını refaktör et”Bu tür prompt'lar sanki a) kodu mantıksal olarak yeniden düzenliyor ve b) dosya adları ilgili kod konumu hakkında anlamsal ipuçları verdiği için ajan performansını da artırıyor
5.000 satırlık şişkin bir dosyada ajan, ilgili kodu bulmak için birden fazla parçayı okumak zorunda kaldığından verimsiz oluyor
Benchmark performansı da genelde refaktörden sonra iyileşiyor; özellikle derlenen Rust'ta bu muhtemelen tesadüf ama şikâyet edecek değilim
Temelde ajan tarzı kodlama araçları kod silme konusunda isteksiz olma eğiliminde. Silmelerini söyleseniz bile, eski kodu tutmak ya da o kodun çağrılabilir kalması için karmaşıklık eklemek adına her yolu deniyorlar
Sadece prototipleme yapıyorsanız bu gerçekten can sıkıcı; sonuçta çok fazla ölü kod birikiyor ve daha sonra özellik eklemeye çalıştığınızda kafa karışıklığı yaratıyor
Bunu bildiğinizde, doğrudan eski yapıları kaldırmalarını istemeniz yeterli
Kod tabanını temiz tutmak, AI'ı doğru şeyi yapmaya teşvik ediyor. Çok sayıda test varsa yeni özellikler eklerken onları da artırıyor; dokümantasyon varsa ayrıca söylemeden onu da güncelliyor
Kod harness'leri geliştikçe bunlar giderek daha fazla yerleşik hale gelecek ve prompt tecrübesi az olan kişilerin de makul sonuçlar alması kolaylaşacak
Genelde önce inceleme yapıp bir gözden geçirme maddeleri listesi oluşturmasını istiyorum; sonra her maddeyi birlikte değerlendirip ben evet/hayır kararı veriyor ya da ek değişiklik öneriyorum
Özellikle tüm sisteme yönelik dikkatli uçtan uca testler yoksa
Zaten kod stili kurallarını CLAUDE.md içine koymuş durumdayım
“Dağınık depoları temizleyen bir ajan pipeline’ı” yaklaşımı korkunç görünüyor ve tek başına tüm araştırmayı geçersiz saymak için yeterli
Bu çalışmadaki minimum çiftlerin yarısı sanki bu şekilde oluşturulmuş gibi görünüyor
Yapay zekanın “temizlediği” bir deponun gerçekten iyi bir kod tabanını temsil ettiğini varsaymayı gerektiren hiçbir sonuca hiç güvenmem
Burada “temizlik”, ajana sadece daha iyi kod yazmasını söylemek değildi
Ona 50~100 adet statik analiz aracı kural ihlali listesi ve satır sayıları verildi, bunları kaldırması istendi
Ardından kural ihlallerinin çözülüp çözülmediği doğrulandı
Bu tür ihlalleri gidermek için kodu LLM ile yeniden yazmak epey kabul görmüş bir pratik
Sonar’ın mevcut tek atımlık LLM tabanlı yaklaşımı [1] 1 yıldan uzun süredir kullanımda ve daha yeni ajan tarzı yaklaşımı [2] da aynı işi oldukça iyi yapıyor
[1] https://www.sonarsource.com/solutions/ai/ai-codefix/
[2] https://www.sonarsource.com/products/sonarqube/remediation-a...
Bence elbette etkiler
Hiçbir model gerçek bir kod tabanının tamamını bağlama sığdıramaz; insan gibi kodu taramak zorundadır
Arama yapar ve dosya okur
Dosyalar beklenen yerdeyse ve modelin ya da insanın ilk aramada kullanacağı isimlerle adlandırılmışsa ilk denemede bulunur; aksi halde daha derin arama ve birden çok deneme gerekir
Tüm yolları görüp, zaten bakılan alanları atlayarak sıradaki yola geçebilir
Geliştiricilerin çalışma şekline oldukça benziyor
NJIT’te yürüyen benzer çalışmalarda da benzer sonuçlar gördük. Biz buna bağlamsal kalite bulaşması diyoruz
Buradaki ilginç kısım, sektörde yaygın olan gerçek durumlar. Kalitesi karışık kod tabanları, legacy kod kalıplarıyla daha yeni “iyi” kalıpların karışıp ajanın teamülleri şaşırdığı kod tabanları gibi
Minimum çift tasarımı aslında güçlü yönlerden biri. Çünkü depoları birbiriyle karşılaştırmak yerine yapı, bağımlılıklar, testler gibi diğer etkenlerden temizliği ayırmaya çalışıyor
Yine de LLM tarafından üretilmiş “berbatlaştırılmış” kodun kullanılması biraz soru işareti yaratıyor; çünkü bu, mekanik ya da insan yönlendirmeli bir yöntem değil
En büyük eleştiri, başkalarının da doğru biçimde işaret ettiği gibi, tam test paketinin doğrulanmamış olması tercihi. “Davranışsal eşdeğerlik” iddiası ancak test ve kapsama kadar geçerli
Bu hipotezin ikna edici olmasının iki nedeni var. 1) LLM’ler kod tabanında gördüklerini taklit eder; yani çöp girerse çöp çıkar mantığına uyuyor 2) Son 1~2 yılda bu modelleri kullanan birçok mühendisin sezgisel olarak hissettikleriyle örtüşüyor
Greenfield, neredeyse her zaman yoğun ve karmaşık bir kod tabanına katılmaktan daha kolaydır; dağınıklık ise karmaşık entegrasyonlar ve legacy amaçlı sistem bakımı gibi yerlerde ortaya çıkar
Ajan kendi bıraktığı stub’lar ve WET code arasında yol bulmayı öğrense bile, insanların gerçekte neler olduğunu takip edemediği bir kod tabanını gerçekten ister miyiz?
Bu yüzden ben en azından kodun ne yaptığını kodla anlatmayı tercih ederim
İki küçük fonksiyonda ortak yardımcıya çıkarılabilecek mantık olsa bile, insan programcı bazen bu soyutlamanın dağınık olacağını ve ikisinden birini biraz değiştirmeye çalışınca kırılacağını bildiği için bunu yapmaz
Bunu sayısallaştırarak görmek ilginç
Temiz yapı, hem insanlar hem de ajanlar için bilişsel yükü azaltıyor gibi görünüyor; bu da isimlendirme ve modülerliğin sanılandan daha önemli olmasını açıklıyor
Nicelleştirmesi zor, ama tüm kod kalitesi metriklerinin eninde sonunda yakalamaya çalıştığı şey de bu
Bu ölçüte göre, kullanılan kod kalitesi metrikleri makulse, sonuç o kadar da şaşırtıcı değil
Kalite metriği kodlama ajanı bağlamında iyiyse, beklenecek sonuç tam da budur
Çok sayıda token kod keşfine harcanıyor. Kodun bulunması ya da çağrı noktalarının izlenmesi ve işi yapmaya yetecek kadar bağlam oluşturulması buna dahil
Ajana bir tür LSP erişimi verip, monorepo ise AGENTS.md gibi dosyalarla hiyerarşik yönlendirme sağlarsanız, keşfe giden token tüketimini büyük ölçüde azaltabilirsiniz
Ancak dağınık bir kod tabanında, her görevi çözmek için er ya da geç bir tür keşif gerekir
Ve bu keşif yalnızca token tüketimi değildir. Her adımda LLM gecikmesi, prefill, decoding, çıktıda ajanın parse etmesi, araç çağrısı, araç yanıtı ve yeniden LLM’e dönüşten oluşan gidiş-dönüş gecikmesi tekrarlanır
Bir kısmı paralel yapılabilir ama pratikte çoğu sıralıdır; bu yüzden iş ciddi biçimde yavaşlar
Ajanları verimli kullanmak için yerellik ve yapı kilit önemdedir. Bağlam penceresi her zaman sınırlıdır ve o pencere içindeki dikkat de tutarlı değildir
Benim deneyimime göre, mühendisi etkileyen her şey ajanı da etkiler
İyi soyutlamalar, uygun boyutta metotlar, iyi isimler, hizmet içinde ve hizmetler arasında ilkelere dayalı yapı, birim testleri; hepsi buna dahil
Bunlar tarihsel olarak mühendislerin işiydi ve başkalarının koda katkı yapmasını kolaylaştırmak içindi
Artık sadece başkalarının değil, diğer ajanların da koda katkı yapmasını kolaylaştırıyor