1 puan yazan GN⁺ 7 시간 전 | 2 yorum | WhatsApp'ta paylaş
  • Geçmişte “rockstar geliştiricilerin” geride bıraktığı anlaşılması zor kod tabanı sorunu, LLM üretimi kodun yaygınlaşmasıyla tüm ekibin bakım yüküne dönüşüyor
  • Rockstar geliştiriciler yeni teknoloji, yeni paradigma ve yeni mimariyi hızla devreye alıp zor işleri çabucak bitiriyordu; ancak başkalarının anlayıp birlikte çalışabileceği kod yazmaya pek ilgi duymuyorlardı
  • LLM ajanları önceki çalışmaları hatırlamadan kısa sürede on binlerce satır kod üretiyor ve bunun tüm sistemle uyumlu olup olmadığına ya da anlaşılabilirliği artırıp artırmadığına aldırmıyor
  • Üretilen kod arttıkça sistem karmaşıklığı da ciddi biçimde büyüyor ve bunu anlamak için yeniden LLM’lere bağımlı hale gelen bir akış ortaya çıkabiliyor
  • Uzun ömürlü yazılımlar için LLM’leri küçük kod parçaları üretmekle sınırlamak, tasarımı insanın yönlendirmesi ve mimariyi problemin karmaşıklığına göre sadeleştirmek gerekiyor

Rockstar geliştiricinin bıraktığı yapı

  • Rockstar geliştirici ekibe katıldıktan sonra yeni teknoloji, yeni paradigma ve yeni mimari konusunda güçlü fikirler ortaya koyar
  • Şirketin çekirdek mimarisinin büyük bölümünü yeniden yazar, yeni build süreçleriyle araçları ve dilleri devreye alır
  • Çok sayıda pull request’i reddederek ekipten beklenen standardı yükseltir; diğerleri ise o kodu anlayıp anlamadıklarını belli edemez
  • En zor işler rockstar geliştiriciye verilir ve o da bunları herkesten daha hızlı bitirir
  • Diğer ekip üyeleri yeni kütüphaneleri öğrenip rockstar geliştiricinin yöntemine uyum sağlamaya çalışırken daha yavaş ilerler
  • Birkaç yıl sonra rockstar geliştirici daha zor ve daha büyük şirket projeleri istediği için ekipten ayrılır

Sonuçlarla baş etmek

  • Geriye kalan ekip üyeleri rockstar geliştiricinin projelerini devralır ve kodun içinde ezildiklerini hisseder
  • Veri akışını takip etmek zordur; hatta sanki biri bir cinayeti örtbas etmeye çalışıyormuş gibi gelir
  • İşe basit bir bug fix ile başlanır ama kodu dizüstünde çalıştırmak bile bir hafta sürer
  • Kodun yarısı anlamadıkları bir dilde, diğer yarısı ise adını bile duymadıkları kütüphanelerle yazılmıştır
  • Yöneticilerine kodun yeniden yazılması gerektiğini söylerler ama “bunu rockstar geliştirici yazdı” denilerek bu fikir kabul edilmez
  • Dağınık kodun içinde kaybolurken iş ilanlarına bakıp ayrılmayı hayal etmeye başlarlar

Rockstar’tan sonra arkasını toplamak

  • Pek çok ekip ve ajans, böyle rockstar geliştiricilerin geride bıraktığı kod tabanını toparlamak zorunda kalır
  • Karmaşık bir kod tabanını anlayıp kurtarma süreci, birbirine dolaşmış yılbaşı ışıklarını yeniden kullanılabilir hale getirmek için çözmeye benzer
  • Rockstar geliştiriciler kod yazmayı, öğrenmeyi ve yeni paradigmaları kullanmayı sever; yeteneklerini sonuna kadar zorlarlar
  • Mümkün olduğunca akıllıca kod yazmaya ve olabildiğince hızlı hareket etmeye odaklanırlar
  • Başkalarının birlikte çalışabileceği kod yazmak, rockstar geliştiriciler için en düşük önceliklerden biri haline gelir

