Oyuncak yazılım yapmanın keyfi

• Oyuncak yazılım geliştirmek, yazılım geliştirmenin özündeki keyfi ve yaratıcılığı yeniden kazanmanın bir yoludur
• Yapay zeka ve endüstrileşme nedeniyle yazılım geliştirmenin saf neşesinin kaybolduğu bir çağda, kişisel projeler olarak basit oyuncak programlar yapmak, iş hayatında da faydalı olacak bilgi ve derin anlayış kazanmak için bir fırsat sunar
• Oyuncak yazılım, 80:20 kuralına göre en az kodla en yüksek işlevi gerçekleştirmeyi hedefler; burada kilit nokta aşırı tasarımdan veya kusursuzluk takıntısından kaçınmaktır
• LLM gibi yapay zeka araçlarına bel bağlamadan, bizzat uğraşarak bir şeyler yapma deneyiminin kendisi öğrenmenin ve gelişmenin özündeki sevinçtir

---

Neden daha fazla oyuncak program yapmalıyız

• Richard Feynman’ın şu sözü: “Yapamadığım şeyi anlayamam” → bir şeyi doğrudan inşa etme deneyimi, derin bir kavrayışa götürür
• Eskiden verilen “tekerleği yeniden icat etme” öğüdünün aksine, tekerleği bizzat yapma deneyimi, okuma ya da teorik öğrenmeden daha fazlasını öğretir
• Son dönemde yapay zeka ve yazılımın endüstrileşmesi, geliştirmenin keyfini ve zanaatkarlığını tehdit ediyor
• Oyuncak yazılım üretmek, insanı bilgisayarlara yeniden bağlayan o basit keyfi geri kazandırır

Oyuncak programların ilkesi: Keep it simple

• Oyuncak yazılım 80:20 ilkesini izler: çabanın %20’siyle işlevlerin %80’ine ulaşmak
• Amaç, nihai bir ürün çıkarmak değil; sadeliği koruyup temel prensipleri doğrudan hayata geçirmektir
• Aşırı yapı tasarımına (over-engineering) karşı dikkatli olunmalı; yalnızca gerçekten gerekli kod yazılmalıdır
• Tüm kod yollarını henüz uygulanmamış durumda bırakarak, ihtiyaç doğdukça uygulamayı genişleten bir yaklaşım önerilir
• Küçük görünen sistemlerin bile pratikte sanıldığından daha kolay yapılabildiği deneyimlenir

Oyuncak yazılımın ek faydaları

• Oyuncak projelerden edinilen bilgi, gerçek işlerde sorun izleme, bug çözme ve hata önleme konularında beklenenden çok daha fazla yardımcı olabilir
• Doğrudan uğraşarak kısıtları deneyimlemek, yazılımın doğasına dair içgörü kazandırır ve yenilikçi çözümler bulmayı da sağlayabilir

Örnek: çeşitli oyuncak yazılım projeleri listesi

Son 15 yılda bizzat hayata geçirilen oyuncak proje türleri, zorluk seviyeleri ve tahmini süreleriyle birlikte derlenmiş. Her projede kısa bir açıklama ve ek referanslar yer alıyor

