Claude Code ile 6 Haftalık Deneyim

 (blog.puzzmo.com)
37 puan yazan GN⁺ 2025-08-07 | 7 yorum | WhatsApp'ta paylaş
  • Claude Code kullanıma alındıktan sonra, büyük ölçekli kod yazımı ve bakımın biçimi ciddi ölçüde değişti — “yazılım dünyasının fotoğrafçılıkla tanışma dönemi”ne benzetilecek kadar, hızlı uygulama ve özgür ifade mümkün hale geldi
  • Tekrarlayan ve “teknik borç” olarak görülen işler (migration, framework değişimi vb.) tek başına bile hızlıca paralel yürütülebiliyor; asıl işle birlikte yapılsa da neredeyse yük oluşturmuyor
  • “Önce deneyip sonra karar verme” yaklaşımına dayalı deneysel geliştirme düzeni sayesinde test/soyutlama/deney kodları kolayca üretilip silinebiliyor; bu da geliştirme verimliliği ve içgörü sağlıyor
  • Oyun prototipleme, iş birliği ve deneysel dağıtım büyük ölçüde hızlandı — oyun tasarımcıları kod yazmadan fikirden uygulamaya birkaç saat içinde geçebiliyor
  • Monorepo, net bir teknoloji yığını, güncel kod tabanı gibi Claude Code dostu ortamlarda gerçek geliştirme işlerinin hızı ve esnekliği ciddi biçimde arttı

Giriş: Claude Code kullanıma girdikten sonraki değişim

  • Son 6 haftadır Claude Code kullanırken, kod yazma ve bakım yapma biçimimde önemli bir değişim hissettim
  • Tüm kodu bizzat yazmak zorunda olmamanın getirdiği bir "ifade özgürlüğü" oluşmuş gibi
  • Claude Code ile tüm yapıyı tek seferde kurgulayıp inceleme ve düzenleme becerileri üzerinden sonuca ulaşmak mümkün
  • Tıpkı fotoğraf ortaya çıktığında elde resim yapmanın cazibesinin azalması gibi, artık programlamanın girdi ve üretim süreci büyük ölçüde değişiyor
  • Bu değişim rahatsız edici gelebilir, ancak LLM tabanlı araçların ortaya çıkışı programlamada bir paradigma değişimi yaratıyor

1. Claude Code’un değiştirdiği kod yazımı ve bakım biçimi

  • Geçmişte haftalar ya da aylar süren migration, refactoring ve teknik borç temizleme işleri, Claude Code’un kullanımından sonraki 6 haftada eş zamanlı yürütülüp tamamlandı
  • Örnekler: yüzlerce React Native bileşeninin React’e taşınması, RedwoodJS sisteminin değiştirilmesi, Jest→Vitest migration’ı, server-side rendering, tasarım sistemi refactoring’i, Node 22 yükseltmesi vb.
  • Eskiden “ayrı planlanıp ele alınması gereken” yan projeler/backlog işleri, artık ana işle paralel ve boş zamanlarda yürütülebiliyor; iş yükü neredeyse artmıyor
  • Eskideki “teknik borç için takvim aç → büyük kaynak ayır” formülü bozuldu; anında başla → ilerlet → tamamla şeklinde bir ‘anındalık’ mümkün oldu

2. “Önce deneyip sonra karar ver” diyen deneysel geliştirme kültürü

  • Bir fikir akla geldiğinde önce Claude Code ile deneniyor; test kodları gibi unsurlar da erken aşamada otomatik üretilip silinerek öğrenme sağlanıyor
  • Frontend test stratejisi olmasa bile Claude Code ile her PR için farklı test yaklaşımları anında üretilip silinerek deneyim birikiyor ve genel yönün belirlenmesine yardımcı oluyor
  • Fikirler ve soyutlamalar üzerine düşünmek de “doğrudan dene → başarısız olsan da maliyeti düşük” yaklaşımıyla hızlıca doğrulanıp keşfedilebiliyor
  • Başarısızlığın maliyeti dramatik biçimde düştüğü için deney-öğrenme-karar döngüsü büyük ölçüde hızlandı

3. Paralel geliştirme ve iş birliği biçimindeki değişim

  • İki ayrı git clone/VSCode profili kullanılarak, her clone’da bağımsız işler yürütülüyor (ör. biri PR hazırlama, diğeri deneysel geliştirme)
  • Claude Code bir clone üzerinde çalışırken diğer clone’da paralel iş yapılabiliyor; ayrıca her clone için farklı tema/port kullanılarak işler net biçimde ayrılıyor
  • Pull Request’ler paralel hazırlanabiliyor, geliştirme sunucusu port çakışmaları önleniyor ve çalışma verimi artıyor
Reklam

4. Oyun prototipi / deneysel geliştirme sürecinde dönüşüm

  • Eskiden haftalar ya da aylar süren oyun prototipi üretme → kurum içi dağıtım → geri bildirim → yayımlama/iptal etme süreci, Claude Code sonrasında tasarımcıların bile birkaç saat içinde doğrudan kod üretip siteye dağıtım yapabilmesine dönüştü
  • Fikir → uygulama → ekip geri bildirimi → deneyi sonlandırma ya da production’a taşıma (yeniden yazım) gibi dağıtım döngüleri dramatik biçimde kısaldı
  • Ancak geçici oyunların yönetimi, resmileştirilmesi ya da ne zaman kaldırılacağı gibi yeni operasyonel sorular da ortaya çıktı

