Sonsuz Sloptember

• AI ajanları, programlama yapmaktan çok programlamanın dağılımını taklit ediyor ve bozuk çıktılar giderek fark edilmesi daha zor hale geliyor
• tinygrad’in bir bölümünü yazmak ve USB <-> PCIe çipi tersine mühendisliği için kullandım, ancak bunu kendim yapsaydım daha iyi ve daha hızlı olabilirdi şüphesi sürüyor
• Ajanlar başlangıçta ilerlemeyi hızlandırıyor, ancak son aşamada slot makinesi kolu gibi tekrar tekrar denemeye bel bağlatıyor ve işi sona erdiremiyor
• Büyük ölçekli organizasyonlar, yavaş geri bildirim döngüleri ve öz denetim olmadan 10 kat üretim nedeniyle yüksek performanslı bireylere göre kalite açısından daha büyük zarar görebilir
• AI arama ve hızlı prototipleme için faydalı, ancak gerçek bir yazılım mühendisi olarak görmek zor ve asıl mesele onu ne zaman kullanmayacağını bilmek

---

AI ajanlarına yönelik temel eleştiri

• AI ajanlarını yazılım geliştirmeye sokma eğilimi çok maliyetli bir hata olabilir; ajanlar programlamanın kendisinden ziyade programlamanın dağılımını taklit eden sofistike istatistiksel modellere daha yakın
• Çıktılar bozuk, ancak giderek tespit edilmesi daha zor şekillerde bozuluyor; istatistiksel model ne kadar isabetli hale gelirse bu sorunları fark etmek de o kadar zorlaşıyor
• Son 6 ayda ajanlarla tinygrad’in bir bölümünü yazdım ve USB <-> PCIe çipini tersine mühendislikle inceledim, ama bunları doğrudan kendim yapsaydım daha iyi ve daha hızlı olabilirdi şüphesi kaldı
• Ajanlar başlangıç ilerlemesini öne çekiyor, ancak bitirme aşamasında slot makinesi kolunu çekiyormuş gibi sonucun iyileşmesini umarak tekrar tekrar denemeye itiyor ve sona ulaştıramıyor
• Birden fazla model, harness ve prompt denendiği için “yanlış kullandın” itirazı ikna edici değil; bu, slot makinesinde belirli bir şekilde bahis yaparsan kazanırsın demeye benziyor
• AI’nin kendisi faydalı; birçok aramada daha iyi bir Google gibi çalışıyor ve kusursuzluk gerektirmeyen hızlı prototiplerde çok hızlı
• Ancak buna bir yazılım mühendisi demek zor; birlikte çalıştığım hiçbir şirketin standardına yaklaşmıyor ve asıl nokta ne zaman kullanıp ne zaman kullanmayacağını bilmek

Organizasyonlar ve kalite üzerindeki etkisi

• AFL, LLM’lerden daha fazla bug buldu ama geliştiriciler statü kaybından korkmadı; satranç ve Go da AI’den sonra daha popüler hale geldiği için AI eleştirisini yalnızca statü kaygısıyla açıklamak zor
• Kodu düzenleyen güvenilir bir robot yardımcının olduğu gelecek umut verici, ancak büyük şirketleri harekete geçirmeye çalışan yaklaşımda kaybetme korkusunun ajan satışında kullanıldığı görülüyor
• Büyük ölçekli organizasyonların, yüksek performanslı bireyler veya küçük organizasyonlara kıyasla ajanlardan daha büyük zarar görme ihtimali var
  • Yüksek performanslı kişiler hataları düzeltebilir, çıktının özensiz olduğunu fark etme eğilimindedir ve alan çok sınırlı değilse her satırı dikkatle okuyup anlama yaklaşımını sürdürür
  • Büyük ölçekli organizasyonlarda geri bildirim döngüleri yavaştır ve hizalanma zayıftır; düşük performanslı çalışanlar öz denetim olmadan ajanlarla 10 kat üretim yaptığında ortalama çıktı kalitesi düşebilir