• Regex motoru (zorluk 4/10, 5 gün) : POSIX tarzı düzenli ifadeleri ayrıştırma ve eşleşen dizeleri tanımlama; regex’in iç işleyişini derinlemesine anlamayı sağlar
• x86 OS çekirdeği (zorluk 7/10, 2 ay) : CLI, basit sürücüler ve bellek yöneticisi içerir; bellek içi dosya sistemi, ELF çalıştırılabilir dosyalar, GUI, süreç yalıtımı gibi ek meydan okumalar da eklenebilir
• GameBoy/NES emülatörü (zorluk 6/10, 3 hafta) : basit komut setleri ve donanım anlayışı, PPU ve PSG ile sıra dışı cartridge formatlarını uygulama
• GameBoy Advance oyunu (zorluk 3/10, 2 hafta) : sprite tabanlı basit oyun; GBA geliştirme topluluğu canlıdır ve sistem yapısı tek başına anlaşılabilecek kadar erişilebilirdir
• 2D fizik motoru (zorluk 5/10, 1 hafta) : temel Newton mekaniği ve basit çarpışma işleme; karmaşık şekiller, eylemsizlik, çözüm algoritmaları, soft body/bileşik etkileşimler gibi yönlere genişletilebilir
• Dinamik yorumlayıcı (zorluk 4/10, 1~2 hafta) : tree-walking interpreter; kendi dilini yapmak teknik ve yaratıcı bir keyif verir
• C benzeri derleyici (zorluk 8/10, 3 ay) : basit tip sistemi ve hedef ortam; çeşitli optimizasyonlar ve farklı backend’leri destekleyen mimari tasarımı
• Metin editörü (zorluk 5/10, 2~4 hafta) : basit dosya girdi/çıktısından başlanabilir, UI toolkit’leri (QT/GTK vb.) kullanılabilir; konsol tabanlı yaklaşım tercih edilir, unicode, syntax highlighting, multi-buffer, LSP gibi özellikler eklenebilir
• Async runtime (zorluk 6/10, 1 hafta) : Rust özelinde impl Future görev işleme ve eşzamanlılık uygulaması; I/O waking ekleme
• Hash Map (zorluk 4/10, 3~5 gün) : iç çalışma prensipleri, closed ve open addressing, Robin Hood kuralı öğrenimi; performansı ve ne zaman uygun olduğunu anlama
• Rasteriser / Texture Mapper (zorluk 6/10, 2 hafta) : 3D grafik pipeline yapısını öğrenme; vektör matematiği, Z-buffer, texture mapping ve shading algoritmalarına kadar derinleşme imkanı
• Signed Distance Field rendering (zorluk 5/10, 3 gün) : matematiksel uzay gösterimi, basit görselleştirme, shader ve vektör matematiğine dair anlayış
• Voxel motoru (zorluk 5/10, 2 hafta) : 3D grafik veya oyun geliştirme deneyimi olanlar için anlaşılması kolay; texture, prosedürel üretim ve ağ gibi alanlara genişletilebilir
• Threaded Virtual Machine (zorluk 6/10, 1 hafta) : hızlı bir yorumlayıcı; mimariye özel kod üretmeden optimize edilmiş interpreter inşası, derleyiciye yakın performans deneyimi
• GUI toolkit (zorluk 6/10, 2~3 hafta) : temel UI araçları geliştirme deneyiminden sonra layout engine, text shaping, erişilebilirlik gibi ileri özellikleri doğrudan uygulama imkanı
• Yörünge mekaniği simülatörü (zorluk 6/10, 1 hafta) : Newton yerçekimi modelini basitçe uygulama; çoklu gök cisminin etkileşimi, integrasyon algoritmaları ve görselleştirmeyle genişletme, NASA verileri kullanma imkanı
• Bitwise Challenge (zorluk 3/10, 2~3 gün) : yalnızca 64 bitlik durumla yeniden üretilebilen bir oyun; yaratıcı durum yönetimi pratiği, ayrıntılı kurallar GitHub’da incelenebilir
• ECS framework (zorluk 4/10, 1~2 hafta) : Entity-Component-System yapısını doğrudan uygulama; dilin tip sistemiyle bütünleştirme, yüksek performans ve özel kısıtlara uyarlama
• CHIP-8 emülatörü (zorluk 3/10, 3~6 gün) : 1970’lerden kalma basit bir sanal makine; hızlı uygulanır, çeşitli fan oyunları gözlemlenip çalıştırılabilir
• Satranç motoru (zorluk 5/10, 2~5 gün) : kurallardan başlayıp adım adım geliştirme; kendi yaptığın motora yenilme deneyimi, geliştirici olarak büyümenin bir sahnesidir
• POSIX Shell (zorluk 4/10, 3~5 gün) : POSIX tabanlı shell’in prensipleri ve sınırları; gerçek shell dili uyumluluğunu uygulayarak derin anlayış ve sayısız numarayla tanışma

LLM gibi araçların kullanımına dair öneriler

• LLM gibi gelişmiş araçlar faydalıdır; ancak gerçek öğrenme, kişi kendi başına keşfe çıktığında daha derin hale gelir
• Mevcut çözümlere bakmak yerine, bilinmeyen alanları keşfedip kendi cevabını bulma sürecinde daha büyük bir tatmin elde edilebilir
• Oyuncak projeleri LLM olmadan yürütmek başta zor ve alışılmadık gelebilir; ancak zamanla kendine özgü bir teknik keyif ve yüksek başarı hissi doğurur

