Kodu Bizzat Yazın

• Kodu bizzat yazma ve ezberden yeniden oluşturma çalışması, kopyalamaya kıyasla anlama ve hafızayı daha sıkı biçimde sınar
• Freecoding, sözdizimini, tipleri ve isimleri zihinde tutarak kodu karakter karakter yazabilme becerisidir ve araçlar çağında da gereklidir
• Sözdizimi, yüksek seviyeli düşünmeyi engelleyen bir gürültü değil; daha yüksek seviyeli düşünmeyi mümkün kılan, hassas anlamı sıkıştıran bir araçtır
• Tipler ve şemalar yalnızca gevşek biçimde başvurulan şeyler olarak kalırsa sistem tasarımı bulanıklaşır; tip modelini anlamazsanız as any gibi kaçış yolları artar
• İsimleri hatırlama ve önceki çalışmaları anlama eksikliği, ajanların yinelenen uygulamalar üretmesini kolaylaştırır ve çıktı ile testleri gözden geçirmeyi zorlaştırır

---

Kodu neden bizzat yazmalısınız

• Zed Shaw’un “Learn X the hard way” kursları, örnekleri kopyala-yapıştır yapmak yerine doğrudan yazmanızı öneriyordu; son dönemde ise alıştırmayı bitirdikten sonra silip ezberden yeniden yapmayı daha güçlü biçimde tavsiye ediyor
• İçeriği etkin biçimde üretmenin, aynı içeriği pasif biçimde tüketmeye göre anlamayı geliştirmesi bilişsel psikolojide generation effect olarak adlandırılır
• Richard Feynman’ın “Yapamadığım şeyi anlamam” sözü gibi, hafızaya dayanarak kodu yeniden kurma çalışması anlama ile hafızayı aynı anda sınar
• Ajan destekli kodlama çağında bu, geliştirme araçlarını hiç kullanmamak gerektiği anlamına gelmez; ancak zaman zaman araçların rahatlığı olmadan kodu karakter karakter yazabilme becerisini geliştirmek gerekir
• Bu tür çalışma, sözdizimi, tipler ve isimler gibi programlamanın ayrıntılarını zihinde tutup “freecoding” yapabilmeye odaklanır

Freecoding ve zihindeki ayrıntı bilgisi

• Freecoding, hafızaya dayanarak kodu doğrudan yazabilme becerisidir; bunun için sözdizimi, tipler ve isimler gibi temel unsurların zihinde tutulması gerekir

• Sözdizimi ve yapı

  • Anahtar kelimelere, noktalama işaretlerine ve dil öğelerine aşina olmak gerekir
  • Bu, yalnızca dilbilgisini ezberlemek değil; kodun biçimini doğru biçimde zihinde canlandırabilme yeteneğiyle ilgilidir

• Tipler ve şemalar

  • Tip sistemi ve veri modeliyle tanışık ve rahat olmak gerekir
  • Projedeki tabloları, sütunları, ilişkileri ve tip yapısını her seferinde gidip kontrol etme düzeyinde kalırsanız sistem düzeyinde tasarım yapmak zorlaşır

• İsimler

  • Fonksiyon, metot, sınıf, import, dosya ve paket adlarını doğru biçimde hatırlayabilmelisiniz
  • Proje ve bağımlılıklar değiştikçe bu bilgiyi de güncel tutmak gerekir
  • Zihninizde canlandırdığınız kodu belli bir hassasiyet düzeyinde yazamıyorsanız, gerçekte onu açıkça anlıyor olmaktan çok anladığınızı sanıyor olabilirsiniz
  • İngilizce, kod kadar hassas bir dil değildir; yeterince ayrıntılı bir spesifikasyonun sonunda koda yaklaşacağı fikri, ayrı bir yazı olan A sufficiently detailed spec is code ile de bağlantılıdır

Sözdizimi yüksek seviyeli düşünmeyi mümkün kılar

• IDE veya kodlama ajanları sözdizimini düzeltebilse de, sözdizimini bizzat ele alma becerisi hâlâ önemlidir
• Parantezleri eşleştirmekte zorlanıyorsanız, başka birinin mantıksal öncülleri ile sonuçlarını akıcı biçimde bağlayabilme yeteneğiniz de sorgulanabilir
• Ayrıntıları önemsemeyen tutum, kelimelerin anlamını netleştirmek yerine havaya göre iletişim kuran işlevsel okuryazarsızlık ile bağlantılı olabilir
• LLM prompt örnekleri ilk bakışta makul görünür, ama dikkatlice okununca aynı anda birbirine zıt talimatlar içerebilir
  • “Yukarıda listelenen skill’lere dahil olmayan dış araçlar veya alternatifler önermeyin”
  • “Görev, mevcut skill’leri aşan yetenekler gerektiriyorsa bunu söyleyin”
