- LLM ajanları, gevşek tanımlı kod üretiminde güçlü olsa da, üretim seviyesindeki arka uçların gerektirdiği API sözleşmeleri, mimari, DB ve ORM kısıtlarına uyumda hâlâ kırılgan
- Aynı OpenAPI spesifikasyonu ile işlevsel gereksinimler sabitlendi ve 8 web framework'ünde 80 greenfield görev ile 20 özellik geliştirme görevine aynı davranış testleri uygulandı
- İşlevsel olmayan kısıtlar, framework seçimi, mimari desen, veritabanı backend'i ve ORM entegrasyonu olmak üzere 4 boyuta ayrılarak yapısal karmaşıklığın etkisi izole edildi
- Kısıt çürümesi, yapısal gereksinimler biriktikçe performansın keskin biçimde düşmesi olgusu; yüksek yapılandırmalı tam belirtilmiş görevlerde assertion pass rate ortalama 30 puan düştü
- Başlıca başarısızlık nedeni veri katmanı kusurları; hatalı sorgu kurgusu ve ORM çalışma zamanı ihlalleri, ajan mantığı hatalarının yaklaşık %45'ini oluşturuyor
Temel sorun ve değerlendirme düzeni
- LLM ajanları, gevşek tanımlı otonom kod üretiminde güçlü olsa da, üretim seviyesindeki arka uç yazılımlar için gerekli yapısal kısıtlara sıkı biçimde uyma becerileri yeterince değerlendirilmiş değil
- Üretim seviyesindeki bir arka uç, yalnızca API sözleşmesine uyan endpoint'leri değil; ayrıca mimari desenler, veritabanı entegrasyonu ve belirlenmiş ORM katmanı gibi işlev dışı gereksinimleri de karşılamalı
- Mevcut benchmark'lar çoğu zaman işlevsel olarak doğru ama yapısal olarak keyfi çözümleri de ödüllendirdiğinden, kısıtlı çok dosyalı arka uç geliştirmenin zorluğunu yeterince yakalayamıyor
- Önceki çalışmalar daha çok mevcut kod tabanındaki belirli sorunları çözmeye, doğal dil prompt'larına dayalı kısıtsız üretime, tek dosyalı çözümlere ve iskelet kod tamamlama senaryolarına odaklandı; yapısal kısıt düzeyinin sistematik olarak değiştirilmesinin etkisini ele alamadı
- Aynı OpenAPI spesifikasyonu ile işlevsel gereksinimler sabitlenip tüm koşullarda aynı uçtan uca davranış testleri uygulanarak yapısal karmaşıklığın etkisi izole edildi
- Deneyler, 8 web framework'üne yayılan 80 greenfield üretim görevi ve 20 özellik geliştirme görevinden oluşuyor
- İşlevsel olmayan kısıtlar; framework seçimi, mimari desen, veritabanı backend'i ve ORM entegrasyonu şeklinde 4 boyuta ayrılıyor
- Temel koşulda yalnızca aynı API spesifikasyonu verilirken, kısıtlı koşullarda clean architecture, PostgreSQL ve SQLAlchemy gibi gereksinimler ekleniyor
- Değerlendirmede uçtan uca davranış testleri ile statik doğrulayıcılar birlikte kullanılarak işlevsel doğruluk ile yapısal uyum birbirinden ayrılıyor
Başlıca sonuçlar ve anlamı
- Kısıt çürümesi (constraint decay), yapısal gereksinimler biriktikçe ajan performansının ciddi biçimde düştüğü bir olgu olarak doğrulandı
- Yüksek performanslı yapılandırmalarda bile, temel koşuldan tam belirtilmiş görevlere geçildiğinde assertion pass rate ortalama 30 puan düştü; bazı zayıf yapılandırmalar ise neredeyse 0'a indi
- Aynı API sözleşmesinde bile framework'e göre başarı oranları büyük farklılık gösterdi; ajanlar Flask gibi hafif ve açık seçik framework'lerde daha iyi performans gösterdi
- FastAPI ve Django gibi görece daha fazla konvansiyon içeren ortamlarda ortalama performans çok daha düşük kaldı
- Hata analizinde başlıca nedenin veri katmanı kusurları olduğu görüldü; hatalı sorgu kurgusu ve ORM çalışma zamanı ihlalleri öne çıktı
- Veri katmanı kusurları, ajan mantığı hatalarının yaklaşık %45'ine yol açan temel neden olarak sınıflandırıldı
- İşlevsel gereksinimler ile yapısal gereksinimleri aynı anda karşılamak, kodlama ajanları için hâlâ önemli ve çözülmemiş bir problem olmaya devam ediyor
- Değerlendirme pipeline'ı, görev koleksiyonu, ajan yürütme izleri ve analiz script'leri constraint-decay adresinde açıklandı
1 yorum
Hacker News yorumları
LLM ile kod üretimine tamamen şüpheyle yaklaşıyordum ama artık işimde kullandığım kodun %80'inden fazlası üretilmiş koddan oluşuyor
Yine de sınırlar epey netleşti ve bazı projelerde ortaya çıkmaya başladı; bu yazı da sanki şüphelerimi doğruluyor
İş ne kadar karmaşık hale gelirse Markdown spesifikasyonları, kurallar, skill'lere konan kısıtlar, stil rehberleri, sınır koşulları, hata işleme ve optimizasyon yönergeleri eklemeye devam ediyorsun
Bir noktada, programlama dillerinin daha biçimsel ve deterministik dünyasındaki karmaşıklığı doğal dilin biçimsel olmayan ve deterministik olmayan dünyasına taşıyormuşsun gibi görünüyor
Yazma hızındaki artış muazzam ve iş dünyası bunu doğal olarak verimlilik artışı olarak görüyor, ama bunun bedeli de çok açık; yine de birçok kişi bunu görmezden geliyor gibi
Kimse bunların %100'ünü gözden geçirmiyor; geçirse bile değerlendirme son derece öznel
“RESTful yaklaşımı izle”, “biz REST kullanıyoruz, GraphQL kullanmıyoruz”, “uç noktaların %90'ı kaynak odaklı ama bazıları RPC gibi görünüyor, onları görmezden gel” arasındaki farkın ne olduğu belirsiz
Hepsi oldukça saçma görünüyor
Aslında tanımsız davranışla dolu ama çoğunlukla “çalışıyor gibi görünen” programlar derliyorsun
İş dünyasının bunu verimlilik artışı olarak görmesi, sonunda “verimliliği” yine saniye başına kod satırıyla ölçülen günlere geri dönüyormuşuz gibi hissettiriyor
Kod tabanı bağlam penceresinin ilk %20'sine sığıp tek bir çıkarımla tamamen tekrarlanabilir olma seviyesini aştığında, çalıştırma harness'i ve kod yama teknikleri çok daha önemli hale geliyor
OAI'nin model üzerinde rafine ettiği apply_patch yaklaşımı, ultra büyük kod tabanları için en iyi yöntem gibi görünüyor
Satır aralıklarına ya da basit bul-değiştir yöntemlerine dayalı yaklaşımlar uçlarda dağılıyor; cshtml dosyaları gibi zorlu durumlarla başa çıkmak için birden fazla uzamsal anchor gerekiyor
prepare/commit davranışı, çok sayıda büyük dosyaya yayılmış belirsiz bağlam üzerinde yineleyip anchor'ları iyileştirmek için ideal
LLM yeni bir şey yaratamaz
“Sistematik araştırma, LLM tabanlı kodlama ajanlarında kısıt çökmesi olgusunu ortaya koyuyor. Mevcut modeller kısıtsız üretimde başarılı, ancak açık mimari kurallara uymaları gerektiğinde performansları düşüyor. Son kullanıcı açısından bu ikilik, ajanların hızlı prototipleme için güvenilir ama prodüksiyon düzeyi backend geliştirme için hâlâ güvenilmez olduğu anlamına geliyor.”
Bu araştırmanın büyük zayıflığı, maliyet nedeniyle en ileri modelleri yeterince test etmemiş olması; bu yüzden somut performans sayılarına temkinli yaklaşmak gerek
Yine de hem davranışın hem de mimarinin doğru olması gerektiğinde model performansının düştüğü sonucu ilginç ve izlemeye değer
Yalnızca işlevsel gereksinimler varsa, aslında bir tür program sentezi yapıyorsun ve reinforcement learning bunu çok güçlü biçimde optimize edebiliyor
İşlevsel ve işlevsel olmayan gereksinimler karıştığında ise, fiilen modele eksik bir spesifikasyon veriyorsun; model de boşlukları doldurmak için kullanıcının niyetini belli ölçüde tahmin etmek zorunda kalıyor
İstenen kod stiline dair örnekleri prompt'a koymanın bu kadar güçlü olmasının nedeni de bu
Başvurulacak içerik arttıkça, daha önce söyleneni tekrar etmeye daha çok yaslanıyor
Yazarların sonraki bölümlere geldikçe daha az dikkat göstermesi ve editöryal çabayı azaltması da mümkün
Amazon'da hacim çok büyük ama LLM'ler henüz iyi yazı yazma aşamasında değil
Birbiriyle uyumsuz çözümler önerip sonra ek bağlam ve gereksinimler verildiğinde, başlangıçtaki mimariye saplanma eğilimi gösteriyor ve uyum sağlamakta zorlanıyor
Bazen de ilk plan lehine değişiklikleri gizlice araya sıkıştırmaya çalışıyor
Olası çözüm uzayının büyük parçaları erişilemez hale geliyor gibi
Örneğin yaklaşık 1 yıl önce, görüntü üreticilerine guardrail uygulandığında herkes birbirine benzemeye başlamıştı; hikâye üreticileri de yalnızca birkaç standart isim kullanmaya başlamıştı
En ileri modellerde hâlâ böyle bir şey olup olmadığını merak ediyorum
Bu tür modellerin zayıflık analizleriyle çok ilgilenmiyorum. Deneyimime göre model güçlendikçe ve akıl yürütme çabası arttıkça birçok zayıflık tamamen ortadan kalkıyor
Özellikle de istenen davranışı açıkça söylediğinde; kabul kriterleri arttıkça başarısızlık oranının yükselmesi de şaşırtıcı değil
Durum daha da kötü. Ajanlar yalnızca “yapısal kısıtlar” altında daha çok zorlanmıyor; o yapısal kısıtların kendisinin değişmesi gerektiğinde daha da kötü performans gösteriyor
Bir sistemi ya da bileşeni tasarlarken, değişmez kabul edilen fikirler oluştururuz
Bazı değişmezler büyük mimari kararlar kadar kapsamlıdır, bazıları ise veri yapısı seçimi kadar küçüktür
Ama sonunda bu değişmezlerle çatışan bir özelliği eklemek istediğin an gelir
O noktada genelde üç seçeneğin olur: özelliği hiç eklememek, özelliği değişmezlerin üstüne zarif olmayan ya da verimsiz biçimde oturtmak ya da geri dönüp değişmezi değiştirmek
Çoğu zaman bunlardan yalnızca biri doğrudur ve en az biri de çok ciddi biçimde yanlıştır, kötü sonuçlar doğurur
Ajanlar, kısıtları takip edebildikleri durumlarda bile kısıtların değiştirilmesi gereken anı fark etmekte son derece kötüler
Bu, örüntü tanıma ile akıl yürütme arasındaki sınırların bir örneği ve düşünce süreci pazarlamasına rağmen LLM'ler zerre kadar akıl yürütmüyor
Onları akıl yürütüyormuş gibi göstermeye yönelik her girişim, bence harness'in şimşeği şişeye hapsetmeye çalışan özyinelemeli bir yalıtım çabasına daha yakın
Çeşitli alanlardaki belge düzenleme işlerini LLM'e devreden yakın tarihli bir makale aklıma geldi https://arxiv.org/abs/2604.15597
O makalede, çoğu LLM'in hataları biriktirip belgeyi bozmadan uzun ufuklu görevleri yerine getirebildiği tek alanın programlama olduğu düşünülüyordu
Bu makalede henüz sadece özeti okudum ama programlamaya daha yakından bakıp benzer bir olguyu gösteriyor gibi görünüyor
Yine de bu, uzun ufuklu bir görevden ziyade daha büyük bir yapısal kısıtlar kümesine ilişkin “uzun stil ufku”na daha yakın görünüyor
İlgili tartışma: https://news.ycombinator.com/item?id=48073246
Çok ilginç bir makale ve tamamen katılıyorum, ama bunun yeni bir şey olduğunu düşünmüyorum
Herhangi bir ajan tabanlı kodlama çözümünü projeye bırakıp önüne bir görev listesi atınca, projenin önceden tanımlı kısıtlarına sihirli şekilde uyacağı yönündeki ilk beklenti zaten biraz hatalıydı
Hiçbir ajan tabanlı kodlama yığınının bunu varsayılan durumda yapabildiğine inanmıyorum
Ajanın bağlamı, kısıtları ve hedefleri istikrarlı biçimde anlaması için hâlâ uygun mekanizmalara ihtiyaç var; büyük yapay zeka laboratuvarlarının araçları, becerileri ve süreçleri sürekli güncelliyor olması da bunun hâlâ gelişen bir alan olduğunu gösteriyor
Bu ek katman, saf model ve token tüketiminden çok daha kârlı bile olabilir
Şu an test edildiği gibi görünen açık modellerin de doğru çalıştırıldığında istenen kısıtlara uyan prodüksiyon kodu üretebildiğini düşünüyorum
Son birkaç ayda sizin prodüksiyon kodunuzun nasıl olduğunu merak ediyorum
Uzun ufuklu ajan tabanlı kodlamayla epey deney yaptım ve https://medium.com/@vishvananda/i-spent-2-billion-tokens-wri..., belirli mimari desenleri zorla dayatmanın ajan performansını kötüleştirdiğini de gördüm
Kısıtları sonradan eklemek yerine süreç içinde birlikte koyunca biraz daha iyi oluyor
Benim kireçlenme dediğim bir yan etki var; kod tabanında bir desen görünmeye başladığında ajan o deseni takip ediyor, ardından bu desen bağlama hakim olup kendini güçlendiriyor
Mevcut bir kod tabanında bu, kod kalitesine bağlı olarak hem güçlü hem zayıf bir yön olabilir
Baştan itibaren mimari yönergeler içeren yeni kod tabanı çalışmaları tamamlandığında daha fazla içgörü çıkacaktır
Ayrıca model, uygulamayı “planlayacak” alanı olduğunda modülerleştirmeyi bir ölçüde iyi yapıyor, ama sonradan soyutlamanın faydalı olacağına kendi başına karar vermesi nadir
Bu özellikle yeni bir kod tabanında birkaç yinelemeden sonra ya da bir legacy kod tabanına sokulduğunda ortaya çıkıyor ve çoğu zaman dev dosyalar ile sonuçlanıyor
Kullanıcı buna işaret edince model bunu düzgün şekilde eleştiriyor ama iş kendi yazdığı koda gelince bu durum epey komik
Bu, “sohbet uzadıkça guardrail'ler bulanıklaşıyor gibi” düşüncesinin başka bir versiyonu gibi geliyor
Bağlam penceresinin tamamını kullanamama nedenimiz, sonlara doğru çıktının kısıtlara veya guardrail'lere uymaması
Oysa prodüksiyon seviyesinde kodu güvenilir biçimde üretmek için modelin geniş bir farkındalığa sahip olması gerekiyor ve bu da bağlam penceresini hızla dolduruyor
Bu, “şu 6 dizindeki her şeyi aklında tutarak bu değişikliği yap” demeye benziyor; her şeyi akılda tutmak bile tek başına bağlam penceresini doldurup kısıtlara uyma yeteneğini kaybettiriyor
Ama o zaman da başarısızlık biçimi, gereksinimleri giderek unutup linter'ı tatmin etmeye odaklanmak olur gibi görünüyor
Deneme/başarısızlık tekrarları da bağlam için hiç iyi olmayacaktır
Araştırmada Python ve JS gibi dinamik tipli diller kullanılmış
Benim deneyimime göre statik tipli kod tabanlarının insanlar için de bakımı daha kolay; dolayısıyla ajanlar için de öyle olabilir
Go kodunda Codex veya Claude Code kullanırken ajanın değişiklik yapıp derlemeyi çalıştırdığını, hataları bulduğunu ve tekrar düzelttiğini sayısız kez gördüm
Günümüz modelleri Python tipleriyle artık oldukça iyi çalışıyor
Python'da birkaç yıldır güçlü statik tip bir seçenek ve aslında sadece varsayılan olması gerekirdi
“8 web framework'üne yayılmış görevler” deniyor; LLM'lerin mevcut framework'lerle çalışmaktan ziyade saf HTML+CSS+JS üretmede daha iyi olduğuna dair bir deneyiminiz olup olmadığını merak ediyorum
Son zamanlarda gördüğüm en şaşırtıcı kombinasyon, Razor Pages üzerine JavaScript ile aşamalı iyileştirme eklemek oldu
Bu yapılandırmada yeni modeller, hangi işin sunucu tarafında (cshtml), hangisinin istemci tarafında (js) olması gerektiğini oldukça iyi ayırt ediyor
Kod tabanının bazı bölümlerini önce deyimsel hale getirip bu dosyaları örnek dosyalar olarak @ ile belirtmek için zaman ayırmanızı öneririm
Bu, Markdown ile yönlendirmeye çalışmaktan çok daha iyi çalışıyor
FastAPI gibi şeylerde epey iyi ama JavaScript en kötü görünen alan
Talimat ve örnek verseniz bile, belirtilen API'leri kullanmak yerine gereksiz yere bir sürü kodu satır içine gömme eğilimi gösteriyor