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 yorumları

• https://archive.is/5I9sB
  Eski tarayıcılarda da çalışıyor ve CloudSnare’den geçerkenki durum dışında JavaScript gerektirmiyor.

• Bir arkadaşım hep “inovasyon güvenin hızında gerçekleşir” der; GPT-3’ten beri bu cümle aklımdan çıkmıyor.
  Doğrulama çok maliyetli ve bu maliyeti düşürmenin temel yolu güven. LLM’leri nasıl güvenilir hale getirebileceğimizi bilmiyorum. Hem kodda hem doğal dilde son derece akıcılar ama aynı zamanda fraktal gibi sonsuza uzanan tavşan deliklerine isteyerek dalıyorlar ve bir insan yapsa kötü niyetli sayılabilecek davranışlar da gösteriyorlar.

  • Yazar olarak o cümleyi sevdim. Birkaç paragrafta anlatmaya çalıştığım şeyi çok özlü ifade ediyor.
    Her şeyi her zaman doğrulamak zorunda olduğumuz bu yeni dünya epey yorucu ve açıkçası çok yavaş.
  • LLM çıktısına tamamen güvenemezsiniz ama onu temizleyip hasar alanını sınırlayabilirsiniz. Kullanıcı girdisini temizlemek, sızma testleriyle savunma yapmak, gizli değerleri dotfile’da saklamak gibi; sonunda “en iyi uygulamalar”a ve bir tür “SOC-AI uyumluluğu” standardına yakınsayacaktır.
    Göz ardı edilemeyecek kadar faydalılar ve güven her zaman tuğla tuğla inşa edilir. İnsanların da en başta pek güvenilir olmadığını unutmamak gerek. Araba kullanmakta olduğu gibi, önceden tanımlanmış yollar üzerinde daha az bug içeren kod üretme becerisi yakında insanları geride bırakacak gibi görünüyor; sonrası ise karmaşıklığı iyileştirmek için temel beceriler mücadelesinden ibaret.
  • “İnovasyon güvenin hızında gerçekleşir” sözü daha fazla açıklama gerektiriyor. Elektriği, uçuşu, radyoaktiviteyi keşfettiğimizde bunlara ne kadar güven vardı?
    Bilimde ilerledikçe güven inşa edilir.

• İş yerinde bunu beklemediğim bir biçimde yaşadım. Bir iş arkadaşımla ilerleme göstermek için baskı altındaydık ve üzerinde çalıştığım oldukça büyük bir refactoring işini hızlıca merge etmeye karar verdim. Taslak bir PR’dı ama ivme kazanmak için merge ettik; sonraki hafta test edilmemiş kod alanlarında birkaç bug çıktı.
  Debug sırasında iş arkadaşım, kodu yapay zekayla yazmış olduğumu varsaydığını belli etti ve sonradan yapay zeka üretimi bir şeyi anlamaya çalışmanın sinir bozucu olduğunu söyledi. Ama bu kodda yapay zeka kullanmamıştım. Elbette kod yazarken yapay zeka kullanıyorum, fakat bu kodu tüm tasarımı dikkatlice düşünerek elle yazmıştım. Bug’lar refactoring’in temel bir kusurundan değil, mevcut kodu değişen API’ye uyarlarken yapılan küçük eksiklerden kaynaklanıyordu.
  Sonuçta iş arkadaşımla aramızdaki gerilimi açıkça konuşabildiğimiz için bu güven inşa eden bir deneyim oldu. Şu anda yaşanan şeyin gücüyle epey yumuşak bir şekilde yüzleşmiş olduk. Geriye dönüp bakınca böyle çözüldüğü için seviniyorum; başka bir çalışma ortamında çok daha dağınık bir hale gelebileceğini hayal ediyorum. Dikkatli olmak gerek.

  • Bu oldukça ciddi ve aşağılayıcı bir suçlamaya dönüşebilir. Bir oyun geliştiricisi kendi karakterinin sesini kendisi kaydetmişse ama tonlama donuk ya da tuhafsa, birileri buna AI diyecektir. Anlamadığı ya da beğenmediği sanat mı? Muhtemelen AI’dır diyecekler. Eurovision’a gönderilen parça kötü gelirse AI derler. Bazı insanlar bu lafı hafife alarak söylüyor ama ben söylemem.
    Yaklaşık 4 yıl önce büyük bir aptallık yaptım. Yerel bir gazete, bir kişi hakkında fotoğrafı başlıca kanıt olarak gösterip saçma iddialar içeren bir haber yayımladı; ben de editöre doğrudan e-posta gönderip görüntünün manipüle edildiğine neden emin olduğumu anlattım. Mantığım kendi yanlış anlamama dayanıyordu: söz konusu kişinin bir meet-and-greet etkinliğinde birçok kişiyle poz verirken konumunun ve duruşunun neredeyse hiç değişmemesini yanlış yorumlamıştım. Editör incinmiş bir şekilde benimle alay eder gibi yanıt verdi; ben geri adım atmayınca, kışkırtıcı biri değil sadece aptal olduğumu fark etti ve fotoğrafın alındığı yayımlanmamış tam videoyu paylaştı. O zaman derin bir özür diledim ve bağış da yaptım; sonraki 1 yıl boyunca egom olması gerektiği kadar küçülmüş kaldı.
    E-postayı göndermeden önce de yanlış suçlamada bulunmak istemediğim için sakin düşünen arkadaşlarımla fotoğrafı paylaşmış ve fikirlerini sormuştum; onlar da görüntünün manipüle edilmiş olma ihtimalinin yüksek olduğu sonucuna vardığı için epey kendime güveniyordum. Şimdi o gazeteye ve ilgili kişilere örtük olarak güveniyorum ama tek bir kişiyi ikna etmek bile gerçekten çok iş gerektirdi.