• Arabayla yolculuk yapınca bir koşucu olarak “runner’s high” hissedilmez → kestirme yerine doğrudan deneyimden daha derin bir keyif alınabilir

[tolluset]

Bunu LLM olmadan deneme fikrine katılıyorum. Hızlı geliştirme gerekmiyorsa, her şeyi tek tek anlayarak doğrudan yapmak daha eğlenceli ve daha tatmin edici gibi görünüyor.

[nezz1204]

Demek ki oyuncak projelerden bahsediyormuş. Sadece başlığa bakınca, oyuncakların içine giren yazılımı yapmaktan söz ediliyor sanmıştım. :)

[GN⁺]

Hacker News görüşleri

• LLM’yi arama motoru gibi kullanan başka insanlar da var mı merak ediyorum. Eskiden Google’da “pros cons mysql mongodb” gibi aratır, resmi dokümanları, forumları, blogları, Stack Overflow’u okuyarak epey zaman harcardım. Ama okurken öğrenmeye ayrılan zamanın kendisi de her zaman değerliydi. Şimdi ise LLM’ye daha spesifik şekilde, örneğin “fotoğraf depolarken mysql vs mongodb artıları eksileri, referans linkleriyle ver” gibi prompt’lar giriyorum. Böylece ana noktaları hızlıca kavrayabiliyorum ve linkler de birlikte geldiği için halüsinasyona bel bağlamak zorunda kalmıyorum. Bazen “postgres ile fotoğraf metadata’sı için bir data schema tasarla, X’i başka bir tabloya ayırmak istiyorum” gibi daha somut isteklerim de oluyor ama bunu yalnızca nasıl bir çıktı istediğimi tam olarak bildiğimde kullanıyorum. Daha çok yazı yazma süresinden tasarruf etmek ya da type’ların tam adını (int mi integer mı gibi) kısa süreliğine unuttuğumda işe yarıyor

  • LLM’yi teknik soru-cevap motoru gibi kullanınca, ilk bakışta makul görünen ama kritik yerlerde yanlış bilgiler verme ihtimali çok yüksek. Cevaba körü körüne güvenip peşinden giderseniz gereksiz yere saatlerinizi, hatta günlerinizi kaybedebilirsiniz. Referans linkleri isteseniz bile bazen gerçekten ilgili bilgi geliyor, bazen de alakasız şeyler; oran neredeyse yarı yarıya. Yine de kesin olarak çok iyi yaptığı bir şey var: “tip-of-my-tongue” tarzı tersine arama. Yani bir kavramı tarif ettiğinizde ona uygun arama terimlerini önermesi konusunda tutarlı ve tatmin edici
  • Yakında şirketler, ürünlerinin daha iyi karşılaştırmalar içinde görünmesi için LLM’lere yüklü para ödemeye başlayacak gibi geliyor. LLM, sonucu “organik” görünür tutarken yalnızca çerçeveyi ve vurguyu değiştirerek bunu yapabilir. Çünkü sadece gerçek ve dayanaklı bilgileri gösterip “bağlamın vurgusunu” değiştirmesi yeterli
  • Ben de aynen LLM’yi arama için kullanıyorum. Hissiyat olarak 2010’ların başındaki, Google’lamanın inanılmaz güçlü olduğu döneme dönmüşüz gibi. Her şeyi bulabildiğiniz zamanlar. Tabii o dönem uzun sürmedi ve bugün Google’da arama yapmak başlı başına acı ve hayal kırıklığı. Google ve pazarlamacıların yarattığı değişimlere dair çok şikâyetim var ama mevcut LLM’ler çevrimiçi bilgiyi anında yüzeye çıkarmada gerçekten çok verimli hissettiriyor. Referans linkleri de çoğunlukla epey doğru. Sonuçta eskisiyle aynı değişim güçleri burada da devreye girecek ve bu da yeniden bozulmadan önce kısa süreli bir fırsat gibi duruyor
  • Ben de LLM’yi arama motoru gibi kullananlardan biriyim. Henüz AI IDE kullanmıyorum. Geçenlerde canlı bir teknik mülakatta, seçtiğim LLM ile Google’lar gibi sorgular sorup cevap vermeye çalıştım; mülakatçı da AI’ı bu şekilde kullanan ilk adayı gördüğünü söyledi. Çoğu geliştiricinin hâlâ AI IDE’lerden önce onu arama için kullandığını sanıyordum. Bizim gibi örnekler gerçekten nadir mi?
  • Hatta geliştirme sırasında da LLM’yi arama motoru gibi kullanıyorum. Mesela “/src/foo altında klonladığım repoyu analiz et ve barFeature’ın nasıl implement edildiğini açıkla. Şimdi /src/baz projesine bak ve foo yaklaşımının baz’da neden uygulanmasının zor olduğunu anlat” gibi. Ondan yeni bir şey üretmesini istemiyorum; var olan projeleri benim fikirlerime tercüme etmesi için kullanıyorum. Gerçekten yeni ve zorlu geliştirme işlerinde kodu kendim yazmam daha keyifli

