GDD - "Gaslight-driven development" çağı

• Son dönemde bilgisayar kullanıcıları, kendi iradelerinden bağımsız olarak sayısız anlamsız işi tekrar tekrar yapıyor ve bilgisayarın söylediğini uyguluyor
• LLM'ler geliştiricilerin API tasarlama biçimini etkilemeye başladı; hatta geliştiricilerin AI'nın önerdiği özellikleri benimsediği ve yakında kodun çoğunu AI'nın yazacağı yönünde öngörüler ortaya çıktı
• Örneğin, Soundslice ChatGPT'nin yanlış yönlendirdiği bir özelliği gerçekten ekledi
• Bunun nedeni, LLM'lerin çok sayıda API'yi analiz ederek geliştiricinin ilk aklına gelebilecek sezgisel tasarımları önermesi
• Yeni fikirler ya da özgün yaklaşımlar geliştirirken LLM'ler uygun olmasa da, çoğu durumda en bariz tasarımı izlemek etkili olabilir
• Artık AI'nın yalnızca araç kullanımını değil, araçların nasıl tasarlanacağını da yönlendirdiği bir döneme girildi

---

Gaslight-driven development

Gündelik hale gelen anlamsız işler

• Son 10 yılda bilgisayar kullanan herkes, üyelik oluşturma, e-posta doğrulama, çerez onayı, CAPTCHA girme gibi özünde gereksiz işleri tekrar tekrar yaptı
• Kullanıcılar bunu istemeseler de bilgisayarın dediğini yapmak zorunda kaldı
• Bu tekrarlar sayesinde, bir bakıma makinenin söylediğini yapmaya alışmış bir hayat zaten normalleşmiş durumda

LLM'lerin değiştirdiği geliştirme gerçeği

• Son dönemde LLM'ler API ya da arayüzlerin nasıl görünmesi gerektiği konusunda fikir bildirmeye başladı
  • 2025 Eylül'ünde toplam kodun %90'ını AI'nın yazacağı yönünde tahminler bile var
• Soundslice örneğinde olduğu gibi, ChatGPT var olmayan bir özelliğin mevcut olduğunu sanıp müşteriler bu özelliği sürekli isteyince şirketin gerçekten o özelliği eklediği durumlar yaşandı
• Instant'ta da benzer bir olay oldu: Daha önce insert ve update işlemlerinin ikisi de tx.update ile yapılıyordu, ancak LLM sürekli tx.create kullanan kod ürettiği için sonunda tx.create metodu eklendi

Bu olgunun anlamı

• Bu değişimin olumlu mu olumsuz mu olduğunu söylemek zor
• Bir yandan, LLM'ler çok sayıda API üzerinde eğitildiği için geliştirici açısından 'en sezgisel' yöntemi önerme etkisine sahip
• Aynı zamanda API'leri yeni başlayanların bakış açısından (newbie’s POV) test etmenin yeni bir yolu
  • Eskiden geliştirici hata yapınca belgeye bakıp kendisi düzeltirdi; şimdi ise LLM sürekli yanlış kullanım örnekleri üreterek geliştiricinin de problemi daha hızlı fark etmesini sağlayabiliyor

Sınırlar ve soru işaretleri

• Yenilikçi işlerde bu yaklaşım uygun değil
  • LLM'ler alışık olmadığı kalıpları ya da tamamen yeni kavramları anlayamıyor
• Sonuçta API gibi alanlarda 'sıradanlık' en iyi seçenek olabilir
  • Çoğu durumda karmaşık tasarlamak yerine hem AI'nın hem geliştiricinin sezgisel olarak anlayabileceği biçimler daha avantajlı

Sonuç: yeni bir çağın başlangıcı

• AI artık yalnızca verilen araçları kullanmakla kalmıyor, aracın kendisinin nasıl tasarlanması gerektiği konusunda da fikir sahibi olmaya başlıyor
• Ve bu fikirler çoğu zaman sanki başından beri öyleymiş gibi geliştiricileri ve organizasyonları gaslighting yoluyla etkiliyor
• Önümüzdeki dönemde AI'nın beklenti ve sağduyusuna göre geliştirme yapmak, doğal bir standart haline gelebilir

[ffdd270]

Bazen, yol bağımlılığı denen büyük kavramın içine LLM bağımlılığı diye güçlü bir çivi çakılıyormuş gibi geliyor. "Eskiden beri kullanıyoruz"dan "LLM seviyor"a doğru değişen bu his, sonuçta nereye varacak acaba...