Yapay zekanın gelişi

  • Son birkaç yılda birçok ekip, adeta bir rockstar geliştirici ordusunun baskısı altında kalmış durumda
  • Birisi her yeni sohbet başlattığında ekibe yeni bir rockstar geliştirici ekleme riski doğuyor
  • Ajanlar dün ne yaptığını hatırlamıyor ve birkaç dakika içinde on binlerce satır kod üretiyor
  • Ajanlar insan açısından imkânsız denecek bir hızla işi tamamlama peşinde koşuyor
  • Üretilen kodun sistemdeki diğer kodlarla uyumlu olup olmadığına ya da sistemi daha anlaşılır kılıp kılmadığına önem vermiyorlar
  • Yapay zekanın elinde, bağlama uygun olmayabilecek “best practice” araç çantası bulunuyor
  • Karmaşıklık faydayı aştığında bile yapay zeka “kemer ve pantolon askısı” tarzı aşırı güvenlik önlemlerinde ısrar ediyor
  • Kod incelemesi istendiğinde, katılmanın zor olduğu maddelerle dolu uzun bir iyileştirme listesi çıkarıyor
  • LLM kullanmazlarsa sonsuza kadar geride kalacaklarını hisseden insanların sayısı artıyor
  • Tüm kodu LLM’lerin yazmasına izin vermenin sonunda asıl geride kalmaya yol açacağı savunuluyor

Yüzlerce AI rockstar’ın arkasını toplamak

  • Dağınık üretim kodu yığınını temizlemek, tek bir rockstar geliştiricinin kodunu toparlamak kadar keyifli değil
  • En azından rockstar geliştiricinin bir tasarım niyeti ve elinden gelenin en iyisini yapma çabası vardı
  • Vibe coding ile üretilen dağınık kod yığını, tek bir yapay geliştirici tarafından yazılmış değil
  • Kod tabanı, farklı sohbetlerde ve farklı bağlamlarda her seferinde tek bir özellik ya da tek bir bug fix üretilerek oluşuyor
  • Bu da onu, sanki yüzlerce farklı rockstar geliştiricinin yazdığı bir kod tabanına benzetiyor
  • Bazı durumlarda teknik borç o kadar büyüyor ki artık asla ödenemeyecek bir seviyeye ulaşıyor

Uzun ömürlü yazılım inşa etmek

  • LLM’leri rockstar geliştirici gibi davranmadan kullanmanın birkaç yolu var
  • Mühendisliğe insan yön verebilir ve LLM’lerden her seferinde yalnızca küçük kod parçaları üretmeleri istenebilir
  • Yazılımın, ekipteki herkesin kolayca anlayıp üzerinde çalışabileceği şekilde yazıldığından emin olunmalı
  • LLM ne yaptığını ve neden yaptığını anlamadan yoldan çıktıysa hız kesmek gerekir
  • Üretilen yazılımın kalitesini güvence altına almak için daha yavaş ilerlemek sorun değildir
  • Aşırı mühendisliği önlemek ve mimariyi problemin karmaşıklığına uyana kadar sürekli sadeleştirmek de sorun değildir
  • Bazen LLM’yi araç çantasında bırakıp kodu doğrudan kendin yazmak da sorun değildir
  • Ustalık her zaman insan elinde kalır; makinelere outsource edilemeyecek bir alandır