• Ajanlar eskisinden daha fazla kod, uygulama ve özellik üretecek, ancak yüksek kaliteli mücevherlerden çok büyük miktarda özensiz çıktı biriken bir döneme girebiliriz
• Apple’ın tüm mühendislere AI kullanımını ittiği yönündeki söylentilere, soyut beklentilerden çok “önümüzdeki 2 yıl içinde macOS daha iyi mi yoksa daha kötü mü olacak?” gibi somut sorularla bakmak gerekiyor
• İnsanlar bir çıktıda, üreticinin insani bir zihinsel durumdan ve süreçten geçtiğini örtük olarak varsayar; ancak AI çıktılarında bu varsayım artık geçerli değil
• Geçmişte kalite için dolaylı gösterge olarak kullanılan dilbilgisi ve sözdizimi gibi unsurlar, AI çıktıları karşısında işe yaramaz hale geliyor; fark, onunla insani biçimde etkileşime girerken ya da onun üzerine bir şey inşa ederken ortaya çıkıyor
• LLM’ler konusunda LeCun/Marcus çizgisine daha yakın bir noktaya geldim; bu modeller programlama yapamıyor ve bu da sürecin önemli olduğu sonucuna götürüyor
• Derin öğrenme hâlâ çözüm olabilir, ancak gerçek programlama ajanları için failing test’i yorum satırına alıp ardından tüm testlerin geçtiğini söyleyen türden RLVR değil, bir dünya modeli gerekiyor
• Bu çağın asıl meselesi, AI’ye yönelik kolektif aşırı heyecan içinde kimin kendine zarar vermeden ayakta kalabileceği olabilir

[GN⁺]

Hacker News yorumları

• Mevcut söylemin büyük sorunu, fazla siyah-beyaz düşünmesi. LLM’lerden şüphe edersen Luddite oluyorsun, inanırsan da “ai pilled” sayılıyorsun.
  Çoğu durumda LLM’ler sizi %80 ila %95’e kadar götürüyor; bazen bundan daha azını, bazen daha fazlasını yapıyor. Arada bir de sizi tamamen yanlış bir yere götürebiliyor.
  Ama herkes sanki yalnız başına bir dolapta otururken kusursuz bir yazılım mühendisi olup olamayacağı üzerinden kavga ediyor ve bunu gerekçe gösterip başka senaryolardaki devasa potansiyeli de reddediyor gibi.
  Sadece internetin sağladıklarıyla bile çoğu organizasyonun bugün olduğundan ne kadar daha üretken olabileceğini düşününce, gerçek şirketlerin çoğu zaman mümkün olanın çok küçük bir kısmını bile yapamadığını görüyoruz. LLM’lere de bu açıdan bakıyorum.
  Sorun dil modellerinde değil, bizde.

  • Gerçek Luddite’lar hakkında ne kadar çok şey öğrenirsem, bakış açılarını o kadar daha anlaşılır buluyorum.
    Asıl Luddite’lar, başlıca düşük kaliteli malları “hileli ve aldatıcı” biçimde üreten, işçilik standartlarını dolanan ve yetenekli zanaatkârların geçimini elinden alan makinelere itiraz eden insanlardı.
  • Bunun rasyonel bir tartışma olabilmesi için işin içinde fazla para var.
  • Yazı özellikle ajanları hedef alıyor: “Yazılım geliştirmede AI ajanlarını benimsemek, bu alanın tarihindeki maliyeti en yüksek hatalardan biri olabilir.”
    Ben ajan kullanmıyorum; basit bir sohbet arayüzü ve devam eden konuşmalar üzerinden fonksiyon düzeyinde yazılım geliştiriyorum. Ortaya çıkan iş akışı epey “kimerik” ve kendi deneyimim ile uzmanlığımdan çok fayda görüyor. LLM sadece süreci akıcı hale getiriyor.
    Benim için iyi çalışıyor ve eskiye dönmek istemiyorum.
  • geohot’un ana fikri de benzer görünüyor. Tam anlamıyla “ai pilled” olun demiyor, Luddite olun da demiyor; daha çok AI’ı araç olarak kullanın diyor.
  • Luddite’lar basitçe “şüpheciler” değil, şiddet içeren eylemcilerdi.
    Bugünün söyleminde “Luddite” denilen kişilerse genelde “AI” abartısını sorgulamaya cüret eden insanlar. Çoğu da aktivist bile değil.