[kandk]

LLM bunu uzun zamandır kullandığımız şeylerden öğrenmişti..

[jujumilk3]

"Artık bilgisayarı kapatabilirsiniz"

[rosen]

Mükemmel bir benzetme!!

[GN⁺]

Hacker News görüşleri

• LLM'in gerçekte var olmayan API endpoint'leri önermesi durumunda, bunu kabul edip o endpoint'i özellikle implemente ederek bilerek 421: Misdirected Request durum kodu döndürmenin nasıl olacağını düşündüm; ya da doğrudan gerçek 501: Not Implemented da kullanılabilir. Eğer 501 ton olarak tam uymuyorsa, yeni bir durum kodu olarak 513: Your Coding Assistant Is Wrong öneriyorum
  HTTP durum kodları wiki referansı
  • 513: Your Coding Assistant Is Wrong fikri çok komikti, sayende keyfim yerine geldi; bir yandan HTTP 407 Hallucination da önermek isterim, yani sunucunun isteği anladığı ama bunun gerçeklikle uyuşmadığına karar verdiği durum
  • Bu hikâye bana GPS'in yanlış olduğunu söyleyen eğlenceli bir uyarı tabelası örneğini de hatırlattı
    GPS is wrong örneği
  • 513 durum kodunun eklenmesine oy veriyorum; zaten 418 kodu da var, 513 olmaması için bir neden göremiyorum
  • Böyle bir şaka yapacaksanız lütfen 418 yanıtını kullanın, daha yaygın kullanılmasını isterim
• Birden fazla kullanıcının aynı sayfaya baktığını gerçek zamanlı görmek eğlenceliydi ama sürekli girip çıkan kullanıcı göstergeleri yüzünden yazıyı okumak çok zorlaştı
  • Böyle sabit ya da sticky öğeleri tek seferde kaldıran bir bookmarklet'im yer imi çubuğumda duruyor; bunu sık kullanıyorum çünkü sayfanın üstündeki tüm sabit/sticky öğeleri kaldırıyor ve scroll'u da geri getiriyor
    (JavaScript kodu sağlanmış)
  • Ben de benzer şekilde rahatsız oldum; sağ tıklayıp Inspect ile geliştirici araçlarını açtıktan sonra aşağıdaki kodu konsola yapıştırınca o kullanıcı gösterim alanı kayboluyor

    document.getElementById("presence")?.remove();
    

    Beyninizin neden özellikle bu harekete bu kadar hassas tepki verdiğini merak ediyorsanız, bunun avcı tespiti içgüdüsüyle ilgisi var
    bilimsel makale bağlantısı, sinirbilim wiki referansı
  • Aklıma Chess Royale geldi; avatarlar ve bayraklarla benzer bir deneyim yaşatıyordu. Gerçekten iyi yapılmış bir oyundu ama Ubisoft'un zaman zaman yaptığı gibi hizmeti kapattılar; kaybolmasına üzüldüğüm bir klasikti
    Chess Royale ekran görüntüsü
  • Eskiden arka planda imleçlerin dolu olduğu sayfa bu değil miydi? Bu noktada bunun bilerek dikkat dağıtıcı yapılmış şaka gibi bir tasarım konsepti olduğunu düşünüyorum
  • uBlock gibi araçlarla sayfa öğelerini kaldırmaya çalışırken bunu adeta köstebek vurma oyunu gibi sürekli tekrarlanan bir durum olarak yaşadım
• Instant'ta tx.update fonksiyonu hem entity ekleme hem de güncelleme işini yapacak şekilde tasarlanmış, ama LLM durmadan tx.create kodu yazıyordu; sonunda tx.create fonksiyonunu da ekledim. Böyle kafa karıştırıcı noktalarda yalnızca LLM'lerin değil gerçek geliştiricilerin de gereksiz yere çok zaman kaybetmiş olabileceğini düşündüm
  • Sonuçta tx.create baştan beri yoksa, birinin zaman kaybetmesi de söz konusu olmazdı diye düşünüyorum
• Hem eklemeyi hem güncellemeyi destekleyen bir fonksiyon için adın update yerine put olması gerektiğini düşünüyorum; update yanlış anlamaya açık
  • Böyle durumlarda doğru ad sanırım upsert
  • put adı mevcut içeriğin üzerine yazmayı ima ederken, upsert hem ekleme hem güncelleme anlamını taşıyor
