Büyük Kod Tabanlarında Claude Code Nasıl Çalışır: En İyi Uygulamalar ve Nereden Başlamalı

• Claude Code, bir indeks yüklemeden geliştirici makinesinde dosya sistemi keşfi yaparak ve grep, referans takibi ile canlı kod tabanını doğrudan okur
• Performans yalnızca modele değil, CLAUDE.md, hook'lar, skill'ler, plugin'ler ve MCP sunucularından oluşan harness ile bunun nasıl kurulduğuna büyük ölçüde bağlıdır
• Büyük depolarda ince ve katmanlı CLAUDE.md, alt dizinden başlama, kapsamı daraltılmış test/lint ve hariç tutma kuralları keşif verimliliğini artırır
• LSP entegrasyonu, metin araması yerine sembol tabanlı tanım ve referans takibi sağlayarak çok dilli ve büyük kod tabanlarında yanlış keşifleri azaltır
• Başarılı benimseme için ayarların her 3-6 ayda bir gözden geçirilmesi ve plugin, izin, kural yönetimini üstlenecek bir DRI veya agent manager gerekir

---

Claude Code büyük kod tabanlarında nasıl keşif yapar

• Claude Code, bir yazılım mühendisi gibi dosya sisteminde dolaşır, dosyaları okur, grep ile gerekenleri bulur ve kod tabanı genelindeki referansları takip eder
• Geliştirici makinesinde yerel olarak çalışır; kod tabanı indeksi oluşturup sürdürmeye veya bunu bir sunucuya yüklemeye gerek yoktur
• RAG tabanlı AI kodlama araçları tüm kod tabanını embedding'e dönüştürüp sorgu anında ilgili parçaları getirir; ancak büyük ortamlarda embedding hattı yoğun geliştirme hızına yetişemeyebilir
• İndeks birkaç hafta, gün ya da saat öncesini yansıtıyorsa, adı çoktan değişmiş bir fonksiyonu veya geçen sprintte silinmiş bir modülü döndürebilir; üstelik bu bilginin eski olduğuna dair hiçbir sinyal olmayabilir
• Claude Code'un ajanik araması, embedding hattı veya merkezi bir indeks olmadan her geliştirici örneğinin canlı kod tabanı üzerinde çalışmasını sağlar
• Bunun bir dezavantajı da vardır: Claude, nereye bakması gerektiğini anlayabileceği kadar başlangıç bağlamı olduğunda en iyi sonucu verir
• Belirsiz bir desenin tüm örneklerini milyarlarca satırlık bir kod tabanında bulması istenirse, iş daha başlamadan bağlam penceresi sınırına çarpabilir
• Kod tabanını iyi yapılandıran ve bağlamı CLAUDE.md dosyaları ile skill'ler üzerinden katmanlayan ekipler daha iyi sonuç alır

Model kadar önemli olan harness

• Claude Code'un performansı, modelin kendisinden çok modelin etrafına kurulan harness tarafından belirlenir
• Harness, beş genişleme noktasından oluşur: CLAUDE.md, hooks, skills, plugins ve MCP sunucuları
• Her katman bir öncekisinin üzerine kurulduğu için, ekibin bunları inşa etme sırası da önemlidir
• LSP entegrasyonu ve subagent'lar bu kurulumun üzerine eklenen tamamlayıcı yetenekler olarak çalışır

• CLAUDE.md dosyaları

  • CLAUDE.md, Claude'un her oturumun başında otomatik olarak okuduğu bir bağlam dosyasıdır
  • Kök dosya genel resmi taşır; alt dizin dosyaları ise yerel kuralları barındırır
  • Her oturumda yüklendiği için performans kaybını önlemek adına geniş kapsamda geçerli olan bilgilere odaklanmalıdır

• Hooks

  • Hooks, Claude'un hatalı davranışlarını engelleyen betiklerden ibaret değildir; asıl değerleri yapılandırmayı sürekli iyileştirmede ortaya çıkar
  • stop hook, oturumda olanları geriye dönük inceleyip bağlam hâlâ tazeyken CLAUDE.md güncellemeleri önerebilir
  • start hook, ekibe özgü bağlamı dinamik olarak yükleyerek geliştiricinin manuel ayar yapmadan kendi modülüne uygun yapılandırmayı almasını sağlar
  • Lint ve formatlama gibi otomatik kontroller, Claude'un talimatları hatırlamasını beklemektense kuralları hook ile deterministik biçimde zorunlu kıldığınızda daha tutarlı sonuç verir

