Writing

Turkish writing

AI Kodlama Ajanları Her Zaman Daha Fazla Bağlama İhtiyaç Duymaz. Bazen Bir Crib Gerekir.

Kodlama ajanlarına daha fazla bağlam vermek yerine, doğru repository emsalini göstermenin neden daha değerli olabileceği üzerine pratik bir argüman.

7 min readwritingtrAIKodlama AjanlarıRepository ContextYazılım Mühendisliği

Mevcut kod tabanları üzerinde AI kodlama ajanlarıyla çalışırken bir şey fark ettim.

Ajanın hangi uygulamayı emsal alması gerektiği konusunda ne kadar net olursam, ortaya çıkan çözüm kod tabanına o kadar iyi uyuyor.

Şunu söylemekle:

“Orders ekranına bu davranışı ekle.”

şunu söylemek arasında ciddi bir fark var:

“Buna benzer bir şeyi Payments ekranında yapmıştık. Önce oradaki uygulamaya bak, mantıklı olduğu yerlerde aynı yaklaşımı takip et.”

İki durumda da ajan gereksinimi anlıyor.

Ama ikinci prompt genellikle beni kullanılabilir sonuca çok daha hızlı götürüyor.

Bu referans olmadan bir ajan teknik olarak gayet makul, fakat o kod tabanına ait olmayan bir çözüm üretebilir. Zaten var olan bir soyutlama yerine yeni bir servis açabilir, mantığı yanlış katmana koyabilir, başka bir helper uydurabilir ya da uygulamanın daha önce çözdüğü bir problemi tekrar çözmeye çalışabilir.

Kod geçerli olabilir.

Mimari hâlâ yanlış olabilir.

Kodlama ajanlarını daha büyük işler için kullandıkça bu ayrım daha önemli hale geldi.

Ajan kod yazmayı bilir. Bizim nasıl kod yazdığımızı otomatik olarak bilmez.

Deneyimli bir geliştirici yerleşik bir ekibe katıldığında, ona her tasarım kararını sıfırdan anlatmayız.

Şöyle şeyler söyleriz:

“Customer Details tarafında bunu nasıl yaptığımıza bir bak.”

“Bu servis Payments entegrasyonuna benziyor.”

“Mevcut background job pattern’ını kullan.”

Bunlar inanılmaz derecede yoğun bilgi taşıyan cümlelerdir.

Deneyimli bir geliştirici referans verilen kodu sadece kopyalamaz. Oradan açıkça yazılmamış birçok şeyi çıkarır: mantığın nereye ait olduğunu, hangi soyutlamaların bilinçli seçildiğini, bağımlılıkların nasıl bağlandığını, hataların nasıl ele alındığını, neyin test edilmesi gerektiğini ve belki de en önemlisi, neyin icat edilmemesi gerektiğini.

Kodlama ajanlarının da aynı bilginin büyük kısmına ihtiyacı var.

Bu problemin arkasında araştırma da var. Repository seviyesinde kod üretimi, modelin yalnızca düzenlenen dosyaya değil, repository’nin başka yerlerindeki ilgili bilgiye de erişebildiğinde daha iyi sonuç veriyor. O zaman ilginç soru sadece ajana ne kadar bağlam verebildiğimiz değil.

Hangi bağlamın vermeye değer olduğu.

Çünkü daha fazla bağlam, her zaman daha iyi bağlam değildir.

Devasa bir talimat dosyası token tüketebilir ve gerçekten işe yarayan bilgiyi yüzlerce alakasız kuralın arasına gömebilir. OpenAI, agent-first bir kod tabanı oluştururken tam olarak bu problemle karşılaştığını anlatıyor: AGENTS.md dosyasını dev bir el kitabına çevirmek yerine, sonunda onu repository içindeki daha derin doğruluk kaynaklarına işaret eden bir harita gibi kullanmaya başlamışlar.

Bu bana çok daha eski bir arama problemini düşündürdü.

Enigma, Bombe ve crib

Çoğumuz Enigma ve Alan Turing hikayesinin genel hatlarını biliyoruz; bunu The Imitation Game gibi filmlerden öğrenmiş olsak bile.

Ama kodlama ajanları bağlamında bana ilginç gelen kısım Enigma’nın kendisi değil.