• LLM yanlış bir metin üretti diye ben tek satır kod değiştirmeden önce evrenin ısıl ölüme girecekmiş gibi geliyor; böyle saçma bir sebeple kodu değiştirmek zorunda olmak bana hem komik hem de kabul edilemez geliyor
• Gönderinin tezine katılmıyorum; gerçekten bilgisayarın istediği gibi davranmak zorunda mıyız diye en baştan sorguluyorum
  Kullanıcıların e-posta doğrulaması ya da kayıt olması da bilgisayar emrettiği için değil, insanların yaptığı tasarım tercihleri yüzünden diye düşünüyorum
  • Buna "thesis" demek bile cömert bir yorum olur; o kısmı görür görmez sayfayı kapattım
• Kısa süre önce ekibimle gelecekteki kodlama ilkeleri hakkında eğlenceli bir sohbet yaptım
  İleride kodun okunabilirliği, SOLID ilkeleri ya da karmaşıklığa odaklanmaktan çok, kullandığım agentic IDE'nin kod bağlamını ne kadar iyi indeksleyebildiği ve modelin o kod üzerinden ne kadar iyi üretim yapabildiği daha önemli olacak gibi görünüyor
  Kod değişim hızı çok arttıkça bakım yapılabilirlik aslında temel metrik hâline gelecek; prompt ile kodun ne kadar uyumlu olduğu ve tesadüfen iyi örtüşen kodun kullanılabilirliği gibi şeylerin daha fazla öne çıktığı bir dünyaya gidiyoruz diye düşünüyorum
• Eğer biri sürekli kendinden emin bir şekilde yeni ama aslında uydurma geliştirme tavsiyelerini benim ürünüm hakkında yayarsa, şirketlerin buna cevaben o hayali özelliği gerçekten ekleyip sonra da şaşkın bir blog yazısı yazıp yazmayacağını merak ediyorum
  • Ben de doğrudan LLM gibi davranıp alakasız hatalar yapsam ama bunları kendimden emin şekilde savunsam, insanlar yine de anlayış gösterir mi diye merak ediyorum
  • Aslında “Clean Code”un yazarı Mr Martin de biraz böyle biri değil mi diye dönüp düşünüyorum
  • Eğer o kişi müşterilerimin %90'ını etkiliyor olsaydı, muhtemelen o hayali özelliği gerçekten eklerdim
  • Çoğu şirketin de kendinden emin bir şekilde o gereksiz özelliğin mutlaka gerekli olduğunu savunacağını düşünüyorum
• Bir yandan bu, LLM ile güzel bir dostluğun başlangıcı gibi de hissettiriyor; fractional CTO olarak çalışırken beni en çok yoran şeylerden biri, farklı müşterilerde environment isimleri gibi küçük naming convention'ların tamamen farklı olması
  Örneğin AWS tarafında dev, prod var, Expo'da ise test, production kullanılıyor; projeler arasında gidip geldikçe bu beklenenden daha fazla zihinsel yük oluşturuyor
  LLM'in de bu problemi çok daha büyük ölçekte yaşıyor olabileceğini düşünüyorum
  Gereksiz API adlandırma/davranış karmaşasına giden bu sinapsları gerçekten anlamlı işlere ayırabilsek en iyisi bu olurdu
  • Bilgisayar biliminde üç zor problem olduğuna dair bir şaka vardır — cache invalidation, isimlendirme ve off-by-one hataları
    LLM ne kadar akıllıca isim verirse versin, incoherent stochastic process'e dayandığı için sorun sürüyor
    Ayrıca environment adlandırmasının neden standart olmadığını hiç ciddi ciddi sordunuz mu diye de sormak isterim
    Eski bir CTO olarak bunu, organizasyon içi iletişim ve standart eksikliği gibi iyileştirilmesi gereken şeylerin işareti olarak görüyorum
    Gerçek kültürü geliştirip ekip farkındalığını artırabildiği için, bu kadar kolay düzeltilebilecek konuları LLM'e bırakmak yerine daha doğrudan ele almak gerektiğini söylemek isterim
• İlgili bağlantı olarak
  önceki Hacker News tartışmasına bakın

[dkmin]

Soundslice'ın viral başarısı