• Kariyerimde yaptığım en iyi şeylerden biri, işler arasında verdiğim 6 aylık arada yürüttüğüm kişisel projelerdi. Başlangıçta yapmak istediğim çok proje vardı ama kısıt olmayınca kapsam sürekli büyüyor ve sonuçta hiçbirini bitiremiyordum. Bu yüzden her projeye yalnızca 1 hafta ayırmaya karar verdim. Bir haftada ne yapılabiliyorsa onu yaptım. Sıfırdan başlayıp yeni bir dilde, framework’te ya da yabancı olduğum bir alanda 1 haftada işe yarar bir şey çıkarmak, özgüvenimi inanılmaz artırdı. Programlamayı neden sevdiğimi de yeniden hatırlattı. Eğer işler arasında birkaç aylık bir boşluk yakalarsanız, Silikon Vadisi mülakatlarına hazırlanmak yerine sadece toy projeler yapmak, aslında ne kadar çok şey bildiğinizi size şaşırtabilir

  • AI üretim araçları varsa, bu tür kişisel toy projelerde inanılmaz yardımcı oluyorlar. Ben daha çok backend tarafındayım ama frontend de yapabiliyorum. Sorun şu ki CSS çok zaman alıyor; geçmişte kişisel projeleri bu yüzden çoğu kez bitiremedim. Şimdi AI’a “bunu güzel göster” dediğimde işi yaklaşık %85 tamamlanmış noktaya getiriyor, ben de kalan bug fix’leri ve düzeltmeleri yapıp hızlıca bitirebiliyorum. Eskiden çamur gibi hissettiren geliştirme artık çok daha akıcı olduğu için kişisel projeleri daha sık yapar oldum
  • Son dönemde kullandığım kütüphanelerden memnuniyetsizlik birikince onları doğrudan düzeltmeye kaydım. Eksik onboarding dokümanları, bozuk SDLC, ciddi performans sorunları gördüğümde bütün günü düzeltmelerle geçiriyorum. Başka insanların beklediği ortak projelerden farklı olarak, kişisel toy projelerde side quest’lere sapmak çok kolay. Ekip işinde birilerinin bekliyor olması baskı yaratıyor
  • 6 ay ara verip sonra nasıl tekrar iş bulabildiğini merak ediyorum. Ben de 6 ay ara vermek istiyorum ama ya sonra iş bulamazsam ve daha uzun süre ara vermek zorunda kalırsam diye endişeleniyorum
  • Küçükken classic ASP + SQL ile sunucu kurar, HTML/CSS/JS’in hepsiyle uğraşır ve kolayca deploy ederdim. O zamanlar FTP ile dosyaları yüklemek yeterliydi. Şimdi daha modern yöntemleri araştırmak istiyorum ama kişisel projelerde her seferinde deploy ve geliştirme süreci yaşam döngüsü arasında kayboluyorum. Toy projelerde hosting ve deploy yaklaşımını nasıl seçtiğinizi merak ediyorum
  • Ben de AI’ın boilerplate kısımları ve test otomasyon kodlarını üretmesi sayesinde bu tür kişisel projelerde gözle görülür biçimde hızlandım