5. Günlük kodlama ve iş birliğinde Claude Code kullanımı

  • Haftalık triage sırasında Claude Code GitHub Action kullanılarak anında PR oluşturulup deney yapılabiliyor; küçük konular hemen uygulanabiliyor
  • Ürün ve teknik tarafta yetkin, aynı zamanda inisiyatif sahibi ekip üyeleri Claude Code’dan en yüksek verimi alıyor; yani ‘full-breadth developer’lar
    • "Full-breadth developers": tek bir geliştiricinin tüm iş akışını özgürce yönlendirmesine yardımcı olur
  • Kod inceleme, bağlam sağlama, düzeltme ve karar verme rolü insanda kaldığında tüm ekibin üretkenliği ve yaratıcılığı artıyor

6. Claude Code dostu kod tabanı ortamı

  • Monorepo: tüm kodun/DB şemasının/API’nin/arayüz mantığının tek yerde olması, Claude Code için bağlamı kavrama ve otomasyon açısından ideal
  • Standartlaştırılmış teknoloji yığını (React, Relay, GraphQL, TypeScript, StyleX, Bootstrap vb.) benimsenirse, LLM bunu daha kolay anlayıp otomasyona dökebiliyor
  • Kod tabanının güncel tutulması ve legacy’nin en aza indirilmesi, LLM kullanım verimini en üst düzeye çıkarıyor

7. Claude Code’un sınırları ve pratikte hissedilen değişim

  • PR/commit sayısı gibi nicel değişimler çok büyük olmasa da işin hissedilen hızı, esnekliği ve üretkenliği belirgin biçimde arttı
  • Claude Code, ‘deneyimli junior+ seviyesinde’ bir pair programmer gibi çalışıyor — mühendis kod kalitesini, mantığı ve bağlamı yönettiğinde çok güçlü bir partner haline geliyor
  • Tekrarlayan işler, teknik borç temizliği ve hızlı yan proje ilerletme gibi alanlarda niteliksel olarak farklı bir çalışma deneyimi sunuyor

8. Junior’lar ve öğrenenler için önerilen ‘paralel uygulama’ stratejisi

  • LLM ekosistemindeki son trendlere aşırı takılmak gerekmiyor
  • Yeni başlayan geliştiricilere, önce kodu kendilerinin yazması, ardından aynı görevi Claude Code’a vererek karşılaştırmalı öğrenme yapmaları öneriliyor
    • Claude Code’un çözümünden yararlanarak çeşitli soyutlamalar ve gerçek dünya kalıpları hızlıca öğrenilebilir
    • LLM’i bir ‘rakip + mentor’ olarak kullanıp hem pratik yetkinlik hem de güncel ekosistem sezgisi birlikte geliştirilebilir
    Reklam
  • Claude Code cep telefonu gibi: her zaman açık tutmak gerekmiyor
    • Önemli olan, kontrolü elde tutup onu verimli kullanmak

9. Yan projelerde ve kısa deneylerde patlayıcı artış

  • Eskiden zaman ve enerji kısıtı nedeniyle denenmesi zor olan küçük deneyler, araç geliştirme işleri ve blog iyileştirmeleri, Claude Code ile birkaç saat içinde hayata geçirilebiliyor
  • Fikir → anında uygulama → başarısız olunsa bile düşük maliyet — production’dan bağımsız yaratıcı deneyleri ve kişisel projeleri paralel yürütmek kolaylaşıyor

10. Gerçek Claude Code sohbeti ve kod inceleme örnekleri

  • DB temizleme script’i, puzzle REPL’i, crossword PDF yerleşimi gibi somut istek → kod üretimi → çalıştırma → düzeltme → inceleme süreçlerine dair gerçek örnekler sunuluyor
  • LLM hataları (muhakeme, abartı, hardcoding vb.) ortaya çıkabilir — gerçek değer elde etmek için mantıksal doğrulama ve kalite sorumluluğunu mühendisin üstlenmesi şart

11. Claude Code’un mühendislikteki yeri ve sonuç

  • Claude Code, referans kod, ekran görüntüsü ve ek açıklamalar gibi geniş bağlamı alma konusunda çok başarılı
  • Claude Code, ‘post-junior (yetkin junior ve üzeri)’ seviyesinde bir yardımcı programcı gibi davranıyor — sonsuz sabır ve hızla pratikte çok verimli bir iş ortağı olabiliyor
  • Tasarım, kalite ve son kontrol insan mühendiste kalırken, Claude Code uygulama, deney ve otomasyonun kapsamını ve hızını büyük ölçüde genişletiyor
  • “Her satırı doğrudan benim yazmam gerekiyor” kısıtından çıkıp tasarım, kalite yönetimi ve yeniliğe daha çok odaklanılabilen bir geliştirme ortamı sağlıyor

İlgili okumalar

7 yorum

 
benjamin 2025-08-08

Ben de Claude Code'u büyük bir memnuniyetle kullanıyorum.
Sanırım ben de artık yaklaşık 6 haftadır kullanıyorum.
İçeriğin büyük kısmına katılıyorum.

https://jeho.page/essay/2025/07/15/claude-code.html
 
