3 puan yazan GN⁺ 2026-02-10 | 1 yorum | WhatsApp'ta paylaş
  • Modern teknoloji sistemleri, tek bir kişinin bütünü anlayamayacağı kadar karmaşık yapılar hâline geldi
  • Yazılım geliştirme ve yapay zeka kullanımı arttıkça, geliştiricilerin iç mekanizmaları anlamadan sistem kurduğu örnekler çoğalıyor
  • Simon Wardley anlamadan sistem kurmanın riskine, Adam Jacob yapay zekanın geliştirme biçimini değiştirdiğine, Bruce Perens ise karmaşıklığın zaten sınırı aştığına dikkat çekiyor
  • Louis Bucciarelli, telefon sistemi örneği üzerinden teknolojinin birçok katmanda iç içe geçtiğini ve bu yüzden kimsenin tam bir anlayışa ulaşamayacağını gösteriyor
  • Yazı, yapay zekanın bu karmaşıklığı derinleştirdiğini, ancak gerçekte insanların uzun zamandır teknolojiyi kısmi anlayışlarla ele aldığını vurguluyor

Teknolojik karmaşıklık ve anlamanın sınırları

  • Twitter'ın gerilemesinden sonra LinkedIn'de teknolojiyi anlama ve karmaşıklık üzerine tartışmalar yoğunlaştı
    • Simon Wardley, Adam Jacob ve Bruce Perens'in gönderileri birbiriyle bağlantılı başlıklar olarak sunuluyor
  • Wardley, temel ilkeleri bilmeden sistem kurmanın tehlikesi konusunda uyarıyor
    • “Magic” ifadesi, iç işleyişi gizleyen framework'leri eleştirel biçimde tanımlıyor; Ruby on Rails buna örnek olarak veriliyor
  • Jacob, yapay zekanın yazılım geliştirme biçimini kökten değiştirdiğini belirtiyor
    • Yapay zeka verimliliği artırıyor, ancak geliştiricilerin altyapıyı anlamadan çalışmasına yol açma eğilimi de taşıyor
  • Perens, Wardley'nin kaygı duyduğu durumun zaten gerçeğe dönüştüğünü söylüyor
    • Modern CPU'lar ve işletim sistemlerinin karmaşıklığı nedeniyle birçok geliştirici gerçek çalışma prensiplerini yanlış anlıyor

Louis Bucciarelli'nin ‘telefon’ örneği

  • Bucciarelli, 1994 tarihli Designing Engineers kitabında teknolojik okuryazarlığın sınırlarını tartışıyor
    • Çoğu insan telefonun nasıl çalıştığını fiziksel düzeyde açıklayamıyor
    • Haberleşme ağlarının routing, sinyal işleme, uydu iletimi, kurumsal işletim ve düzenleyici yapılar gibi çok katmanlı unsurları iç içe geçmiş durumda
  • Sonuç olarak “kimse kendi telefonunun nasıl çalıştığını tamamen bilmiyor” noktasına varıyor
    • Bu, karmaşık teknolojik sistemlerin insanın tam kavrayışını aştığını simgeliyor

Teknik mülakatlar ve ‘bilginin sınırları’

  • Yazar, Netflix'te çalıştığı dönemde Brendan Gregg ile yaptığı bir sohbeti anımsıyor
    • Gregg'in mülakatlarda adayın bilgisinin sınırını ve buna verdiği tepkiyi değerlendirdiği aktarılıyor
    • Mülakatları, “kimsenin sistemin tamamını bütünüyle anlamadığı” gerçeğini ön kabul olarak alarak yürüttüğü belirtiliyor
  • Bu yaklaşım, bilmediğini kabul etme tutumunun teknik yetkinlik kadar önemli olduğunu gösteriyor

Karmaşıklığın doğası ve yapay zekanın etkisi

  • Wardley, Jacob, Perens ve Bucciarelli'nin görüşleri, farklı katmanlarda karmaşıklığın kaçınılmazlığını ortaya koyuyor
    • Wardley: Anlamadan inşa etmenin riski
    • Jacob: Yapay zekanın getirdiği verimlilik ve mesafe
    • Perens: Zaten var olan karmaşıklığın gerçekliği
    • Bucciarelli: Sistemin tamamını anlamanın imkânsızlığı
  • Yazı, yapay zekanın bu sorunu daha da derinleştireceğini kabul ederken, insanların uzun süredir teknolojiyi kısmi anlayışlarla kullandığı gerçeğini de hatırlatıyor

Okuyucu tartışmalarının özeti

  • Yorumlarda, yapay zekanın öğrenmeyi ve anlamayı zayıflattığı yönünde çok sayıda kaygı dile getiriliyor
    • Bazıları, “LLM kodu yazdıkça anlama zinciri kopuyor” diye belirtiyor
    • Wardley ise “önceden anlayış hiyerarşik bir zincir içinde korunuyordu, ancak LLM bu zinciri ortadan kaldırıyor” diye açıklıyor
  • Başka bir okur, “yapay zekanın faydalarının risklerinden büyük olduğunu kesin kabul etmek erken” diyerek karşı çıkıyor
  • Genel olarak, yapay zeka çağında teknik anlayışın kaybı ve öğrenmenin kopuşu temel tartışma başlıkları olarak öne çıkıyor