• Skills

  • Skills, her oturumu şişirmeden gerekli uzmanlığı istek üzerine kullanılabilir halde tutar
  • Büyük bir kod tabanında düzinelerce iş türü olabilir; ancak her uzmanlığın her oturumda bulunması gerekmez
  • Skills, kademeli ifşa (progressive disclosure) yaklaşımıyla uzman iş akışlarını ve alan bilgisini bağlam alanının dışında tutar, yalnızca gerektiğinde yükler
  • Örneğin bir güvenlik inceleme skill'i, Claude zafiyetleri değerlendirirken yüklenir; bir dokümantasyon işleme skill'i ise kod değişikliğinden sonra belgelerin güncellenmesi gerektiğinde devreye girer
  • Skills belirli yollara kapsamlandırılabilir; böylece ödeme servis ekibinin dağıtım skill'i yalnızca ilgili dizine bağlanır ve monorepo'nun diğer bölümlerinde çalışırken otomatik yüklenmez

• Plugins

  • Plugins, iyi çalışan yapılandırmaların örtük bilgi olarak kalmamasını sağlayan dağıtım aracıdır
  • Bir plugin, skill'leri, hook'ları ve MCP ayarlarını tek bir kurulabilir paket içinde toplar
  • Yeni bir mühendis ilk gün plugin'i kurduğunda, Claude'u daha önce kullanan kişilerle aynı bağlam ve yeteneklere anında sahip olur
  • Plugin güncellemeleri, managed marketplaces üzerinden tüm organizasyona dağıtılabilir
  • Büyük bir perakende organizasyonu, Claude'u dahili analiz platformuna bağlayan bir skill geliştirdi; böylece iş analistleri iş akışını terk etmeden performans verilerini çekebildi ve bunu şirket geneline açmadan önce plugin olarak dağıttı

• Language Server Protocol entegrasyonu

  • Language Server Protocol (LSP) entegrasyonu, Claude'a geliştiricinin IDE'sindekine benzer kod gezintisi yetenekleri kazandırır
  • Büyük kod tabanları için kullanılan çoğu IDE, zaten “go to definition” ve “find all references” özelliklerini çalıştıran bir LSP kullanır
  • Bunu Claude'a açtığınızda, fonksiyon çağrılarını tanımlarına kadar takip edebilir, dosyalar genelindeki referansları izleyebilir ve farklı dillerde aynı ada sahip fonksiyonları ayırt edebilecek sembol düzeyi hassasiyet elde edersiniz
  • LSP olmadan Claude metin desen eşleştirmesine dayanır ve yanlış sembole gidebilir
  • Bir kurumsal yazılım şirketi, büyük ölçekte C ve C++ keşfini kararlı hale getirmek için Claude Code dağıtımından önce organizasyon genelinde LSP entegrasyonu sundu
  • Çok dilli kod tabanlarında yapılabilecek en değerli yatırımlardan biridir

• MCP sunucuları

  • MCP sunucuları, Claude'u doğrudan erişemediği dahili araçlara, veri kaynaklarına ve API'lere bağlamanın yoludur
  • En olgun ekipler, Claude'un doğrudan çağırabileceği araçlar olarak yapılandırılmış aramayı sunan MCP sunucuları kurar
  • Diğer ekipler, Claude'u dahili dokümantasyon, bilet sistemleri ve analiz platformlarına bağlar

• Subagents

  • Subagents, keşif ile düzenlemeyi birbirinden ayırır
  • Bir subagent, kendi bağlam penceresine sahip yalıtılmış bir Claude örneğidir; işi alır, tamamlar ve yalnızca nihai sonucu ana ajana geri döndürür
  • Harness kurulduktan sonra bazı ekipler, alt sistemleri haritalandıran ve sonucu dosyaya yazan salt okunur subagent'lar çalıştırıyor; ardından ana ajan bu genel resme dayanarak düzenleme yapıyor

