Claude Code ile İyi Sonuçlar Elde Etmek

• Son birkaç ayda çeşitli LLM programlama ajanları denendiğinde, Claude Code en tatmin edici araç oldu
• Claude Code sayesinde kısa sürede yaklaşık 12 program ve proje geliştirildi; normalde zaman kısıtı nedeniyle başlanmayacak işler bile mümkün hale geldi
• Başarılı kullanım için net bir şartname hazırlamak, proje yapısı, build ve lint çalıştırma yöntemlerini içeren dokümantasyon sağlamak, yapay zekadan kendi kodunu gözden geçirmesini istemek ve kişiselleştirilmiş bir global ajan rehberi kullanmak kritik önemde
• Yapay zekanın yazdığı kod sık sık hatalı veya verimsiz olabileceğinden, tüm kod ve test vakaları mutlaka elle gözden geçiriliyor; eksik testler doğrudan ekleniyor ya da yapay zekaya yazdırılıp tekrar inceleniyor
• Ek olarak paylaşılan global ajan rehberi; adım adım uygulama planı, test odaklı geliştirme, sadelik-açıklık-pratiklik merkezli bir yaklaşım, kalite kriterleri ve problem çözme süreci gibi ayrıntılı geliştirme yönergeleri içeriyor

---

Claude Code kullanım deneyimi ve etkisi

• Son birkaç ay boyunca çeşitli LLM programlama ajanları denendi ve özellikle Claude Code ile deneyim en başarılısı oldu
• Tamamen sorunsuz olmasa da, kısa sürede 12'den fazla program ve proje tamamlanabildi
• Claude Code olmadan aynı dönemde tüm bu işleri yapmak neredeyse imkânsız olurdu
• Bu çalışmaların çoğu, zaman maliyeti nedeniyle normalde hiç başlanmayacak projelerdi

Claude Code kullanım stratejileri

• Net bir şartname hazırlamak
  • Projeye başlamadan önce gereksinimler ve bağlam açık biçimde belgelenip ajana veriliyor
  • Böylece kod yazımının yönü ve kapsamı netleşiyor
• Proje yapısını dokümante etmek
  • Build, lint ve test çalıştırma yöntemlerini içeren bir belge hazırlanıyor
  • Böylece ajan kod tabanını daha etkili biçimde keşfedip çalışabiliyor
• Ajandan kod incelemesi istemek
  • Claude Code'dan ürettiği kodu bizzat gözden geçirmesi istenerek beklenmedik iyileştirmeler veya hatalar bulunabiliyor
• Kişisel global rehber kullanmak
  • Problem çözme yaklaşımı, TDD uygulaması, sadelik ve açıklığı koruma, deneme sayısı sınırı (3 kez) gibi kişisel kuralları içeren ~/.claude/CLAUDE.md ile tutarlı bir geliştirme süreci korunuyor

LLM tarafından yazılan kodun doğrulanması

• Yapay zeka tarafından üretilen kodlarda sık sık mantık hataları, performans düşüşü ve eksik testler gibi problemler olabiliyor
• Yazar tüm kodu manuel olarak gözden geçiriyor ve çalışmasını doğruluyor
  • Eksik test vakalarını doğrudan ekliyor
  • Ya da yapay zekadan yazmasını isteyip kodu ve testleri yeniden inceliyor
• Profesyonel ortamda, PR üzerinde kendi adı yer aldığı sürece nihai kalite sorumluluğunun kendisine ait olduğunu özellikle vurguluyor

Kişisel “global” ajan rehberinin ana içeriği

Bu rehber ~/.claude/CLAUDE.md dosyasında yönetiliyor

• Felsefe ve temel ilkeler

  • Kademeli ilerleme: Küçük değişikliklerle ilerlemek, derleme ve testlerin her zaman geçmesi
  • Mevcut kodu öğrenmek: Uygulamadan önce kod kalıplarını analiz etmek ve plan oluşturmak
  • Pratikliği öncelemek: Projenin durumuna uygun esnek yaklaşım
  • Açıklığı öncelemek: Okuması kolay, niyeti açık kod; gereksiz numaralardan kaçınmak