Crib, menu ve Bombe arasındaki ilişki.

Bombe’ye yalnızca şifreli bir mesaj verilip şöyle denmiyordu:

“Bunu çöz.”

Kod kırıcılar, şifreli mesajın içinde yer alması muhtemel bir açık metin parçası bulmaya çalışıyordu. Buna crib deniyordu.

Bazı mesajlarda tahmin edilebilir ifadeler vardı. Örneğin hava durumu raporlarında doğal olarak tekrar eden kelimeler ve kalıplar bulunuyordu. Makul bir crib bulunduğunda, tahmin edilen açık metin ile şifreli metin arasındaki ilişki Bombe için bir menu oluşturmakta kullanılabiliyordu.

Crib, Enigma ayarlarını içermiyordu.

Cevabın kendisi değildi.

Cevabın nerede olabileceğini sınırlıyordu.

Bombe daha sonra bu kısıtlarla uyumlu olası makine ayarlarını deneyip adayları bulabiliyordu. Bir Bombe “stop”u bile otomatik olarak doğru cevap kabul edilmiyordu; adayların hâlâ kontrol edilmesi gerekiyordu.

Kodlama ajanlarını düşündüğümde bana tanıdık gelen kısım bu.

Ajana şunu söylediğimde:

“Bu probleme yapısal olarak benzeyen bir şeyi burada çözmüştük.”

Ona yeni gereksinimin uygulamasını vermiyorum.

Ona bir crib veriyorum.

Teknik olarak mümkün olan her çözümü keşfetmek yerine, çok daha dar bir sorudan başlayabiliyor:

Bu kod tabanı buna benzer problemleri zaten nasıl çözüyor?

Bu, aramanın şeklini ciddi biçimde değiştiriyor.

Referans uygulama sadece bir örnek değildir

Bunu yalnızca few-shot prompting olarak tarif etmek cazip: modele bir örnek verirsin, model de ona benzeyen bir şey üretir.

Bence kod tabanı içinde olan şeyin bir kısmını bu açıklama kaçırıyor.

İyi bir referans uygulama mimari bilgi taşır.

Ajana, sistemi daha önce inşa eden mühendislerin aldığı kararlar hakkında bir şey söyler.

Diyelim ki ajandan permission handling eklemesini istiyorum.

Başka bağlam vermeden birçok çözüm makul görünebilir: route guard, middleware, component wrapper, hook, servis, API seviyesinde kontrol ya da yeni bir soyutlama.

Sonra bir cümle ekliyorum:

“Bu ekran Payments ile aynı permission modelini kullanıyor. Önce Payments uygulamasına bak.”

Bir anda arama alanının büyük kısmı alakasız hale geliyor.

Referans, ajana tam olarak ne yazacağını söylemiyor.

Doğru cevabın çözüm uzayının neresinde yaşama ihtimalinin yüksek olduğunu söylüyor.

Burada dil modellerinde analojik akıl yürütme araştırmalarıyla da ilginç bir bağlantı var. Modeller, her problemi tamamen yeni bir problem gibi ele almak yerine, ilgili önceki örnekleri kullanarak yeni bir problem hakkında akıl yürütebiliyor. Bu, kod üretimi dahil farklı akıl yürütme alanlarında gösterilmiş durumda.

Yazılım mühendisliğinde ise ek bir avantajımız var:

ihtiyacımız olan örnekler çoğu zaman zaten repository’nin içinde duruyor.

Daha zor problem onları bulmak.

Bugün ne yapabiliriz?

Kodlama ajanlarının repository anlama konusunda daha iyi hale gelmesini bekleyebiliriz. Şüphesiz gelecekler.

Ama bugünkü araçlarla yapabileceğimiz oldukça basit şeyler de var.

İlki repository’nin kendisini iyileştirmek.

AGENTS.md, CLAUDE.md, Copilot talimatları ve benzeri dosyalar yalnızca kodlama kurallarını değil, mimari işaret taşlarını da belgelemek için faydalı yerlerdir.

Bu dosyaları sadece şuna benzer talimatlarla doldurmak yerine:

“Dependency injection kullan.”

ya da:

“Servisler için unit test yaz.”

şuna benzer yönlendirmeler ekleyebiliriz:

