LLM kodlama ajanlarının hâlâ kötü olduğu iki şey

• LLM kodlama ajanları, kopyala-yapıştır benzeri kod taşıma işlerini doğal şekilde yerine getiremiyor
• Kod refaktörizasyonu sırasında hafızaya dayanarak kod yazma yaklaşımı nedeniyle tutarlılığı garanti etmek zorlaşıyor
• Problem çözme sürecinde neredeyse hiç soru sormuyor ve tahmine dayalı denemeleri sürdürüyor
• İnsan geliştiriciler belirsizlik olduğunda sorularla problemi netleştirirken, LLM duvara çarpana kadar denemeyi tekrarlıyor
• Bu özellikler nedeniyle LLM ajanları insan geliştiricinin yerine geçen değil, yalnızca özgüveni yüksek bir stajyer seviyesinde görülüyor

---

LLM kodlama ajanlarının başlıca sınırlamaları

Son dönemde LLM'leri kodlama yardımcı aracı olarak kullanma girişimleri artıyor, ancak insan geliştiricilere hâlâ tuhaf gelen noktalar var. Bu yazı, LLM kodlama ajanlarının özellikle rahatsızlık veren iki nedenini açık şekilde anlatıyor

1. Kod taşıma ve refaktörizasyon yöntemindeki tuhaflık

• LLM, gerçek anlamda 'kopyala-yapıştır' işlemi yapmıyor
  • Örneğin büyük bir dosyayı küçük dosyalara refaktörize etmesi istendiğinde, LLM kod bloklarının bir kısmını 'hatırlayıp' kaynak dosyada delete komutunu kullanırken yeni dosyada 'hatırladığı' kodu write komutuyla yazıyor
  • 'cut' veya 'paste' araçlarını kullanmak yerine, tüm düzenlemeler bellekte yeniden kuruluyor
  • İnsan geliştiriciler kod taşırken 'kopyala-yapıştır' ile kod eşleşmesine dair güven kazanır, ancak LLM bunu garanti etmiyor
  • Şimdiye kadar yalnızca Codex, sed ya da awk komutlarını kullanarak insanın 'kopyala-yapıştır' davranışını taklit etmeye kısmen çalıştı, ancak bu da kusursuz değil

2. Soru sormadan problem çözme yaklaşımı

• LLM'nin problem çözme süreci de insanlardan çok farklı
  • LLM neredeyse hiç soru sormuyor ve çok sayıda varsayıma dayanarak problemi çözmeye çalışıyor
  • İnsan geliştiriciler, büyük değişikliklerde veya durum net olmadığında her zaman sorularla durumu doğrular; 'kötü soru yoktur' anlayışıyla hareket eder
  • Buna karşılık LLM, sürekli denemeyi tekrarlayıp sorun çıkınca bunu daha da sert biçimde yineleme eğiliminde
  • Soruları teşvik etmek için prompt aşırı biçimde tasarlanabilir, ancak Roo gibi bazı araçlar dışında bu davranış pek görülmüyor
  • Temelde bunun nedeni, LLM geliştiren şirketlerin 'daha hızlı kod yazma'ya odaklı RL (pekiştirmeli öğrenme) uygulamış olması olabilir

Sonuç

• Bu özellikler nedeniyle LLM, henüz insan geliştiricilerin yerini alacak düzeyde değil
• Gerçek iş akışında ancak 'aşırı özgüvenli bir stajyer' kadar yetenek gösteriyor
• LLM ile işbirliği deneyiminin tamamen doğal hissettirmemesinin nedeni de bu

[GN⁺]

Hacker News görüşü