• Varsayımı anlamak zor. Birinin iyi kod yazdığına güveniyorsanız, bu güven o kişinin kodunun iyi çalıştığını öğrendiğiniz içindir; yoksa o kişinin zihninde “iyi kod üreten” apriori bir zihinsel model bulunduğu için değil
  Biri LLM kullanarak hatasız kod üretirse ona güvenirim. Biri LLM kullanarak bol hatalı kod üretirse güvenmem. O kişinin yalnızca kendi kafasını kullanarak kod ürettiği zamandan ne farkı var?

  • Yazar olarak, temel varsayım çok büyük ekipler gibi orta güven ortamlarında ya da açık kaynak projeler gibi düşük güven ortamlarında yatıyor
    LLM yüzünden, yalnızca gönderilen koda bakarak yamayı çıkaran geliştiricinin kalitesini anında değerlendirmek çok zorlaşıyor. Karşınızdakinin nasıl biri olduğunu kestiremiyorsanız “sıfır güven”e dönüp her şeyi çok sıkı incelemeniz gerekir. Yani artık güvenli bir “inceleme kestirmesi” yok; işi bu tür sinyallere dayanarak yürüten yerlerde bu acı verici olabilir. Zaten yetkin ve yüksek güvene sahip bir ekipteyseniz bu sorun geçerli değildir; hatta kavramın kendisi yabancı gelebilir
  • “Kod iyi çalıştığı için güvenmeyi öğrendik” denmiş ama iyi çalışmasından çok daha fazlası var. Koda yakın olan ama kodun kendisi olmayan pek çok ipucu bulunur
    Katkıda bulunan kişi değişiklikleri iyi açıklıyorsa daha çok güvenirim. Geçmişte mükemmel işler yaptıysa daha çok güvenirim. Değişiklikleri makul commit’ler gibi iyi birimlere ayırıyorsa daha çok güvenirim. Yeni özellik eklemeden önce hata düzeltmek gibi doğru sorunları seçiyorsa daha çok güvenirim. Mevcut kodu sürdürebildiğini gösteriyorsa, sadece üstüne ekleme yapmasından daha çok güvenirim. Düzenli katkı yapıyorsa daha çok güvenirim
  • LLM kodu birkaç kez üst üste iyi çalışınca aşırı güvenip yeterince test etmemek kolaydır; sonra da bir şeyi kaçırırsınız
    Sorun çoğu zaman iletişim hatasıdır. Görev, işi yapan kişi için açık olabilir; ancak sık bağlam sıfırlamaları nedeniyle LLM’in de büyük resmi bildiğini garanti etmek zordur ve belirsizlik varsa aptalca varsayımlar yapması kolaydır. 4o’nun deep research özelliğinin bir şey yapmadan önce ek bilgi sorma biçiminin kod üretiminde de standart olması gerektiğini düşünüyorum. Bu, dağ gibi sorunu önleyebilir
  • “Biri LLM kullanarak hatasız kod üretirse ona güvenirim” denmiş ama o kodun gerçekten hatasız olduğunu bilmek, zaten o kişiye güvendiğiniz için mümkün olan bir şey
    Bazı durumlar basittir. Bu rutin istenen değeri döndürüyor mu döndürmüyor mu meselesidir. Ama başka durumlar çok daha karmaşıktır; sistemin diğer parçalarıyla nasıl etkileşeceğini ve kolay fark edilmeyen sınır durumlarının neler olacağını öngörmek gerekir. Böyle bir durumda “hatasız” kod yazmak için yazarın kodun sonuçlarını anlaması gerekir; geliştirici LLM’in yazdığı kodun tam olarak ne yaptığını anlamıyorsa bu sonuçları da anlayamaz. O zaman yük inceleyiciye geçer ve inceleyicinin iş yükü artar. Varsayım buydu
  • İnsanlar LLM kullandığında, bir araçla iş yapmıyor; araca iş yaptırıyorlar. LLM ne hesap makinesidir ne de internet
    İyi bir pratik kural, LLM’in dahil olduğu işleri doğrudan reddetmek ve LLM’in yazdığı iletişimleri de görmezden gelmektir. İngilizceyi yabancı dil olarak kullanan biri için bile, ChatGPT’nin onun adına konuşmasındansa o kişinin “aksak” İngilizcesinin çok daha iyi olduğunu düşünüyorum. LLM’lerin ciddi sorunları daha belirgin hâle geldikçe bu tür politikaların genel standart olacağını düşünüyorum ve öyle olmasını umuyorum

