Kod Artık Daha Ucuz

• Yapay zeka kodlama araçlarının yaygınlaşmasıyla kod yazma maliyeti hızla düştü, ancak ortaya çıkan kodu anlama maliyeti fiilen daha da arttı
• LLM'ler deterministik değildir ve kaynak kodu korumaz; ayrıca çıktı kapsamı genel yazılıma kadar genişler, bu yüzden derleyici çıktısıyla aynı şey sayılamaz
• LLM'ler, insanların anlayabileceğinden çok daha hızlı kod ürettiği için, kimsenin anlayamadığı büyük değişiklikleri önlemek adına kademeli (incremental) kullanım öneriliyor
• Kod ucuzladığında asıl risk karmaşıklık (complexity) olur; bu, sistem ölçeğine göre en az geometrik olarak artarken LLM'ler karmaşıklıktan korkmayan üretken kodlayıcılardır
• Çözüm olarak, kod eklemekten çok kaldırıp sadeleştiren çıkarıcı mühendis (subtractive engineer) öneriliyor ve bilgisayar programlama zanaatının korunması vurgulanıyor

---

Kodun Ucuzladığı Çağ

• Son bir yılda yapay zeka oldukça iyi kalitede kodu çok hızlı ve büyük miktarda üretirken, kod üretim maliyeti ciddi biçimde düştü
• "Asıl sorun zaten kodlama değildi" iddiasına karşı, kodlamanın da sorunun bir parçası olduğu ve bu kısmın yapay zeka kodlama araçlarıyla büyük ölçüde azaldığı savunuluyor
• Geçmişte kodlama becerisiyle gurur duyan geliştiriciler için, saf kodlamanın öneminin azalmasının ne anlama geldiği soruluyor

Anlama Maliyetinin Yükselişi (Understanding is Expensive(er))

• Kod, programcının elinden zahmetle çıkmak yerine toplu halde üretildiğinde, o koda dair anlayışın kendisi ortada olmaz
  • Anlayış gerekiyorsa, bu ancak kod yazıldıktan sonra kodu okuyarak edinilebilir
  • Yaygın kanıya göre başkasının yazdığı kodu okumak, kendi kodunu yazmaktan daha zordur
• "Derleyici çıktısını da anlamıyoruz" şeklindeki yapay zeka savunusu bir kategori hatası (category error) olarak tanımlanıyor
  • Derleyici deterministiktir, LLM ise tasarım gereği deterministik değildir
  • Derleyici iş akışı özgün kaynak kodu korur, LLM iş akışı ise çoğu zaman korumaz
  • Derleyici çıktısı makine kodu gibi dar bir alanla sınırlıdır, LLM çıktısı ise genel yazılıma kadar uzanır
• Çoğu durumda, özellikle de görev açısından kritik yazılımlarda, LLM tarafından üretilmiş kod olsa bile geliştiricinin alttaki kodu anlaması gerekir
• LLM'ler, kimsenin yetişemeyeceği bir hızda kod üretebilir; dolayısıyla anlama hızını aşma riski vardır
  • Bu nedenle devasa değişiklik listelerini tek seferde üretmek yerine kademeli kullanım önerilir
  • Mekanik refactoring için uygun olabilir, ancak bir kod tabanına yeni anlamlar (semantics) sokarken son derece risklidir