• Kısa süre önce ilginç bir deneyim yaşadım. Kodla ilgili değildi ama kod ve ilişkili alanlarda da gayet yaşanabilecek bir şeydi (hatta gerçekten bir iş arkadaşımın da başına geldi). HN'de 15 yıl önce kabul edilen bir düzenlemenin neden daha yaygınlaşmadığı tartışılırken, ben o dönemdeki teknoloji seviyesinin genel vakaları karşılamaya yetmediğini, bu yüzden düzenlemenin yalnızca o zaman mümkün olan kısımlara uygulandığını tahmin etmiştim (ilgili yorum). Birkaç saat sonra tartışmaya tekrar baktığımda, bazı kişilerin o dönemde bile ilgili teknolojinin yeterince ucuz olduğunu söylediğini gördüm. Bunun üzerine LLM'den bu konuda kanıt bulmasını istedim ve teknik sınırlamalar nedeniyle böyle olduğunu söyledi. Kaynak doğrulamak için alıntıladığı materyallere baktım; gerçekte teknik sınırlamaları tartışan yalnızca tek bir kaynak vardı ve o kaynak da HN'ye bıraktığım kendi yorumumdu. Bunu iş yerinde anlatınca bir iş arkadaşım, GitHub'da "X Windows'ta şöyle çalışır" diye bir görüş yazdığını, sonra Google'da arayınca LLM tabanlı bir cevabın o görüşü kaynak gösterip aynı şeyi savunduğunu anlattı. O yüzden LLM'ye "X nasıl çalışır?" diye sormak yerine, "Birisi X'in nasıl çalıştığını sorarsa alıntılanabilecek bağlantıların listesini göster" demek istiyorum

  • Soruyu bu şekilde sormanın "sorting prompt"a benzediğini düşünüyorum. Mike Caulfield'ın şu yazısından öğrendiğim bir teknik; ben de kod yazarken kullanıyorum (ör. Claude code slash command). LLM'ye doğrudan cevap vermesini söylemek yerine araştırma yapma, sınıflandırma ve değerlendirme işi verdiğinizde çok daha doğru sonuç alabiliyorsunuz

  • Çoğu insan da HN'de belli bir konudaki yorumları okurken "bu kişi bir şey biliyor gibi, şimdilik doğru kabul edeyim" diye güveniyor. Bir şeyi doğrudan deneyimlemek veya doğrulanmış bilgi edinmek aslında çok pahalı olduğu için, böyle 'ucuz bilgi'nin de sonuçta değerli olduğunu düşünüyorum

  • LLM'den gerekçe sunmasını istediğim deneyimlerim oldu ama bugüne kadar LLM'nin söylediği şeyi gerçekten destekleyen gerçek bir dayanak verdiğini hiç görmedim

  • LLM bazen bağlantıları bile uydurup sahte olarak oluşturuyor. Gerçekten araştırma yapmasını sağlayacak bir derin araştırma moduna ihtiyaç var, ama o zaman bile bağlantıdaki bilgiyi nasıl yorumladığı sonuçta eğitiminden etkileniyor

  • Yakın zamanda NotebookLM'e 6-8 tane güvenilir kaynak (IETF, OpenID spesifikasyonları ve ek belgeler) verip "OID4VP'nin izin verdiği credential formatları neler?" gibi çok basit bir soru sordum. Cevabın %90'ı doğruydu ama tamamen dayanaksız, rastgele bir formatı büyük bir özgüvenle ekledi (sanki spesifikasyonun yazarıymış gibi). Şüphelenip spesifikasyonu bizzat kontrol ettiğimde bunun hemen yalan olduğunu gördüm. Artık "temellendirilmiş" bir LLM bile olsa, olgusal doğruluğa güvenim tamamen çöktü denebilir