• Bileşenlerin rolleri ve sık karıştırılan noktalar

  • CLAUDE.md: Claude'un otomatik okuduğu bağlam dosyasıdır ve tüm oturumlara yüklenir. Projeye özgü kurallar ve kod tabanı bilgisi için uygundur; ancak yeniden kullanılabilir uzmanlığın skill'e konması gerekirken kolayca buraya doldurulabilir
  • Hooks: Temel anlarda çalışan ve olaylarla tetiklenen betiklerdir. Tutarlı davranış otomasyonu ve oturum öğrenimlerini yakalamak için uygundur; ancak otomatik çalışması gereken işler kolayca prompt'larla çözülmeye çalışılır
  • Skills: Belirli iş türleri için paketlenmiş talimatlardır ve yalnızca ilgili olduklarında istek üzerine yüklenirler. Oturumlar ve projeler boyunca yeniden kullanılacak uzmanlık için uygundur; ancak her şeyi CLAUDE.md içine koymak kolaydır
  • Plugins: Skill, hook ve MCP ayar demetleridir; yapılandırmadan sonra her zaman kullanılabilirler. Organizasyon genelinde işe yarayan kurulumları dağıtmak için uygundur; ancak iyi ayarlar kolayca örtük bilgi olarak kalabilir
  • LSP: Dile özgü sunucular aracılığıyla gerçek zamanlı kod zekâsıdır ve yapılandırıldıktan sonra her zaman kullanılabilir. Tipli dillerde sembol düzeyinde keşif ve otomatik hata algılama için uygundur; ancak çoğu zaman bunun kendiliğinden olacağı varsayılır
  • MCP sunucuları: Harici araç ve verilerle bağlantıdır; yapılandırıldıktan sonra her zaman kullanılabilir. Claude'un doğrudan erişemediği dahili araçlara ulaşmak için uygundur; ancak temel kurulum çalışmadan önce MCP bağlantıları kurmaya başlanması kolaydır
  • Subagents: Belirli görevler için ayrı Claude örnekleridir ve çağrıldıklarında çalışırlar. Keşif ile düzenlemeyi ayırmak ve paralel çalışma için uygundur; ancak keşif ve düzenleme aynı oturumda yapılmaya çalışılır
  • LSP'ye plugin katmanı üzerinden erişilir; subagent'lar ise yapılandırılmış bir genişleme noktası değil, bir delege etme yeteneğidir

Başarılı dağıtımlarda tekrar eden üç yapılandırma deseni

• Büyük ölçekte de keşfedilebilir bir kod tabanı oluşturmak

  • Claude'un büyük kod tabanlarında ne kadar yardımcı olabileceği, doğru bağlamı bulma yeteneğiyle sınırlıdır
  • Her oturumda çok fazla bağlam yüklemek performansı düşürür; çok az bağlam ise Claude'un körlemesine keşif yapmasına yol açar
  • Etkili dağıtımlar, erken aşamada kod tabanını Claude'un okuyabileceği hale getirmeye yatırım yapar

  • CLAUDE.md dosyalarını ince ve katmanlı tutun

    • Claude, kod tabanında ilerlerken CLAUDE.md dosyalarını eklemeli olarak yükler
    • Kök dosya genel çerçeveyi, alt dizin dosyaları ise yerel kuralları taşır
    • Kök dosya yalnızca yönlendirmeleri ve kritik uyarıları içermelidir; geri kalan her şey kolayca gürültüye dönüşür

  • Depo kökünden değil, alt dizinden başlayın

    • Claude, kapsam göreve gerçekten ilgili olan kod tabanı bölümüyle sınırlandığında en iyi çalışır
    • Monorepo'larda bu ters sezgisel gelebilir; çünkü araçlar çoğu zaman köke erişimi varsayar
    • Claude dizin ağacında otomatik olarak yukarı çıkar ve bulduğu tüm CLAUDE.md dosyalarını yükler; dolayısıyla kök düzeyindeki bağlam kaybolmaz

  • Test ve lint komutlarını alt dizin bazında kapsamlandırın

    • Claude yalnızca tek bir servisi değiştirdiği halde tüm test paketini çalıştırırsa timeout yaşanır ve ilgisiz çıktılar bağlamı tüketir
    • Alt dizinlerdeki CLAUDE.md dosyaları, kod tabanının o bölümüne uygulanacak komutları açıkça belirtmelidir
    • Bu yaklaşım, her dizinin kendi test ve build komutlarına sahip olduğu servis odaklı kod tabanlarında iyi çalışır
    • Derin çapraz dizin bağımlılıkları olan derlenen dil monorepo'larında alt dizin bazlı kapsamlandırma daha zordur ve projeye özgü build ayarları gerektirebilir

  • Oluşturulan dosyaları, build çıktıları ve üçüncü taraf kodu .ignore dosyalarıyla hariç tutun

    • .claude/settings.json içine permissions.deny kuralları commit edilirse, hariç tutma kuralları sürüm kontrolüne alınmış olur
    • Ekipteki tüm geliştiriciler ek ayar yapmadan aynı gürültü azaltımından faydalanır
    • Bazı kod tabanlarında oluşturulan dosyaların kendisi de geliştirme hedefi olabilir
    • Kod üreticileriyle çalışan geliştiriciler, proje düzeyindeki hariç tutma kurallarını yerel ayarlarında geçersiz kılabilir; bu da ekibin geri kalanını etkilemez

  • Dizin yapısı yetmiyorsa kod tabanı haritası oluşturun

    • Kodun tipik dizin yapısı içinde toplanmadığı organizasyonlarda, kökteki hafif bir Markdown dosyası işe yarar
    • Her üst düzey klasör ve içeriği için tek satırlık açıklamalar eklemek, Claude'un dosya açmadan önce göz gezdirebileceği bir içindekiler tablosu oluşturur
    • Yüzlerce üst düzey klasör varsa, kök dosya yalnızca en üst düzey yapıyı açıklamalı; alt dizin CLAUDE.md dosyaları ise bir sonraki ayrıntı seviyesini istek üzerine sunmalıdır
    • Daha basit durumlarda, Claude'un başvurması gereken belirli dosya veya dizinleri @ ile anmak da aynı işlevi görebilir

  • Dize yerine sembol bazlı arama için LSP sunucuları kullanın

    • Büyük kod tabanlarında yaygın bir fonksiyon adını grep ile ararsanız binlerce eşleşme çıkabilir ve Claude neyin önemli olduğunu anlamak için dosyaları açıp bağlam tüketir
    • LSP yalnızca aynı sembole işaret eden referansları döndürür; böylece Claude daha hiçbir şey okumadan filtreleme yapılmış olur
    • Bunu kurmak için dile uygun code intelligence plugin ile ilgili language server ikilisinin kurulması gerekir
    • Claude Code belgelerinde kullanılabilir plugin'ler ve sorun giderme yöntemleri yer alır

  • İstisnalar

    • Katmanlı CLAUDE.md yaklaşımının da bozulduğu uç durumlar vardır
    • Yüz binlerce klasör ve milyonlarca dosya içeren kod tabanları ile Git dışı sürüm kontrolünde bulunan legacy sistemler buna örnektir