Büyücünün Çırağı Tuzağı (The Sorcerer's Apprentice Trap)

• Disney filmi Fantasia içindeki "The Sorcerer's Apprentice" sahnesi, yapay zeka çağı için uygun bir benzetme olarak sunuluyor
  • Çırak, temizlik işinin yükünü azaltmak için süpürgeyi büyüler; ancak süpürge giderek daha hırçın biçimde temizlik yapar ve durum kontrolden çıkar
  • Sonunda büyücü (Sorcerer) geri gelir, durumu yeniden kontrol altına alır, çırağın ahmaklığını azarlar ve karmaşayı giderir
• Bu benzetmenin dersi, çırak değil büyücü olmak gerektiği; bunun için de büyücünün kodu anlaması gerektiğidir

Karmaşıklık Hâlâ Kötü (Complexity: Still Bad)

• İnsanlar geometrik ve üstel eğrileri kavramakta zorlanır; bileşik faiz (compound interest) gibi şeylere adeta masalmış gibi inanır
• Kod ucuzladığında asıl riskin karmaşıklık (complexity) olduğu ve bunun sistem ölçeğine göre en az geometrik, çoğu zaman da üstel olarak arttığı ileri sürülüyor
• LLM'lerden önce de üretken kodlayıcılar (prolific coder) vardı
  • Karmaşıklıktan korkmayan üretken kodlayıcılar, mevcut sorunların üstüne sürekli kod yığar; böylece sistem, yapılan her düzeltmenin en az o kadar yeni hata ürettiği düzeltilemez bir durgunluk durumuna sürüklenir
• LLM'ler hem karmaşıklıktan korkmuyor hem de üretken kodlayıcılar gibi davranıyor; bu yüzden risk oluşturuyorlar

Çıkaran, Sınır Koyan Mühendis (The Subtractive, Constraining Engineer)

• LLM tarafından üretilen kodun risklerine karşı çıkaran ve sınır koyan mühendis (subtractive, constraining engineer) öneriliyor
  • Bu mühendis "hayır" der, LLM çıktısını dikkatle inceler, sadeleştirme önerir ve kararlı biçimde kontrolü elinde tutar
  • Gururunu kendi yazdığı koddan değil, sistemden çıkardığı veya içeri girmesini engellediği koddan (ve katmanlardan) alır
  • Bu tutum, inşa eden birinden (builder) çok bir heykeltıraşa (sculptor) yakındır
• İnşa edici (builder) yaklaşım, sistem tasarımı düzeyinde hâlâ geçerlidir
  • İyi mühendisler, bileşenleri etkili biçimde birleştirip sistem kurmayı bilmelidir
  • Ancak bu düzeyde de gereksiz bileşenleri ve sistem sınırlarını kaldırarak dağıtımı ve etkileşimi sadeleştiren çıkarıcı düşünce tarzı faydalıdır
• Çıkarıcı mühendis, geçmişteki çoğu kodlayıcıdan farklı bir tiptir; "hayır" demeye ve kahramanca yeniden yazımlar yerine mevcut sistemi inceltip iyileştirmeye daha yatkındır
• Bu yaklaşım, kodun ucuzladığı ve karmaşıklığın hâlâ en tepedeki yırtıcı (apex predator) olduğu ikili gerçeğini kabul eder ve bilgisayar programlama zanaatını korumanın üretken bir yolunu sunar

[GN⁺]

Lobste.rs görüşleri

• Peter Naur’un 1985 tarihli Programming as Theory Building yazısı bugünlerde birkaç kez daha yeniden okumaya değer görünüyor

• “LLM’ler karmaşıklıktan korkamaz” ifadesinin abartıya yakın olduğunu düşünüyorum
  Başarısızlık biçiminin kendisi gerçekten var. Talimatları geniş verdiğinizde LLM, katmanlar ekliyor, soyutlamalar üretiyor ve probleme kıyasla gereğinden fazla kod çıkarıyor. Ama bu davranışı gözlemlemek kolay, incelemek kolay ve şaşırtıcı şekilde yönünü değiştirmek de kolay. İstenen yazılım stilini AGENTS/CLAUDE.md dosyasıyla hizalayabilirsiniz
  En küçük değişikliği isteyin, neyin silinebileceğini sorun ve o soyutlamanın gerçekten değer üretip üretmediğini sorun. Değişmezleri, bağlanma noktalarını ve bilişsel yükü de sorun; ayrıca zekice numaraları ayıklayan ikinci bir geçiş isteyin, genelde bu baskıyı takip ediyor. Bunu prompt’a koyarsanız en baştan kaçınmasını da sağlayabilirsiniz
  Risk, LLM’in karmaşıklığa asla saygı duyamamasında değil; çevresindeki sürecin ödüllendirdiği kod biçimini isteyerek üretmesinde. Miktarı ödüllendiren ekipler miktar alır, sadeliği ödüllendiren ekipler de çoğu zaman onu alabilir
  Bugünün modelleri çoğu insandan daha iyi ve ileride daha da iyi olacak. Kod iyi değilse yapay zeka laboratuvarlarını geri bildirimle sıkıştırmak gerekir. Örneğin GPT ailesinin iyi dokümantasyon yazmada çok kötü olduğunu düşünüyorum

  • Hem doğru hem değil. Meselenin özü yetenekten çok eğitim biçimi ve hedeflere daha yakın görünüyor. Şu anda moda olan şey “tüm projeyi vibe coding ile yaptım” tarzı ve LLM’ler sıfırdan bir şey üretmeye kıyasla mevcut kodu değiştirmede çok zayıf. Büyük olasılıkla eğitim biçiminden kaynaklanıyor, ayrıca istatistiksel bir önyargı da var gibi duruyor. Büyük ve karmaşık kod tabanlarından gelen kod, küçük ve basit projelerden çok daha fazla olduğu için eğitimde daha büyük ağırlık almış olmalı
    Bu yüzden “imkansız” ifadesi en iyi seçenek olmayabilir, ama varsayılan olarak karmaşıklığa doğru eğen çeşitli önyargılar olduğunu düşünüyorum
    Ayrıca hiçbir şey yapmamaktansa bir şey yapmaya dönük bir önyargı da var. İyi programcılar, belirli bir isteği atan bir yöneticiden çok daha fazla bağlam kullanır ve alternatifler de sunar. LLM’ler de bunu yapabilir belki, ama mevcut LLM’ler “planlama sırasında soru sorma” ya da yineleme tespiti kodu olsa bile doğru soruları sormakta usta değil. Böyle eğitim verisi de muhtemelen yaygın değil
    Bir bakıma prompt engineering, bu sorun demetinin etrafında yapılan korkunç bir hack’e benziyor
  • O ifadeye tamamen katılıyor muyum emin değilim ama kesinlikle bir şeyler var. Bir yandan, tek hedefli bir Makefile yeterliyken varsayılan olarak devasa bir CMake projesi üretmek gibi “yaygın karmaşıklık” örnekleri gördüm
    Öte yandan, “Bu bir aylık bir proje olduğu için bunu önermiyorum. Bu haliyle commit edip demo olarak bırakmaya ne dersiniz?” gibi yanıtlar aldıktan sonra LLM’i ikna edip rahatlatmam gerekmişti. İkisinin de bir saatten kısa süreceğini bildiğim halde böyleydi. Ama “Tamam, git tamamen yeni bir şey yap. Yöntemi sen bul” dersen deniyor; bu anlamda korkusuz denebilir
  • Lobsters’ta “vibe coding” hakkında nüanslı bir tartışma görmek, herhalde cehennem dondu /s
    Şaka bir yana, katılıyorum. Benim deneyimimle de örtüşüyor

• “Kodu anlamanın maliyeti daha pahalı hale geldi” sözüne genel olarak pek katılmıyorum
  Düşünmeden üretilmiş LLM kodu için doğru olabilir, ama uygun şekilde yönlendirildiğinde LLM de okuması kolay ve katmanları iyi ayrılmış kod üretebilir. Elbette bu durumda mimari tercihlerinin çoğunu insan yapıyor, ama zaten öyle olması gerektiğini düşünüyorum
  Karşı örnek olarak, tanımadığım biri tarafından yazılmış kodu anlamada LLM’lerin çok güçlü olduğunu hissettim. Claude Code’dan belirli bir kodu derinlemesine analiz edip her bölümünü açıklayan bir Markdown belgesi oluşturmasını ve benim incelemeye ya da anlamaya hangi sırayla başlamam gerektiğini önermesini isteyebiliyorum
  Bu gerçekten çok değerli

  • Alışık olmadığım kodda LLM kullanma deneyimim genel olarak iyiydi, ama alışılmışın dışına çıkan kısımlarda yaratıcı biçimde uydurup yalan söylediği oluyor. Sorun şu ki kod yabancı olduğu için ikisini ayırt etmek zor

• “İnsanlar genelde üstel eğrileri iyi anlayamaz. Bu yüzden bileşik faiz gibi masallara inanırlar” denmiş; yani bileşik faiz bir masal mı demek istiyor? Ben mi bir şeyi yanlış anladım?