2 yorum

 
GN⁺ 7 시간 전
Hacker News görüşleri
  • Zanaatkârlığın her zaman insan elinde kalacağı ve asla makinelere dış kaynak olarak verilemeyeceği yönündeki son cümle biraz endişe verici görünüyor
    Diğer sektörlerde de zanaatkârlık ölmedi ama çok daha ucuz ve kolay erişilebilir alternatiflerin gerisine itildi. El yapımı deri ayakkabı hâlâ satın alabilirsiniz ama 1000 doların üzerinde ödemek isteyen az kişi var; haftalar harcanmış bir tablo da alınabilir ama çoğu insan HomeGoods'tan duvar süsü ve çeşitli ev eşyaları alıyor
    Temel fark, tek kullanımlık olduğu varsayımı; ne yazık ki yazılım da giderek diğer ürünler gibi “tek kullanımlık” hâline geliyor. Basit bir geri sayım uygulamasıysa atılıp yenisi yapılabilir ama uzun süre çalışan iş süreçlerini ayakta tutan yazılım böyle ele alınmamalı
    Yazılım zanaatkârlığına odaklanınca mesele, “benim kullanımım için gerekli olan şey” ile “butik, pahalı ve gereksiz olan şey” karşıtlığı gibi görünebilir. Oysa aslında “bakımı yapılabilir ve güvenilir olan şey” ile “atılsa da olur olan şey” karşıtlığı olmalı
    Bunun OpenAI ya da Anthropic gibi büyük model sağlayıcılarına fayda sağlayıp sağlamamasından bağımsız olarak, burada söylenmek istenen bu değil

    • Diğer sektörlerdeki zanaatkârlık, yazılımda kastedildiği biçimde ölmüyor
      Düz bir kutuda gelen ve benim tornavidayla kurduğum ucuz masa da fabrikada seri üretilmiş olabilir ama onun tasarımında, özel yapım bir üründen çok daha fazla uzmanın zanaatkârlığı yer almış olabilir. Yapı, yüksek başlangıç tasarım maliyetinden sonra düşük marjinal maliyetle seri üretime dayanıyor
      Yazılım da başından beri büyük ölçüde böyleydi. Firefox indirirken bir zanaatkâr bana özel web tarayıcısı yapmıyor; bir veri merkezindeki CDN sunucusu önbellekten bayt kopyalıyor
      Yapay zekanın tehdit ettiği şey, diğer sektörlerde büyük ölçekte pek görülmemiş olan başlangıç yatırımı tipi zanaatkârlığın ikamesi. Yapay zekanın daha başarılı biçimde ikame ettiği şey ise düşük maliyetli “el işi” yazılım; bu alan bugüne kadar ekonomisi çok zayıf olduğu için fiilen var olmayan bir kategoriydi
    • Fiziksel sektörlerle yazılım çok farklı. Deri ayakkabı her müşteri için yeniden, bir çift olarak tekrar tekrar üretilir ama kod bir kez yazılır ve tüm müşteriler aynı ürünü kullanır
      Bu yüzden kalite yatırımında çok daha büyük bir kaldıraç oluşur
      Yazılımın aynı anlamda tek kullanımlık olduğuna katılmak da zor. Sorun geçiciyse kod atılabilir ve başka bir sorun çıktığında yenisi yapılabilir. Ama sorun kalıcıysa kod da kalır
    • Talaşlı imalat tarafından bakınca ilginç bir perspektif var
      Vida bir zamanlar özel üretilen, değerli bir nesneydi ve iyi bir vida yapmak için muazzam zaman ve emek gerekiyordu. Bugün makine vidası dediğimiz şeyi bile çok yetenekli birinin aşırı emek harcayarak üretmesi gerekirdi
      Ama makineler zanaatkârlığı aktarabilir. Gerçekten iyi bir vida yaptığınızda, makine o vidanın kalitesini sayısız yeni vidaya taşır
      Günümüzde her tür ve kalitede vida neredeyse aynı ölçüde sarf malzemesi oldu; eskiden elde günler ya da haftalar sürecek bir vidayı bugün milyarlarca adet üretiyoruz
      Ben yapay zekayı da ilerleme vidası olmayan bir torna gibi görüyorum. Başta vidayı elle yapmak zorundasınız, sonrasında ise üretebildiğiniz kaliteyi istediğiniz kadar yeni vidaya aktarabilirsiniz. Daha iyi vida yapabildiğinizde onu tornaya takar, daha iyi vidalardan daha fazla üretirsiniz. Ama temelde, doğrudan yapabildiğiniz vidanın kalitesiyle sınırlısınızdır. Eğri büğrü, pütürlü ve kötü şeyler yapabiliyorsanız makineden de en fazla o kadar çıkar
    • Bu tamamen yanlış bir bakış açısı. Yazılımdaki “zanaatkârlık”, ayakkabının üretimine değil ayakkabı tasarımına daha yakın
      Yazılım geliştiricileri yazılım birimleri üretmez, özgün fikrî mülkiyet oluşturur. Kitap yazarlarına ya da müzisyenlere daha çok benzerler
      Yazılımda birim üretime karşılık gelen bir şey yok. Sadece bitlerin kopyalanıp taşınması söz konusu
      Dolayısıyla yazılım bağlamında “zanaatkârlık”, iyi bir şeyi tasarlamaya ne kadar özen gösterdiğiniz anlamına gelir. Kullandığımız yazılımın kalitesinin artık önem taşımadığı bir noktaya varmadığımız sürece ortadan kalkmayacaktır ve şu anda o yöne gittiğimize dair bir işaret yok
    • El yapımı ayakkabı benzetmesi, tek bir kişinin kullandığı yazılımdan bahsetmiyorsa pek uymuyor gibi
      Daha uygun bir karşılaştırma, ayakkabı fabrikasının üretim ekipmanını yapan ve bakımını üstlenen mühendisler olabilir. Tüketiciden bir adım uzaktalar ama orada da açıkça zanaatkârlık var
  • AI ya da dış kaynak kod düzeltme işi harika. Geçen hafta bir müşterinin departmanı için bir aracı vibe coding ile yapmaya çalıştığını öğrendik; ortaya çıkan şey derlenmek için 10 GB bellek isteyen devasa bir Next.js çöpüydü, binlerce lint hatası vardı ve Git'e gürültülü geliştirme logları bile girmişti
    Şimdi bunu bizim düzeltmemiz gerekiyor; yani bu tür işler tekrar tekrar gelen 10 bin ila 50 bin euroluk bedava işe benziyor. Ne yaptığınızı biliyorsanız çok kolay, bilmiyorsanız imkânsız. Daha fazlasını getirsinler yeter

    • Bir bakıma müşteri, uygulanacak spesifikasyonu ve UI mockup'larını vermiş oldu
    • Buna 1000 kat katılıyorum
      KOBİ'lere yönelik ihlal müdahalesi işi yapıyorum; son birkaç yılda iş yükü başa çıkması zor olacak kadar arttı ve banka hesabım bir ejderhanın altın yığını gibi hissettiriyor
      Güvenliğin her zaman entegre edilmesi ve planlanması gerektiğini savunuyorum; ihlal vakaları görmek istediğim falan yok
      Ama muğlak bir uzmanlığa sahip insanların bir saat içinde uygulama fışkırtabilir hâle gelmesi, benim gibi insanlar için muazzam bir piyango oldu
    • Bu tür işlere odaklanan ajanslar büyük para kazanacak. Zaten birkaç tane aldık ve insanlar ürünleri vibe coding ile yapabileceklerini düşündükçe daha fazlası gelecektir. Dediğin gibi kolay para
    • Bir sürü insan AI üzerine büyük para koyuyor. Bunların bir kısmı umut verici ama her bahis kazanmayacak
      Bu düşünce tarzına, insanların para attığı bir insan slot makinesi gibi bakılabilir
    • Kendi kimliğini ya da müşteri kimliğini açığa çıkarmadan, bunun pratikte nasıl geliştiğine dair daha fazlasını anlatıp anlatamayacağını merak ediyorum
      Müşteriler size geldiğinde, baştan itibaren bunu prod'a çıkarmak için yardım mı arıyorlardı, yoksa AI yaklaşımı tamamen çöktükten sonra son çare olarak mı geliyorlardı, merak ediyorum
      Bu projelerin genelde çöküş biçimleri var mı, yoksa başarısızlık çoğunlukla daha ince ve sinsi mi oluyor diye de merak ediyorum
  • Hayatta gerçekten olağanüstü diyebileceğim birkaç insanla karşılaştım. “Bir insan nasıl bu kadar zeki olabilir?” dedirten türden insanlardı.
    Gerçekten zeki insanlarda görülen iki özellik var ve bunlar genelde birbirini dışlıyor. Biri, ne kadar zeki olduklarının farkında olmamaları. Bir şey onlara basit geldiği ya da kendi bildikleri bir konu olduğu için, bilgisayar bilimi diploması olan herkesin bunu bildiğini, hatırladığını ve anladığını varsayıyorlar. Kriptografiyle ilgili matematiği durmadan anlatan arkadaşları dinlerken, “O dersi geçtim ama az önce anlattığın konuyu gerçekten bildiğimi söyleyemem” diye hissettiğim oldu.
    Diğeri ise, çevresindeki insanların çoğundan daha zeki olduğunun sürekli ve acı verici biçimde farkında olan insanlar. Bazıları kaba davranıyor, bazılarıysa kendilerinden görece “daha aptal” insanlarla çevrili olmaktan bıkmış durumda. İkinci gruba bir ölçüde empati duyuyorum. Her şeyin açık, bariz ve kolayca çözülebilir göründüğü bir hayat yaşayıp, cevabı çoktan belli olan konularda insanlığın durmadan saçma seçimler yaptığını izlemek zorunda kaldığınızı hayal edin.

    • Üçüncü bir sorun daha var. İnsanların çok büyük bir çoğunluğu kendisinin o son cümlede tarif edilen kişi olduğuna inanıyor.
    • Çok okuduğumu ya da IQ’mun yüksek olduğunu iddia etmiyorum ama sağduyu gibi gelen küçük meselelerde benzer hissediyorum.
      İnsanların bocaladığını ya da X yapılırsa bariz biçimde kötü sonuç olan -Y ortaya çıkacağı hâlde yine de X yaptıklarını görünce çıldıracak gibi oluyorum. Çoğu zaman bunu yüksek sesle söylememeyi öğrendim.
      Özellikle yakın aile ilişkilerinde bu hiç sağlıklı olmuyor. O kadar çok şey görüyorum ki, istersem dırdırımla insanı öldürebilirmişim gibi geliyor.
    • Böyle insanları tanıdım ve karşılaştım.
      Ama hiçbiri, ekip olarak bizim ve benim aylarca temizlemek zorunda kaldığımız devasa bir enkaz bırakmış bir 10x geliştirici değildi.
    • Birinin temel bir özelliğinde uç noktada olması, yalnız bir hayat demek.
      Ne kadar çabalarsanız çabalayın, insanların çoğuyla ilişki kurmak zor oluyor ve onların da sizi anlaması özellikle zor oluyor. Yaşanmış deneyim farkı çok büyük oluyor ve çoğu zaman aşılması kolay olmuyor.
    • Pek çok geliştirici sadece gündelik işlerini yapmayı ya da cargo cult yaklaşımını izlemeyi seçiyor.
      Her geliştirici aynı çıktıyı üretemez elbette ama kültürel ortalamanın ötesinde düşünmeyi sürdürmeye karar verirse herkes kendi biçiminde daha zeki olabilir.
      Çoğu insan bunu yapabileceğinin farkında bile değil.
  • Şu iki cümle bana çok dokundu.
    “Veri akışını takip etmek o kadar zordu ki sanki biri bir cinayeti örtbas etmeye çalışıyordu.”
    “Kodu sadece dizüstü bilgisayarda çalıştırmak bile bir hafta sürdü.”
    Veri akışını anlamakta ya da düzgün bir geliştirme ortamı kurmakta zorlanan tek kişinin ben olduğumu hep sanıyordum. Sahtekârlık sendromu ve zaman zaman “hız” dayatan toksik ortamlar da hiç yardımcı olmadı.
    Bunun sadece bana özgü olmadığını görmek iyi geldi.

    • “Kodu sadece dizüstü bilgisayarda çalıştırmak bile bir hafta sürdü” kısmı şaşırtıcıydı.
      CLI üzerindeki Claude Code, uygulamayı ayağa kaldırmayı ve rastgele bağımlılık ya da Docker sorunlarını debug etmeyi eskisine göre çok daha kolay hâle getirdi. Eskiden hem mimariyi öğrenmek hem de neden kendi makinemde çalışmadığını çözmek zorundaydım.
    • Yalnız değilsin. Ben de aynı şekilde hissettim ve bu tür bilgi genelde insanların kafasının içinde ya da rastgele bir Slack yazışmasının içinde oluyor.
      AI kodunda bu daha da kötüleşiyor. Çünkü çoğu zaman o anda makul görünen şeyler sadece üretilmiş oluyor.
  • Başkalarının arkasını toplamak zorunda kalan insanları biraz kıskanıyorum. En azından bulmaca çözer gibi bir tarafı var.
    Şu anki işim gerçekten çok sıkıcı. Junior birinin de yapabileceği kadar basit işler ama nedense mid-level geliştirici istediklerini söylüyorlar. Bunun bu işten daha iyi olduğumu söylediğim anlamına gelmediğini ya da mid-level birinin böyle işler yapmayacağını savunduğumu düşünmeyin. Sadece bu şirketin yazdığı koda ilgi duymaya kendimi zorlayamıyorum. Eski, tozlu ve önemli hiç kimsenin kullanmadığı şeyler. Müşteriler bu aracı bir zamanlar satın almış, şimdi de yeterince umursamadıkları için kullanmaya devam ediyor; sonuçta eğlenceli bir araç değil, değiştirilmeye değecek kadar da önem vermiyorlar.
    Yakında deneyimime daha uygun bir işe geçeceğime dair söz verildi ama böyle durağan bir şirkette o tür müşterilerin geleceğine pek inanamıyorum.
    Bu şirketin hem müşteri hem çalışan kaybetmesi şaşırtıcı değil. Ama ipoteği ödemem gerekiyor. Bugün sözleşmenin uzatılmayabileceği söylendi; açıkçası bu, fiilen aynı maaşa daha fazla sahiplenme ve daha fazla iş istenmesiyle tehdit edilmek gibiydi.
    Ne yazık ki gerçekten ilginç yeni bir pozisyon bulana kadar dayanmak zorundayım. Çok paraya da ihtiyacım yok, “gelişim” gibi şeyler de hiç ilgimi çekmiyor. Sadece hayatta kalmaya yetecek kadarına ihtiyacım var.
    Bu yorum konuyla çok alakasız olmuş olabilir, kusura bakmayın. Bunu dökebileceğim başka bir yer yok.

    • Yalnız değilsin. Microsoft’ta birebir aynı durumdaydım ve sonunda istifamı verdim.
      L63’tüm ama yaptığım işi L60~L61 seviyesindekiler de rahatlıkla yapabilirdi ve sık sık David Graeber’in sözünü ettiği Bullshit Jobs türü işlerden birinde olduğumu hissediyordum. Maaş cömertti ama işe girişte verilen hisse teşviki bitince, o işte yalnızca istikrar uğruna kaldığımı fark ettim.
      Kendimi, Hooli ofisinin terasında hisselerinin vest olmasını beklerken güneşlenen mühendislerden biri gibi hissetmeye başlamıştım. Kariyerimde 9. yılımdaydım ve bunun o aşamada benim için en iyisi olduğuna inanmıyordum.
      Gerçi benim büyük mali yükümlülüklerim yoktu, o yüzden karar vermek çok daha kolaydı.
    • İlk başta “medior” sözcüğünün “senior” için garip bir yazım hatası olduğunu sandım ama iki kez görünce araştırdım. Avrupa’nın bazı bölgelerinde orta seviye anlamında kullanılıyor gibi görünüyor.
    • “Bu şirketin yazdığı koda ilgi duymaya kendimi zorlayamıyorum” sözüne çok katılıyorum.
      Berbat şirketlerin ürettiği berbat ürünler, çoğu zaman insanların tembelliği ve zevksizliği üzerinde yaşıyor; pazarlamacılar da bunu paraya çeviriyor.
      Şimdi daha da kötüsü, bütün alanın LLMleşmesi ile bu durum 100 kat büyütülüyor. Kodu bakım yapılamaz hâle getiriyor ve daha da kötüsü hepimizi daha aptal yapıyor.
      Keşke bunu hiç keşfetmemiş olsaydık diye içtenlikle düşünüyorum.
    • Üzerinde çalıştığın kod tabanına dikkatle bakarsan, ister başkasının bıraktıkları ister kendi bıraktıkların olsun, temizleyecek epey şey bulma ihtimalin yüksek.
    • “Aynı maaşa daha fazla sahiplenme ve daha fazla iş istenmesiyle tehdit edilmek” kısmını biraz merak ettim.
      Bunun sadece daha fazla mesai ve angarya iş anlamına mı geldiğini, yoksa gerçekten daha çok kod yazma fırsatı mı içerdiğini, ya da bir anda daha değerli olduğunu kanıtlama beklentisi mi olduğunu merak ediyorum.
      Yaşadığını küçümsemeye çalışmıyorum. Eğer ikinci durumsa, belki gerçekten bir şeyler yapılabilir mi diye düşünüyorum.
  • İlk birkaç bölüm bana çok dokundu. Eskiden rockstar geliştirici olduğumu sanıyordum ama bunun iyi bir şey olmadığını fark ettim
    İşleri ekip arkadaşlarımdan 10 kat daha hızlı bitirebiliyor olabilirdim. Ama bir noktada bunun benim ortalama bir insandan 10 kat daha üretken olmamdan değil, çalışma tarzımın etrafımdaki ortalama insanları 1/10 kadar üretken hâle getirmesinden kaynaklandığını anladım
    Sonra yavaşladım ve bu, genel olarak hayatım için olumlu bir değişiklik oldu. Takım oyuncusu olmak bu çılgın sektörde aynı düzeyde yukarı yönlü hareketlilik sağlamıyor ama ruh sağlığı için şaşırtıcı derecede iyi oldu

    • Ben de geçmişte rockstar tarzında geliştirip sonunda kendi ayağıma sıktığım zamanlar yaşadım
      Benim durumumda bu genelde gereksiz şeyleri aşırı soyutlamak ya da gerçekte hiç ortaya çıkmayacak kullanım senaryoları için bir şeyler yapmak şeklinde oluyordu. Bu yüzden düşüncelerim aşırı soyutlamaya kaydığında YAGNI ve KISS'i hatırlamaya çalışıyorum
  • Bu yazının değeri çok düşük
    Ne demek istediği bile pek anlaşılmıyor, daha çok kendi kendini sırtını sıvazlayan bir yazı gibi duruyor

    • Kötü kod diye bir şey kesinlikle var. Ama bu yazı, “kötü kod” ile “karmaşık, büyük ve alışması zaman alan kodu” birbirine karıştırıyor gibi görünüyor
      “Rockstar geliştirici”nin bıraktığı muazzam miktarda kötü kod denilen şeylerin önemli bir kısmı, aslında değişen gereksinimlere karşı karmaşıklığın uzun süre boyunca yavaş yavaş birikmesinin sonucuydu
      Ayrıca insanlar “okunabilirlik için refactor yapıyorum” diye düşünüyor ama gerçekte çoğu zaman olan şey “kodu yeniden yazarken süreç içinde onu anlamaları” oluyor
    • Özetle söylenen şey “LLM kullanırken yavaşla ve ne yaptığını düşün”müş. 5 dakikamı çaldı
      Daha fazla içerik ya da gerçek örnekler bekliyordum. Yazının %90'ı yazarın söylenmesine ve sorunu tanımlamasına gidiyor, sondan bir önceki paragrafta da alelacele ortaya atılmış belirsiz bir çözüm geliyor. Gerçek bir ilgisi ya da faydası neredeyse yok
  • Kârlı iki projemin etrafındaki altyapıyı kurmaları için iki production engineer üzerinde sert baskı kurmam gerçekten aptalcaydı
    Her şeyi 10x patronu gibi spagetti kodla yapıp Anthropic'e geçerek 9 haneli bir maaş paketini kapmış olsaydım çok daha fazla para kazanabilirdim. Aptal, hem de çok aptaldım
    En azından benim buradan çıkardığım sonuç bu

  • Yazılan kodun bakımını çoğu zaman yazarı değil, başka biri yapmak zorunda kalır. Bu yüzden kimsenin anlayamadığı kod yazarsan sonuçta bakım başarısızlığına yol açarsın
    Ekip için anlaşılması kolay kod, hız, teknik mükemmellik gibi farklı şeyleri optimize ediyor olabilirsiniz
    Ama teknik mükemmelliği optimize etsen bile ekipteki başka hiç kimse o kodu anlayamıyorsa bu yine de başarısızlıktır
    Aşırı tasarlanmış kod gördüm

 