• Model zekâsındaki değişime göre CLAUDE.md dosyalarının bakımını yapmak

  • Modeller geliştikçe, bugünkü model için yazdığınız talimatlar gelecekteki model için engel haline gelebilir
  • Geçmişte Claude'un zorlandığı desenleri yönlendiren CLAUDE.md kuralları, yeni modellerde gereksizleşebilir veya hatta kısıtlayıcı olabilir
  • Örneğin tüm refactor işlemlerinin tek dosyalık değişikliklere bölünmesini zorunlu kılan bir kural, eski modellerin akışı korumasına yardımcı olmuş olabilir; ancak yeni modelin iyi yapabildiği koordineli çok dosyalı düzenlemeleri engelleyebilir
  • Model muhakemesi ya da Claude Code araçlarının belirli sınırlamalarını telafi etmek için oluşturulan skill ve hook'lar, o sınırlamalar ortadan kalktığında ek yüke dönüşür
  • Perforce kod tabanında p4 edit zorlamak için dosya yazmayı yakalayan bir hook, Claude Code yerel Perforce modu ekledikten sonra gereksiz hale gelir
  • Ekipler her 3-6 ayda bir anlamlı bir yapılandırma gözden geçirmesi beklemelidir
  • Büyük model sürümlerinden sonra performansın durağanlaştığı hissediliyorsa da ayarları gözden geçirmek değerlidir

• Claude Code yönetimi ve benimsenmesi için sahiplik atamak

  • Yalnızca teknik kurulum, benimsenmenin gerçekleşmesini sağlamaz
  • En hızlı yayılan dağıtımlarda, geniş erişim verilmeden önce altyapı yatırımı yapılmıştı
  • Küçük bir ekip, bazen tek bir kişi, araçları birbirine bağlayarak geliştiricinin Claude ile ilk karşılaşmasında her şeyin iş akışına uygun çalışmasını sağladı
  • Bir şirkette birkaç mühendis, ilk günden kullanılabilecek bir plugin ve MCP paketi oluşturdu
  • Başka bir şirkette ise AI kodlama araçlarının yönetimine adanmış bir ekip, dağıtımdan önce altyapıyı hazırladı
  • Bu iş genellikle yeni mühendislerin onboarding'inden ve geliştirici araçlarının inşasından sorumlu geliştirici deneyimi veya geliştirici verimliliği organizasyonunun altında yer alır
  • Birçok organizasyonda Claude Code ekosistemini yöneten hibrit PM/mühendis rolü olan bir agent manager ortaya çıkıyor
  • Adanmış bir ekip yoksa, minimum uygulanabilir model tek bir DRI'dır
  • Bu DRI; Claude Code yapılandırmasının, ayar kararlarının, izin politikalarının, plugin marketplace'inin ve CLAUDE.md kurallarının sahibi olmalı ve bunları güncel tutmaktan sorumlu olmalıdır
  • Aşağıdan yukarı benimseme heyecan yaratır; ancak işe yarayanları merkezileştirecek biri yoksa parçalanmaya yol açabilir
  • Standartlaştırılmış CLAUDE.md katmanları veya seçilmiş skill ve plugin'ler gibi Claude Code pratiklerini toplayıp yayacak bir kişi ya da ekip gerekir
  • Bu olmadan bilgi örtük kalır ve benimsenme duraklar

