Tembelliğin Erdemini Kaybetmenin Tehlikesi

 (bcantrill.dtrace.org)
2 puan yazan GN⁺ 17 일 전 | 1 yorum | WhatsApp'ta paylaş
  • Programlamadaki tembellik, basit bir ihmal değil, soyutlama ve sadeliği arayan entelektüel bir erdem olarak tanımlanır
  • Gerçek tembellik, sorunu derinlemesine düşünüp gelecekte zamandan tasarruf etme sürecidir ve bu, sonraki kuşak geliştiricilere de fayda sağlar
  • Modern yüksek seviyeli soyutlamalar ve 'brogrammer' kültürü, bu erdemin kaybolmasına ve onun yerini sahte çalışkanlığın almasına yol açar
  • LLM'ler bu eğilimi uç noktaya taşır ve kod miktarını değerle karıştıran aşırı üretim araçları olarak işlev görür
  • İnsanın sınırlı zamanından doğan erdemli tembelliği koruyup, LLM'leri basit ve sürdürülebilir sistem tasarımı için kullanmak gerekir

Programcının Erdemi Olarak Tembellik ve Onu Kaybetmenin Tehlikesi

  • Larry Wall'un 『Programming Perl』 kitabında ortaya koyduğu programcının üç erdemi olan tembellik (laziness), sabırsızlık (impatience) ve kibir (hubris) arasında, tembelliğin en derin anlama sahip olduğu vurgulanır
    • Tembellik, basit bir öz eleştiri değil, soyutlama ihtiyacı ve estetiğini içinde barındıran bir kavramdır
    • Sistemi mümkün olduğunca basit kılmanın ve güçlü soyutlamalarla daha fazla işi daha kolay yapabilmenin itici gücüdür
  • Gerçek tembellik, 'hammock-driven development' örneğinde olduğu gibi dışarıdan dinleniyormuş gibi görünse de, gerçekte sorunu derinlemesine düşünüp gelecekte zamandan tasarruf etmek için entelektüel emek yürütme sürecidir
    • Doğru soyutlama bir kez kurulduğunda, yalnızca geliştiricinin kendisine değil gelecek kuşak geliştiricilere de fayda sağlar
    • Bu tür tembellik, yazılımın daha kolay yazılmasını ve sistemlerin daha kolay kurulmasını sağlar

  • Tembellik erdeminin kaybolduğu çağ

    • Son 20 yılda yazılım üretiminin kapsamı genişledikçe, kendini programcı olarak görmeyen insanların sayısı arttı
      • Bu kişiler için tembellik erdemi asıl anlamını yitirdi
    • Modern yüksek seviyeli soyutlamaların getirdiği üretkenlik patlaması, tersine sahte çalışkanlığı (false industriousness) teşvik etti
      • Bu durum 'brogrammer' kültürü ve 'hustle porn' şeklinde ortaya çıktı; ironik tembelliğin yerini sonsuz kod dökme davranışı aldı

  • LLM'lerin getirdiği yeni aşırılık

    • LLM'lerin (büyük dil modelleri) ortaya çıkışı bu eğilimi en uç noktaya taşıdı
      • LLM'ler, insanın üretim tarzını büyüten araçlar olarak 'brogrammer' kültürünün steroidli hali gibi işliyor
    • Örnek olarak Garry Tan, LLM kullanarak bir günde 37.000 satır kod yazdığını söylemiştir
      • Karşılaştırma için DTrace'in tüm kod tabanı yaklaşık 60.000 satırdır
    • Ancak bu yaklaşım, tembellik erdeminden yoksun bir kusur olarak, yazılımın değerini kod miktarıyla ölçme hatasını ortaya koyar

  • LLM'lerin sınırları ve insan tembelliğinin değeri

    • LLM'lerin emek maliyeti 0 olduğu için, gelecekte zamandan tasarrufu hesaba katmadan sonsuz derecede karmaşık sistemler üretebildiği belirtilir
      • Sonuç olarak sistemleri daha büyük ve daha karmaşık hale getirir; gösterişe dayalı metrikleri tatmin ederken özsel kaliteye zarar verir
    • İnsani tembellik, zamanın sınırlı olması kısıtından doğar ve bu da net soyutlamaları ve sadeleştirilmiş sistem tasarımını zorunlu kılar
      • En iyi mühendislik her zaman kısıtlardan doğar; insanın zaman kısıtı bilişsel yükü sınırlar ve sadeliği aramaya iter
      • LLM'lerde bu tür bir kısıt bulunmadığından, kendi başlarına sadeliği aramak için bir motivasyonları yoktur

  • LLM'leri araç olarak kullanmanın yönü

    • LLM'ler hâlâ yazılım mühendisliği için güçlü araçlar olarak önemli bir rol oynayabilir
      • Oxide'ın LLM kullanım rehberine göre, LLM yalnızca bir araçtır ve insan erdemlerinin yerini alamaz
    • LLM'ler, teknik borç (technical debt) gibi üretken olmayan tembellik sorunlarını çözmekte ya da mühendislik disiplinini güçlendirmekte kullanılabilir
    • Ancak kullanım amacı mutlaka 'erdemli tembelliği' gerçekleştirme yönünde olmalıdır
      • Yani daha basit ve daha güçlü sistemler kurarak, gelecek kuşak geliştiricilere fayda sağlayan sonuçlar bırakmalıdır