• Sadelik tanımı

  • Fonksiyonlar ve sınıflar tek bir sorumluluğa sahip olmalı
  • Erken soyutlamadan kaçınılmalı
  • Karmaşıklık azaltılmalı ve açıklama gerektirmeyen kod hedeflenmeli

• Çalışma süreci

  • 1. Planlama ve aşamaları belirleme:
    • Karmaşık işler 3 ila 5 adıma bölünüp IMPLEMENTATION_PLAN.md içine yazılıyor
    • Her aşama için hedef, başarı kriteri, test vakaları ve ilerleme durumu belirtiliyor
  • 2. Uygulama akışı:
    • Anlama → test yazma (kırmızı) → minimum uygulama (yeşil) → refactor → commit
  • 3. 3 deneme sınırı sonrası yeniden değerlendirme:
    • Başarısızlık durumunda deneme geçmişi, hatalar ve nedenler kaydediliyor
    • Alternatifler araştırılıyor (2-3 yaklaşım)
    • Temel tasarım ve problemin parçalanması yeniden gözden geçiriliyor
    • Farklı kalıplar veya özellikler deneniyor

• Teknik standartlar

  • Composition öncelikli, dependency injection kullanımı
  • Arayüz kullanımı, test edilebilirliğin sağlanması
  • Açık veri akışı
  • TDD öneriliyor, testlerin devre dışı bırakılması yasak

• Kod kalitesi kuralları

  • Her commit derlenmeli, testleri geçmeli, yeni özellik testlerini içermeli ve kod stiline uymalı
  • Commit öncesi formatter ve linter çalıştırılmalı, değişiklikler self-review'dan geçirilmeli ve commit mesajı "neden"i açıklamalı

• Hata işleme

  • Hızlı başarısızlık ve spesifik mesajlar
  • Debug için gerekli bağlamın sağlanması
  • İstisnaların uygun seviyede ele alınması, istisnaların gizlenmemesi

• Karar verme ölçütleri

  • 1. Test edilebilirlik
  • 2. 6 ay sonra da anlaşılabilir okunabilirlik
  • 3. Proje kalıplarıyla tutarlılık
  • 4. Sadelik
  • 5. Değişikliğe açıklık

• Proje entegrasyonu

  • Benzer 3'ten fazla özelliğin analiz edilmesi
  • Mevcut kalıpların ve kütüphanelerin yeniden kullanılması
  • Aynı test yardımcı araçlarının kullanılması
  • Yeni araçların devreye alınması için güçlü gerekçe gerekmesi

• Kalite kapıları

  • Tüm testler geçmeli
  • Proje kurallarına uyulmalı
  • Linter uyarısı olmamalı
  • Commit mesajı açık olmalı
  • Uygulama planla uyumlu olmalı
  • TODO içinde issue numarası bulunmalı

• Test yönergeleri

  • Uygulamaya değil davranışa odaklanan testler
  • Mümkünse test başına tek bir assertion
  • Senaryoyu açıklayan net isimler
  • Mevcut test yardımcılarının yeniden kullanılması
  • Testler deterministik olmalı

• Kesinlikle yasak

  • --no-verify ile hook'ları atlamak
  • Testleri devre dışı bırakmak
  • Derlenmeyen kodu commit etmek
  • Doğrulama olmadan tahminde bulunmak

• Mutlaka yapılmalı

  • Kademeli commit'ler
  • Dokümantasyonun sürekli güncellenmesi
  • Mevcut uygulamadan öğrenilmesi
  • 3 başarısızlıktan sonra yaklaşımın yeniden değerlendirilmesi

Claude Code ile geliştirilen açık kaynak projeler