“Permission tabanlı UI için Payments uygulamasını referans al.”

“Harici API client’ları için CustomerClient referans uygulamadır.”

“Yeni bir soyutlama eklemeden önce repository içinde yapısal olarak benzer bir uygulama ara.”

GitHub artık repository genelinde, path’e özel ve ajan talimat dosyalarını destekliyor. Anthropic de benzer şekilde CLAUDE.md dosyasını kısa tutmayı ve Claude’u önemli dosyalara, komutlara ve konvansiyonlara yönlendirmek için kullanmayı öneriyor.

Ama bu dosyaları yazarken gelecekteki her gereksinimi tahmin edemeyiz.

Bu yüzden ikinci kısım prompt anında gerçekleşiyor.

İstediğim özelliğin sistemdeki başka bir şeye benzediğini zaten biliyorsam, bu bilgiyi prompt’a eklemek genellikle yazabileceğim en değerli cümlelerden biri oluyor.

Ajanın benim zaten bildiğim bir şeyi keşfetmek için zaman harcamasını engelliyor.

Ve aksi halde kod tabanının alakasız bölgelerini keşfetmeye gidecek token’ları kurtarıyor.

Üçüncü bir adım daha var ve bence en ilginç olanı bu:

ajanlar kendi crib’lerini bulmakta iyi hale gelmeli.

Yeni bir pattern oluşturmadan önce ajan, repository içinde yapısal olarak benzer uygulamaları arayabilmeli, bunları karşılaştırabilmeli, en güçlü emsali belirleyebilmeli ve bunu planının bir parçası olarak kullanabilmeli.

Kabaca şöyle:

Gereksinim -> benzer uygulamaları bul -> mimari emsali belirle -> planla -> uygula -> doğrula.

Bu noktada repository araması sadece “bu kelimeleri içeren kodu bul” olmaktan çıkar.

Akıl yürütme sürecinin bir parçası haline gelir.

Ben ne deniyorum?

AI destekli geliştirme üzerine son dönemde yaptığım birçok deneme yavaş yavaş bu yöne doğru ilerledi, başta bunları “crib” kavramıyla düşünmüyordum.

Yerel modellerin kod tabanı bağlamı çekebilmesi için repository index’leme, farklı ajanların yazılım teslim sürecinde farklı roller üstlendiği agent workflow’ları ve kodlama ajanlarına çalıştıkları sistemler hakkında daha kalıcı bilgi vermek için repository seviyesinde talimatlar üzerine denemeler yaptım.

Bu yaklaşımları kullandıkça, yalnızca retrieval’ın yeterli olmadığına daha fazla ikna oldum.

Bir görevle ilişkili kodu bulmak faydalı.

O görev için emsal teşkil eden kodu bulmak çok daha değerli.

Bu biraz farklı bir retrieval problemi.

Ve belki de daha ilginç bir problem.

Mimari kararları ajanların keşfetmesini kolaylaştırabilirsek - dokümantasyonla, daha iyi repository yapısıyla, açık referanslarla ve daha akıllı aramayla - teknik olarak geçerli ama bulunduğu yere ait olmayan kodu düzeltmek için daha az zaman harcarız.

Model sistemin yalnızca bir parçası

Kodlama modelleri daha iyi olacak.

Context window’lar büyüyecek. Repository araması gelişecek. Ajanlar büyük sistemlerde yardımsız gezinmekte daha iyi hale gelecek.

Ama bunun mühendislik problemini ortadan kaldırdığını düşünmüyorum.

Büyük bir kod tabanı binlerce olası ipucu içerir. Bunların çoğu elimizdeki görev için alakasızdır.

İş, ajana yalnızca daha fazla bilgi vermek değildir.

İş, aramasını değiştiren bilgiyi bulmasına yardımcı olmaktır.

Crib fikrinin zekice taraflarından biri buydu: iyi seçilmiş az miktarda bilgi, aksi halde devasa olan bir arama problemini çok daha sınırlı hale getirebiliyordu.

Bugünün makineleri çok farklı, problemler de öyle.

Ama prensip şaşırtıcı biçimde tanıdık geliyor.

Bazen atılım daha hızlı aramak değildir. Önce doğru crib’i bulmaktır.

Kaynaklar ve ek okuma