• LLM, her türden kötü işi inandırıcı biçimde iyi bir iş gibi gösterir. Bu yüzden yapay zeka kullanan birinin çıktısına otomatik olarak şüpheyle yaklaşmak mantıklı.
  Eskiden akrabalarımdan birinin dolandırıcı olduğu ortaya çıkmıştı. Yakalandıktan sonra onunla ilişkimi kesip onu tanımadığımı söyledim; o da “Ben, senin 10 yıldır tanıdığın o kişiyim” dedi. Ben de “Öyle olabilir. Ama şimdiye kadar onun kim olduğunu hiç bilmediğimi ve bundan sonra da bilemeyeceğimi ancak şimdi fark ettim” diye cevap verdim.
  Hepimiz hayatımızdaki insanların aktif biçimde bize zarar vermeye çalışmadığını varsayarız. Bu güven kırıldığında çok sert kırılır. Yapay zeka kullanan hiç kimse “bu benim işim” diye iddia edemez. Çünkü bunun gerçekten sizin işiniz olup olmadığını bilemeyiz. Yapay zeka kullanan biri, onu bütünüyle anlamadığı sürece iyi bir iş olduğunu da iddia edemez; muhtemelen de bütünüyle anlamıyordur. Öğrencilerimin önemli bir kısmının yazdıklarımı okuyup anladığını iddia ettiğini, ama gerçekte anlamadıklarını gördüm. Ya ben bir yapay zeka olsaydım ve onlar benim çalışmamı alıp yazar olarak kendi adlarını koysaydı? Hiçbir şeyi açıklayamaz, savunamaz ya da üzerine devam çalışması yapamazlardı. Bu sorun yapay zekadan önce de vardı, ama şimdi on kat daha kötüleşti.

  • Bu bakış açısının nereden geldiğini anlıyor ve saygı duyuyorum. Bu teknolojinin yarattığı sahicilikten uzaklık korkusu için “dolandırıcı” benzetmesi makul. Ancak full-stack yazılım geliştirmenin derin siperlerinde bulunmuş biri olarak başka bir bakış açısı sunmak istiyorum.
    Kullanışlı LLM’ler ortaya çıkmadan önce karmaşık uygulama programlamaya “10 bin saatten fazla” harcamış biriyim. Yıllar boyunca her gece dokümanlara ve başkalarının kaynak kodlarına gömülerek full-stack ustalığına tamamen daldım. Sonunda bu yoğunluk ciddi bir tükenmişliğe yol açtı; sağlığım bozuldu, evliliğim sarsıldı. Uygulamayı yayımladıktan hemen sonra toparlanmak için 3 yıl boyunca tamamen bırakmak zorunda kaldım ve bir daha asla elime alamayacağımdan emindim.
    LLM’lerin kod konusunda epey iyi hale geldiğine dair çok şey duyunca temkinli biçimde bilgisayarın başına döndüm; işte o noktada deneyimim bu kaygılardan ciddi biçimde ayrılıyor. “Yapay zeka kullanan biri ‘bu benim işim’ diyemez” sözüne katılamıyorum. LLM kullandığımda ben tasarımcı ve nihai denetçiyim. Vizyonu ben yönlendiriyorum, sistemi ben tasarlıyorum, LLM’in ürettiği her satırı diff aracıyla inceliyorum. Yakın zamanda işimin fiyat teklifi motoru için LLM ile birlikte karmaşık bir optimizasyon modeli geliştirdim. Gerçek bir optimizasyon modeli kullanmak her zaman “doğru” yöntemdi; ama eskiden kütüphanenin tüm ayrıntılarını öğrenmek ve başkalarının kodunu okumak için aylar süren zahmetli çalışma gerekirdi. Bu kez bir haftada bitirdim. Bu bana kendi işim gibi mi geliyor? Kesinlikle evet. Sadece yorulmayan, çok yetenekli ama zaman zaman kusurlu bir yardımcım vardı.
    Kullanıcının “bütünüyle anlamayacağı” iddiasında da benim deneyimim tam tersini gösteriyor. Önemsiz olmayan işlerde LLM’i etkili kullanmak için, LLM’i yönlendirmek ve sık ortaya çıkan ince hataları yakalamak adına temelleri daha derinden anlamak gerekiyor. Yıllara dayanan deneyimim olmasaydı karmaşık çok modüllü geliştirmeyi yönlendiremez, çıktıları debug edemez ya da inandırıcı biçimde iyi görünen bir işin aslında N+1 problemi gibi nedenlerle yanlış olduğunu anlayamazdım.
    Öğretmenlik deneyiminize empati duyuyorum. Öğrencilerin bu araçlarla anlamış gibi yapması gerçek ve zor bir sorun. Akademide amaç öğrenme süreci, yani o 10 bin saatin anlamlı bir kısmını kazanmaktır. Ama profesyonel dünyada amaç sonuçtur ve bu, daha iyi sonuçlar elde etmek için yeni ve güçlü bir araçtır. Öğretmenlerin bu yeni gerçeklikte öğrencileri nasıl eğitmesi gerektiğini bilmiyorum, ama LLM kullanımını şeytanlaştırmak muhtemelen en iyi yol değil.
    Benim için bu, kötü işi iyi göstermedi. Harika işi yeniden mümkün kıldı ve aynı zamanda hayatımı geri almamı sağladı. Beni ve ailemi yıpratmadan yazılım geliştirme zanaatının keyfini geri verdi; şimdi hayatım çok daha dengeli ve bunun için minnettarım.