GN⁺ 2025-08-07
Hacker News görüşleri

  • Yaklaşık 2 haftadır Claude Code kullanıyorum; normalde AI ile kodlamaya şüpheyle yaklaşırdım ama gerçekten şaşırdım. Verim almak için biraz öğrenme eğrisi var ve uygun bağlam sağlamakla işi parçalara ayırmak şart. Elbette programlama becerisi gerekiyor; bilmediğiniz her şeyi AI’a olduğu gibi atarsanız kesin sorun çıkıyor. 25 yılı aşkın deneyimim olduğu için Claude Code ne üretirse üretsin gözden geçirip yanlış olduğunda düzeltebileceğime güveniyorum. 10–15 yıl önce kodu doğrudan yazmak zorunda kalmayacağımız bir sinir arayüzü gibi bir şey hayal ederdim; Claude Code sanki bunun bir kısmını gerçekleştirmiş gibi. Bazen günlük kullanım limitine takıldığım için alternatif olarak Gemini CLI 2.5 pro modelini kullandım ama Claude Code ile kıyas bile kabul etmez. Gemini o kadar sinir bozucu ki kullanamıyorum. Eskiden ayda 100 doların üzerinde bir geliştirme aracına para vereceğimi hayal bile etmezdim; şimdi Max planına yükseltmeyi ciddi ciddi düşünüyorum.

    • Kıdemli bir geliştiricinin genç geliştiriciye tavsiye verip rehberlik edebildiği durumlarda bu aracın çok iyi uyduğunu düşünüyorum. Etrafımdaki kıdemli geliştiricilerden duyduğum kadarıyla gençler, LLM’lerle daha da garip, daha yavaş, güvenlik açısından zayıf ya da düpedüz berbat kod üretip kodu anlamadan PR açıyorlar diye çok şikayet ediliyor. Benim için en faydalı kullanım alanları boilerplate üretimi (yalnızca açıklama verince sınıf taslağı çıkarması), JSON’ı sınıflara ya da başka formatlara dönüştürmesi ve “Bu kodda sorun ne? Staff seviyesinde bir mühendis bunu nasıl değiştirirdi?” gibi sorular. Hatta bizzat benim yazdığım kodda hataları önceden Claude Code ile yakaladığım da oldu.

    • İlginç olan şu: “vibe coding”e şüpheyle yaklaşan insanların beklentisi, aracı gerçekten denemeden önce inanılmaz düşük oluyor. Birçok kişi LLM’in ürettiği kodun çöp olacağını düşünüp uç örnekleri ortalama sanıyor. Ama doğrudan kullanınca, beklediklerinden çok daha iyi olduğunu görüp kendileri şaşırıyor. Tabii ki Claude Code ile 10 kişilik ekiple bir anda 1 milyar dolarlık bir SaaS çıkarmak mümkün değil ama yine de bu aracın gerçek gücünü küçümseyen çok insan var.

    • Aslında teknik olarak bakarsak yaptığınız şey vibe coding değil. Daha çok AI destekli yazılım mühendisliği. Vibe coding, AI ne kod üretirse üretsin onu aynen kullanıp anlamadan ilerlemek demek. Terim herkes için farklı şey ifade ettiği için vibe coding kavramına fazla güvenmemek lazım.

    • Ben de daha birkaç ay öncesine kadar hiçbir abonelik hizmetine 20 dolardan fazla ödeme yapmıyordum; şimdi ise her ay 200 dolarlık Max 20 planına para veriyorum. ABD’de yaşayan Slovak kökenli, 20 yıllık deneyime sahip bir geliştirici olarak ben de buna şaşırıyorum. Başka araçları da denedim ama hiçbirinde bu kadar doğrudan üretkenlik ve verimlilik hissetmedim. Claude Code gerçekten başka bir seviyede. Elbette sürekli detayları takip etmeniz gerekiyor ama benim yöntemim Plan Mode ile gereksinimleri ve kod değişiklik planını en ince ayrıntısına kadar çıkarmak, buna %100 ikna olduktan sonra çalıştırmak ve ardından ortaya çıkan sonucu code review etmek. (Derleyici hataları, unit test ve lint sorunlarını AI kendi hallediyor.) Biraz tuhaf ama çok bilgili, inanılmaz hızlı bir junior engineer varmış gibi hissettiriyor. Yazılım geliştirmenin yönü açıkça buraya gidiyor; gelecek bu.

    • Son zamanlarda Claude modelinin SQL yazma/düzeltme konusunda güvenilirliğinin düşük olduğunu düşünüyorum. Örneğin koşul ifadelerini iyi kuruyor ama AND/OR kısımlarını parantezle gruplamıyor; Gemini pro ise bunu doğru şekilde hata olarak yakalıyor.

  • Claude Code’un tüm rakip araçların açık ara önünde olduğuna kesinlikle katılıyorum. 2023’ten beri AI ile kod üretimi için CLI araçları bizzat geliştiriyorum ve başlıca seçeneklerin neredeyse hepsini denedim diyebilirim. Yazarın birçok yöntemine güçlü şekilde katılıyorum:

    1. Monorepo çok zaman kazandırıyor.
    2. Net bir spec ile başlamak ve o spec’e yeterince zaman ayırmak gerekiyor. İyi bir taslak olursa spec’in çoğunu AI yazabiliyor.
    3. En baştan testlerin hazır olması şart. Bu en önemli nokta. İyi testler ve iyi bir spec olursa AI daha iyi çözümleri yinelemeli şekilde keşfedebiliyor. Sanki TDD geri dönmüş gibi.
    4. Tip sistemi ve linter inanılmaz büyük yardım sağlıyor.
    5. Dış dokümantasyonu proje içinde ayrı bir dizinde toplamak faydalı oluyor (ör. docs/external-deps).
    6. Her araçta olduğu gibi, size uyan teknikleri öğrenmek biraz zaman alıyor. Eskisine göre daha kolay ama hâlâ öğrenilecek şeyler var. Herkesin workflow’u biraz farklı; bu yüzden süreç aslında kodlamanın kendisine benziyor. Yakın zamanda Permiso(https://github.com/codespin-ai/permiso) adlı aşırı basit bir GraphQL RBAC sunucusunu da vibe coding ile yaptım. Henüz istikrarlı biçimde test edilmiş veya gözden geçirilmiş bir proje değil ama basit bir şeye ihtiyacı olanlar için şimdiden yararlı olabilir.

    • İkinci maddeyle ilgili olarak (iyi bir spec ile başlamak), spec’i somut olarak nasıl hazırladığınızı merak ediyorum. Ayrı bir Markdown belgesi mi yapıyorsunuz, ne kadar ayrıntı gerekiyor, bunları merak ediyorum. Ayrıca “en baştan testleri hazır et” tavsiyesine katılıyorum ama pratikte Claude, test hook’ları olduğunda bazen test kodunu önce yazma sürecini atlayıp doğrudan hatayı/gerek varsayımları doğrulamadan düzeltme tekrarına giriyor. Bu yüzden test davranışını açıp kapatan bir flag bile kullanıyorum.

    • Monorepo size zaman kazandırıyor olabilir ama Claude’un araç çağrıları ve token tüketimi çok daha fazla oluyor. Bence Aider gibi yalnızca gerekli dosyaları seçip AI’a vermek daha iyi. Claude’un neden bu kadar popüler olduğunu pek anlamıyorum. Aider neredeyse her açıdan daha iyi bir araç ve farklı LLM’leri de bağlayıp kullanabiliyorsunuz.

    • CC’yi düzgün kullanmak için proje yapısının iyi kurulmuş olması gerekiyor. Testleri, tipleri ve dokümantasyonu düzgün hazırlanmış bir Django projesinde CC neredeyse her şeyi iyi yaptı ama arada yönlendirme gerekiyordu. Son zamanlarda CC’yi çevrimdışı olarak yerel modelle çalıştıran bir yan proje de yapıyorum. İlk sürümü ChatGPT yardımıyla iyi çıkmıştı ama CC’ye geçince, CC’nin asıl meselelerde dönüp dolaşıp hata yapmaktan kaçındığını ve mevcut kodu refactor etmek ya da bug düzeltmek yerine sürekli yeni dosya/script üretme alışkanlığı gösterdiğini fark ettim.

    • Dış dokümantasyonu proje içine doğrudan formatlayıp koyuyor musunuz merak ediyorum. Çoğu projenin dokümanı sadece web sitesinde oluyor; siz ayrıca temiz Markdown dosyaları hazırlamak için zaman harcıyor musunuz?

  • Claude Code’un gerçek gücü yalnızca kod yazmanın ötesine geçip tüm bilgisayarı kontrol edebilmesinde yatıyor. Bir CLI aracı varsa Claude onu kullanabiliyor; yoksa bile Claude’a sormak çoğu zaman şaşırtıcı sonuç veriyor. Örneğin görüntü crop/resize etme, YouTube videosundan mp3 çıkarma, ses dosyasındaki sessiz bölümleri silme gibi her türlü ufak işi ona yaptırdım. Bu sayede inanılmaz zaman kazanıyorum. Eskiden nasıl yaptığımı artık hatırlamıyorum bile. Eski yönteme bir daha dönebileceğimi sanmıyorum.

    • Claude’a kendi gerçek bilgisayarınızı bağlamak yerine (her zaman kendi makineniz olmayan) ayrı bir bilgisayar vermek daha iyi. Benim durumumda IDE bir cloud VM üzerinde çalışıyor; Claude’u oraya bağlıyorum ve tarayıcıdan erişiyorum (https://brilliant.mplode.dev). Bence bu, agent çalıştırmaya en yakın ve en iyi UX. Terminal ya da ssh hazırlamaya gerek kalmadan yalnızca giriş yapıyorsunuz; instance otomatik oluşturulup duraklatılıyor. Sonuçta Claude + kişisel Linux instance’ı + IDE’yi doğrudan bir link üzerinden açmış oluyorsunuz. İleride istediğim kadar instance açıp yetkileri, dosya sistemini ve container izinlerini (JWT vb.) daha ince ayarlarla kontrol etmeyi planlıyorum. Eğer bir arıza ya da inceleme gerektiren durum olursa doğrudan IDE’ye girip çözebiliyorsunuz. Ayrı bir UI da gerekmiyor; IDE içindeki panellerden görebiliyor veya doğrudan container içinde web uygulamasını çalıştırabiliyorsunuz. Bu teknolojinin gelişimi beni uzun zamandır hiçbir şeyin heyecanlandırmadığı kadar heyecanlandırıyor.

    • Her şey güzel görünse de sadece fiili kod çıktısına bakarsak veriler öncesi ve sonrası arasında neredeyse fark yok. Claude ile çalışınca da commit, PR ve satır sayısı eskiden çok farklı değil. Yani AI ile kodlama “üretkenlik arttı” hissi ve “elimi sürmeden bir şey ürettim, ne güzel” duygusu veriyor ama gerçekte çok miktarda review, düzeltme ve yeniden prompt yazma gerekiyor; sonuçta toplam çıktı miktarı benzer kalıyor. Dahası, zor kısımları AI’a devrettikçe kişinin kendi tasarım ve düşünme becerisi zayıflıyor. Bir ay boyunca Claude gibi LLM’lerle çalışıp sonra kendi başınıza küçük bir uygulama yapmayı deneyince, yalnızca kod değil bütün yapıyı tasarlamak bile daha zor geliyor. Uzun vadede codebase yavaş yavaş bozulabilir ve sonunda eksiye düşme riski de büyük (en azından mevcut nesil LLM’lerde).

    • Eskiden ImageMagick (mogrify) komutlarını tek tek eski usul kendim yazardım. AI araçlarının desteğiyle inanılmaz zaman kazanıyorum.

    • Linux PC’nin sürekli çökmesinin nedenini Claude’a teşhis ettirdim; journalctl ile logları tarayıp asıl nedeni buldu, gerçekten büyük yardım oldu. Sorun çözümünde doğrudan işe yarayan bir deneyimdi.

    • Bir başka örnek de statik site üretiminin çok kolaylaşmış olması. Yazıyı hangi sözdizimiyle yazarsam yazayım, Claude Code’a “bu gönderiyi blog formatına dönüştür” demem yetiyor. Mesela “image.jpeg görselini ekle” diye yazmam bile yeterli oluyor, gerekeni yapıyor. Markdown ya da Hugo formatına takılmamak büyük rahatlık.

  • Claude code’u günde 12–16 saat kullanan biri olarak şu ipuçlarını keşfettim:

    1. Başlatır başlatmaz sonnet modeline geçin (opus ile kalite farkı büyük).
    2. compacting (konuşma geçmişini sıkıştırma) süreç içinde kaliteyi ciddi düşürüyor; bu yüzden doğru zamanlama önemli.
    3. İlk prompt aşırı önemli ve oturumun karakterini burada belirliyorsunuz. Eğer Claude instance’ı kararsız ya da isteksiz davranmaya başlarsa oturumu kapatıp yenisini açmak daha iyi.
    4. “Belki kötü bir fikir olabilir ama şunu yapmak istiyorum” gibi nazik bir üslupla rica ederseniz çok daha istekli yardımcı olma eğiliminde oluyor.
    5. Docker orkestrasyonunu Claude’a bırakınca üretkenliğim 10 kat artmış gibi hissettim. Yeni container ayağa kaldırma, hata loglarını kontrol etme, silme/yeniden build etme gibi tüm akışı Claude’a verince tek bir prompt ile tüm servisi ayağa kaldırabiliyorum.
      1. madde Docker dışında playwright MCP sunucusuyla birlikte kullanılırsa UI ve istekleri de anında kontrol ettirebilirsiniz. 6. Plan mode ile başlayıp plan hoşunuza gidene kadar yinelemeli biçimde düzenlemek. 7. Slash command (/komut) özelliğini aktif kullanarak mini prompt’larla sürekli iyileştirme, bağlam sağlama ve gh gibi dış araçların kullanımını yönlendirme. compacting’i asla bir anda %0 noktasında yapmayın; uygun bir ara noktada uygulamak daha iyi. 1. maddeye (sonnet önerisi) ise katılmayabilirsiniz.

    • Docker’dan uzak durma eğilimim var ama 5. ipucu (Claude ile Docker orkestrasyonu) gerçekten ilgimi çekti. Hangi prompt formatını kullandığınızı merak ediyorum.

    • Çok ayrıntılı bir plan.md dosyasıyla (sistemler arası bağlantılar, genel mimari vb.) başlayıp claude-loop(https://github.com/DeprecatedLuke/claude-loop) gibi araçlarla gece boyunca çalıştırıp sabah elle patch atma yöntemini de başarılı şekilde kullandım.

    • Claude Code’u günde 16 saat nasıl kullandığınızı merak ediyorum.

    • Bazen Claude container’ın içini gereğinden fazla kurcalıyor. Sadece kodu anlamasını istemiştim ama container içinde türlü türlü yöntemlerle kodu çalıştırmaya uğraşıp işleri daha da tuhaflaştırdığı oldu. Eskiden dosyaları CLI komutlarıyla pipe edip hiçbir şey yapmadığı da olmuştu; yani bir şeyi takıntılı biçimde çalıştırma eğilimi var.

  • Claude Code’un gerçekte ne kadar iyi olduğunu bilmiyorum (kendim kullanmadım) ama kişisel olarak beni düşündüren bir nokta var. Çok yavaş ve dağınık bir gdscript (Python benzeri) kod tabanını C#’a refactor etmek istiyorum. Daha temiz ve daha hızlı olmasını istediğim kişisel bir proje. Bu iş benim için yeni bir meydan okuma ve öğretici yanı da var. Claude kullanırsam öğrenebileceğim değerli bir fırsatı elimden alıyormuşum gibi hissediyorum (uzun vadede kişisel gelişim için de yararlı olabilir); kullanmazsam da değerli zamanımı sıkıcı bir işe harcıyormuşum gibi geliyor (üstelik bu tür işler ileride zaten otomatikleşecek). Sürekli bir ikilem yaşıyorum.

    • 35 yıllık geliştirme deneyimimde, hangi LLM olursa olsun benim çözebileceğim ama yapmak istemediğim (sıkıcı, tekrarlı) işleri AI’a bırakıyorum. Mesela Open API 3.0 şeması düzeltmekten hiçbir şey öğrenmeyeceğim için bunu Claude’a yaptırdım; örnek kod üretimini de AI’a bırakıyorum. Gerçekten yeni bir şey öğrendiğim noktalar olursa Anki SRS gibi uygulamalarda flashcard olarak not alıyor ya da TIL bloguma yazıyorum. Veya örnekleri birkaç kez bizzat kendim uygulayıp deneyime dönüştürüyorum. Önemli olan yeni öğrenilen şeyi beyninizde en az iki kez bağlamak; ancak o zaman etkili öğrenme oluyor. Yeni bir doğal dil kelimesi öğrenirken onu üç cümlede kullanmaya çalışmak gibi.

    • Üretilen kodu bizzat review etmezseniz (yani C#’ı yeterince öğrenmezseniz) codebase çok hızlı bozulur. LLM ile kodlamada hatalar birikme eğiliminde olduğu için mutlaka iyileştirme gerekir; yoksa sürdürülemez bir çöp yığınına dönüşür. Çevremdeki arkadaşlar AI’ın yeterli test kodu üretmesini sağlayarak sorunları erken yakaladıklarını söylüyor ama ben henüz bu yöntemi kullanamadım. Benim kodum algoritmadan çok mantık ağırlıklı olduğu için test yazmak da biraz belirsiz kalıyor.

    • 16 yıldır profesyonel geliştiriciyim; Claude Code’un daha önce duvara toslayıp kafamı patlattığım şeyleri çok daha kolay çözmeme yardımcı olduğunu hissediyorum. Yeni şeyleri hızlı öğrenirken AI araçları, özellikle soru-cevap odaklı “ask” modu çok etkili oluyor; benzetmeler, örnek vakalar ve ezber tekniklerini aktif kullanıyorum. Eğer amaç yavaş ilerleyerek derin öğrenmekse, daha yavaş da olsa klasik yöntemleri tercih etmek daha iyi. Ama hedef hızlı öğrenmekse AI kullanmak kötü bir seçenek değil. Sadece sonuç istiyorsanız iyi bir spec yazmak ve testleri sağlam tutmak önemli. Sonuç olarak hangi yöntemi seçerseniz seçin, sürekli bir şeyler üretmeye devam etmek anlam taşıyor.

    • Eskiden “kendi x kütüphaneni yaz” diye bir blog akımı vardı. İnsan en çok bir şeyi bizzat uygularken öğreniyor. Mesela client-side router’ı merak ediyorsanız kendiniz bir router yazmanız gibi. LLM çağında her şey bir kütüphane koduyla değiştirilebilir ama gerçekten C# öğrenmek istiyorsanız port işini kendiniz yapmanız daha iyi. Sadece sonuca ihtiyacınız varsa ve başka şeylere odaklanmak istiyorsanız Claude’a bırakabilirsiniz. Öğrenme sürecinde mutlaka acılı bir bölüm olur; fazla kolaysa aslında hiçbir şey öğrenmiyorsunuz demektir.

    • AI öncesinde de kopyala-yapıştır kültürü hakimdi. Stackoverflow’dan niye aldığını anlamadan kod kopyalayan arkadaşlar sonuçta hiçbir şey öğrenmedi. Tavsiye ya da kavram açıklaması istemek için AI kullanmakta sorun görmüyorum. Ama her şeyi sizin yerinize yazmasını isterseniz net biçimde öğrenme olmaz. Yine de geliştirici olarak kendi zamanınızı korumak da akıllıca. Öğrenilecek şey sonsuz; hedefiniz oyun geliştirmekse GDscript port etme işi vazgeçilmez bir deneyim olmayabilir. Tabii ki içinde öğrenilecek taraflar da var.

  • Yaklaşık 3 haftadır Claude Code ile kod yazıyorum; 10 yıllık deneyimim var ve daha çok Python ML/veri mühendisliği tarafında çalışıyorum. Bunun birkaç nedeni var:

    1. Başlamanın acısını ortadan kaldırıyor; ilk satırı yazma bariyeri kalmıyor.
    2. Çalışırken zihnimi tamamen düşünmeye ayırabiliyorum.
    3. Aynı anda birden fazla işi paralel yürütebiliyorum.
    4. “Şuna da bakmalıydım” diye bir şey aklıma gelirse hemen yeni bir Claude oturumunda deniyorum (artık TODO bırakmıyorum).
    5. Analiz/görselleştirme, plotting vb. işlerde script’leri kolayca otomatik çalıştırabiliyorum.
    6. Basit lint/type/test sorunlarını kendi kendine düzeltiyor. Genel olarak yalnızca kodun özüne—neyin yapılması gerektiğine, çıktının doğru olup olmadığına ve nasıl daha iyi hale getirilebileceğine—odaklanabiliyorum.

    • Başlangıçtaki sürtünmeyi ortadan kaldırması gerçekten çok büyük fark yaratıyor. Eskiden “zamanım olsa yapmak isterim” dediğim şeyleri şimdi birkaç prompt ile hayata geçirebiliyorum. Mesela NYT Connections oyununu terminalde yapmak istiyordum; 3 prompt’ta bitti (https://github.com/jleclanche/connections-tui).

      1. madde özellikle etkileyici. Eskiden test ya da teknik borç bırakmak normaldi ama şimdi “test suite lazım” demek bile çoğu zaman oldukça düzgün bir şey ürettiriyor. Mükemmel olmasa da orta zorluktaki işleri artık gerçekten takip edebilir hale geldik.

  • Agent tabanlı kodlamayı sürekli denemeye çalışan meraklı azınlıktan biri olarak, neden benim deneyimimin ana akımdan farklı olduğunu düşünüyordum. Sanırım kilit nokta şu açıklama:

    "Claude Code ile artık programlamada ‘fotoğrafın ortaya çıktığı andayız’. Eskiden elde çizim yapma havası vardı ama şimdi bir fikri doğrudan hayata geçirip, kendi code review ve düzenleme becerimle istediğim şekle yontabiliyorum." Bu benzetme yerinde olsa da insanlar hâlâ resim yapıyor, bazıları resim satın almak için para ödüyor ve bazıları kodlamanın kendisini bir sanat olarak seviyor. Ben doğrudan kod yazmayı bir hobi olarak seviyorum; code review’dan hoşlanmıyorum ama mecburen yapıyorum. Seçenek verilse kendim yapmayı seçerim (zaten bu yüzden IC olarak kaldım). İnsanlar AI kodlama agent’larını çokça junior developer intern gibi görüyor ama ben daha çok ürkütücü buluyorum.

    • İnsanların hâlâ resim yaptığı ve resimlere para verdiği bir dünyanın gerçekten sürüp sürmediğini sormak istiyorum. Çoğu el işinin modüler ve seri üretim süreçlerine yenildiği noktada artık değer, ürünün kendisinden çok üretici ile tüketicinin hayal gücü üzerinden kurduğu ortak deneyime kaymış gibi. Yani mesele yalnızca Amazon’dan bir şey sipariş etmek değil; zanaatkârla kurulan ilişki ve üretim süreci de bir anlatı olarak tüketiliyor. Kodlamanın da gelecekte hayatta kalmak için buna benzer bir yöne gitmesi gerekebilir.

    • Bu bakış açısını ben de çok iyi anlıyorum. Küçük işler, bug fix’ler ve taslak üretimi için agent tabanlı kodlamanın faydasını kabul ediyorum. Ama sadece az sayıda modeli sarmalayan farklı arayüzler yüzünden destek/karşıtlık tartışmalarının bu kadar alevlenmesini anlamıyorum. Ayrıca junior developer’lar üzerindeki etkisini de hâlâ düşünüyorum. Eğer AI code review’u da otomatikleştirirse hayatım daha da güzel olurdu.

    • Bu benzetmenin tamamen geçerli olduğunu düşünmüyorum. Tarihsel olarak resim, gerçek dünyayı temsil etmenin tek yoluydu; ama sanat yalnızca taklit değil, üreticinin yorumudur. İnsanların hâlâ resim yapmasının nedeni de bu. Eğer kodlamanın kendisini sanat olarak görüyorsanız devam edebilirsiniz. Ama birçok insanın amacı ürün geliştirmek ve ürünün kendisi zaten sanat olabilir. AI ile bu hedefe daha hızlı ulaşılabiliyorsa elbette AI’ı seçmek daha mantıklı değil mi? Öte yandan saf “kod maymunu” günlerini de biraz özlüyorum. Şimdi herkesin lead developer gibi yalnızca yön verme, code review ve teknik kararlar aldığı bir döneme gidiyor gibiyiz. Günlük işte daha az elle kod yazacak olmak biraz hüzünlü.

    • Daha uygun benzetme, el aletlerinden elektrikli aletlere geçiş gibi. Resim-fotoğraf benzetmesi yeni bir mecranın doğuşunu anlatıyor; burada ise o kadar köklü bir değişim yok. Agent tabanlı kodlama o kadar devrimsel değil.

  • Claude Code’u çok kullanmaya çalıştım ama fazla yavaş ve sürekli bir şeyler ters gidiyor; insanı yoruyor. Çoğu işte zihinsel enerjiyi koruduğumu hissetmiyorum. Bazı işlerde yardımcı oldu ama sık sık da arkadan vurdu, bu yüzden sık kullanmak istemiyorum. Mesela nushell ile .zshrc dönüştürmesini istedim; 30 dakika uğraştı ve yine çalışmadı. Oysa resmi dokümantasyona kendim baksam 10 dakikadan kısa sürerdi. Bu tür hayal kırıklıkları yüzünden Claude’u tekrar kullanma isteğim pek kalmadı.

    • Bu deneyim benimkine de çok benziyor. Test kodu yazma gibi işlerde yardımcı olmasını umdum ama çoğu kez her şeyi yeniden ben yazmak zorunda kaldım. Debugging’de ise bir kez bile işe yarar sonuç alamadım. Yalnızca çok basit script dönüşümleri (komut çıktısı parse etme gibi) veya yeni proje scaffolding’i biraz işe yarıyor (ama bunları ne kadar sık yapıyoruz ki). Basit kod port etmede fena değildi ama başarısız deneyimler çok daha fazlaydı.

    • context7 MCP gibi bir şey denediniz mi merak ediyorum. Az popüler dillerde ya da alışılmadık alanlarda LLM’ler zayıf kalma eğiliminde. context7 gibi güncel kaynaklardan doğrudan referans çeken yöntemler bana daha iyi geliyor.

  • RSI ve karpal tünel sendromu yüzünden daha az kod yazabiliyordum ama Claude sayesinde yeniden programlama yapabiliyorum (ağrım onda bire indi). Aslında uzak durmaya çalıştığım bir teknolojiydi ama kariyerimi sürdürebilmem için artık gerekli hale geldi.

    • Benzer hikâyeleri çok duydum. RSI yaşayan insanlar için Claude gibi araçlar gerçekten oyun değiştirici. En zor ve sıkıcı boilerplate gibi tekrarlı işleri çok daha rahat hale getiriyorlar. Eskiden tekrar eden kod görünce hem bileğim hem zihnim yorulurdu; şimdi bunlarla uğraşmama gerek kalmadı ve daha soyut ya da yeni problemlere odaklanabildiğim için programlama çok daha keyifli hale geldi. “Bu araçlar yüzünden kariyerim bitebilir” endişesi var ama bence tam tersine benim kariyerimi kurtarabilir.

    • Claude kullanmaya başladıktan sonra RSI ağrım neredeyse kayboldu. Özellikle çok hassas komutlar ve cümlelerle tekrarlı işleri değiştirebilmek büyük fark yaratıyor. Ses tanıma kullanan çok örnek de duydum; erişilebilirlik açısından da yeni kapılar açılıyor gibi.

    • Claude Code’u sesle doğrudan kullanabilmek daha da faydalı olmaz mı diye düşünüyorum. MacOS’ta ücretsiz TTS/ASR seçenekleri var ve BYOK ile başka ses motorları da bağlanabiliyor (https://github.com/robdmac/talkito).

    • Yeterince doğru ve kullanışlı bir STT/ses tanıma uygulaması kullanıyorsanız Claude Code’a ayrıntılı bağlam aktarmak da çok etkili oluyor. Çeşitli ses tanıma uygulamalarını denedim; klavye kısayolu tabanlı hands-free modu, doğruluk ve hızı birlikte sunduğu için Wispr Flow bana en iyi uyan çözüm oldu. Yine de yerel uygulama desteği de olsa keşke.

    • Acaba metin girişini tamamen sesle mi yapıyorsunuz?

  • Bakım açısından yazarın görüşüne çok katılıyorum. Eskiden refactor ya da hatırlatma amaçlı TODO/ticket açacağım işleri şimdi Claude sayesinde anında uyguluyorum. Böylece tekrar eden zahmet ciddi biçimde azaldı. Refactor fikirlerini hızlıca deneyip beğenmezsem atmak da çok kolaylaştı. Bu tür işlerde gerekli aktivasyon enerjisi belirgin şekilde düştü. AI agent’ları paralel ya da çevrimdışı biçimde gelişigüzel çalıştırmanın ise tükenmişliğe ve kod kalitesinin bozulmasına yol açabileceğine, bu yüzden insan gözetimi modunda kalınması gerektiğine de katılıyorum. Bununla ilgili ek notlarımı https://www.modulecollective.com/posts/agent-assisted-coding... adresinde yazdım.
 
zxavi 2025-08-07

Benim hislerim de tam olarak asıl yazıyı yazan kişiyle aynı haha
$200 ödeyip bir saat içinde 4 yıllık bir problemi çözdüm.
Muhtemelen tek başıma... Cursor ile ise bunu asla çözemiyordum.
 
beoks 2025-08-07

Acaba claude code ile Cursor + Claude LLM kullandığınızda aradaki farkın ne olduğunu söyleyebilir misiniz?
Ben Cursor kullanıyorum ama claude codea geçip geçmemeyi düşünüyorum.
 
zxavi 2025-08-07

Claude LLM derken API anahtarını mı kastediyorsunuz?
Yoksa sohbet penceresinin altındaki Agent modellerini kastediyorsunuz, değil mi?

Cursor’dan da oldukça memnundum ve kullandım ama kullanım sınırına sık sık takıldığı için, $60’lık planı kullanırken bile limite takılır mıyım diye sürekli tedirgin oluyordum.
Böyle olunca da arada gemini cli kullanıp duruyor, epey stres yaşıyordum.

Cursor + Claude 4 sonnet de fazlasıyla iyiydi ama bir gün geçince limite takılması, bir de limite takılınca bir ay boyunca kullanamamak en büyük sorundu.

Cursor + Claude 4 opus’u ise denemeye bile cesaret edemedim.

Claude Code sonuçta cli tabanlı ve IDE’ye bağlı özellikler taşımadığı için denemeye karar verdim.

Başta $20 dolar ödedim ama bunda da opus yok.

Sonra limite dayanırken, bari bir ay kullanayım diyerek $200 ödeyip denedim

ve resmen yeni bir dünya açıldı. opus... seviyesi bambaşkaymış...

Şu an 200’lük planın 4. günündeyim ve bir kenarda bekleyen zor sorunların hepsini çözüyorum haha
 
zxavi 2025-08-07

Yazı düzenlenmiyor galiba

Cursor + Claude 4 Sonnet de fazlasıyla iyiydi ama bir gün geçince limite takılması ve limite takılınca bir ay boyunca kullanılamaması en büyük sorundu.

Bir ay değil de bir gün gibiydi sanırım. Bir ay boyunca sürekli tedirgindim.
Bir de Cursor’la çok kavga ettim ama
Claude Code’la pek kavga etmiyorum.
 
beoks 2025-08-07

Ooo, ayrıntılı yanıt için teşekkürler.
Ben de limite takıldığım için mecburen Cursor’u Auto modunda kullanıyorum ama sanırım geçmem gerekecek.