LLM Kod Üretimi Güvenin Zayıflamasına Yol Açabilir

• Son dönemde LLM tabanlı kod üretimi, geliştiriciler arasında giderek daha fazla kullanılmaya başlandı
• Otomatik üretilen kod nedeniyle kod kalitesi ve güvenilirliği konusunda endişeler artıyor
• Geliştiriciler, kodu yeterince anlamama ve yetersiz doğrulama nedeniyle proje bakım zorluğunun artması sorununu yaşıyor
• Güvenilir olmayan kod kullanımının yaygınlaşması, tüm yazılım ekosistemini etkiliyor
• Teknolojik ilerlemeyle birlikte güvenilirliği sağlamaya yönelik yöntemlerin oluşturulması gereği vurgulanıyor

---

Genel Bakış

Jay, kendi blogunda son dönemde ortaya çıkan LLM (büyük dil modeli) tabanlı kod üretim teknolojisinin yazılım geliştirme sahasındaki etkilerini ele alıyor. Bu araçların gelişmesiyle geliştirme verimliliği artarken, aynı anda kodun güvenilirliği ve kalitesi ile ilgili sorunlar da öne çıkıyor.

LLM Kod Üretim Teknolojisinin Yükselişi

• Geliştirme sahasında LLM kullanan otomatik kod üretimi araçları hızla yayılıyor
• Karmaşık özelliklerin uygulanması veya tekrarlayan kodlama işlerinde yüksek verimlilik sağlıyor
• Hızlı prototip üretimi ve yeni dil öğrenme yükünü azaltma gibi avantajlar sunuyor

Güvenilirlik Sorunu

• LLM'nin ürettiği kod, her zaman amaçlandığı gibi çalışmayabiliyor
• Kod içindeki niyet ve tasarım mantığı belirsiz olduğundan, anlama ve doğrulama süreci zorlaşıyor
• İnceleme ve test süreçleri yetersiz kalırsa beklenmedik hatalar veya açıklar ortaya çıkabiliyor

Proje Bakımı ve Ekosisteme Etkisi

• Otomatik üretilen kodda dokümantasyon eksikliği ve yetersiz açıklama sorunları ortaya çıkıyor
• Geliştiriciler kodun çalışma mantığını kavramakta zorlandığı için bakım karmaşıklığı artıyor
• Güvenilir yazılım geliştirme kültürünün zarar görme riski bulunuyor

Sonuç ve Öneriler

• LLM tabanlı kod üretim teknolojisi yenilikçi olsa da, güvenilirliğin sağlanması temel bir görevdir
• Otomatik üretilen kodun benimsenmesinde doğrulamanın güçlendirilmesi ve sistematik kod incelemesinin gerekliliği vurgulanıyor
• Uzun vadede bilişim ekosistemindeki güvenin korunması için standartların oluşturulması önem taşıyor

[GN⁺]

Hacker News görüşleri

• archive.is bağlantısı paylaşılmış; eski tarayıcılarda da çalışıyor ve JavaScript yalnızca CloudSnare'i aşmak için gerekli

• Bir arkadaşım hep "yenilik güvenin hızında gerçekleşir" der. GPT3 ortaya çıktığından beri bu söz aklımda dönüp duruyor. Doğrulama yüksek maliyet gerektirir ve güven bu maliyeti düşürmenin başlıca yoludur. Ama LLM'lerde güveni nasıl inşa edeceğimizi bilmiyorum. Hem kodda hem doğal dilde son derece akıcılar, ama aynı zamanda bir insan yapsa kötü niyetli sanılabilecek yönlere de sapabiliyorlar

  • Ben yazının yazarıyım: Bu alıntıyı gerçekten çok beğendim. Birkaç paragrafta anlatmaya çalıştığım şeyi çok kısa şekilde özetliyor. Artık her şeyi tek tek doğrulamak zorunda olduğumuz bir dünya açıkçası gerçekten yorucu ve yavaş
  • LLM çıktısına tam güven duyulamaz. Ama arıtma ve etki alanını sınırlama mümkün. Kullanıcı girdisini filtrelemek, sızma testi yapmak, sırları dot dosyalarında saklamak gibi yöntemlerle sonuçta "en iyi uygulamalar" ve "SOC-AI düzenleme uyumu" gibi standartlara yaklaşacağız. LLM'ler görmezden gelmek isteseniz bile fazla faydalı. Güven de sonuçta adım adım inşa edilir. İnsanlar da zaten güvenilirlikten çok uzak; otonom araçlarla kıyaslarsak, belirli kurallar içinde insanlardan daha az hatalı kod üretmek mümkün hale gelebilir. Sonrasında da karmaşıklık yavaş yavaş iyileşir
  • "Yenilik güvenin hızında gerçekleşir" sözü biraz daha açıklama gerektiriyor. Elektrik, uçuş, radyoaktivite ilk keşfedildiğinde o kadar güven var mıydı? Bilimde güven ilerleme sırasında birikir