• Benim için zaten durum böyle. “Gözden kaçırdığım için üzgünüm, tamamen haklısınız” cümlesini sayısız kez okudum. Yaklaşık 10 seferin 8-9’unda.
  Öte yandan insanların ücretli LLM tarafından üretilmiş kodu hiç düşünmeden kopyalayıp yapıştırdığını, bekledikleri gibi çalışmayınca da öfkelendiğini sürekli görüyorum. Bu arada bu daha iyi senaryo. Çünkü dışarıdan çalışıyor gibi görünen bir şeydense bariz biçimde bozuk olması daha iyi.

  • Deneyimime göre LLM, gereksinimleri karşılamaktan çok testleri geçmek için kodu değiştirmeye son derece güçlü biçimde eğilimli.
  • LLM’i tarayıcıdaki chatbot olarak mı kullanıyorsunuz? Bizim doğrudan kod erişimi vererek kullandığımız AI agent’lar o kadar geveze değil. Ayrıca en azından buralarda birçok junior programcıdan daha yetkin görünüyorlar. Kısa ve net görevleri agent’a verdiğinizde, kod incelemesi dışında pek bir şey gerektirmeyecek kadar iyi yaptığı noktaya neredeyse geldik.
    Yine de tahmin motoru hâlâ gerçek mühendislik yapamıyor. Python generator gibi bir şey kullanmasını özellikle söylemezseniz, muazzam miktarda bellek tüketen kod üretmesi çok olası. Ne yazık ki bu, tanıdığım birçok Python programcısından da çok farklı değil; ama aynı zamanda LLM’in söylendiği kadar tam olarak kötü olduğuna dair bir örnek. Olumlu tarafı ise insanları “özellik ekle” şeklindeki tek satırlık taleplerden daha ayrıntılı spesifikasyonlar yazmaya gerçekten yöneltmesi.
    Bizim için AI agent’ların en faydalı olduğu yer, kimsenin öncelik vermediği legacy code. Önceki binyılda yazılmış bir veri çıkarıcı var; faksla gelen belirli bir belge türünden veri çıkarmak için hardcode edilmiş yaklaşık 200 koordinat kullanıyor. Belge yaklaşık 30 yıl boyunca değişmediği için iyi çalışıyordu, ama yakın zamanda değişti ve Copilot koordinatları düzeltmeyi yaklaşık 30 saniyede yaptı. Bir insan için muhtemelen aşırı sıkıcı, tüm gün sürecek bir iş olurdu. Ancak vibe coding çağında sektörümüzün uzmanları nasıl yetiştirmeyi düşündüğü konusunda hiçbir fikrim yok.
  • “10 seferin 8-9’u” değil. %100 uydurma bir istatistik.