• AI’ın şu anki yetenek seviyesinde, onu mevcut bilgi üzerinde çalışan çok iyi bir aramaya benzetmek bana kişisel olarak faydalı geldi. Bir başvuru kitabı, Stack Overflow ve GitHub’a uzanan aranabilirliğin bir sonraki aşaması gibi görünüyor.
  Programcılar, aklıma gelen herhangi bir meslekten daha fazla aynı teknikleri yeniden kullanır ve yeniden icat eder; bu yüzden önceki tekniği çok iyi arayan bir araca zaten uygundu. AI’ın bu önceki tekniği belirli kullanım durumlarına uyarlayabilmesi onu daha da güçlü kılıyor.
  Ama nasıl Stack Overflow’dan kopyalanmış kod parçalarını birleştirerek büyük başarı elde edilmiyorsa, bugünkü AI da tüm projeyi düzgün biçimde ortaya çıkaramıyor.

  • İyi paketlenmiş, yeniden kullanılabilir kütüphanelerden ziyade; yeniden yazma ve yeniden icat etme maliyetini düşüren araçların cevap olduğu daha net hale geliyor.
  • Mevcut AI’ın Stack Overflow ve Google’ın güçlendirilmiş haline daha yakın olduğuna %100 katılıyorum. Benim deneyimime göre, başlangıç iskeleti dışında tam ölçekli uygulamaları iyi kuramıyor.
    Eski ve pek de iyi kullanılmayan bir legacy kod tabanında, örneğin “uygulama X, Y’yi nasıl yapıyor” diye AI ajanına kod okutabilirsiniz. Ama ona rastgele özellikler geliştirtmem ya da refactoring yaptırmam.
    Böyle yaparsanız çok fazla commit oluşur ve geliştirme ekibinde kafa karışıklığı yaratır; zaten uğraştığınız karma karışıktan daha da kötü bir sonuç çıkma ihtimali yüksektir. Son zamanlarda AI konusunda biraz hayal kırıklığı yaşıyordum; bu açıklama deneyimimi iyi özetliyor.
  • “AI önceki tekniği belirli kullanım durumlarına uyarlayabiliyor” sözü zaten herkesin iddia ettiği şey.

• Yazılım mühendisliğinde en zor şey doğru problemi çözmektir. Hangi problemin çözülmesi gerektiğini tespit etme becerisinin üst düzey kıdemli mühendisleri ayırdığını düşünüyorum.
  Burada basitleştirerek söyleyeyim: Çözüldüğünde ürüne kattığı değer, karmaşıklığına ve yan maliyetlerine kıyasla en yüksek olan problem, doğru problemdir.
  Uzun zaman önce bir web ürününde çalışmıştım; orada genç bir tasarımcı, backend’in LDAP araçlarıyla yönetilebilmesinin harika olacağını düşünmüştü. Bu yüzden ürünün veritabanı şeması ve yapısı OpenLDAP’ı taklit ediyor, bileşik CN anahtarları kullanıyordu ve tüm kod tabanı veritabanını her okuyup yazdığında bu yapıyla uğraşmak zorunda kalıyordu. Veritabanı şeması tasarlanırken LDAP uyumluluğu çözülmesi gereken doğru problem değildi.
  Doğru problemi çözen yazılımı teşhis etmek zor olabilir. Genelde çalışma biçimi o kadar doğal görünür ki, başka bir tasarım seçilebileceği gerçeği pek görünmez.
  Zaman içinde yanlış problemi çözen bir tasarımın etki alanını sınırlayan şey genelde o tasarımın yarattığı sürtünmedir. Geliştirme yavaşlar ve yanlış problemi daha fazla çözmeye çalışan geliştirme de yavaşlar. Bu kendi kendini sınırlayan bir olgudur.
  LLM kodlama ajanlarında beni ciddi biçimde endişelendiren şey tam da bu. O sürtünmenin üstünü örtüyorlar. Düzeltmiyorlar; sadece maliyeti ileri tarihe erteliyorlar.
  Sonuç olarak, sağladığı değere kıyasla karmaşıklığı sınırsız büyüyen kod tabanları ortaya çıkıyor ve bunu kontrol edecek mekanizma kalmıyor.
  Genç mühendisler de hangi problemin belirli bir tasarım içinde çözülmesi gereken doğru problem olduğuna dair mühendislik sezgisini ve zevkini geliştirecek geri bildirim döngülerini yaşayamaz hale geliyor.
  Alanın bütünü açısından bakınca, doğru problemi çözmek diye bir kavramın var olduğunu bile unutabiliriz.
  Ne yapmak gerektiğini bilmiyorum. Belki de erken emeklilik planı yapmam gerekir.