Yönetişim ve dağıtım

• Büyük organizasyonlarda, özellikle regülasyona tabi sektörlerde, yönetişim soruları erken aşamada ortaya çıkar
• Hangi skill ve plugin'lerin kullanılabileceğini kimin kontrol ettiği, binlerce mühendisin aynı şeyi birbirinden bağımsız yeniden üretmesinin nasıl önleneceği ve AI tarafından üretilen kodun insan yazımı kodla aynı inceleme sürecinden nasıl geçirileceği başlıca konulardır
• Başlangıçta onaylı skill'lerden oluşan tanımlı bir küme, zorunlu kod inceleme süreçleri ve sınırlı ilk erişimle başlayıp güven arttıkça ölçeklenen bir yaklaşım önerilir
• En sorunsuz dağıtımlar, erken aşamada mühendislik, bilgi güvenliği ve yönetişim temsilcilerinin birlikte yer aldığı çapraz fonksiyonlu bir çalışma grubu kuran ve gereksinimleriyle dağıtım yol haritasını birlikte tanımlayan organizasyonlarda görülür

Organizasyona uygularken varsayımlar ve sınırlamalar

• Claude Code, mühendislerin ana kod tabanı katkıcıları olduğu, deponun Git kullandığı ve kodun standart dizin yapısını izlediği geleneksel yazılım mühendisliği ortamları merkez alınarak tasarlanmıştır
• Büyük kod tabanlarının çoğu bu çerçeveye uysa da, büyük ikili varlıklara sahip oyun motorları, geleneksel olmayan sürüm kontrol ortamları ve mühendis olmayan kişilerin de kod tabanına katkı verdiği ortamlar ek yapılandırma çalışması gerektirir
• Sunulan desenler geleneksel kurulumları varsayar ve çeşitli müşteri ortamlarında çalışmıştır
• Kalan karmaşıklık, her organizasyonun kod tabanı, araçları ve organizasyon yapısına göre değerlendirilmelidir
• Anthropic'in Applied AI ekibi, bu desenleri organizasyonların somut ihtiyaçlarına uyarlamak için mühendislik ekipleriyle doğrudan çalışır

[GN⁺]

Hacker News yorumları