• Toy yazılım geliştirmek, bisiklet, araba ya da tekne bakımı yapmak gibi. Keyifli. Ama işe gidip gelmek için kullandığınız bisikleti tamir etmek stresli. Toy yazılım yapmak keyifli ama onu bir gün gerçekten kullanmak istediğinizde bütün bug’ları fark etmeye başlıyor ve onları düzeltecek vaktiniz olmuyor; ikilem burada başlıyor

  • Sadece kendim kullanacağım yazılımlar geliştirmeyi daha çok seviyorum. Arabada da aynı şekilde, daha ucuza daha uzun süre kullanabilmek tatmin veriyor
  • Bir zamanlar kendi e-posta sunucumu işletiyordum ama artık yapmıyorum. Bunu kendim yapmak istediğim için değil, böyle işleri artık uzmanlara bırakmak istiyorum
  • Yakın zamanda kendi invoice uygulamamı yaptım. İhtiyacım olan özellikleri tek tek eklemek çok keyifliydi. Hatta mevcut ücretli servislerde aylık abonelikle sunulan özellikleri bile dahil ettim ama gerçekten fatura göndermem gereken an geldiğinde, benim uygulamamda çözülmesi gereken çok fazla sorun olduğunu fark ettim: stil, adres girişi vs. Sonunda bisiklet sürmenin keyfiyle işe gidip gelme bisikletinin pratikliği arasında bir denge bulmak gerektiğini hissettim. Zamanla keyif ve pratikliğin birbirine yaklaşabileceğini de fark ettim
  • Ben de “tamamlanmış yazılım” hâline getirmek istediğim çok fazla şey düşünüyorum ama ne zamanım ne de enerjim var. Sıkıcı ve tekrarlı işler de çok fazla. Yine de “AI çıktısını” yönetip ayıklamak da başlı başına iş. Hâlâ erken deney aşamasındayım; birkaç ay sonra da aynı fikirde olur muyum bilmiyorum
  • Bu yüzden kişisel bir web sitesi yapmak gerçekten çok keyifli. Onu gerçekten kendi oyun alanınız gibi kullanabiliyorsunuz

• LLM hakkında bu kadar olumsuz görüş olmasına şaşırdım. LLM size bilgiyi kaşıkla veriyor. Yeni bir projeye başlarken zaten her şeyi bilerek başlamazsınız. Elinizden geleni yapıp batırmanız, sonra çalışmanız, neden olmadığını anlamanız ve yeni bir yaklaşımla düzeltmeniz asıl öğrenmedir. Her şeyi bildiğinizi varsayıp sadece tutorial izlerseniz, yöntemlerin sınırlarını ya da gerçek artı-eksi yönlerini yaşayarak öğrenemezsiniz. Örneğin regex ile parser yazmaya kalkıp recursive ifadeleri işleyemediğini kendiniz keşfetmeniz; daha karmaşık yapıları ve zaman karmaşıklığı sorunlarını elinizle hissederek öğrenmeniz gerekir. Bizzat optimize eden bir compiler implement edip her türlü optimizasyon numarasında tökezleyince, gerçek compiler’ların neden öyle tasarlandığını anlarsınız. Kendi layout engine’inizi yazınca width gibi bir kavramı bile doğru ele almanın ne kadar zor olduğunu deneyimlersiniz. Deneme-yanılma yoluyla öğrenmekten daha iyi çok az şey var. LLM hataları önlüyor diye, önemli öğrenme fırsatlarını da kaçırmayalım

  • Birçok insan LLM kullanmazsan geri kalırsın diyor ama bana kalırsa uzun vadede asıl büyük avantaj, LLM’yi daha az kullanmak olabilir

• Ben de bilgisayar grafikleri öğrenmek için yıllarca hafta sonlarımı ve gecelerimi sayısız tuhaf projeye gömdüm. Tek kuruş kazanmadım ama sonunda hayalimdeki işe girdim. Öne çıkan çalışmalardan bazıları:

  • Tiny ray-tracer
  • 2D rigid-body simulator
  • Character animation system
  • Animation curve visualizer
  • Motion capture playback in the web Bu kod yığınlarının asıl amacı tamamen “bilgi edinmek”ti