• LLM'lere karşı savaşmak, rüzgâra karşı işemek gibi
  Mevcut biçimiyle LLM'ler geliştiricileri daha üretken kılıyor gibi görünüyor. Daha az deneyimli geliştiricilere, deneyimli geliştiricilere kıyasla daha büyük bir fayda sağlama ihtimali de var. Üretkenlik artışı, hatta belki çok büyük çarpanlarla üretkenlik artışı, herhangi bir nedenle bu teknolojiye karşı çıkanların koyduğu engeller yüzünden terk edilmeyecek
  Yeni bir üretkenlik aracının muazzam zarar verdiği örnekler, örneğin büyük bir servisi kayda değer süreyle durduran bir hata ortaya çıksa bile, bu teknoloji ciddi üretkenlik sağlıyorsa durdurulmayacak. Teknolojiyle birlikte çalışmak ve zayıf yönlerini hafifletmek tek makul yol. Ve bu hafifletme önlemleri, yeni teknolojinin üretkenlik kazanımlarını tamamen ortadan kaldıran bir kurallar bütünü olmamalı. Önlemler, teknolojinin benimsenmesini artıracak şekilde teknolojiyle birlikte işlemeli; aksi hâlde etrafından dolaşılır

  • “Mevcut biçimiyle LLM'ler geliştiricileri daha üretken kılıyor” sözü bence geliştiriciye ve ne başarmaya çalıştıklarına göre çok değişiyor
    Benim deneyimime göre LLM sayesinde üretkenliğinin 10 kat arttığını güçlü biçimde söyleyenler genelde nispeten junior frontend geliştiricileri ya da sürekli sıfırdan yeni uygulama yapan seri startup geliştiricileri. Elbette bunlar tamamen geçerli kullanım örnekleri; ama bu yüzden junior frontend geliştiricisi ile senior embedded C geliştiricisi, yapay zeka üretkenlik artışını konuşurken kolayca farklı yönlere düşebiliyor
    Teknolojiyle birlikte çalışıp zayıflıkları hafifletmenin tek makul şey olduğunu söylemek yerine, sadece daha sağduyulu kullanmak yeterli. Örneğin yapay zeka “ajanı” fikrinin kendisi iyi mi? Yakın zamandaki Copilot olayı[0], MS'i ve yapay zekayı alay konusu gibi gösterdi. Yapay zekanın işleri otonom olarak yapmasını sağlama girişiminin kendisi pek de akıllıca olmayabilir
    Yakın tarihli bir benzetme olarak blockchain ve kripto paralar var. Sevseniz de sevmeseniz de Coinbase gibi şirketlerin başarısına bakınca blockchain'in gerçek ama dar bir kullanım alanı bulduğu açık. Fakat kripto para hararetinin yaşandığı dönemde “kahve çekirdeği tedarik zincirini blockchain ile takip edeceğiz” gibi şeyler söyleyen insanlar vardı. 2025'te Twitter abartı şakası gibi geliyor ama 2020'de IBM gerçekten bunu satmaya çalışıyordu[1]. Bir gün geriye dönüp baktığımızda yapay zeka ajanlarının ya da bugünkü üretken yapay zeka uygulamalarının bazılarının bu balonun kahve blockchain'i olduğunu görebiliriz
    [0] https://www.reddit.com/r/ExperiencedDevs/comments/1krttqo/my...
    [1] https://www.forbes.com/sites/robertanzalone/2020/07/15/big-c...
  • Yine “daha üretken” lafı geldi
    Ama bu, model/insan kombinasyonunun kullanıcının ihtiyaçlarını daha etkili karşıladığı anlamına gelmiyor. “Daha fazla kod” ürettiği anlamına geliyor. 2000 satır kod silen bir değişiklik seti çıkaran LLM yok. Bu yüzden “mühendisi daha üretken yapıyor” sözünün üretilen kod miktarıyla ilgili olduğunu anlayabiliyoruz
  • Yazarın aslında söylemediği bir şeye karşı çıkıyorsunuz gibi görünüyor
    Sanki mesele LLM kullanmak ya da kullanmamak şeklinde ikili bir tercihmiş gibi savunuyorsunuz; oysa yazar esas olarak risk azaltmadan bahsediyor. Benzetmeyle söylersek, yazar birkaç arabanın patladığını işaret edip eski atlar patlamadığına göre tutkal fabrikasını çalıştırmadan önce arabaları daha az patlar hâle getirmemiz gerektiğini söylemiş; ama siz yazarın araba geliştirmeye temelden karşı olduğunu düşünüyor gibisiniz
  • Yazı bana rüzgâra karşı işemekten ziyade, özellikle ekip içinde LLM ile kod yazarkenki çeşitli dikkat noktalarını ve bunları hafifletmeye yönelik fikirleri ele alıyor gibi göründü
  • Komik ama React yeni çıktığında öğrenmeyi reddettiğimi hatırlıyorum. Daha erken öğrenseydim muhtemelen piyasaya birkaç yıl daha erken girmiş olurdum
    Şimdi de GPT kullanmak istemeyen bir yanım var; son zamanlarda iş arkadaşlarım “ChatGPT'nin dediğine göre” ya da “bu kodu ChatGPT yazdı” diyor. Kodu kendim yazıp GPT kullanmamaktan gurur duyuyorum ama aynı zamanda Google ve Stack Overflow da kullanıyorum. Ona da GPT'nin daha yavaş bir versiyonu denebilir