İlgili okumalar

1 yorum

 
GN⁺ 17 일 전
Hacker News yorumları

  • Benim alanım olan Computational Fluid Dynamics tarafında da, LOC ile övünür gibi test sayısıyla övünen insanlar var
    Ama yakından bakınca bu testler pek de sıkı değil ve benim elle hazırladığım testlerden çok daha gevşek kalıyor
    1 milyon kolay test, kodun kritik kısımlarını kapsamıyorsa hiçbir anlam ifade etmiyor

    • Testleri kendim yazmam gerektiğini ben de fark ettim
      Ayrıca Claude kod çalışmadığında testleri “düzeltivermesin” diye test değişikliklerini her zaman git diff ile kontrol ediyorum
      Testleri sıkı yönetince Claude zor makale algoritmalarını bile iyi uyguluyor ve zaman kazandırıyor, ama çok fazla bakım istiyor
    • Bu bir tür reward hacking gibi
      Model, test denilen ödül fonksiyonunu “kazandım ilanı” için kötüye kullanıyor
      Muhtemelen RL ön eğitim verilerinde de buna benzer örüntüler vardır diye tahmin ediyorum
    • LLM’in aptalca olmayan testler üretmesini sağlamak gerçekten zor
      assert(1==1) gibi işe yaramaz yüzlerce test çıkıyor
      Bu yüzden “böyle testler üretme” diye ayrı bir yasaklar listesi tutmak gerekiyor

  • 30 yıl boyunca bizzat kod yazdıktan sonra artık tamamen AI coding tarafına geçtim ama insanların AI’ın ürettiği kodun LOC’unu ya da özelliklerini kendi başarısı gibi sunması bana tuhaf geliyor
    Günde yüz binlerce satır “kod yazdığını” söyleyip övünmek, sonuçta sadece birkaç satır prompt girmek değil mi?

    • Bu bir spektrum gibi
      Bizzat onayladığın değişikliklerde belli ölçüde emek payı sayılabilir ama tamamen vibe-coded app tarafında neredeyse hiç müdahale yok
      Ben ortalardayım — AI’ın ürettiği kodun tamamını tek tek incelemiyorum ama mimari tasarımı ve refactoring yönünü ben belirliyorum
      Ortaya çıkan sonuç, kendim yapsam çıkacak olana benziyor ama çok daha hızlı tamamlanıyor
    • Meta’da artık AI kullanım liderlik tablosu varmış; en çok Claude token’ı tüketen kişiyi gösteriyormuş
      Meta’nın Claude kullanması Anthropic için herhalde epey sevindiricidir
    • Aslında LOC’un fazla olması kötü sonucun işareti de olabilir
    • Bazıları LoC’nin kalite metriği olarak anlamsız olduğunu savunuyor
      Çünkü artık implementation, test ve maintenance’ın tamamını ajanlar üstleniyor
      LoC’yi, ajanın gereksinimleri ne kadar zorlayabildiğini gösteren bir tür yetenek göstergesi olarak görüyorum
      İnsanın eleştirel incelemesi ise hâlâ geri bildirim olarak sisteme verilebiliyor

  • “Daha fazla soyutlama kullanmalıyız” sözü eskiden doğru olabilir ama bugün sanki tam tersi geçerli gibi geliyor
    Ben WET (Write Everything Twice) felsefesini seviyorum — iki kez yaz, soyutlamayı ancak üçüncüde düşün

    • Buna sıkça Rule of Three da deniyor
      Wiki maddesine bakılabilir
    • Yazılımın gerçek güzelliği doğru soyutlamada yatıyor
      İşletim sistemleri, RDBMS’ler, bulut orkestrasyonu gibi yenilikler bunun örneği
      Ama kodların çoğu basit iş mantığından ibaret, bu yüzden soyutlama çoğu zaman köstek oluyor
      O yüzden benim ilkem şu: “üç gerçek kullanım senaryosu kanıtlanmadan platform kurma”
    • Bir şeyi ikiden fazla yazmak zaten düşük bir eşik, dolayısıyla Perl’deki alıntıyla da çelişmiyor diye düşünüyorum
    • İkinci kez yazmak, problemi daha iyi anlamışken iyileştirme fırsatı veriyor
      Üçüncüde soyutlamaya kalkarken Second-System Effect tehlikesine dikkat etmek lazım — aşırı özgüven karmaşık sistemler doğuruyor
    • 1991 tarihli Programming Perl sonrasında ortaya çıkan soyutlama katmanı patlaması gerçekten şaşırtıcı

  • Alman general Kurt von Hammerstein-Equord’un ünlü bir sözünü paylaşıyor
    Zeki ve çalışkan insanlar kurmay olur, aptal ve tembel insanlar gündelik işlerde kullanılır, zeki ve tembel insanlar lider olur,
    ama aptal ve çalışkan insanlar tehlikelidir; onlara asla sorumluluk verilmemelidir

    • “Benim gibi %90 tembel tayfa nereye giriyor?” diye şaka yollu bir yanıt bırakmış

  • LLM ile 200 bin LOC yazdığını söyleyip övünmek ne kadar aptalcaysa, bunu görüp “bu kod aptalca” diye küçümsemek de o kadar yanlış bir tavır bence
    Sonuçta önemli olan kod çıktısı değil, değer üretimi
    Garry Tan’ın gerçekten değerli bir şey üretip üretmediğini bilmiyorum

    • Kod kalitesinin önemsiz olduğunu düşünmek büyük hata olur
      Horizon IT skandalı gibi örneklerde kötü kod gerçek zarar veriyor
      Garry’nin projesini inceleyen Polonyalı geliştirici Gregorein’in değerlendirmesine göre uygulamada test harness, Hello World uygulaması, yinelenen logo dosyaları gibi bir sürü dağınıklık vardı
      Böyle kodun güvenlik saldırı yüzeyini büyütmüş olmasından endişe ediyorum
    • Garry sıradan bir geliştirici değil, YC’nin CEO’su
      LOC’a odaklanmıyor; yaptığı şey daha çok AI tanıtım gönderisi paylaşmak
    • Gerçek metrik değer – maliyet olmalı
      AI geliştirme ve işletim maliyetlerini düşürüyor ama güvenlik ve hukuki risk gibi gizli maliyetleri artırıyor
      AI övgücüleri hep ilk kısmı öne çıkarıyor
    • 200 bin LOC’u okuyup bunun kötü bir fikir olduğunu kanıtlayacak zamanım yok
      Bunu kanıtlama yükü vibe coder tarafında olmalı
      LOC ile övünmenin hâlâ aptalca olduğunu düşünüyorum
    • “Değer üretimi” söyleminin kendisi de tehlikeli olabilir
      Fosil yakıt temelli büyümede olduğu gibi, kısa vadeli değer uzun vadeli maliyetler doğurabilir

  • Son birkaç PR’da LLM’in yanlış çözümler ürettiğini sık sık görüyorum
    Mesela zaten mevcut olan bir JSON parser varken gidip yeniden parser yazıyor
    Bir insan olsa “bu çok verimsiz” derdi ama LLM’de tembellik olmadığı için yanlış yönde bile gayretle çalışıyor

    • Ayrıca proje içindeki yinelenen fonksiyonları hiç fark etmiyor
      formatTimestamp gibi bir fonksiyonun üç kopyası olduğunu tek bir grep ile görmek mümkünken bunu görmezden geliyor

  • LLM’in tembel olmaması tespitine katılıyorum
    Ama bunun kalıcı bir sorun mu olduğu, yoksa bir sonraki model yükseltmesinde ya da CICD pipeline içinde çözülecek bir şey mi olduğu belli değil
    Ben genelde özellik tamamlandıktan sonra “hata veya refactor gerektiren yer var mı kontrol et” diye prompt veriyorum,
    ileride sistemin otomatik biçimde son commit’leri analiz edip sadeleştirme önerileri sunduğu bir aşama da gelebilir

    • Ama LLM’e “X’i bul” derseniz her zaman bir şey buluyor
      Bu yüzden bitiş koşulunu tanımlamak zorlaşıyor
    • Sonuçta sorun aracın özü değil, nasıl kullanıldığına dair sınırlamalar
      “Ekle” dersen ekliyor, “azalt” dersen LOC’u düşürüyor
      Büyük işleri verip incelemeyi atlarsanız code slop birikmesi çok kolay oluyor

  • LLM, basit bir konsol çıktı programı yerine tam bir SPA üretmeye eğilimli oluyor
    Ayrıca spec.md dosyasını kısa ve öz tutmayı da beceremiyor
    “Bu belgeyi güncelle ve çevresindeki içeriği sadeleştir” dendiğinde daha da karmaşık hâle getiriyor
    Sonuçta okunabilir bir belge için özetlemeyi insanın bizzat yapması gerekiyor
    LLM çıktısını düzenlemek acı verici ve metni doğrudan yazınca kavrayış da korunmuş oluyor

  • Yazılım geliştirmenin klasik derslerini artık LLM’lere ve vibe coder’lara öğretme zamanı geldi
    Negative 2000 Lines of Code hikâyesindeki gibi, bazen kodu azaltmak gerçek ilerleme demektir

  • Böyle bir liderlikle çalışabilmek ne güzel olurdu diye düşünüyorum
    Gerçekten kavrayış sahibi bir liderle çalışmak büyük şans