• Küçük dilbilgisi, yazım ve yapı ayrıntılarını doğru ele alma becerisi ile büyük resmi doğru anlama becerisi birbirinden ayrı değildir
• Sözdizimi, yüksek seviyeli düşünmeyi engelleyen bir ayrıntı değil; daha yüksek seviyeli düşünceyi sıkıştıran ve mümkün kılan zihinsel bir araçtır
• Tip gösterimi, doğal dildeki açıklamadan daha hassas ve daha kısa olabilir

  x bir nesne dizisidir ve her nesnede string tutan zorunlu bir domain özelliği ile number tutan isteğe bağlı bir port özelliği vardır
  

  x : { domain: string, port?: number }[]
  

Tipler ve şemalar sistem tasarımının temel ipuçlarıdır

• Fred Brooks, The Mythical Man-Month kitabında tabloları gösterirseniz çoğu zaman akış şeması olmadan da yapının netleştiğini söyler
• Veritabanı kullanıyorsanız, projenin tablolarını, sütun adlarını ve ilişkilerini en ince ayrıntısına kadar biliyor olmalısınız
• Bu bilgilere ihtiyaç oldukça gevşek biçimde bakmak yerine, önceden kavrayıp zihinde tutmak etkili sistem düzeyinde tasarım için gereklidir
• Bu çabayı göstermezseniz, düşünce ne kadar dağınıksa veritabanı şeması da o kadar tekrar eden, benzer verilerle dolu ve denormalize bir yapıya dönüşebilir
• Rust veya Haskell gibi güçlü tipli dillerde edinilen deneyim, tipler hakkında güçlü bir zihinsel modelin faydasını iyi gösterir
• Doğru bir “zihinsel type checker” veya “zihinsel borrow checker” geliştirme çalışması, zayıf tipli diller kullanırken de işe yarar
• Bu soyut akıl yürütme kaslarını kullanmazsanız, geçersiz durumları ifade edilemez hâle getirmek gibi veri modellemenin temel ilkelerini de kolayca kaçırırsınız
• Tiplerin nasıl kenetlendiğini anlamazsanız, TypeScript koduna her yere as any serpiştirmeye başlarsınız
• Normal akışta tipler üzerine düşünmenin verdiği rahatsızlığa katlanamıyorsanız, tip hatalarını ayıklamanın anormal akışı daha da zor gelir
• Bunun anlamı Haskell geliştiricilerinin veya Rustacean’ların her zaman daha iyi kod yazdığı değildir; ama diğer koşullar eşitse, tiplerde akıcı olmak avantaj sağlar

İsimleri hatırlamalısınız ki yeniden kullanabilesiniz

• Projede veya bağımlılıklarda sık kullanılan fonksiyon, metot, sınıf, import, paket ve dosya adları kolayca akla gelmelidir
• Bu, zaten yapılmış olan şeye, yani önceki çalışmalara (prior art) aşina olma ilkesinin daha özel bir biçimidir
• Birçok kişinin kodlama ajanlarına yaslanmasının nedeni, istedikleri işlevi zaten yerine getiren yeniden kullanılabilir önceki çalışmaları bilmemeleridir; bunun sonucunda ajanlara tekerleği yeniden icat ettirirler
• SaaS boilerplate projects varlığını bilmiyorsanız, ajanın her şeyi sıfırdan scaffold etmesi gerektiğini düşünmek kolaydır
• Bu amaç için yapılmış, doğrulanmış açık kaynak projeleri klonlamak; aynı işi ajana yaptırmaktan daha hızlı, daha ucuz ve daha güvenilir olabilir
• Biri LLM’lerin birkaç yıl içinde tam bir tarayıcı yapabileceğini öngördüğünde, Chromium’u fork etmenin bunu aslında bugün mümkün kıldığı ve düzeltme ile bakımın da daha kolay olduğu karşı argümanı yapılabilir
• Aynı proje veya şirket içindeki kodun yeniden kullanımında da isimleri hatırlamak önemlidir
• Neyi aramanız gerektiğini bilmiyorsanız, ekip arkadaşlarınızın yaptığı işin üstüne inşa edemezsiniz

Ajan çıktısını gözden geçirmek insan anlayışı gerektirir