• Yakın zamanda Codex CLI ile bir HTML dosyasını refactor ettirdim ama beklediğim gibi kodu copy-paste yapmak yerine, LLM hafızasından yeniden yazarak kodu değiştirdi ve yorumları da sildi. Peş peşe 40 karmaşık bağlantıdan oluşan bir bölüm vardı; dağıtımdan hemen önce son kontrol için hepsine tek tek tıkladım. İlk kısmı düzgündü ama ortadan sonra 31 bağlantının hepsi 404 veriyordu. Domain doğruydu ama URL yolu değişmişti. Git commit'inde eski URL'lere baktığımda, LLM'nin gerçekte var olmayan yollara URL'leri "halüsinasyonla" çevirdiğini gördüm. Böyle ince ve sessizce oluşan hatalar gerçekten tehlikeli. Çok dikkat etmek lazım

  • Son noktanın çok önemli olduğunu düşünüyorum. "Çok ince ve sessizce giren hatalar" yüzünden, LLM işi insan kadar iyi ya da daha iyi yapsa bile aynı şekilde ele alınamaz. Özellikle de code review geleneksel olarak sorunları önleyen önemli bir katmanken, burada incelenmesi gereken hata türleri değişiyorsa mevcut code review yöntemi verimsiz kalıyor. Eskiden büyük kod taşıma işlemlerinde bloğun olduğu gibi taşındığını varsayıp daha üst seviyedeki şeylere odaklanmak mümkündü; ama LLM refactor'larında 'taşınan' kod aslında özetlenmiş/yeniden kurulmuş "yeni" kod olabilir, yani her karaktere bakmak gerekir. Bu yüzden Pull Request açıklamasında "AI kullanımı" diye bir bölüm bulunmasının, AI'ın nerede ve nasıl kullanıldığını belirtmesinin, review sırasında özellikle kontrol edilmesi gereken alanları anlamayı kolaylaştıracağını düşünüyorum

  • Ben de kod veya araştırma soruları sorarken benzer deneyimleri sık yaşadım. LLM ilk başta iyi gidiyor ama N'inci adımdan sonra kafasına göre içerik uydurmaya başlıyor. Yakın zamanda seyahatten önce Gemini'den güncel bira üreticisi listesi istedim; çoktan kapanmış veya geçici çalışan yerleri gayet rahat şekilde listeye koydu. Çalışma saati bağlantıları eklemesini ve kapanmış yerleri çıkarmasını isteyince, listenin başını düzeltti ama son taraflarda ya alakasız değişiklikler yaptı ya da kapanmış yerleri hiç silmedi. Buna rağmen her seferinde her şeyi kusursuz araştırdığını büyük bir özgüvenle söyledi

  • Kodla ilgili değil ama bir keresinde etkinlik duyurusunda yalnızca yazım/dilbilgisi kontrolü yapmasını istedim. LLM hafifçe düzeltilmiş bir sürüm gönderdi ama tarihi sessizce bir gün ileri almıştı. Neyse ki fark edip düzelttim ama çok basit işlerde bile körü körüne güvenilmemesi gerektiğini öğrendim. Kısa ve açık tek cümlelik prompt'larda bile LLM bazen etkileyici şeyler yapıyor ama bazen en basit şeylerde bile beklenmedik hata yapabiliyor

  • 5 dakika önce de Claude'dan yalnızca koda debug ifadeleri eklemesini istemiştim ama regex'i sessizce değiştirmişti. Diff'te kolay yakalandı ama büyük değişikliklerde bunu kaçırmak gerçekten kolaylaşıyor

  • Dağıtımdan hemen önce 40 bağlantının hepsini tekrar kontrol etmen akıllıca olmuş. Ama Codex bitirdikten sonra 'git diff' bakmadan doğrudan master'a göndermen biraz şaşırtıcı