1 yorum

 
GN⁺ 2026-02-10
Hacker News görüşleri
  • Son dönemde programlamada beni endişelendiren şey, ne üst katmanı (ürünün amacı) ne de alt katmanı (uygulama biçimi) bilen "orta katman geliştirme" anlayışının artması.
    Eskiden işi bilmesem de kodun ne anlama geldiğini anlardım; şimdi ise kodun nasıl çalıştığını bilmenin bile gerekmediği bir hava var.
    Claude kullandıkça durumsal farkındalık yeteneğimin giderek azaldığını hissediyorum. Testler geçip buton çalışınca iş bitmiş sayılan bir geliştirme kültürü içinde, artık öğrenecek ya da katkı sunacak bir şeyim kalmamış gibi geliyor

    • "Sahiplik" vurgulanıyor ama gerçekten inisiyatif almaya çalışınca erişim kısıtları ve bilgi eksikliğiyle karşılaşıyorsun.
      Özellikle büyük şirketlerde şeffaflık eksikliği daha fazla. Son teslim tarihini yetiştirmek için fazla mesai yaptım ama takvimin benden habersiz ertelendiği oldu.
      Eğer bana sadece basit bir araç gibi davranılacaksa, o rolü oynarım. Ama gerçekten sahiplik isteniyorsa, karar masasında bir koltuk da gerekir
    • Buna karşılık ben, Claude sayesinde odaklanma gücümün arttığını hissediyorum.
      Eskiden tekrarlayan kurulum işleriyle zaman kaybediyordum, şimdi ise sadece temel işlevlere odaklanabiliyorum. Bu sayede genel yapıyı zihnimde daha iyi tutabiliyorum
    • Bu durum tarım otomasyonuna da benziyor. Bugünlerde traktörde oturman yeterli, makine geri kalan her şeyi yapıyor. Sonunda insan sadece koltuk sensörü için bir ağırlık haline geliyor
    • Ben, Claude'un tam otomatik geliştirmeden çok küçük değişiklik odaklı etkileşimli kod düzenlemeyi desteklemesini isterdim.
      Örneğin IDE'de birkaç satır seçip sesle “burayı şöyle değiştir” dediğinde bunun anında uygulanması gibi.
      Yeterince hızlı olursa fare + ses kontrolü, erişilebilirlik aracı olarak da harika olabilir
    • Aslında bu tür sorunlar eskiden beri vardı. En tipik örnek dependency hell.
      Hatta LLM'lerin bu karmaşıklığı azaltabileceğini düşünüyorum. Uygun düzeyde soyutlamayı severim ama içini hiç bilmemekten hoşlanmam
  • Bu yazı, insanların iç işleyişi bilmeden soyutlama (abstraction) kullanması olgusuyla ilgili.
    Ama bu doğal bir gelişim süreci. Birileri o soyutlamayı tasarladı ve üst katmanın kullanabilmesi için hazır hale getirdi.
    “Ben Wi-Fi sürücüsünü bilmiyorum, o halde kodu da bilmem gerekmiyor” mantığı geçerli değil

    • Sorun şu ki artık çoğu insanın yeni soyutlamalar oluşturma yeteneğini kaybetme riski var.
      Eskiden insanlar "gerekli karmaşıklıkla" doğrudan uğraşarak düşünme becerilerini geliştirirdi; şimdi ise çoğu zaman sadece boru hattında bir geçiş noktası gibi davranılıyor
    • LLM'in yazdığı kod çok gereksiz ayrıntılı oluyor, bu yüzden incelemesi daha uzun sürüyor.
      Çözüm, soyutlamayı genel amaçlı diller yerine DSL (alan özelinde dil) ile sarmak olabilir. SaaS için de API-first yerine DSL-first yaklaşımının daha iyi olduğunu düşünüyorum
    • Aslında Clean Code ve OOP kültürü de zaten aşırı soyutlama nedeniyle performans kaybına yol açmıştı.
      AI'ın bundan daha kötü olduğunu düşünmüyorum. Önemli olan, dayandığın soyutlamaları anlaman
  • Bağımlılık ağacı gerçekten en büyük sorunları çıkarıyor.
    Sadece Node.js projelerine bakınca bile yüzlerce bağımlı paket var. Çoğunun içini bilmesen de olur ama arayüzler sık sık bozuluyorsa bu tehlikeli hale gelir.
    Ekipler çoğu zaman EOL (destek sonu) ya da güvenlik açıklarını takip etmiyor. “Bu hâlâ bakım görüyor mu?” sorusunun bile cevabı bilinmiyor

    • Bu tür sorunları SBOM/SCA araçları ile izlemek ideal olurdu.
      Ama AI'dan önce de zaten sürüm çakışmaları yüzünden dependency hell yaşayan çok proje vardı
  • İnsanların her şeyi bilmesi gerekmiyor ama temellerin kaybına yol açan cehalet tehlikeli bence.
    Yemek pişirmeyi örnek alırsak, buğday yetiştirmen gerekmez ama yumurta pişirmeyi bile bilmiyorsan bu bir sorundur.
    Şirketler tüm yiyecekleri standartlaştırıp pişirip önüne koyarsa, bu ilerleme mi olur gerileme mi sorusu ortaya çıkıyor

    • Çoğu insanın avcılığı ya da tarımı bilmesine gerek yok. Çünkü tedarik zinciri yeterince dağıtık ve yedekli.
      Bir gün robotlar gıda üretimini tamamen devralırsa, yemek yapmayı bilmemek de önemsiz hale gelebilir
    • Nerede sorun olmadığı ve nereden sonra risk başladığına dair eşik çizgisi kişiden kişiye değişiyor
    • “Yumurta pişirmeyi bilmemek neden tehlikeli olsun?” diye itiraz edenler de var.
      Sonuçta bağımlılıktan kaçınmak için malzeme bilimine kadar bilmek gerekmiyor, değil mi?
  • CPU komutları ve önbellek gibi alt katmanlar onlarca yıldır sıkı biçimde doğrulanmış ve belgelenmiş durumda.
    Buna karşılık LLM'in ürettiği kod o kadar güvenilir değil ve yarın yeniden düzenlenmesi gerekebilir

  • Ben alt katmanların ayrıntılı çalışmasını bilmesem de kendi kodumun nasıl çalıştığını anlıyorum.
    Alt katmanı bilmemek ile kendi sorumluluk alanını bilmemek tamamen farklı şeyler

    • Geçmişte, karmaşık sistemlerde bile her parçayı bilen birileri vardı.
      Bugün ise kimsenin anlamadığı kod parçalarının ortaya çıkması asıl tehlike
  • AI'ın durumu daha da kötüleştirdiği iddiasına katılmıyorum.
    Tam tersine LLM'ler neredeyse her türlü bilgiyi öğrendiği için, “telefon nasıl çalışır?” gibi soruları sistematik biçimde açıklayabiliyor.
    İnsanların “neyi bilmediğini bilememe” sınırı var ama LLM'ler dil ile ifade edilmiş bilgi söz konusu olduğunda neredeyse her şeyi kapsıyor.
    Elbette akıl yürütme ya da kod üretmede zayıflar ama bilgiyi bütünleştirme yetenekleri insanlardan daha güçlü

    • Ama LLM'ler gerçekten “bilen” değil, inandırıcı görünen şeyler üreten sistemler.
      Gerçek dokümantasyonun yerini tutamazlar. Yine de insanlar gibi “neye bakman gerektiğini” göstermede çok faydalılar
  • İyi tasarım, bütünü bilmeden de sistemin çalışmasını sağlamaktır.
    Sorun AI'ın ürettiği sistemler değil; bizim onların hata biçimlerini ve sınırlarını henüz yeterince iyi bilmememiz.
    Sonuçta asıl mesele, insanla AI'ı nasıl koordine edip ihtiyaç duyulan sistemi kuracağımıza dair örgütsel tasarım becerisi

  • Bilgisayarın iç yapısını tamamen bilmiyorum ama pratik betik otomasyonu ile sorun çözüyorum.
    x86 assembly öğrenmeden de Python ile altyapı yönetebilirim.
    Ama deneyimli geliştiricilerin bu bilgiyi paylaşma sorumluluğu olduğunu düşünüyorum. Ben de bir gün bu rolü sürdürmek istiyorum

    • Sadece “pragmatizm” dersen, sonunda bu aşırı uzmanlaşmaya çıkar.
      Merakını kaybetmemeli ve kıdemli geliştiricilerle aktif biçimde konuşmalısın
    • Temelleri anlatmaya çalışınca sık sık “buna gerek yok” tepkisi geliyor.
      Ama temel anlayışın önemi ne kadar vurgulansa da görmezden gelinmesi gerçekten can sıkıcı
    • Bu arada iyi öğrenme kaynakları arasında cpu.land gibi siteler var
  • “Bir URL girildiğinde neler olur?” gibi sorulara gerçekten yanıt verebilirim.
    ABD Donanması'nda denizaltı reaktörü teknisyeni olarak çalıştım; elektronik teoriden sistem arıza gidermeye kadar eğitim aldım.
    Sonrasında IT'ye geçerken de aynı tavırla, dokümantasyon ve deneyler üzerinden işin sonuna kadar gittim.
    Bu alışkanlık sayesinde sorun çözerken rastgele görünen bilgi bağlantıları çok işe yarıyor.
    VMEbus Vikipedi maddesi da bakmaya değer

    • Benim tepkim de benzerdi. Örneklerin çoğunu beyaz tahtada anında açıklayabilirim.
      Yalnız, bilmediğim şeylere tahammül edemeyen bir yapım var; o yüzden muhtemelen istisna sayılırım
    • Anlayışın derinliği çeşitlidir. Bir web geliştiricisi ağ yığınına kadar biliyor olabilir ama kablosuz sinyallerin analog dünyası bambaşka bir katman