• HTML/XML tanıyan reverse proxy (cdzombak/xrp)
• VS Code Solarized teması (açık/koyu) (cdzombak/dzsolarized-vscode)
• Flickr photostream RSS üreticisi (cdzombak/flickr-rss)
• Lychee fotoğraf kütüphanesi metadata aracı (cdzombak/lychee-meta-tool)
• macOS ekran kilidi durumu için MQTT raporlama (cdzombak/macos-screenlock-mqtt)
• Lychee Bird Buddy fotoğraf başlıklarını otomatik ayarlama (cdzombak/lychee-birb-title)
• Yerel LLM tabanlı otomatik fotoğraf sınıflandırma (cdzombak/lychee-ai-organizer)
• macOS için toplu yazılım kurulum otomasyonu (cdzombak/mac-install)
• RSS servis projesi (cdzombak/rss.church)
• Flickr fotoğraflarını tam/seçmeli dışa aktarma ve metadata koruma (cdzombak/flickr-exporter)
• Statik HTML galeri üreticisi (cdzombak/gallerygen)

[wedding]

İyi sonuçlar çıktıysa, bu birinin daha önce yazdığı kodu iyi referans aldığı anlamına mı geliyor.

[aeolian21]

Yazarın yaptıklarının hepsini herkes zaten çok önceden yapıyordu; gereksiz şeylerle övünmek yerine
LLM’ler arasında karşılaştırıldığında neden Claude’un en iyisi olduğunu düşündüğüne dair gerekçeleri yazmak çok daha anlamlı bir yazı olurdu
gerçekte üretilen kodların karşılaştırması, derleme hatası sıklığı, bağlamı kavrama istikrarı gibi şeyler
aslında bağlamı kavrama yeteneği en iyi olan Gemini’dir (1 milyon token)

[zxcv123]

Sadece işe yaramaz şeyler yapmış ve üstüne bir de lafı gereksiz yere uzatmış.

[knunu]

Birileri için faydalı olabilir haha

[GN⁺]

Hacker News görüşü

• Bugün ilk kez Claude ve bir kodlama ajanıyla gerçekten başarılı bir deneyim yaşadım. Daha önce Cursor kullanmıştım ama artık Claude ve başka araçları da birlikte deniyorum. Yazıda da dendiği gibi, asıl önemli nokta net bir spesifikasyon yazmak. 2 saat boyunca 12 adımlık bir belgeyi bizzat hazırlayıp nasıl uygulanacağını düzenledim ve arka plan bilgilerini de ekledim. Claude da bu prosedürü takip ederek kodu adım adım üretti. Bence bu sayede yaklaşık 6 ila 10 saat kazanmış oldum. Bundan sonra gözden geçirme, test etme, kademeli ayarlamalar yapma ve özellik ekleme kısmını ben üstleneceğim. Bu başarının temelinde, Claude’un yapması gereken tüm adımları açıkça benim yazmış olmam var. Yani genel akışı ben tasarladım, Claude ise sadece talimatları uyguladı. Bu süreç bana, en azından bir süre daha orta seviye ve üzeri geliştiricilerin yapay zeka tarafından yerinin alınmayacağına dair güven verdi. Ama Claude’un spesifikasyonu baştan sona okuyup düzenli, belgelenmiş kod üretmesini izlemek gerçekten çok ilginçti. Kendi ellerimle kod yazmak zorunda kalmamam etkileyiciydi.

  • Ben bu kadar hazırlık yapmadan da Claude ile iyi sonuçlar alıyorum. Neredeyse kendim kod yazıyormuşum gibi, Claude’dan her seferinde tek bir adım istiyorum. Her değişikliği hemen uygulatıp commit’liyor, ardından diff’i inceliyorum. Claude garip bir sonuç üretirse anında düzeltmesini istiyorum. Ayrıca kullanmasını istediğim mevcut kodu ya da fonksiyon referanslarını doğrudan veriyorum. Bu yöntemle çok daha az yazarak ve daha az zaman harcayarak harika sonuçlar alınabiliyor.

  • Naur’un “Programming as Theory Building” yazısını okumanı tavsiye ederim. Problemi teorik olarak nasıl anlamak ve doğrudan nasıl modellemek gerektiğini oradan öğrendim. Aksi halde LLM kendi (hatalı) teorisini kurabiliyor.
    “Programming as Theory Building” - Naur oku

  • Yazıda dendiği gibi, net bir spesifikasyon gerçekten çok önemli. Ben de Claude ile bir programlama dili geliştiriyorum ve bunu doğrudan hissediyorum. Programlama, gerçekten çok sayıda küçük kararın art arda verilmesinden oluşuyor. Açık biçimde yönlendirmezseniz LLM çoğunu tahmin ederek halletmeye çalışıyor ve sık sık yanlış seçim yapıyor. Bu küçük hatalar birikerek yanlış sonuçlara yol açabiliyor.

  • Eğer böyle bir spesifikasyon belgesi örneğini doğrudan paylaşabilirseniz gerçekten çok iyi olur. Geliştirmeyi kendi kendine öğrenen ve Claude Code ile deney yapan biri olarak, pratikte hangi bilginin ve hangi derinliğin işe yaradığını anlamama çok yardımcı olur.

  • Aslında epey çok orta seviye ve kıdemli geliştirici de düzgün bir spesifikasyon dokümanı yazamıyor. Ama ne demek istediğini anlıyorum.