• Şu anda gri pazar peptitleri satın alıp, üzerinde “insan tüketimi için değildir” yazan maddeleri sadece şüpheli anekdotlara ve hislere güvenerek enjekte eden insanlar var. Amaçları cildi temizlemek ve kas kütlesini artırmak gibi şeyler
  Hepsi birden aniden zombiye mi dönüşüyor? Hayır. Birkaç yıl sonra vücutlarında ne olacağını gerçekten biliyorlar mı? Onu da bilmiyorlar. Felaketle sonuçlanabilir mi? Evet, olabilir
  Son yaklaşık 6 ayda sektörün yapay zekayı kodun başlıca üreticisi hâline getirmek için agresif biçimde yön değiştirmesini düşününce bu benzetme aklıma geliyor. Yapay zeka peptit, kod tabanı da beden. Bu yaklaşımın ne kadar sürdürülebilir olduğunu kelimenin tam anlamıyla kimse bilmiyor. Çünkü bunu anlayacak kadar zaman henüz geçmedi
  Belki sorun çıkmaz, belki de tam bir curcunaya döner. Koca mühendislik ekipleri direksiyonu bırakıp uyuyabilir; aslında anlamadıkları hâlde ne inşa ettiklerini anladıklarını sanabilirler ve LLM artık yükü taşıyamadığı anda, düzeltmek ya da bakım yapmak için tüm kapasitelerini kaybedebilirler
  https://www.bbc.co.uk/news/articles/cdr268m5pxro
  Kendi kişisel kod tabanımda ise bakım yapılabilirlik ya da ömür benim için gerçekten önemli değilse artık bunu yapmıyorum

  • Akıllı geliştiriciler muhtemelen izole modüller oluşturacaktır. Böylece AI tarafından üretilen modül sürekli başarısız olursa kesip atıp yeniden yapabilirler

• Şu an “bir süredir kodu doğrudan yazmayan” taraftayım. Beni yeniden manuel kod yazmaya döndürecek kadar büyük bir sorun örneği görmek isterim
  Benim asıl sorunum, her model sürümünde kalitenin dalgalanması ve özellikle komut satırı araçlarında eski API'leri ya da dokümantasyonu araya sıkıştırma eğilimi
  İçinde 10 yıllık tortu birikmiş milyon satırlık tek parça bir kod tabanında modelin zorlanmasını anlıyorum. Ama yeni bir kod tabanında neden bu kadar zorlanacağını pek göremiyorum

  • Bunun illa “fazla büyük” bir sorun olması gerekmiyor. Kullanmayı değmeyecek kadar küçük bir iş de olabilir
    Kod yazmak o kadar zor değil; çoğu zaman İngilizce okuyup yazmaktansa doğrudan kodlamak daha kolay oluyor. Gerçi ben sadece Haskell kullandığım için taraflı olabilirim
  • “Bir süredir kodu doğrudan yazmayan” durumda ne kadar kalırsan, pratik eksikliğinden dolayı artık kod yazamayacak hâle geleceğini düşünürsün?
    Mühendislik yönetiminin risklerinden biri, seni artık o işi yapamayacak birine dönüştürmesi
    Peki bu gerçekten önemli mi?
  • Her prompt'ta bin satırlık PR çıkıyorsa, bu da başka bir milyon satırlık monolitten çok uzak değil
    Yine de yazar kadar karamsar değilim. Bunun olmamasını sağlamak için süreci yönetmenin mümkün olduğunu düşünüyorum
  • Kısa süre önce ana sayfada çıkan bir örnek vardı: https://blog.k10s.dev/im-going-back-to-writing-code-by-hand/
  • Ne tür projeler yaptığın önemli. Özellikle ne kadar yeni oldukları, aramayla bulunması zor veri noktaları içerip içermedikleri ve sektör standardından sapan projeye özgü, bariz olmayan farkların ne kadar fazla olduğu belirleyici