• Kod tabanını “bir yazılım mühendisi gibi” gezdiği ifadesiyle varılan sonuç birbiriyle çelişkili görünüyor
  Otomatik tamamlama ya da LSP’yi zaten hep kullanıyoruz ve bunlar faydalı; bunlar da bir tür indeks değil mi? Claude’un neden bunları kullanamadığı da soru işareti
  Yazılım mühendisleri bazen kod tabanını hatırlar da; bu da esasen RAG’e yakın bir şey ve otomatik tamamlanan CMD+P ile gereken dosyayı bulmaya yönelik ciddi bir kas hafızası da var
  Binlerce mühendisin aynı anda değiştirdiği tüm kod tabanı için gerçek zamanlı olması gerekmiyor; benim üzerinde çalıştığım branch’i iyi görmesi yeterli
  Kod tabanını en baştan dosya sistemini dolaşarak keşfetmek nadirdir; genelde ancak yeni bir kod tabanındayken yapılır, o durumda bile buna en iyi deneyim demek zor

  • Benim çalışma şeklimle birebir aynı
    LSP’nin olmadığı dönemlerden beri büyük kod tabanlarında gezinmeyi öğrendim ve uzun yıllar vim kullanıp ilgili dosyaları grep ile buldum
    Geçen yıl Claude Code’u ilk denediğimde “ne oluyor, tam da benim yapacağım şeyi yapıyor” diye hissetmiştim
  • Cevap yazının girişinde var
    Claude Code’un milyonlarca satırlık monorepo’larda, onlarca yıllık legacy sistemlerde, onlarca repoya yayılmış dağıtık mimarilerde çalıştırıldığı varsayılıyor
    Bu yüzden her yerde çalışan sağlam araçların kullanıldığı genel duruma göre optimize edilmiş; özellikle de büyük ve dağınık kod tabanlarında
    Ama iyi düzenlenmiş küçük bir repoda daha iyi araçlar kullanabileceğiniz ve kullanmanız gerektiği eleştirisi de doğru
    En azından Codex böyle çalışıyor; örneğin grep yapmadan önce go doc kullanıyor
  • Gerçekten büyük kod tabanlarında grep ve find zaman aşımına uğruyor
    O ölçekte çalışınca Claude’un aramayı mümkün kılmak için yapılmış araçları kullanmadığını hemen fark ediyorsunuz
  • Kısa bir paragraf içinde kulağa hoş gelen çok ifade var ama pratikte daha çok temennili bir iddia gibi duruyor
    “Bir yazılım mühendisi gibi” ifadesi sadece kısmen doğru
    İnsanlar da sembol araması kullanır ama belirli bir iş bağlamında zaten hatırladıkları sembolleri ararlar
    Claude Code’un şu an sembolleri körlemesine tarama biçimi, mühendislerin çalışma biçiminden farklı
    Tek bir yazım hatası yüzünden ajan bir şeyi yeniden uygulaması gerektiğine karar verebilir ve dosyayı şans eseri okusa bile kolayca halüsinasyona kapılabilir
    Bu, büyük kod tabanlarında çalışma şekli de değil
    Özellikle “grep ile tam olarak gereken şeyi bulur” kısmı takılıyor aklıma
    grep yapabilmek için neyi grep’leyeceğini bilmen gerekir ve binlerce sonuç çıkarsa hepsine bakman gerekir
    Böyle bir çıktı geldiğinde insanlar sonuçları körlemesine taramak yerine çıktıyı daraltmanın yollarını düşünür
    Yazıdaki yaklaşım sağlam bir öneriler bütünü olmaktan çok mevcut yöntemi gerekçelendiren bir açıklama gibi
    “Kod tabanı indeksine gerek yok” ifadesi teknik olarak doğru olabilir ama sadece grep-read-grep ile bağlamı şişire şişire sonunda bir noktada cevaba ulaşılır demek
    Bu da “Claude Code olmadan da geliştirici bunu elle yapabilir, öyleyse Claude Code’a gerek yok” demeye benziyor
    Bu “gerek yok” mesajının, kararı topluluğa mutlak bir ilke gibi sunduğu için sorunlu olduğunu düşünüyorum
    Genel olarak organizasyon maliyeti konusunda dürüst
    Birçok organizasyonda Claude Code ekosistemini yönetmek için PM ile mühendisin karışımı olan “ajan yöneticisi” rolü ortaya çıkıyor ve ekiplerin her 3-6 ayda bir anlamlı yapılandırma gözden geçirmesi gerektiği söyleniyor
    Bu, önceden kurulmuş bir kod zekâsı katmanı olmadan büyük ölçekli Claude Code kullanmanın gerçeğini doğru yansıtıyor
    Yön doğru seçilmiş ama yazıyı bitirince geride “sorunu çözemedik ve sınırımız burası” hissi kalıyor
  • Kod tabanının bir kısmını sıfırdan keşfediyor olsan bile hiç değişmeyen bölümler var; bunları her seferinde keşfetmek büyük bir token israfı
    Claude’la sık sık tartıştığım konulardan biri de daha az keşif yapmasını sağlamaya çalışmak
    Neredeyse hiç değişmeyen şeyleri yavaş ve pahalı bir yöntemle taramaktansa ben onları daha iyi biliyorum ve daha hızlıyım
    Ama her seferinde aynı tür tavşan deliğine giriyor