• Yazının iddiasına katılıyorum. Ama bence en büyük sorun, ajanın kod deposunun yalnızca çok küçük bir kısmını görmesi. Zaten var olan helper fonksiyonları bilmediği için durmadan aynısını yeniden oluşturuyor. UI geliştirmede tüm UI yapısını kıyaslayamadığı için tutarsız kod tekrar ediyor. Sonuçta insanın "şu dosyadaki helper fonksiyonlara bak", "bunu şu implementasyon gibi yap", "bu dokümanı mutlaka oku" gibi doğru bağlamı iyi vermesi gerekiyor. Uygun bağlamı doğrudan verirseniz ajanların faydasını ciddi şekilde artırabiliyorsunuz. Bu arada başka bir sorun da, büyük monorepo'larda klasör yapısında gezinmekte kötü olmaları; örneğin alt dizinde 'npm test' çalıştırmayı bile gerçekten sık sık beceremiyorlar

  • Gerçekten benim yaşadığım sorun da bu. Kısa süre önce Cursor ile yazılmış yaklaşık 200 satırlık yeni bir özelliği review ettim ama gerçekte gerekli olan kod çok azdı. Utility library'de zaten bulunan fonksiyonları bulmak gerçekten çok zahmetli olduğu için çoğu zaman olduğu gibi bıraktım. 5 yıl önce bu tür review'larda yeni başlayanları onboard etme yönü baskındı ve bunları göstermek önemliydi; ama bugünlerde Cursor vb. yüzünden kod miktarı artarken, geliştiricinin kendisi de yapıyı bildiği hâlde şirket politikası nedeniyle bilerek böyle üretim yapıldığı için verimliliğin düştüğünü hissediyorum

  • 'npm test' gibi komutları alt klasörde çalıştırmak hep sorundu. Vite/React frontend ve .NET backend olarak ayrılmış bir repo'da, npm komutu başarısız olunca panikleyip defalarca aynı şeyi yapıyor ve çözemeyip gereksiz troubleshooting'e sapıyordu. Bir keresinde 'CLAUDE.md' içinde önce mevcut dizini kontrol etmesini söyleyen bir talimat yazdım ama yine de rastgele yolu unutma sorunu kaldı. Bu yüzden 'run-dev server restart', 'run-dev client npm install' gibi hangi dizinde olursa olsun çalışan alias'lar ekledim ve saf dotnet/npm komutlarını yasaklı listeye koyup, AI'ın proje rehberine bakarak bu alias'ları kullanmasını zorunlu kıldım. Bu yöntem nispeten daha istikrarlıydı ama bu noktaya gelmek için epey zaman, emek ve stres gerekti

  • Büyük bağlamlı modeller tool call ile kullanılsa iyi olur diye düşünüyorum. Gemini chat'in GitHub'daki tüm repoyu ingest etme yeteneği var. Yeni fonksiyon yazmadan önce, kod tabanında aynısı zaten var mı diye kontrol eden bir 'not-invented-here' aracı olsa nasıl olur? Tabii önce birinin böyle bir aracı zaten yapıp yapmadığını araştırmak gerekir

  • İşte bu yüzden claude.md gibi dokümanlar gerekli. Bizim kurallarımıza uyulacaksa bunların mutlaka belgelenmesi gerekiyor

  • Aslında bu durum, kıdemli mühendislerin pratikte iş arkadaşlarıyla çalışırken sık sık yaşadığı bir şey

• Yazıda alıntılanan kısma tamamen katılıyorum. LLM'lerin üst düzey geliştiricilerin yerini alamayacağına katılıyorum. Aklı başında biri için şu anda bunu söylemek saçma olur. Ama düşük performanslı veya orta seviye geliştiricilerin şimdiden yerinin alındığını düşünüyorum. Örneğin organizasyonumuzda 6 aylık bootcamp geçmişi olan 3 kişi vardı; o dönemde iyi geliştirici bulmak çok zor olduğu için işe almıştık. Ama gerçekte çok çok basit görevlerde bile zorlandılar ve ben her seferinde review'da kodu baştan sona toparlamak zorunda kaldım. Sonra AI araçları katlanarak gelişti ve bu kişilerin performansını aştı. Sonuçta 2'si işten çıkarıldı, kalan 1'i de kendi ayrıldı. Son dönemde junior geliştirici alımını da neredeyse durdurduk ve bootcamp çıkışlı kimseyi bir daha asla almayı planlamıyoruz. Çevremde de durum benzer; bu yüzden bootcamp sektörünün kendisi de yok olma eğiliminde. AI'ın gelecekte iyi geliştiricilerin bile yerini alıp alamayacağını bilmiyorum ama şu anki verilere bakınca inanılmaz hızlı ilerlediği açık. Olumsuz görüşler gerçeği görmezden gelmek oluyor. ABD'nin ilk dönemlerinde nüfusun %90'ı tarımdaydı; bugün bu oran yalnızca %2. Ama gıda üretimi ve çeşitliliği çok daha fazla. Bunların hepsi teknolojik ilerlemenin sonucu. Aynı şeyin yazılım sektöründe de yüksek hızla tekrarlanabileceğini düşünüyorum

  • Elbette teknolojiyle gıda üretimi arttı ama besin değerinin düştüğü ve toksisitenin arttığı da doğru

  • Bootcamp çıkışlıların gelişememesinin sebebinin ne olduğunu düşündüğünü merak ediyorum