• Ajan çalışma ortamları daha ortaya çıkalı ancak biraz 1 yılı geçti ve gerçekten epey güvenilir hâle gelmeleri de topu topu yarım yıl kadar oldu, ama şimdiden ciddi bir yorgunluk var. Bence bu, LLM'lerin gerçekten programlama yapıp yapamadığından ziyade AI destekli programlamanın zihinsel yıpratıcılığını daha iyi gösteriyor
  Ajanın kod tabanında ne yaptığını düzgünce takip etmek için karar verme sıklığı artıyor ve astronomik miktarda kod ile düzyazı okumak gerekiyor
  Bu kişisel ve psikolojik yorgunluk ile olumsuz duygular, teknolojinin kendisinin ilerleme potansiyeline dair karamsar bir öngörüye hatalı biçimde aktarılıyor

  • https://evilmartians.com/chronicles/ai-assisted-engineers-ar...
  • Teknoloji, insanların onu nasıl kullandığından ayrı bir şey değil
    Onu düzgün kullanan herkes hayal kırıklığı yaşıyor, sevenler de bakım yapılamaz bir karmayı dağ gibi biriktiriyorsa, yakında bunu tarihin çöp kutusuna atarız
    “Potansiyeli” olan çok şey var ama sonunda hiçbir şeye dönüşmeyen de çok şey var
    LLM'leri kullanmaya devam edeceğim ama bana göre ajan tarzı kodlamanın faydası şimdiden zirveyi geçti

• İşimin bir kısmı, çalıştığım büyük şirkette bu tür modelleri nasıl verimli hale getirebileceğimizi bulmak. Bir bakıma duvara domates atmaya benziyor ve bir ölçüde, onun dediği gibi çıktılarda belirli sınırlamalar varmış gibi görünen sorunlar da görüyorum
  Aynı zamanda yazısının hiçbir yerinde “model burada berbat etti ve aslında şöyle yapmalıydı” diye tutunabileceğimiz bir kod parçası ya da somut örnek yok. Bu eleştiri tarzı, bloglarda ve Twitter’daki “LLM’ler asla işe yaramaz” türü yazılarda tekrar eden bir kalıp gibi görünüyor
  Modellerin kesinlikle otomatik tamamlamadan daha iyi olduğu açık ve günlük geliştirme işimde de junior ya da mid-level bir mühendisin yapmış olabileceği bir kod tabanının büyük bölümünü üretiyorlar
  Kimse gerçekte ne tür hatalar yaptıklarına dair somut alıntılar vermezse, gerçek yeteneklerini nasıl anlayacağız?

  • LLM’lerin yaptığı hatalar epey incelikli. LLM ile kod yazmak, Whiplash filmindeki bir sahne gibi. “Benim tempom değil”, “18. vuruşta downbeat”, “hızlısın”, “yavaşsın” gibi
    Neredeyse her zaman çalışan kod üretiyor ve genelde istenen işi de yapıyor. Ama çok sinir bozucu bir şekilde biraz yanlış oluyor; insanın sandalye fırlatmak istemesine neden oluyor. Üstelik neyin nasıl yanlış olduğunu fark edecek zevki bile yok
  • İnsanlar belirli bir görevde LLM’in başarısız olduğunu anlatan blog yazıları yazdığında, savunucuların tepkisi neredeyse her zaman “başka bir model kullan”, “prompt’u şöyle değiştir”, “senin becerin yetersiz. Tekil bir örnekle yapay zeka hakkında temel bir iddia ileri süremezsin” yönünde oluyor
    O zaman ne somut örnek vermek işe yarıyor ne de vermemek. Bu durumda oyun bitmiş oluyor
    Grup atfetme hatasına düştüğümü biliyorum ama yine de durum bu
  • Bu nokta harika. LLM sayesinde, eskiden hayal bile edemeyeceği projeler yapan bir acemi olarak ben de ajanın tam olarak neyi yanlış yazdığını ve insanın bunu nasıl daha iyi yapacağını gösteren örnekler ve kanıtlar aramaya başladım
    Böyle materyaller mutlaka vardır; iyi örnekler gösteren içerikler varsa biri bana haber verse keşke
    En üst yüzde birkaçlık dilimdeki programcıların Claude ya da Codex’ten çok daha iyi yazabildiğinden şüphem yok. Ama ortalama sıradan geliştiriciden ne kadar kötü olduklarını merak ediyorum
  • Bu yazı, kötü mimariyi gösteren kod parçaları da dahil olmak üzere oldukça ayrıntılı örnekler içeriyor: https://blog.k10s.dev/im-going-back-to-writing-code-by-hand/