• Bu konuyu işte beklemediğim bir biçimde yaşadım. Bir iş arkadaşım ve hızlı sonuç baskısı yüzünden benim yaptığım büyük bir refaktör, henüz geçici PR durumundayken birleştirildi. Sonra test edilmemiş kodda hata çıktı. Hata ayıklama sırasında iş arkadaşım, benim AI ile kod yazdığımı düşündüğünü ve AI'ın ürettiği kodu sonradan anlamaya çalıştığı için sinirlendiğini söyledi. Oysa o kod dikkatle benim elimle yazılmıştı ve hatanın sebebi de basit API değişikliği sürecindeki küçük yanlışlardı. Hatta bu deneyim sayesinde iş arkadaşımla güvenle ilgili gerilimi doğal biçimde açığa çıkarıp yapıcı şekilde konuşabildik. Şimdi dönüp bakınca, bu tür bir güven inşa etme deneyimi anlamlıydı; ortam farklı olsaydı çok daha karmaşık bir hale de gelebilirdi. Hep dikkatli olmak gerektiğini hissettiriyor

• Ben öncülü pek anlayamıyorum. Birinin iyi kod yazdığına güvenmek, o kişinin bizzat kod yazıp iyi sonuç verdiğini deneyimlemekten gelir. LLM kullansa da hatasız kod veriyorsa güvenirim, LLM kullansa da hatalıysa güvenmem. Bunun kafadan yazmaktan ne farkı var anlamıyorum

  • Ben yazının yazarıyım: Benim demek istediğim şu; güven düzeyi orta seviyede olan büyük ekiplerde ya da açık kaynak gibi düşük güven ortamlarında, LLM yüzünden yalnızca gönderilen koda bakarak geliştiricinin yeteneğini değerlendirmek giderek zorlaşıyor. Karşı tarafın eğilimini anlayamadığınız için sonunda "tam güvensizlik" moduna geçip tüm kodu didik didik incelemek zorunda kalıyorsunuz. Eskiden hızlı inceleme için kullandığınız kısayollar artık işlemiyor ve böyle bir kültüre alışmış organizasyonlarda bu oldukça acı verici olabilir. Zaten yüksek güvene sahip ekiplerde bu sorun hiç tanıdık gelmeyebilir
  • Eskiden A=B ise yüksek B, A'nın da iyi olduğu anlamına gelirdi. Şimdi A+Ai=B oldu; yani B yüksek olsa bile A yüksek olmayabilir. Ve AI'ın şu anki durumu olasılıksal olduğu için, bazen hiçbir şey yapmamaktan bile daha kötü sonuç verebiliyor
  • "Yalnızca çalışan koda güvenirim" dediniz ama güvenin dayanağı, geliştiricinin kodun gerçekten hatasız olduğunu önceden biliyor olmasıdır. Ancak karmaşık sistemlerde, kodun diğer parçalarla nasıl etkileşeceğini ve hangi uç durumların çıkabileceğini anlamak için yazanın bağlamın tamamını kavraması gerekir. Eğer kodu LLM yazdıysa ve geliştirici içeriğin tamamını anlamıyorsa, bu doğrulama yükü inceleyene kayar ve aşırı yük oluşturur. Söylenen tam olarak bu
  • LLM ile kod yazarken birkaç kez iyi sonuç alınca aşırı özgüven oluşuyor ve testler ihmal ediliyor. Gerçekte sorunların çoğu iletişim hatalarından çıkıyor. Çalışan kişi genel görevi net anlıyor olsa da LLM durum tutmakta zorlanıyor ve bağlam muğlaksa saçma varsayımlar yapabiliyor. 4o gibi, ek bilgiyi önce sürekli talep eden yaklaşımın tüm kod üretim modellerinde standart olmasını isterdim; gerçekten çok fazla sorunu önleyebilirdi
  • Güven yalnızca çalışıp çalışmama üzerinden oluşmaz. Değişiklikleri açıkça açıklamak, geçmişte iyi katkılar yapmış olmak, uygun değişim birimleri kullanmak (uygun büyüklükte commit'ler gibi), sorunların önceliğini doğru belirlemek (özellik eklemeden önce bug düzeltmek), mevcut kodu sürdürebilmek, istikrarlı faaliyet göstermek gibi birçok unsur da önemlidir

• Zaten o çağdayız. "Bunu gözden kaçırdığım için özür dilerim, dediğiniz doğru" cümlesini aşırı sık görüyorum. 10 seferin 8-9'unda karşıma çıkıyor. Öte yandan LLM'in ürettiği kodu anlamsızca kopyala-yapıştır edip sonra beklediği gibi olmayınca öfkelenen insanları da sık görüyorum. Aslında bu daha iyi. Açıkça bozuk olan şey, görünüşte düzgün duran şeyden daha iyidir diye düşünüyorum

  • Benim deneyimimde LLM'ler, gereksinimleri karşılamaktan çok testleri geçirecek şekilde kodu değiştirmeye eğilimli
  • LLM'i tarayıcı sohbet botu olarak mı kullanıyorsunuz? Biz doğrudan koda erişebilen AI agent kullanıyoruz; çok daha az konuşuyor ve etrafımdaki junior'ların çoğundan gerçekten daha iyi işler çıkardığı da oluyor. Kısa ve belirli görevleri iyi yapıyor, biraz code review yeterli olduğu için neredeyse doğrudan kullanıyoruz. Tabii prediction engine gerçek mühendislik yapmayı bilmiyor. Mesela Python generator açıkça istenmezse hafızayı korkunç tüketen kod ürettiği çok oluyor. Ama etrafımdaki Python geliştiriciler de benzer hataları sık yapıyor. Hatta bu yüzden "add feature" demek yerine net bir spec yazmaya zorlaması faydalı oluyor. AI agent'ın en kullanışlı olduğu yer, kimsenin ilgilenmek istemediği legacy code. Eskiden faksla gelen bir belgeden 200 koordinat üzerinden veri çıkaran bir sistemimiz vardı; 30 yılı aşkın süredir değişmeden kullanılıyordu, yakın zamanda belge değişti. Copilot koordinatları düzeltmek için 30 saniye harcadı. İnsanın en az bir gününü alacak işti. Ama böyle bir kodlama çağında nasıl uzman olunacağını bilmiyorum
  • 10 seferin 8-9'u çok abartılı. %100 uydurulmuş bir istatistik

• Önceki soyutlama araçları karmaşıklığı azaltırken o soyutlamanın "doğruluğunu" temel varsayım olarak alıyordu. Elbette kusursuz değillerdi ve hataları vardı, ama sorun özlerinde değil uygulamalarındaydı. Bir kez yamalanınca daha sağlam hale geliyorlardı. Buna karşılık LLM'ler olasılıksal tahmin motorları; belli bir süre boyunca ancak yaklaşık doğruluk gösteriyorlar. Burada yazarın gözden kaçırdığı nokta şu: kusurlu olasılıksal ajanlarla da güvenilir deterministik sistemler kurulabilir. Örneğin bir garbage collection aracına, yazarına güvendiğim için değil, aracın yeterince test edildiğini ve istediğim gibi çalıştığının kanıtlandığını gördüğüm için güvenirim. Gelecekte test güdümlü geliştirmenin daha da güçleneceğini düşünüyorum. Güven değil, doğrulama söz konusu

  • Otomatik testlerin tüm sorunları yakalayabileceğini düşünmek safça. Eşzamanlılık, kaynak yönetimi, güvenlik açıkları gibi otomatikleştirmesi zor çok fazla şey var. Üstelik testlerin kendisini kim doğrulayacak? Kod da testler de ayrı ayrı mantık uygular ve bazen hatanın kaynağı kod değil test tarafı olur. Testlere de koşulsuz güvenilmemeli
  • Ben yazının yazarıyım: Burada aracın etkisinden çok aracın kendisine odaklanıyorum. Örneğin modelin bizzat garbage collector olarak çalıştığını, programın memory dump'ını alıp gereksiz blokları serbest bırakmaya karar verdiğini düşünün; bu yargıya asla kalıcı biçimde güvenemezsiniz. Ne kadar "patch" ya da "fine-tuning" yapılırsa yapılsın bir sınır var. JVM gibi deterministik çıktı üreten sistemlerde bir hata bulunduğunda, bir kez düzeltildi mi o hata kalıcı olarak ortadan kalkar. LLM'lerde durum böyle değil. Bence eski soyutlamalarla LLM dünyası arasındaki temel ayrım burada. LLM'lerin endüstri üzerinde çok büyük etkisi olacağını düşünüyorum ama tarihsel örnek az olduğu için gerçekten bilinmeyen bir alandayız
  • "Olasılıksal bir kaynaktan (entropy machine) güvenilir deterministik sistem çıkar" kısmı bana epey radikal geliyor. Ve TDD de hep tüm sorunları çözen sihirli araç gibi sunuluyor. Oysa yanlış testlerle tamamen yanlış yazılım üretildiğini utanç verecek kadar çok gördüm

• LLM'lere duyulan tepkinin bir faydası yok. Bugün LLM'ler geliştirici verimliliğini artırıyor. En azından daha az deneyimli geliştiriciler için daha da faydalı. Verimliliği ciddi biçimde artıran araçlar, kim ne derse desin kolay kolay terk edilmez. Elbette büyük hatalar yüzünden büyük servislerin uzun süre çökmesi gibi zarar örnekleri çıksa bile, verimlilik önemli olduğu sürece teknoloji durmaz. Bu yüzden gerçekçi olan, zayıflıkları çözmekten (hafifletmekten) ve teknolojiyle birlikte ilerlemekten başka bir yol olmaması. Bu süreçte hafifletici önlemler verimlilik artışını bozarsa by-pass edilir; teknolojiyle uyumlu tamamlayıcı çözümler yerleşir

  • "LLM geliştirici verimliliğini artırıyor" sözü kişiye ve duruma göre çok değişiyor. Benim deneyimimde "10x üretkenlik" diyenler çoğunlukla junior frontend geliştiriciler ya da startup'ta sık sık ilk uygulamaları yapan geliştiriciler oluyor. Elbette bunlar da iyi örnekler ama böyle geliştiricilerle gömülü C alanında kıdemli bir geliştirici adeta farklı bir dil konuşuyor. Bu yüzden AI verimlilik tartışması çoğu zaman farklı bağlamların birbiriyle konuşması gibi. Ayrıca "makul kullanım" açısından bakınca AI agent fikrinin kendisi iyi mi, ondan da emin değilim. Copilot olayı yüzünden hem MS hem AI alay konusu oldu. AI'a işi otonom biçimde bırakmak her zaman akıllıca olmayabilir. Benzer şekilde blockchain de kripto çılgınlığının zirvesinde aşırı abartılmış birçok örnek sundu ama Coinbase gibi gerçekten anlamlı bir nişe oturan örnekler de vardı. 2020'de IBM kahve çekirdeği tedarik zincirini blockchain ile yönettiğini iddia ediyordu (2025'ten bakınca Twitter şakası gibi, ama o zaman ciddiydi). Sonunda bugünkü AI agent'lar ve üretken yapay zekanın başka uygulamaları da ileride aşırı hype örnekleri olarak görülebilir Copilot olayı Forbes yazısı
  • "Daha üretken" ifadesi tekrar tekrar geçiyor ama bunun anlamı insan/AI kombinasyonunun sonuçta kullanıcı gereksinimlerine daha iyi uyduğu değil; sadece "daha fazla kod üretiliyor" demek. LLM'in 2 bin satır kodu silen bir PR hazırladığına dair bir hikâye hiç duymadım. "Mühendis verimliliğini artırıyor" demek fiilen daha çok kod yazılıyor demek
  • Yazarın niyetinin aslında eleştirel olduğu düşüncesi yanlış. Mesele LLM kullanılsın mı kullanılmasın mı ikilemi değil, risk yönetimi ve hafifletme üstüne odaklanmak. Bir benzetme yaparsak, otomobil geliştirmeye karşı çıkmaktan çok, otomobillerin patlama riski olduğu için o patlamayı azaltmaya daha çok odaklanalım demek gibi
  • Bana göre orijinal yazı "anlamsız yakınma"dan çok, LLM ile çalışırken kolayca gözden kaçan tuzaklar ve ekip içi tamamlayıcı önlemler üzerine gerçekçi bir düşünme denemesi
  • React ilk çıktığında öğrenmeyip sonra pişman olduğum zamanı hatırlıyorum. GPT'ye karşı isteksizliğim hâlâ var ve çevremde "chatGPT dedi ki" ya da "bu chatGPT kodu" gibi laflar dönüyor; ben ise bizzat uğraşarak kod yazmakla gurur duyuyorum. GPT kullanmıyorum ama aslında Google ya da Stack Overflow'u yavaş bir GPT olarak da düşünebilirsiniz