• Bir anekdot olarak, LLM onboarding ve orkestrasyon için bir proje tasarlıyordum; Claude ise her dosyanın sadece ilk 40 satırını okumayı seçti
  Daha sonra başka bir oturumda düşük kalitenin nedenini arayan Claude bu kusuru fark etti ve doküman satırlarıyla fonksiyon imzalarının giriş/çıkışlarını girdi olarak kullanan bir AST analizi yapacak şekilde kodu değiştirdi
  Claude’un ilk yaklaşımı gerçekten çok kötüydü
  Claude Code’un ne kadar çok düzeltilip gözden geçirilmesi gerektiğinde iyi hale gelebileceği ya da en baştan iyi kod üretip üretemeyeceği konusunda şüpheliyim
  Genellersek, Claude “sadece ilk 40 satırı oku” gibi yerel ve tanımlanabilir kötü kararları düzeltebilir
  Çünkü kusur ayrıştırılmıştır ve tek bir kod parçasına kadar izlenebilir
  Ama gerçek yazılım kalite sorunları çoğu zaman, tek tek bakıldığında makul duran küçük kararların birleşip kötü bir sonuç üretmesinden oluşur
  O zaman bunların hiçbiri açık bir “kusur” değildir; dolayısıyla düşük kaliteli bileşenleri parça parça üreten bir araç, her parça tek başına kabul edilebilir göründüğü için iyi koda yakınsamayabilir

  • Bağlamı korumak için kaynak koda dar bir delikten bakacak şekilde eğitilmiş gibi görünüyor
    Böyle durumlarda alt mantık ya da tam teşekküllü alt ajanlar iyi uyabilir
    Örneğin bir alt ajana “bu dosyayı gözden geçir ve özetle, X ve Y ile ilgili kısımları işaretle; ben de ana bağlamda bakayım” diyebilirsiniz
    Ayrıca ana iş akışını düzenli aralıklarla gözlemleyip, düşündüğü dosyanın içindeki bir şeyin mevcut işle ilgili ya da yön değiştirici olabileceğine karar verirse araya girmesini de sağlayabilirsiniz

• Claude Code büyük kod tabanlarında nasıl çalışıyor mu? Basit
  Küçük projelerde bile ilk prompt’ta 5 saatlik kullanım kotasının %35’ini yiyip bitiriyor; 5 dakika içinde hızlı cevap vermezse cache uçuyor ve bir sonraki prompt’ta yine %12-15 ödüyorum

  • Bağlantı verilen yazı bunu nasıl önleyeceğini anlatıyor
    Büyük bir kod tabanında naif biçimde serbest bırakırsanız, ararken çok token yakması normal

• Claude Code kod tabanını inceleyip etkili bir harness otomatik üretemez mi?
  CLAUDE.md, AGENTS.md, skills ve eklentiler tanımladım ama başkalarının anlattığı kadar fayda göremedim
  Mesela LSP eklentisi olsa bile Claude Code LSP’nin sembol yeniden adlandırma özelliğini kullanmıyor; dosyaları tek tek ve yavaş biçimde düzenliyor ya da prompt’ta belirli ipuçları olduğunda skill çağırması açıkça yazsa bile çağırmıyor
  Ben mi yanlış kullanıyorum? Kopyalayıp kullanılabilecek sağlam harness örnekleri var mı merak ediyorum

  • Bu, yıllardır süren bir acı noktası ve hâlâ hiç çözülmedi
    “A ise X yap. B, C, D yap. A yap.” desen de gidip X’i kullanmıyor
    Çünkü “unutuyor”
    Kural oluşturmaya harcadığınız zamanın gerçekten karşılığını verip vermeyeceğine güvenemiyorsunuz; hatta bir gün başarısız olacağına daha çok güvenebiliyorsunuz
    RAG, harness ve skills bunun hepsini düzelteceğini iddia etti ama pratikte düzeltemedi
  • /init kullanmayı ve kod tabanını açıklayan CLAUDE.md ya da AGENTS.md dosyaları tutmayı bıraktım
    Geriye yalnızca kod tabanının nasıl keşfedileceği ve araştırma yaparken git log kullanılması gerektiği kaldı; bunun bile muhtemelen tekrar olduğu söylenebilir
    Ben de cevabı bilmiyorum
    Üzerinde çalıştığım kod tabanı yaklaşık 100 bin satır; bu büyük sayılır mı bilmiyorum ama şahsen üzerinde çalıştığım en büyük repo
  • Bazı durumlarda script’e bağlı hooks’ların bağlam penceresine bilgi enjekte etmesi etkili görünüyor
    Bağlamı sınırlamak için gereksiz linter mesajlarının bir kısmını ayıklamak zorunda kaldım
    İşletim sisteminin paket deposundan kurulup script’ten çağrılabilen linter’lar ya da dile özel denetleyiciler de yardımcı olabilir
    Model ile skill bağlamının birleşimi de fark yaratabiliyor
    4.6’da “çalışan” bir skill 4.7’de o kadar iyi uymayabiliyor; 4.7 daha açık talimat istiyor ama 4.6’ya göre nispeten daha stabil
    Skill’i güncellemek de işe yarayabilir ve önce/sonra test ve çalıştırmaları karşılaştırmak gerekir
    Claude Code gereksiz araç çağrılarını da bağlama eklediği için, örneğin beads’i seviyorsanız işi bastırmanız gerekebilir