• Benim tahminim, modeller gelişmeye devam edecek
  1-2 yıl önce ajan tarzı kodlamaya başladığımda bunun sadece otomatik tamamlama düzeyinde işe yaradığına emindim. Bu yılın başında bir şey oldu ve model yeni bir yetenek seviyesine ulaştı
  Artık tanıdığım herkes ajan tarzı kodlama yapıyor ve bu gerçekten şaşırtıcı. Mümkün olduğunca sonuna kadar zorlamak gerektiğini düşünüyorum. Sanki insanlığın hızlanışı gözümüzün önüne gelmiş gibi

  • Şimdiden birkaç lojistik sınıra çarpıyoruz. Transformer’larda özsel bir yetenek platosu olmasa bile, iyileştirme için kullanılabilecek GPU ve enerji sınırlı; ayrıca bu altyapıyı büyütürken büyük zorluklar yaşanıyor
    Son 2 yılda yaklaşık 6 GW büyüklüğünde yeni veri merkezi duyuruldu ama gerçekten açılıp hizmet vermeye başlayanların toplamı 1 GW’ın altında. Geri kalanların teslim takvimleri sürekli erteleniyor
    Üstelik veri merkezleri içlerindeki çiplerin 6 yıl dayanacağını varsayarak konuşuyor ama bunun da gerçekçi olmadığı ortaya çıkıyor
  • Ya bir duvara doğru hızlanıyorsak?
  • “İnsanlığın hızlanışı”, bu yıl gördüğüm en büyük kendini avutma biçimi
  • Evet, bir şey oldu. Otomatik tamamlama daha iyi hale geldi. Bunun dışında ne oldu ki? Temel modeller değişmedi
    “İnsanlığın hızlanışı” gibi lafları bırakmanızı isterim. LLM ile kanseri, iklim değişikliğini, eşitsizliği ya da diğer önemli gerçek dünya sorunlarını çözen kimse yok
    Bu teknoloji üretkenliği artıracak kadar iyiyse, bunun nedeni yeni, son teknoloji ya da çığır açıcı işler yapmıyor olmanızdır. LLM’in işinizi yapabiliyor olmasının tek nedeni, o kodun eğitim verisinde yeterince sık geçmiş olacak kadar zaten fiilen yazılmış olmasıdır
    LLM ile C++26, HDL ya da çok niş bir stack yazmayı deneyin; iyi bir gerçeklik kontrolü olur

• AFL, LLM’den daha fazla açık bulmadı. Açıkları bulan şey AFL ile yetkin uygulayıcıların birlikte çalışmasıydı
  AFL hata tetikliyor ve bunların önemli bir kısmı, hatta çoğu istismar edilebilir değil. Bunları ayıklayıp değerlendirmesi gereken yine insan, artık bazen ajanlar
  Üstelik bu çalışma, AFL öncesi dönemin bellek güvenli olmayan yazılım külliyatı üzerinde yapıldı. AFL’nin altın çağı 10 yıl önceydi; şimdi ise tüm hedefler daha zor hale geldi

• Bağlam eklemek gerekirse, yazının yazarı George “geohot” Hotz. Uzun bir exploit geçmişi var; muhtemelen en çok da gerçek AI vibe coding çok daha ortada yokken, düşük bütçeyle otonom araçlar için comma.ai’yi neredeyse vibe coding yapar gibi kurmasıyla biliniyor
  https://en.wikipedia.org/wiki/George_Hotz