• "Katkı yapılan kodun LLM ürünü olmadığını, özgün olduğunu ve tamamen anlaşıldığını taahhüt et" ya da "çoğu iş elle yapılsın" gibi politikalar yerine, sadece çıktıya odaklanmak gerekir. Katkı veren kişinin değişiklikleri iyi anladığını istemek doğru. Ama "junior'lar belirli bir süre LLM araçlarını kullanmasın ya da sınırlı kullansın" gibi politikalar pek iyi değil. Onboarding sırasında yaşanan dağınık ortam kurulum problemlerinde LLM çok yardımcı oluyor. Ayrıca kodu ve dokümantasyonu anlamakta da iyi; yararlı bir metin arama ve özetleme aracı olarak da işe yarıyor

  • Onboarding aslında büyük ölçüde rastgele ortam sorunlarını çözmeyi öğrenme süreci. Tüm zorlukları ve karmaşıklığı otomasyonla yok edersek, sonra kimse böyle durumlarda ne yapacağını bilmeyecekmiş gibi geliyor. Bunu sadece ben mi düşünüyorum merak ediyorum

• "AI Cliff" (LLM doğruluğunun bir anda sert biçimde düşmesi) kavramını ilk kez duydum. Başkaları da bunu yaşadı mı merak ediyorum

  • Ben sık yaşıyorum. Kod karmaşıklığı belli bir eşiği geçince LLM tüm bağlamı kafasında tutamıyor ve alakasız davranmaya başlıyor. Benim rolüm, LLM'in karşısına çıkan karmaşıklığı yönetmek. Bugünkü LLM'ler zaman geçtikçe yapıyı daha karmaşık hale getirme eğiliminde. Genelde ondan refactor isteyip sadeleştiriyorum ya da çok karmaşıklaşırsa bizzat kendim toparlıyorum. Şu anki LLM'lere uzun süre bırakırsanız sonunda devasa bir Rube Goldberg tarzı karmaşa çıkarıyorlar ve bunu eninde sonunda yine insanın temizlemesi gerekiyor. Deneyimli geliştiriciler LLM'in ne noktada sizi açık denize sürüklediğini çabuk fark edip erken dönebiliyor; acemiler ise ne olduğunu fark etmeden tamamen kaybolabiliyor
  • Buna bazen context drunk diyorum. Diyelim giriş bağlamı 10 bin token ve %99 doğru. LLM 1000 token'lık bir yanıt veriyor ve bunun yalnızca %90'ı doğru. Bu gidip gelme sürdükçe bağlam penceresinin çoğu, LLM'in ürettiği daha düşük doğruluklu çıktının tekrarlarıyla doluyor. Hatalar birikiyor ve yakın tarihli bilgi daha ağır bastığı için giderek daha saçma hale geliyor. Bu sadece kodda değil düzyazıda da oluyor
  • Ben buna context rot diyorum. Bağlam yığıldıkça çıktı kalitesi düşüyor. Sohbet ya da alakasız içerik ne kadar fazlaysa kalite o kadar hızlı çöküyor. Özellikle chain of thought (COT) bağlamda kaldığında, düşünce sapmışsa onun izi bozulmayı daha da artırıyor. Ben şahsen bağlamın bazı bölümlerini ayıklayan bir pruning özelliği olmasını isterdim. Ben genelde kendim özet çıkarıp yeni oturuma taşıyarak context rot ile başa çıkıyorum
  • Bunu sadece vibe coding gibi sohbet arayüzlerinde yaşadım; agent tipi araçlarda daha seyrek çünkü kod bağlam penceresini kendi yönetiyor ve doğrudan dev tooling çalıştırıp sanity check yapabiliyor
  • İş amaçlı AI oturumlarını sık sık sıfırladığım için "AI cliff" hissini pek yaşamıyorum. Ama yaratıcı roman yazarken bağlam uzunluğu ve tutarlılığı önemli olduğundan, AI'ın bir noktadan sonra karakter kişiliğini koruyamayıp garip davranmaya başladığı olmuştu. Geri döndürülemez gibi hissettirdiği için çok tuhaf bir deneyimdi

• Orijinal yazı, birçok kişinin yorumunu özetlemeyeceğini söylüyor ama pratikte biraz öyle yapıyor gibi. Yine de PR'da AI üretimi kod içeren dosyalar için bir işaret olsa iyi olurdu. LLM kodu ile insan kodunun hata tipleri farklı; bunları ayırarak inceleyebilsek zaman kazandırır. Büyük organizasyonlarda böyle bir politika deneyimleyen oldu mu ya da bunun için hazır otomasyon araçları var mı merak ediyorum. Şirketler LLM üretimi kod oranını ölçüyorsa, daha ayrıntılı metrikler için böyle araçlar zaten vardır belki

  • Ben yazının yazarıyım: Gerçekte ekip içi güven ve LLM üzerine bu kadar fazla tartışma görmediğim için yazılı hale gelmiş örnekler görmedim. Bunun yanlış bir çevrede çalışmamdan mı kaynaklandığını, yoksa ana akımda görülmesinin zor olmasından mı bilmiyorum