• Bu yazının sunduğu “programlamanın keyfi” ruhuna gerçekten ihtiyaç olduğunu düşünüyorum. AI agent coding çağında bu ruh daha da değerli. Ama yazarın toy projeler için verdiği tahmini süreler bana fazla kısa geliyor. Ben ortalama hızda biri değilim belki ama listedeki projelerin çoğunun, günde sadece 2-3 saat çalıştığınızı varsayarsak, birkaç günde bitecek şeyler olduğunu düşünmüyorum. Başlamadan önce yapılacak araştırma bile ciddi zaman alıyor gibi geliyor. Mesela yakın zamanda Pelican blogumu kişisel bir Odin static site generator ile değiştirdim; günde 2-3 saat ayırmama rağmen 2 hafta sürdü. Üstelik bu, listedeki diğer projelere göre daha kolay sayılabilecek bir işti

  • Senin projen artık “toy” projenin ötesine geçmiş. Sen kendin gerçek müşteri olmuşsun ve deploy edildikten sonra da düzgün çalışmasını bekliyorsun. İşte bu beklenti toy ile gerçek aracı ayıran sınır. Bir saat içinde bir word processor da yapabilirsin. Belki yalnızca tek tek tuş girişini işleyen, aşırı basit, kapatma düğmesi bile olmayan bir sürüm olur. Ama bu da bir “toy” word processor olmak için yeterli
  • Eğer “X gün”ü 24*X saat olarak yorumlarsan bu liste daha makul görünmeye başlıyor
  • Toy projelerin güzel yanlarından biri deadline olmaması. Bu yüzden yeterince rahat ve yavaş ilerlemek mümkün. Ben de PEG tabanlı, Turing-complete bir dili COVID döneminden beri hâlâ cilalıyorum
  • Bu süreler, ne kadar 3rd-party kütüphane kullandığınıza, neyi kendiniz çözdüğünüze ve ne kadar gerçekten öz meseleye odaklandığınıza göre çok değişiyor. Yazarın GitHub’ına bakarsanız (https://github.com/ssloy?tab=repositories) ölçeği küçük tutma konusunda çok şey öğrenebilirsiniz. Ayrıca yazarın problem alanına dair zaten derin bir kavrayışı var; o yüzden bu kadar “sıkı” kod yazabiliyor. Konu sizin için yeniyse, bu şekilde implement etmek çok zor

• “LLM’yi bu tür projelerde kullanmayın” tavsiyesine ben de katılıyorum ama bunun fazla uç bir yere çekilmemesi gerektiğini düşünüyorum. AI’dan nasıl yardım alınacağına dair tavsiyelerin, neden bir insandan yardım istemekten bu kadar farklı algılandığı da ilginç. Blogun en altına “iyi programlayan bir arkadaşınız varsa ondan asla yardım istemeyin” yazsanız tuhaf olurdu. Uzman bir arkadaş bağlamı anlar ve sorunu sizin kendi başınıza çözmenize yardımcı olur. AI’a da gerçekten “sorunu benim yerime çözme, uzman bir arkadaş gibi bana rehberlik et” diyen kişi sayısı muhtemelen çok az. Elbette bugün bunu tam yapamayabilir ama 1-2 yıl sonra bu tür rehberlik çok doğal hâle gelebilir. O yüzden “nasıl bir yardım istediğinizi açıkça ifade etme” alışkanlığını edinmek iyi olur. LLM’nin ille de yanlış cevaplar üreteceğine dair katı bir önyargıya sahip olmaya gerek yok

  • AI’ın henüz uzman bir geliştirici olmadığını çok net hissediyorum
  • LLM’yi uzman bir arkadaş gibi kullanmak benim de en sık yaptığım şey. Güvenilir sonuç almak için prompt’u ya da sorunun kendisini önyargısız olacak şekilde yeniden formüle etmek gerekiyor. Son zamanlarda Claude ve ChatGPT’nin benim fikirlerime fazla uyum sağlamaya başladığını hissediyorum
  • (yazar) Aslında ben gerçekten “uzman arkadaşınızdan da yardım istemeyin” demeye daha yakınım. Gerçekten tıkandığınız anlarda konuyla ilgili kısa bir literatür okumak daha iyi olabilir. Birçok şeyi kendi başınıza deneyip sendeleyerek çözme deneyiminin, yaratıcılığı ve problem çözme becerisini geliştirmede vazgeçilmez olduğuna kuvvetle inanıyorum. O kafa karışıklığı dönemi gerekli. Ama tabii herkes buna kendisi karar vermeli
  • Ben de LLM’ye gerçekten “öğretmen” gibi davranarak soru soruyorum. Ondan stajyer gibi cevap vermesini istemiyorum

• Claude tabanlı vibe coding sayesinde uzun zamandır ilk kez gerçekten eğlenceli bir yan proje başlattım. Araçlara ve sürece alıştıktan sonra birkaç hafta içinde aile için takvim/hava durumu dashboard’u, Bluesky okuma uygulaması (okunmuş gönderileri gizleyen), oyunlaştırılmış şirket PM dashboard’u, belirli bir süre sonra Reddit gönderilerini gizleyen Chrome eklentisi, bakımı yapılmayan bir WordPress eklentisinin yerine geçen uygulama gibi farklı uygulamaları çok hızlı üretmeye başladım. Başta Claude’a UI iyileştirmeleri gibi birçok şeyi bırakıyordum ama artık %90 tamamlanmışlık düzeyinden memnun olmayı ve sonsuz iyileştirme yerine yeni uygulama özelliklerine odaklanmayı öğrendim

  • Claude bazen bir bug’ı düzelttikten sonra sonucu hemen göstermiyor; bu da can sıkıcı olabiliyor. Tek bir değişiklik için güncellenmiş çıktıyı 6 kez yeniden istemek zorunda kaldığım oldu. Benzer deneyim yaşayan var mı?

• Bu liste gerçekten etkileyici. Yazara kolay gelen projelerin önemli bir kısmı bana çok daha zor görünürdü. Yine de kendi toy projelerime geri dönme isteği uyandırması açısından kesinlikle motive edici. Ama LLM ile öğrenme konusundaki sonuç biraz daha nüanslı. Nasıl kullandığınıza göre tamamen değişiyor. Mesela “bu problemi benim için implemente et” demek öğrenme açısından en kötü kullanım şekli olabilir; ama “ELF yapısını en üst düzey soyutlamayla, özellikle de ‘neden’e odaklanarak açıkla” demek inanılmaz güçlü bir öğrenme hızlandırıcısı olabilir. Her seferinde araştırmayı kendiniz yapmıyor olmanız bir eksi olabilir ama gerçekten zihinsel olarak meseleyle boğuşuyorsanız, her an Sokratik tarzda soru-cevap alabiliyor olmak muazzam bir öğrenme çarpanı

  • (yazar) İşte benim yazıda kastettiğim “belirli türde öğrenme” tam olarak bu. Örneğin ELF binary yapısını öğrenmek istiyorsanız bunu sadece kendi tahminlerinizle çözemezsiniz. Tarihi ve tasarım kararlarını anlamanız gerekir; dolayısıyla spec, dokümanlar ya da LLM dahil referanslara ihtiyaç vardır. Ama özünde önemli olan “kendi yaparak öğrenme”. Kendi binary formatınızı uydurup sendeleyerek ilerlerken, ELF gibi gerçek formatların neden öyle olduğunu, hangi problemleri çözdüğünü ve tüm tasarım alanını daha iyi kavrarsınız. Böyle keşif temelli öğrenme sırasında LLM yardımı almamayı öneriyorum. “Size sadece bir notebook, bir text editor ve bir compiler verip 10 yıl bıraksak, nereye kadar ilerleyebilirdiniz? Hangi noktada spesifik bilgiye ihtiyaç duyup tıkanırdınız?”

• Burada tanıtılan projeler gerçekten iyi fikirler ama hiçbirinin bana çekici gelmemesi garip. Böyle zamanlarda acaba programlamayı gerçekten hiç sevmiş miydim diye düşünüyorum

  • Ben tam tersiyim sanırım. Listedeki projelerin çoğu bana ilginç geldi; bazılarını denemek istedim, bazılarını da gerçekten yaptım. Hatta ben de yakın zamana kadar aynı soruyu soruyordum ve çocuk doğduktan sonra izne çıktığım dönemde, sırf keyif için “basit” bir kodlama projesine başladım. Tüm bağımlılıkları atıp her şeyi sıfırdan kendim yapmaya karar verince iş düşündüğümden çok daha karmaşık hâle geldi ama bu yüzden, o birkaç saatlik kodlama zamanını dört gözle beklemeye başladım. Bir anda kod yazmak yeniden çok eğlenceli oldu. Belki sen de tükenmişlik yaşıyorsundur