• Yazarın, kusurlu ve olasılıksal aktörlerin de güvenilir deterministik sistemler oluşturabileceği noktasını kaçırdığını düşünüyorum
  Bir çöp toplama aracına, yazarın anladığı anlamda güvenilir olduğu için güvenmezsiniz; kapsamlı testlerden sonra amaçlanan işi yaptığının kanıtlanıp kanıtlanmadığına bakıp güvenirsiniz. İleride güvenin zayıfladığı bir tabloyu rahatlıkla hayal edebiliyorum ve bunun sonucunda test güdümlü geliştirmenin daha da ivme kazanacağını düşünüyorum. Güvenme, doğrula

  • Otomatik testlerin tüm sorunları bulacağını beklemek safça. Otomatik olarak bulunması zor birçok sorun türü var. Eşzamanlılık sorunları, kaynak yönetimi hataları, güvenlik açıkları bunlardan bazıları
    Daha önemli soru şu: Testlerin kendisini kim test ediyor? Geleneksel geliştirmede tüm mantık iki kez uygulanır. Bir kez kodda, bir kez de testlerde. Testler kodu denetler; kod da tersine, örtük olarak testleri denetler. Hatanın uygulama kodunda değil testte olduğu durumlar epey yaygındır. Testlere körü körüne güvenip, bir ajanın test hatasını koda kopyalamanın yolunu bulmasını bekleyemeyiz
  • Yazar olarak burada belirli bir aracın çıktısının ne kadar etkili olduğundan çok, aracın kendisi hakkında konuşmak istemiştim
    Çöp toplama örneğini ele alırsak, elbette bir gün ajan tabanlı bir sistemin bir şeyleri ayağa kaldırıp test harness’leri ve hata düzeltmeleriyle döve döve çalışır hâle getirmesi mümkün olabilir. Ama modeli çöp toplayıcının/aracın bizzat kendisi olarak kullandığınızı hayal edin. Örneğin her sweep sırasında program belleğini modele verip gereksiz blokları serbest bırakmasını söylemek gibi. Modelin doğru bellek bloklarını kesin olarak tanımlayacağına asla güvenemezsiniz; hiçbir “yama” ya da “ince ayar” da sizi oraya ulaştırmaz
    JVM gibi geçmiş soyutlamalarda deterministik çıktı, bu örnekte JIT’in ürettiği assembly, hatalıysa o hata yamalanır ve o soyutlama bir daha aynı kusura sahip olmaz. LLM’ler böyle değil. Sektörün tüm karakterini değiştiren geçmiş geliştirme araçlarından söz ederken, benim için bu fark çok önemli. LLM’lerin gelecekteki çalışma biçimleri üzerinde derin etkisi olmayacağını söylemiyorum. Sadece, tarihsel emsali neredeyse olmayan tamamen bilinmeyen bir alana girmiş olduğumuzu düşünüyorum
  • “Kusurlu ve olasılıksal bir aktör güvenilir deterministik sistemler oluşturabilir” demek oldukça büyük bir iddia. Özünde entropi makinesi olan bir sistemin bir şekilde düzen ürettiği mi söyleniyor?
    Test güdümlü geliştirmenin daha fazla ivme kazanacağı sözüne gelince de, TDD’nin yazılım inşa etmenin tüm sorunlarını çözen sihirli mermi gibi neden sürekli sunulduğunu anlamıyorum. Yanlış testlerden yola çıkıp TDD’nin yanlış yazılım ürettiğini gördüğüm durumların sayısı açıkçası utandırıcı derecede fazla