• Kod tabanı indeksleme konusundaki iddiaya katılmıyorum
  PHPStorm ya da diğer JetBrains IDE’lerinde indeksleme gayet iyi çalışıyor

  • PHPStorm indekslemesi harika
    Çok nadiren bozuldu ama düzeltmesi kolaydı ve hiç eski sonuç aldığıma rastlamadım
    Claude’un arama araçlarını kullandıysanız, o ekibin indeksleme hakkında hiçbir şey bilmediğine şaşırmazsınız
    Ana ürünü metin tabanlı sohbet olan bir şirketin, kullanıcıların o sohbet içinde metin aramasını kolay yapamaması anlaşılır gibi değil
  • Claude Code, JetBrains’in MCP’sini kullanarak o indeksi kullanabiliyor
  • Tuhaf bir iddia
    Yapay zekâ çöpü bir yazı mı bu? GitHub Copilot’un da oldukça iyi bir yerel indeksi var
    Kodu bir vektör veritabanına koymak o kadar zor bir problem değil

• Bu yazıyı kesin Claude yazmış
  Süsleme çok, gerçek içerik az

• C, C++, C#, Java, PHP gibi ekiplerin AI kodlama araçlarıyla sürekli yan yana düşünmediği dillerin de buna dahil olduğu ifadesi garip
  Claude Code’un bu dillerde iyi çalışmayacağını neden varsayalım ki? Hangi dili ima ediyorlar, Python ve JavaScript’i mi?

• Haftalar değil aylar ölçeğinde bile zeminin kaydığı bir sektörde, belirgin kalıpların ortaya çıkmasına yetecek kadar zaman geçtiği ve bu kalıpların büyük kod tabanlarında başarılı olduğu iddiası ilginç
  Başarı ölçütü ne? Üretim veritabanını silmemek mi, ekibin hızlanması mı, kod tabanının ömrünün uzaması mı, operasyon ekibinin daha mutlu olması mı?

  • Eğer AI aracı yüzünden üretim veritabanı silindiyse, bu geliştiriciye üretim kaynaklarını silebilecek prod yetkisi vermiş olan kişinin ve organizasyonun başarısızlığıdır demeye devam edeceğim
    Bu seviyede sınırsız erişim verilmiş bir şirkette hiç çalışmadım

• Son zamanlardaki stresimin tamamı Claude Code’un talimatları izlememesinden geliyor ve kod tabanı büyüdükçe bu daha da kötüleşti
  Yanlış anlaşılmasın, Claude inanılmaz ve onu seviyorum
  Ama yalnızca Claude Code’u “işe alıp” kod tabanının bakımını yaptırmak ya da özellik ekletmek kesinlikle mümkün değil
  Geçmiş hatalara dair sürekli memory maddeleri ekliyorum ama önemli talimatları görmezden gelme sorunu hâlâ yaklaşık %90 olasılıkla yaşanıyor
  Bunu önlemenin tek yolu her işi başında bekleyip çıktıyı çok yoğun şekilde gözden geçirmek
  Claude Code dokümantasyon ve büyük kod tabanlarını anlamada mükemmel ama bütünü anlamayı gerektiren değişikliklerde zayıf
  Örneğin kod tabanı genelinde farklı entity’ler için kullanılan yaklaşık 10 adet registry pattern var; “şu tek registry pattern’i kullan” diye açık bir kural olmasına rağmen Claude Code her entity için bağımsız 4 ayrı registry yazdı
  Bu basit işi doğru yaptırmak için yarım gün boyunca neredeyse Claude Code’a bağırdım; sonunda stres ve zamandan tasarruf etmek için gidip kendim düzelttim

• Her CLAUDE.md dosyasına tam olarak ne girmesi gerektiğini somut terimlerle bile açıklamıyorlar; böyle dosyaların ne kadar önemli olduğunu bilmiyorum

  • Balık: Buradan okuyabilirsiniz https://code.claude.com/docs/en/best-practices#write-an-effe...
    Balık tutma yöntemi: 1) Resmi skill-creator kurulur 2) yukarıdaki bağlantı kullanılarak claude-md-improver oluşturulur 3) resmi belgelerde progressive-disclosure konusu araştırılıp skill iyileştirilir 4) yeni skill CLAUDE.md dosyasına uygulanır ve değişiklikler kabul edilir