• Ajanlar isim keşfi ve kod üretiminde yardımcı olabilir, ancak çıktıyı anlamlı biçimde inceleyebilmek yeni problem hâline gelir
• Mevcut işlevleri bilmiyorsanız, ajanın bir özelliği yinelenen biçimde mi uyguladığını anlamak zordur
• Kodları ajandan daha kötü anladığınız bir durumda, ajanın çıktısının kalitesini de sağlıklı biçimde değerlendirmek zordur
• Ajanlardan test üretmesini isteyebilirsiniz; ama üretilen testleri dikkatle incelemezseniz, testlerin kendisi anlamsız koda dönüşebilir
• Gerçek bir örnekte, testler uygulama kodunu çağırmadan yalnızca diziler ve string’ler üzerinde doğrudan some veya includes kullanarak beklenen sonucu doğruluyordu

  describe("abort detection logic", () => {
    it("detects aborted stopReason in messages", () => {
      const messages = [
        { role: "assistant", stopReason: "aborted", content: [] },
      ];
      const isAborted = messages.some((m: any) => m.stopReason === "aborted");
      expect(isAborted).toBe(true);
    });
  
    it("detects abort in error string", () => {
      const error = "The operation was aborted";
      const isAborted = error.includes("abort");
      expect(isAborted).toBe(true);
    });
  
    it("does not false-positive on normal errors", () => {
      const error = "Network timeout";
      const isAborted = error.includes("abort");
      expect(isAborted).toBe(false);
    });
  
    it("does not false-positive on normal stop reasons", () => {
      const messages = [
        { role: "assistant", stopReason: "stop", content: [] },
      ];
      const isAborted = messages.some((m: any) => m.stopReason === "aborted");
      expect(isAborted).toBe(false);
    });
  });
  

• Yazılım geliştirmede gündelik sürtünme çoktur; isimleri hatırlama gibi küçük bir sürtünmeyi aşmamayı seçerseniz, testleri gözden geçirme gibi daha büyük sürtünmeleri de aşmazsınız
• Kodlama ajanları, kullanıcının talimatlarını ana bağlam olarak aldığından, entelektüel olarak tembel bir kullanıcı ajanı da benzer biçimde tembel bir yöne sürükleyebilir

Azim ve ustalık birbirinden ayrı değildir

• Eustress, faydalı strestir; kendinizi yeni ve zor şeyler yapmaya zorladığınızda küçük rahatsızlıklara karşı dayanıklılık kazanır, daha büyük rahatsızlıkları da aşabilirsiniz
• Sürekli rahatsızlıktan kaçarsanız, çaresizlik ve hayal kırıklığının büyüdüğü bir kısır döngüye girersiniz
• Bir alanda hassasiyet, hafıza ve yapısal düşünme geliştirirseniz, diğer alanlardaki beceriler de birlikte gelişir
• LLM’lerin eğitim verisinden genelleme yapması gibi, insanlar da bir alanda geliştirdiği alışkanlık ve becerileri başka alanlara geneller
• Yazılım geliştirme doğası gereği, düzenli olarak konfor alanının dışına çıkmayı içerir; bu, ilgili yazı Software engineers are not (and should not be) technicians ile de aynı bağlamdadır

[GN⁺]

Lobste.rs görüşleri

• Buna tamamen katılıyorum. Alıştırma problemlerini bitirdikten sonra az önce yaptığını silip yalnızca hafızandan tekrar yapmak gerçekten çok önemli
  Takıldığında ipuçlarına bakabilirsin ama az önceki süreci mümkün olduğunca hafızandan yeniden kurma alışkanlığı kadar önemli çok az şey var

• Commit mesajlarını ve dokümantasyonu bizzat yazmak daha iyi
  Programcılar bu tür yazıları sevmediği için kolayca “bunu LLM yazar zaten” diyebiliyor ama kendin yazınca kullanıcı deneyimiyle uygulama kararlarını aynı yerde yüzleştiriyorsun. “X yapmak için -Y veriliyor… bir dakika, bu gerçekten en iyisi mi?” “Bu, X'i Y ile düzeltiyor… ama Z ile de olmaz mı?” gibi sorgulamalar ortaya çıkıyor

  • Buna bazen tutorial odaklı geliştirme deniyor. Sonradan kullanıcı deneyimini düşünmek yerine, istenen kullanıcı deneyiminden başlayıp tutorial'ı yazarak geriye doğru çalışma yöntemi

• “Parantez dengesini kurmakta zorlanıyorsan, başkalarının mantıksal öncülleri ile sonuçlarını ne kadar akıcı bağlayabildiğinden şüphe ederim” kısmına güldüm ama bir an da irkildim
  Kendimi savunmak gerekirse bazen fonksiyonlar fazla devasa olabiliyor

• Anlamadığın vibe coding çöpünü düzeltmek de aslında öğrenmek için iyi bir yöntem. Çok yazı yazmış oluyorsun ve boşlukta değil, gerçek bir bağlam içinde çalışıyorsun

  • Kısa süre önce bir ölçüde çalışan ama pek iyi olmayan bir şeyi vibe coding ile yaptım ve kod gerçekten berbattı
    Onu elimle yeniden yazarak son 8 ayda paslanan programlama hissimi geri kazanmak için bir fırsata çevirdim. Yeniden yazımın sonucu hoşuma gitti ve gerçekten daha iyi çalışıyor. LLM hâlâ açıklama yapmakta ya da tıkandığım yerleri açmakta faydalı ama tüm kod tabanını benim bildiğim hissi çok daha iyi
  • Duruma göre değişir. Domuza yeniden ruj sürsen de sonuçta domuz olarak kalabiliyor