• Daha önemli ders şu: LLM'ler oldukça basit görevlerde bile ciddi miktarda talimat ve gözetim olmadan çok kırılgan. 2.5K satırlık küçük projemde parser refactor etmesini istedim; planı mantıklı görünüyordu. Aşamaları checkpoint'lere bölüp sırayla ilerlettim ama her "eski yapı silindi mi?", "yeni yapıyla değiştirildi mi?" diye sorduğumda cevap "hayır, olduğu gibi duruyor" oldu. Testlerin %80'i başarısızdı ve somut düzeltme yönleri bile göstersem, "refactor" gibi soyut görevlerde hep aynı nedenle başarısız oldu. Sonunda "şu sınıfta şunu değiştir" seviyesinde çok detaylı talimatlar vermeden olmuyor. Bu durumda bağımsız çalıştırmak mümkün değil ve LLM kullanmanın anlamı ciddi biçimde azalıyor

  • Benim deneyimim biraz farklı. TypeScript ile yazılmış expression tree parser'ı (tinqerjs.org) kendi elimle yazdığım kod 0 olacak şekilde sadece Codex+Claude ile 2 haftada (part-time) tamamladım, yüzlerce test de ekledim (tekrarlar dahil). ORM de yaptım; LLM ile en az 4-10 kat zaman kazancı sağlayabildim. Neredeyse hiç gözetim gerekmedi. Bence sonucu belirleyen şey kullanım amacı ve sürecin ne kadar oturduğu. LLM'yi etkin kullanan geliştiriciler de kendi benzersiz iş akışlarını kuruyor ve hepsinin ortak noktası test, dokümantasyon ve code review'a odaklanmaları

  • "<Refactor talimatı çok detaylı olmak zorunda, o yüzden anlamı kalmıyor>" meselesini, "yüksek seviyeli adımları iyi bölüp talimat verirsem tek başıma yapacağımdan çok daha hızlıyım" yaklaşımına çevirmek gerekiyor

  • Bu da yine yazıda işaret edilen 'AI'ın cut-paste değil, delete/recreate yaklaşımı' ile bağlantılı. Kodun ufak ufak drift etmesi aslında kaçınılmaz

  • Hangi modeli/aracı kullandığını merak ettim. Cursor veya Copilot kullanırken ben de bu tür küçük refactor'larda sürekli gözetim gerektirmesi sorununu sık yaşadım

• LLM'nin yardımcı olduğu alanlar kesinlikle var. Örneğin bu sabah bir PDF Metadata parser hatasını, PDF spesifikasyonuna derinlemesine girmeden LLM yardımıyla düzelttim. Ama çoğu durumda çıkan sonuç benim doğrudan yapmamdan daha verimsiz oluyor. Daha önce Codex Code ile unit test yazdırmaya çalıştığımda, çeşitli setup'lar hazırlamıştım ama data mocking zahmetli olduğu için buna verdim. 8 kez denemek ve elle düzeltmek zorunda kaldım; ayrıca entity'nin obsolete olduğunu ve serviste artık kullanılmadığını da anlayamadı. Sonuç olarak hayal kırıklığıydı. Geliştiriciyi tamamen değiştirecek kadar iyi değil ama Stack Overflow'un eskiden yaptığı gibi, yabancı konularda bilgiye maruz kalma ve çözüme yönlendirme açısından oldukça faydalı olduğunu düşünüyorum

  • Şu anda bile LLM'nin kendisinde yeterince potansiyel olduğunu düşünüyorum. Ama asıl sihir coding agent'larla birleştiğinde ortaya çıkıyor. Doğru araçlar hazırlanır, modelle entegrasyon ve iterasyon kurulursa copy-paste bile uygulanabilir; bugün eksik görülen şeylerin çoğu iyi bağlam ve talimatlar, tekrarlı doğrulama ve sağlam ajan mimarisiyle telafi edilebilir. Ayrıca hızlı yanıt, geniş bağlam ve talimatlara iyi odaklanan modeller deneyimi ciddi şekilde iyileştiriyor. İnsan tarafında prompt yazma becerisi de çok önemli. Sonuçta iyi yazılım mühendisliği yetkinliği, özellikle de başka geliştiricilere iş tarif etme becerisi, ayrıca AGENTS.md (veya CLAUDE.md) gibi kod tabanı içi talimat ve iyi uygulama belgeleri gerekiyor. Sonuç olarak, "AI/LLM geliştiricilerin yerini alabilir mi alamaz mı" tartışması artık bayatlıyor. Asıl mesele "LLM'm için ben ne yapabilirim?" sorusu