• Çıktıyı belirtmelisiniz, süreci değil. Katkı veren kişinin yamayı anlamasını beklemek iyi bir fikir
  Ama onboarding döneminde junior’ların LLM destekli araçlardan bir süre kaçınmasını önermek ya da şart koşmak berbat bir fikir. Onboarding’de rastgele ortam kurulum sorunları çok olur ve LLM’ler çoğu zaman bu konularda oldukça güçlüdür. Aynı zamanda koda ve belgelere yetişme işidir; paylaşmak isteyeceğiniz harika metin arama/özetleme araçları da vardır

  • Bu tür sorunların içinden geçmeyi öğrenme süreci gerçekten önemli
    Hayattaki tüm zorlukları ve karmaşıklıkları pürüzsüzce ortadan kaldırırsanız, çok geçmeden bir zorluk ya da karmaşıklıkla karşılaştığınızda ne yapacağınızı hiç bilemeyeceğiniz bana çok açık görünüyor. Böyle düşünen sadece ben miyim?

• LLM’nin “belirli bir süre doğruya yakın şeyleri yaklaştırıp sonra zamanla doğruluğunun keskin biçimde düşmesi” olgusunu, yazarın AI uçurumu dediği şeyi ilk kez duyuyorum. Bunu başkaları da yaşadı mı?

  • Oldukça sık yaşıyorum. Kod karmaşıklığı belirli bir eşiği aşınca LLM her şeyi zihninde tutamaz hâle geliyor ve bocalamaya başlıyor. LLM ile çalışırken rollerimden biri, LLM’nin gördüğü karmaşıklığı yönetmek
    Mevcut üreteçler zamanla işleri sadeleştirmekten çok daha karmaşık hâle getirme eğiliminde. LLM’ye daha sade refactor etmesi için prompt veren ya da LLM’nin başa çıkamayacağı kadar karmaşıklaştığında bizzat refactor eden taraf hep ben oluyorum. Bu yüzden en azından mevcut nesil LLM’lerde, sadece “LLM’nin dizginlerini serbest bırakıp” istediğini yapmasına izin verirseniz, sonunda devasa bir Rube Goldberg tarzı keşmekeş üretmesi ve sizin de onu temizlemeye çalışmanız oldukça kaçınılmaz görünüyor
    Yazının ana fikrine bağlarsak, deneyimli biri LLM’nin sizi açık denizlere sürüklemeye başladığını erkenden fark eder ve biraz uzağa açılsa bile sığ sulara dönüş yolunu bulabilir. Yeni başlayan biri ise ne olduğunu anlamadan boyunu aşan derinlikte, denizde yolunu kaybetmiş hâlde kalır
  • Buna bağlam sarhoşluğu dendiğini gördüm
    Bağlam girdisi olarak %99 doğru 10 bin token olduğunu hayal edin. LLM her yanıtladığında %90 doğru 1000 token daha ekliyor. LLM’yi birkaç tur düzelttikten sonra bağlam penceresinin çoğu LLM’nin kendi artık çıktılarıyla doluyor. Daha kötüsü, hataların birikmesi. Doğru olan %90 bile yanlış kod hakkındaki tartışmanın doğru şekilde dışa vurulmasından ibaret; ayrıca LLM daha yeni token’lara daha fazla önem veriyor. Aynı sorun düz yazıda da ortaya çıkıyor
  • Ben buna bağlam çürümesi diyorum. Bağlam doldukça çıktı kalitesi de birlikte aşınıyor. Bağlamda ne kadar çok gereksiz ya da yan konu tartışması varsa çürüme o kadar kötüleşiyor ya da hızlanıyor
    Düşünme modellerinde bu sorun daha da kötüleşebilir. Düşünme süreci tamamen bağlamın içinde olduğu ve düşünce gerçekten yan yola saparsa çürümeyi besleyen zehirli tohumlar ektiği için. Bir şekilde bağlam budamayı uygulayıp ilgisiz bağlam oluştuğunda kesip atabilsek iyi olurdu. Şimdilik çürümenin başladığını hissedince bir özet çıkarıp yeni bir instance’a taşıyorum
  • Chat arayüzüyle vibe coding yaparken, yani geri bildirim döngüsü tamamen olmadığında, bunu yaşadım
    claude code, codex, gemini cli gibi ajan tabanlı araçlarda bu çok daha az sorun. Çünkü bunlar kendi bağlam pencerelerini yönetebiliyor ve geliştirme araçlarını çalıştırarak kendi sanity check’lerini yapabiliyor
  • Bağlam çok büyüdüğünde ya da kirlendiğinde chat’i/ajanı yeniden başlatmak gerekiyor. Eski Windows gibi
    Bu süreç, yeni ajanın yetişebilmesi için mevcut çalışma durumunu belgeleme alışkanlığını kazandırıyor