GN⁺ 7 시간 전
Lobste.rs görüşleri
  • Bu yazıda gerçekten işe yarar tavsiye pek yok

    • Birinin kişisel şikâyetlerini inandırıcı göstermek için iki moda terimle süslenmiş gibi duruyor
      “Rockstar geliştirici” ifadesi her zaman şüpheli gelmiştir, ama gerçekten üstün geliştiriciler var. Yalnız bu insanlar yazıda tarif edildiği gibi davranmaz; mevcut ortam içinde ellerinden geleni yapar, kod tabanını iyileştirir, doğrulanmamış yeni şeyleri oyuncak gibi içeri taşımaz ve testler, script’lenmiş deployment, linting vb. sayesinde ayrıldıklarında sistemi daha kararlı bir halde bırakırlar
      Buraya yapay zeka da sanki bu davranışları daha kötüleştirecekmiş gibi eklenmiş, bu mümkün olsa da henüz yeterince kanıtlanmış görünmüyor. On yıllardır danışman olarak çalışıp berbat kod tabanlarını çok temizledim; bazen neden haddini aşan kişilerdi, ama daha sık sebep daha iyi yöntemi bilmeyen ekiplerdi. Hiçbir durumda da “bunu bir rockstar/ninja/moda terim geliştirici yapmıştır herhalde” diye düşünmedim
  • Artık sadece chatbot’un tepemize boca ettiği çöpleri temizlemekle kalmayıp, bunu umursamayan insanların arkasını da toplamak zorunda mıyız diye düşündürüyor
    Tek yaptığım balonun sönmesini beklemek

    • Zaten hep böyleydi, yapay zeka sorunu büyütüyor sadece. Öte yandan toparlama işini kolaylaştırdığını da söyleyebiliriz
  • 2026’da bir şirkete katılıp hâlâ create-react-app kullandıklarını görürseniz, gerçekten önerilen davranış biçimi nedir merak ediyorum. Hiçbir şey söylemeyip geçmek mi gerekiyor?

    • Yeni bir projeyse artık deprecated olduğunu ve önerilmediğini söyleyebilirsiniz
      Eski bir projeyse teknik borç bulmuşsunuz demektir. Herkeste vardır. Bunu düzeltmeye ikna etmenin en iyi yolu, iş açısından mantıklı bir gerekçe oluşturmaktır. Çalışıyorsa gerçekten bir risk mi? Diğer teknik borçlarla kıyaslandığında önceliği ne? Yükseltmezseniz hangi örtük riskleri üstleniyorsunuz? Yükseltmek için ne kadar emek gerekir?
      Emek azsa ve ekip arkadaşlarınız da istiyorsa izin istemeden doğrudan yapmak da mümkün olabilir. Ama bu en çok, değişiklikten etkilenen kişilerin desteği varsa ve kendi çıktınızı aksatmıyorsa işe yarar. Şirketteki ilk haftanızda yapılacak iş olmayabilir
      Genelde “nasıl olması gerektiğini” söylemektense, neden şu anda böyle olduğunu sormak ve anlamaya çalışmak her zaman daha iyidir. Geçmişi olan her kod tabanı, henüz bilmediğiniz binlerce kararın sonucudur. Bilgi ve empatiyle donanmanız gerekir
    • Katıldığımda önce gözlemlemeyi, farklı yapılması gereken her şeyi hemen işaret etmekten daha çok tercih ederim. Ekibe yeni giren birinin her şeyi değiştirmesiyle gerçekten etki yaratan işlere odaklanması arasında bir denge var. Daha yeni katılmışken neyin etki yarattığını henüz bilmiyorsunuz
    • Hangi kavgayı seçtiğinize bağlı. Şahsen buna değmez diye düşünüyorum ama ben siz değilim. Legacy code her yerde var ve create-react-app gibi bir framework’ten çıkıp yeniden yazmanın maliyeti, insanların zaten alışkın olduğu durumda devam etmesinin maliyetinden çok daha yüksek
    • Web geliştiricisi değilim ama bu sorunun anlamı ne? create-react-app’in eskidiği mi söyleniyor, yoksa React’in mi?
    • İnsanların artık CRA’den nefret ettiğinin bu kadar doğrulanmış olması hissini paylaşmak istedim
      Ben 2020’de hâlâ havalı göründüğü zamanlardan beri nefret ediyordum
  • “Ajan dün ne yaptığını hiç hatırlamıyor” kısmı çözülebilir bir sorun. Bellek yaklaşımları vb. kullanılabilir. Evrensel olarak iyi değil ama giderek iyileşiyor
    “Bu kodun sistemdeki diğer kodlarla iyi uyum sağlayıp sağlamadığını umursamıyor” kısmıysa benim deneyimimle örtüşmüyor. Genelde LLM tarafından üretilen kod, ilgili alandaki benzer koda epey benzemeye eğilimli oluyor. Yönünü bulmak için okuduğu kod neredeyse aynen yansıyor
    “Sistemin anlaşılmasını kolaylaştırıp kolaylaştırmadığını umursamıyor” da çözülebilir. Bunu LLM’e değerlendirtebilir ve kademeli olarak düşürebilirsiniz. Neyin daha anlaşılır olduğunun çoğu zaman sistemin deterministik olmayan bir özelliği olması nedeniyle, paradoksal biçimde bunu ölçmek için diğer araçlardan daha uygun yaklaşım LLM olabilir. Yeni bir oturumda “bu yeni eklenen kodu anlamak için sistemin ne kadarını anlamak gerekiyor” diye sorup o kapsamı daraltacak şekilde optimize edebilirsiniz
    “AI’ın burada uygun olmayabilecek best practice araç çantası var” kısmı, AI kullanma sürecinin çoğu zaman yeni bir projeye aynı ideallerle gelen bir junior geliştiriciyi eğitmeye benzemesinden kaynaklanıyor. Junior’a sözlü olarak anlatır, bunu hatırlayıp uygulamasını beklersiniz; AI içinse bunu AGENTS.md / CLAUDE.md dosyalarına yazarsanız bilgi kalıcı olur
    “Kod incelemesi istediğinizde katılmadığınız bir sürü iyileştirme çıkarıyor” kısmında ise, Codex özelinde listeyi küçük, öz ve yüksek değerli tutacak şekilde ayarlanmış durumda. Diğer modeller farklı olabilir ama bu da sonuçta talimat düzeyiyle ilgili bir mesele. Önem verdiğiniz şeyler çoğu zaman dokümante edilmeye değerdir ve AI kullanınca buna ihtiyaç duyulur

  • Rockstar’larla uğraşırken sorunun yarısı egodur, ama yine de insanın yazdığı kodu bırakan bir rockstar’ın arkasında bunu destekleyen bir düşünce ve niyet olurdu
    Buna karşılık AI’ın üstüne insan kabuğu geçirilmiş “rockstar”ların havası aynı hatta daha büyük, ama çözdüklerini iddia ettikleri problemin yarısını bile gerçekten bilmeyebiliyorlar

  • Fonksiyonel programlama yaklaşımını olabildiğince uygulayıp, farklı şekillerde bir araya getirilebilen bağlamdan bağımsız bileşenler oluşturursanız ciddi bir kaldıraç elde edebilirsiniz
    Uygulama ayrıntılarını soyutlayan tekil yapı taşlarını, belirli bir bağlama bağlı işlerden ayırırsanız; gereksinimler değiştiğinde veya başka bir yaklaşım seçildiğinde bu blokları kolayca yeniden düzenleyebilirsiniz. Ayrıca tüm yerleşim bağlamını bilmeden her parçayı bağımsız olarak akıl yürüterek değerlendirebilir, bu parçaların nasıl birleştiğine bakarak üst düzey mantığı anlayabilirsiniz
    Fonksiyonel diller, LLM ile çalışmak için iyi bir temel sunar. Çünkü kodu doğal olarak bağlamı sınırlayacak şekilde yazmaya yönlendirir. Bu da programın belirli bir işlevini anlamak için gereken kapsamı azaltır ve hem model hem de insan kullanıcılar için fayda sağlar