• ~/.claude/CLAUDE.md oluşturup içine kurallar yazmanın pratikte çok etkili olduğunu sanmıyorum. Claude bir insan değil; her kod satırı üzerinde dikkatle akıl yürütmüyor. Öznel ve muğlak yönergeler, kodu gerçekten değiştirecek bir etki yaratmıyor. Bir de context rot diye bir sorun var.
  (context rot açıklaması: LLM’in uzun sohbetler veya görevler sırasında bağlamı kaybetmesi ya da bozması. Referans: https://news.ycombinator.com/item?id=44564248)
  Gerçekçi olmak gerekirse, tek bir dosyaya türlü türlü kuralı doldurup yapay zekanın bunlara kendiliğinden uyacağını beklemek imkansız. Bunu yapmak istiyorsanız her kural için bir sub-agent oluşturup bunu yapay zeka yerine klasik bir pipeline’a ayırmanız gerekir. Ama bu durumda maliyet üstel olarak artar.

  • Maliyet meselesiyse, workflow oturduktan sonra daha ucuz LLM’ler kullanılabilir (işletim maliyeti yine pahalı olsa da). Fine-tuning, prompt optimizasyonu, özel distillation teknikleri gibi yöntemlerle maliyet düşürülebilir. Bu alanda zaten çok fazla araştırma yapılıyor.

  • CLAUDE.md içine ne koymanın iyi olacağını merak ediyorum.

• Sayfanın altındaki örnek projelere bakınca, çoğunun tek ve belirli bir amaca optimize edilmiş yazılımlar olduğunu görüyorum. İleride açık kaynak projelerin de böyle, tek kişinin ihtiyacını karşılayan son derece özelleşmiş biçimlere evrileceğini düşünüyorum. Bu tür yazılımların (utility’lerin) LLM’in tek seferde ürettiği tüketilebilir kodlara dönüşeceğini hissediyorum.

• Claude Code’a yaklaşımım sürekli değişiyor. Şirketin büyük web uygulamasına Claude Code ile doğrudan anlamlı özellikler katkı olarak eklemekte hâlâ başarılı olamadım. Spesifikasyon bir yere kadar yardımcı oluyor ama sonunda akış tuhaf yönlere kayıyor ve yanlış seçimlerin tekrarlandığı bir döngüye giriyor. Bu Claude’un sınırı da olabilir, benim spesifikasyonumun hâlâ yeterince kesin olmaması da. Çok denedim ama “zorlayıcı olan” ya da “çok fazla alan uzmanlığı gerektiren” işlerde başarısızlık çok olduğu için artık pek denemiyorum. Bunun yerine, bir arkadaşımın tavsiyesiyle zihinsel yükü neredeyse olmayan backlog işlerinde Claude kullanmaya başladım. Mesela çok da bağ kurmadığım bir Playwright test setini yeni bir workspace’te oluşturtmayı denedim. Son derece başarılıydı. Kullanıcı deneyimini bir insana anlatır gibi Claude’a anlattım ve dev server yolunu verdim. Playwright MCP kullanarak hangi feature’ın nasıl kullanılacağını bulmasını, çalışma sürecini belgelemesini, testleri yazmasını ve hataları debug etmesini istedim. Projedeki UI kodunu tarayıp data-testid selector’ları ekleme işini de buna dahil ettim. Tüm süreci ana task.md içinde topladım ve her feature için ayrı task markdown dosyaları da oluşturmasını istedim. Bu yaklaşım çok etkili oldu. Hatta iki tarayıcı kullanıcısının sezgisel olmayan şekilde etkileştiği karmaşık bir feature’da da kullandım; %100 doğru değildi ama ne kadar karmaşıksa o kadar fazla bağlam düzeltmesi ve kod düzeltmesi gerekti. Yine de genel olarak günler sürecek can sıkıcı işleri tek seferde halletti.

• CLAUDE.md’yi mümkün olduğunca 100 satırın altında, minimal bir dosya olarak tutmak en iyisiydi.

  • projenin temel bağlamı ve amacının kısa özeti
  • type, interface ve helper’ları anlamaya yetecek kadar asgari proje yapısı açıklaması
  • package.json’ı tekrar tekrar parse etmeye gerek bırakmayacak temel komutlar Uygulama/test akışında deneyimlediğim kadarıyla Claude bazen tüm testleri en baştan bir kerede yazmaya çalışıyor ya da sadece import başarısız olunca her şeyi birden implemente ediyor (yani TDD’ye uygun değil). Bu yüzden TDD-Guard diye bir hook yaptım; böylece bir seferde yalnızca tek bir testin geçmesine, testin doğru nedenle fail etmesine ve testi geçirecek minimum kodun yazılmasına zorladım. Kod kalitesinde ise husky, lint-staged, commitlint gibi araçları otomatikleştirerek çok iyi sonuç aldım. Böylece daha önemli bilgiler için context alanı açılabiliyor. Claude Code tıkandığında en iyi yöntemin sonunda geliştiricinin doğrudan devreye girmesi olduğuna katılıyorum. Yine de işin sadece çok genel tavsiyelerde kalması biraz yetersiz geliyor.
  • Otomasyon yaklaşımıyla ilgileniyorsanız:
    • tdd-guard ve örnek kurulum
    • husky
    • commitlint
    • lint-staged

• Bir aydan uzun süredir her gün Claude Code ile çalışıyorum. Cursor, Q ve başka şeyler denedim ama Claude Code çok daha iyi. Yazıda geçen ipuçları, benim zamanla fark ettiklerimle büyük ölçüde örtüşüyor.
  Birkaç ek düşünce paylaşayım:

  • Web konsolunda önce Claude ile fikir oturumları yaparak başlıyorum. Projenin hedefini anlatıyor, alan modellemesini ve kilometre taşlarını geniş çerçevede planlıyorum. Küçük projelerde bunu birkaç saatlik gidip gelmeli tartışmalarla netleştiriyorum. İlk CLAUDE.md sürümü de burada ortaya çıkıyor.

  • Asıl projeye başlarken Claude hem benim global CLAUDE.md dosyamı hem de projeye özel CLAUDE.md dosyasını okuyarak başlıyor. Her oturumda bu şekilde.

  • Süreç içinde de Claude Code’a proje CLAUDE.md dosyasını sürekli güncelletiyorum. Planı takip ederken ilerleme durumunu işaretliyor, oturum sonunda proje özeti, nasıl çalıştığı, kod içinde nasıl gezinileceği gibi şeyleri yazdırıyorum. Bir tür uzun vadeli hafıza görevi görüyor. Oldukça işe yaradı.

  • Rehber ne kadar iyi olursa olsun, Claude’un önden gitme eğilimi var. Bu yüzden benim aktif katkıda bulunduğum işlerde onu mutlaka küçük increment’lerle, adım adım odaklı tutuyorum. Sadece tek seferlik ya da prototip işlerde ise istediği gibi uygulamasına izin veriyorum.

    • $20’lık aboneliğin Cursor’a kıyasla fiyat/performans açısından iyi olup olmadığını merak ediyorum. Her gün kullanmak gerekir mi, gerçekten değiyor mu bilmek istiyorum.

• Proje seviyesindeki CLAUDE.md dosyasını çok uzatmadan kısa ve öz tutmak iyi oluyor. Daha ayrıntılı içerikse alt klasörlere taşınmalı. En üst seviye dosya bir tür harita işlevi görüyor. Her yeni feature planlandığında Claude uygun klasörlere bakıp gereken context’i referans alıyor ve adım adım bir uygulama planı çıkarıyor. Her adımın sonunda da Claude’a yeni context’e göre uygulama planını güncelletiyorum. Böylece context bir sonraki adıma doğal biçimde aktarılıyor ve pencere de sıfırlanarak sonraki aşamaya temiz bir başlangıç yapılabiliyor.

• Claude Code ile Factorio benzeri bir ASCII oyun yapıyorum. İlk başta neredeyse hiç denetim olmadan kod yazmasına izin verdim ve ana özelliklerin çoğunu (save/load, options, debug, map generation, inşa, belt, crafting, QoL vb.) tek seferde yaptı. Ama detayları düzeltmeye kalkınca, örneğin hareketi değiştirince bantlar bozuluyor gibi, başka şeyler de sürekli kırılmaya başladı. Bunun üzerine Playwright otomasyonu eklettim ama testlerin kalitesi düşüktü ve her yerde sleep çağrıları vardı. Koda yakından bakınca yapının React frontend ve useEffect üzerine kurulduğunu gördüm; yani düzgün bir oyun motoru mimarisi yoktu. Hook kurallarına çok iyi uymuyor, zamanlama mantığını da iyi kavramıyordu. Bu yüzden şimdi tick tabanlı bir oyun motoru getirip en baştan yeniden yapmaya başladım ve code review de ekledim. İlerleme daha yavaş ama çok daha sağlam gidiyor. İyi bir demo tamamlayabilirsem Show HN’de paylaşmayı planlıyorum.

  • İlk temel iskelet oturana kadar insanın doğrudan katkısı gerçekten çok değerli. Bir refactor turu geçtikten sonra biraz daha rahat olunabiliyor.

• Benim gibi Claude’un iş ve kişisel aboneliklerini birden kullanan biri varsa, alias claude-personal="CLAUDE_CONFIG_DIR=~/.claude-personal claude" gibi bir yöntemle hesap geçişini kolaylaştırabilir.
  Birden fazla Claude hesabını verimli kullanma blogu

• Herkes “önceden net bir spesifikasyon yazıp context vermek asıl mesele” diyor ama benim deneyimime göre bu her zaman işe yaramıyor. Gerçek bir uzmanla birlikte oturup Opus 4 ve Sonnet 4 ile CC oturumu yaptım; karşı taraf çok net bir spec hazırlamıştı ama sonuç, benim yöntemimden çok daha iyi değildi. Benim yöntemim ise aklıma geldikçe feature istemek, CLAUDE.md olmadan her seferinde o anın context’iyle doğrudan talimat vermek şeklinde. Spesifikasyon tabanlı workflow önemli şeyleri sürekli unutuyor, context belgesinde olmayan şeyleri uyduruyor (hatta bazen açıkça yasak olanları bile). Buna karşılık ben mesela “invoice için bir CRUD sayfası ekle, önce codebase’i analiz et” gibi doğrudan komutlar vermenin daha iyi sonuç verdiğini gördüm. Bu sadece benim deneyimsel bir gözlemim ama Claude ile 100’den fazla proje yapmış biri olarak, Claude’un haddini aşmasını engelleyen özel hook’lar dışında belirli bir yöntemin daha iyi olduğuna kesin kanaat getiremiyorum. Birçok kişi “spec tabanlı daha iyi” diyor ama gerçekten göstermeleri istendiğinde, bariz yanlışları düzeltmek için gereksiz derecede çok zaman harcadıkları durumlara sık sık rastladım. Hatta CLAUDE.md içine “şunu asla yapma” diye yazsanız bile, Claude’un yine de bunu yapma eğilimi vardı.