• "Soruyu daha net sormaya yönlendiren prompt" yazmayı aşırı engineering olarak görmüyorum. Hatta "net değilse önce soru sor" diye prompt tasarlamak çok etkili oldu. İyi programcılar, spesifikasyonu tam verip vermediklerini ve ek clarification gerekip gerekmediğini fark edebilir; böylece AI'ı önceden gerekli ek soruları sormaya yönlendirebilirler

  • Kaç soru sorulacağını doğrudan da belirleyebilirsiniz. Karmaşık konularda önceden 20-30 soru sormasını isterim ve sonuçlar oldukça tatmin edici oluyor. Bu tür Soru-Cevap'ları ayrı bir dosyada saklayıp sonraki oturumlarda veya başka ajanlarla yeniden kullanmak da faydalı

  • Bu yaklaşım sayesinde artık eskisi gibi prompt yazmıyorum. Sadece fikri verip "gerekirse soru sor" diyorum; çoğu zaman benim düşünmediğim noktaları güzel yakalıyor

• Metindeki copy-paste kısmından ilham alıp clippy'ye (macOS yardımcı aracı) bir ajan buffer aracı ekledim. clippy'nin bir MCP sunucusu var ve sistem panosuyla etkileşime giriyor; bu sefer ayrı bir özel buffer kullanmak uygundu. Eklenen işlevler buffer_copy (dosyadan belirli satır aralığını kopyalayıp özel buffer'a kaydetme), buffer_paste (buffer'daki tam baytları hedef dosyaya ekleme/değiştirme), buffer_list (buffer içeriğini görme). Örneğin ajan "auth.py'nin 50-75. satırlarını kopyala" dediğinde, sunucu dosya G/Ç'sini doğrudan yapıyor; token üretimi veya halüsinasyon hiç yok. Sistem panosunu da etkilemiyor. Önceden AI'ın ürettiği kodu doğrudan panoya kopyalayıp kullanmak mümkündü. clippy'nin ana amacı macOS pbcopy'yi geliştirmek — gerçek dosya içeriğini kopyalayıp terminalden Slack veya e-postaya dosyanın kendisini yapıştırabilmek. macOS'ta Claude gibi MCP uyumlu ajan kullananlar buraya bakabilir. brew install neilberkman/clippy/clippy ile kurulabiliyor

• Çoğu geliştirici de soru sormakta çok iyi değil. Pek çok şeyi doğal kabul edip atlama eğilimindeler. 25 yıllık geliştirme deneyimimde iş arkadaşlarımın yarısından fazlasında ikinci kusur vardı. Ben de kariyerimin yarısında böyleydim; o yüzden daha çok empati kuruyorum

  • Yine de insanların otonom araçlardan veya AI'dan, insanlardan daha yüksek güvenilirlik beklemesi doğal bir şey. "İnsan da yapamıyor" savunması, böyle beklentisi olan insanlar için pek ikna edici bir argüman değil. Kişisel olarak bunu oldukça anlaşılır buluyorum

• Metindeki "LLM'ler copy-paste (veya cut-paste) yapmaz" iddiasında olduğu gibi, kodu hatırlayıp silip yeniden yazma eğilimindeler; bu yüzden sanki her seferinde yeni bir write command veriyormuşsunuz gibi oluyor. Refactor işlerinde zaten gerçek copy/paste çok sık gerekmiyor; çoğu zaman bağlama dayalı recall yeterli oluyor. Gerçek çalışmada copy/paste komutunun kendisinin ne kadar faydalı olduğu da belirsiz geliyor bana (en azından benim testlerimde büyük fark yaratmadı). Hatta tekrarlı ve çok bağlam tüketen kısımlarda fastmod gibi araçlarla codex ya da claude'a "şu kısmı toplu değiştir" dedirtmek daha etkili. Problem çözme yaklaşımı insanlardan farklı olduğu için biraz tuhaf hissettiriyor ama yeterince planlayıp iletişim kurulduğunda yaklaşım ciddi biçimde değişebiliyor

  • IDE'ler birçok dosyada fonksiyon imzasını veya adı anında değiştirebiliyor ama LLM ajanları bunu denediğinde dakikalar sürse bile çoğu zaman doğru yapamıyor. Gerçek copy/paste desteğinin faydasının açık olduğunu düşünüyorum

  • copy/paste, bağlam patlamasını azaltma konusunda da çok önemli. Modelin kod bloklarının içeriğini aklında tutması gerekmiyor; ihtiyaç olduğunda onlara her zaman erişebiliyor