• “Listelenen yeteneklerde olmayan dış araçları ya da alternatifleri asla önermeyin. Görev için kullanılabilir yetenekleri aşan bir işlev gerekiyorsa bunu söyleyin” promptunun neden birbiriyle çelişen talimatlar olduğunu pek anlamadım
  “Verilen yeteneklerle bunu yapamam” demek her iki talimatla da tutarlı. Son cümle “hangi yeteneğin gerektiğini söyle” olsaydı çelişirdi ama mevcut haliyle bakınca bir tutarsızlık görmüyorum

  • Doğru yorum gibi geliyor ama promptu yazan kişi muhtemelen LLM'nin sadece “üzgünüm, başka yetenekler gerekiyor ama bunu söyleyemem” demesini değil, neyin gerektiğini söylemesini amaçlamış olabilir. Tabii gerçekten cümleyi tam yazıldığı gibi kastetmiş de olabilir
  • “Verilen yeteneklerle bunu yapamam” yanıtının ikinci talimatla tutarlı olmadığını düşünüyorum
    İkinci cümle, modelin gerekli dış araç ya da alternatiflerin varlığını olumsuz yoldan ima etmesini değil, yapıcı biçimde varlıklarını doğrulamasını söylüyor gibi okunuyor

• “İşlevsel olarak açık ifade edemeyen insanlar neredeyse istisnasız biçimde imla ya da dilbilgisi açısından doğru cümleler kurmakta da zorlanır” sözü, disleksi yaşayan ya da sadece farklı düşünen insanlar hakkında epey sert bir önyargı gibi geliyor
  Elbette imla ya da dilbilgisi kullanamamanın doğrudan işlevsel açıklık eksikliği anlamına geldiğini tersinden iddia etmiş değildin ama her iki yönden de çok kapsayıcı bir ifade sayılmaz
  Daha yapıcı bakarsak, node editörlerini düşünebiliriz. Node tabanlı sistemlerin bugünkü uygulamalarında çok sorun var ama iyi tasarlanırlarsa program yazma biçimini sınırlayarak bazı sözdizimi hatalarını en baştan engelleyebilirler. Örneğin bir node string alıyorsa ona sayı veremezsin. Bu, kısıtları build zamanında ya da çalışma zamanında zorladıkları için değil, sayıyı orada en baştan “ifade edemez” hale getirdikleri için olur. Yanlış döngü aralıkları, argüman sayısı hataları ya da parantez dengesizlikleri de yapısal olarak yanlış olamayacak şekilde tasarlanabilir
  Bazı kısıtları yapısal olarak zorlayan araçlarla yazılım geliştiriyor olmak, o kısıtları anlamadığın anlamına gelmez. Sadece o tür hatalarda yanlış bir şey girme ihtimalini azaltır. Bir aracın fonksiyonların süslü parantez sayısını ya da mantıksal blokların girintisini senin yerine takip etmemesi yüzünden rahatsız olman da, neden o sözdizimine dikkat edilmesi gerektiğini anlamadığın anlamına gelmez
  Node sistemlerini örnek vermemin nedeni, LLM'nin “at ve unut” ya da beyni kapatan vibe coding unsurunu çıkarıp yalnızca sözdizimi sorununu izole biçimde göstermesi. LLM'yi çıkarınca sözdizimine odaklanan iddia oldukça zayıflıyor
  Yazının geri kalanına katılıyorum ama sözdizimi becerisini birinin kodu anlama ya da iyi kod yazma yeteneğinin temel göstergesi gibi görmek çok yanlış bir yönelim gibi geliyor bana

  • İmla ya da dilbilgisi açısından doğru cümle kuramayan birinin işlevsel olarak açık olamayacağını söylemek istemiyorum
    Bunun iyi niyetli bir geri bildirim olduğunu da anlıyorum ve savunmacı görünmek istemem. Bunun böyle kapsayıcı olmayan bir iddia gibi duyulmaması için ifade etmeye çalıştığımı düşünüyordum ama aynı fikri daha iyi anlatacak başka bir ifade ya da kurgu varsa buna açığım
    Yine de o noktayı tamamen çıkarmak istemiyorum. Vermek istediğim ana fikir, bir kişi zihinsel rahatsızlıktan deneyimsel kaçınma yoluyla uzaklaşmaya başladığında genellikle ilk bozulan şeyin imla ve dilbilgisi olması. Disleksisi olan insanların bu süreçte zarar görmemesi için bu iddiayı ayarlamanın bir yolu vardır diye düşünüyorum