- Gerçek açık kaynak depolarından 2.430 tanesi üzerinde Claude Code'un araç seçme eğilimlerini analiz eden araştırma sonuçları
- Toplam 20 kategorinin 12'sinde hazır araçlar yerine doğrudan geliştirme (Custom/DIY) yaklaşımı seçildi ve bu en sık görülen tercih türü oldu
- Buna karşılık araç seçerken GitHub Actions (%94), Stripe (%91), shadcn/ui (%90) gibi belirli seçeneklerde yüksek yoğunlaşma görüldü
- Dağıtım ortamları dile göre sabitlenmiş durumda; JS için varsayılan seçim Vercel, Python için Railway olurken AWS·GCP·Azure birincil tercihlerin dışında kaldı
- Daha yeni modellere gidildikçe Drizzle, FastAPI BackgroundTasks gibi yükselen araçlara geçiş eğilimi belirginleşiyor ve ekosistem içi seçim tutarlılığı %90 seviyesinde
Araştırmaya genel bakış
- Claude Code v2.1.39 kullanılarak toplam 2.430 deney yürütüldü; gerçek depolarda açık uçlu sorular üzerinden araç seçimleri gözlemlendi
- 3 model (Sonnet 4.5, Opus 4.5, Opus 4.6), 4 proje türü, 20 araç kategorisi
- %85,3 çıkarım oranı ile 2.073 geçerli yanıt elde edildi
- Modeller arasında %90 uyum oranı görüldü ve 20 kategorinin 18'inde aynı ekosistem içinde seçim tutarlılığı korundu
Temel bulgu: Build vs Buy
- 20 kategorinin 12'sinde Custom/DIY geliştirme en yaygın tercihti
- Toplam 252 Custom/DIY seçimi yapıldı; bu sayı tekil araçların her birinden daha fazla
- Örnek: feature flag'ler ortam değişkeni tabanlı yapılandırma dosyalarıyla kuruldu, Python kimlik doğrulaması JWT + passlib ile doğrudan yazıldı, önbellekleme için bellek içi TTL sarmalayıcısı kullanıldı
- Kategori bazında Custom/DIY oranları
- Feature Flags %69, Authentication(Python) %100, Authentication(genel) %48, Observability %22
Varsayılan yığın (Default Stack)
- Claude Code, fiilen araç seçerken JS ekosistemi merkezli bir varsayılan yığın oluşturuyor
- En üst sıralardaki araç seçimleri: Zustand (%64,8), Sentry (%63,1) vb.
- Bazı durumlarda JS ile ilgili seçimlerin %100'ü belirli bir araca yoğunlaşıyor
- Bu varsayılan yığın, çok sayıda yeni uygulamanın geliştirilmesini doğrudan etkiliyor
Pazarın ana akımına ters düşenler (Against the Grain)
- Pazar payı yüksek bazı araçlar arasında Claude Code'un neredeyse hiç kullanmadığı seçenekler var
- Durum yönetimi: ana tercih yok, bunun yerine Zustand 57 kez seçildi
- API Layer: framework içine gömülü routing tercih edildi
- Test: yalnızca %4 ana tercih, 31 vakada alternatif tercih
- Paket yöneticisi: 1 ana tercih, 51 alternatif tercih
Yeni modellerde araç değiştirme eğilimi (The Recency Gradient)
- Model ne kadar yeniyse, o kadar yeni araçlara geçiyor
- JS ORM: Prisma (%79) → Drizzle (%100)
- Python iş işleme: Celery (%100) → FastAPI BackgroundTasks (%44)
- Python önbellekleme: Redis (%93) → Custom/DIY (%50)
- Her ekosistem içinde nesiller arası araç değişimi açık biçimde gözlemleniyor
Dağıtım ortamlarının ayrışması (The Deployment Split)
- Dağıtım tercihleri dil yığınına göre sabit
- JS (Next.js + React SPA): 86 vakanın 86'sında Vercel seçildi
- Python (FastAPI): Railway %82 oranında seçildi
- AWS, GCP ve Azure toplam 112 vakanın hiçbirinde birincil tercih olmadı
- Alternatif öneriler olarak Netlify (67 kez), Cloudflare Pages (30 kez), GitHub Pages (26 kez), DigitalOcean (7 kez) öne çıktı
- AWS Amplify, Firebase Hosting vb. yalnızca anıldı, önerilmedi
- Örnek yanıtlarda Vercel için kurulum komutları ve gerekçeler sunulurken AWS Amplify tek satırlık bir anmayla sınırlı kaldı
Modellerin ayrıştığı alanlar (Where Models Disagree)
- 20 kategorinin 5'inde modeller arasında fark görüldü
- JS ORM: Prisma → Drizzle
- JS Jobs: BullMQ → Inngest
- Python Jobs: Celery → FastAPI BgTasks
- Caching: Redis → Custom/DIY
- Real-time: SSE → Custom/DIY
- Kalan 18 kategoride aynı ekosistem içinde tutarlı seçimler korundu
Kurumsal benchmark hizmeti
- Amplifying, bireysel geliştirici aracı şirketleri için özel bir dashboard sunuyor
- Yapay zeka ajanlarının kendi araçlarını rakiplere kıyasla ne ölçüde önerdiği görülebiliyor
- Gerçek kod tabanları üzerinden araç öneri rekabetçiliği analizi destekleniyor
Veri keşfi
- Ayrıntılı analiz başlıkları arasında kategori bazlı derin inceleme, ifade kararlılığı, depolar arası tutarlılık, pazar etkisi yer alıyor
- Araştırma sonuçlarının ileride Sonnet 4.6 modeli temel alınarak güncellenmesi planlanıyor
4 yorum
İlginç ama sanki sadece kendi token’larını daha çok kullanıp daha fazla ücret alan yöne evrilmişler gibi de geliyor; aslında belli ölçüde bazı kütüphaneler yapay zeka tarafından zaten öğrenilip öylece oluşturuluyor olabilir diye de düşünüyorum.
Ajan tercihleri nedeniyle yalnızca belirli kütüphanelerin gelişeceğini düşünmek de biraz tuhaf geliyor.
İlginç bir araştırma. Özellikle "Build vs Buy" kısmında 12/20 kategorinin DIY olması etkileyici.
Biz de AI ajan persona standardı (Soul Spec) oluştururken benzer bir gözlem yaptık; Claude Code’a
CLAUDE.mdya daAGENTS.mdile araçlar belirtilmezse, kendi yöntemiyle uygulama eğilimi oldukça güçlü oluyor.Bu araştırmadaki "Recency Gradient"in işaret ettiği şey, yeni bir aracın Claude’un varsayılan stack’ine girebilmesi için eğitim verisinde yeterince görünür olması ya da proje bağlamı dosyalarında açıkça belirtilmesi gerektiği gibi görünüyor. Sonuçta Context Engineering, araç seçimini bile belirliyor.
Orijinal veri setinin de açık olması güzel: https://github.com/amplifying-ai/claude-code-picks
Buna Assistive agent optimization (AAO) diyorlarmış.
Geliştirici araçları için artık ajanların tercih ettiği ürün olmak önemli hale geldi.
Ajan ondan hiç söz etmezse giderek uzaklaşılır
Hacker News yorumları
LLM reklamlarının geleceğinin tamamen görünmez hale gelmek olduğunu düşünüyorum
Sonuçta en güçlü türden bir ‘influencer’ haline gelmiş oluyor
Ya da bu reklam değil, bir çıkar çatışması (conflict of interest) meselesi olabilir
Örneğin Gemini’nin GCP tabanlı kurulumları daha fazla tercih edip etmediği buna işaret edebilir
Anthropic araştırması, SEO yerine LLM ürün görünürlüğünü hedeflemenin bir yolu olduğunu gösteriyor
Yaklaşık 6 ay beklersen tarayıcılar bunu toplayıp eğitim verisi olarak kullanıyor → sonunda kâr
Eğer Gemini kullanıyor olsalardı bunun olmayacağını düşünüyorum
Bu tam anlamıyla ‘Nudge’ kavramının nihai uygulaması
Gelecekte ajan tabanlı kodlama sistemleri ne inşa edeceklerine kendileri karar verecek ve insanlar seçenekleri hiç görmeden sadece sonucu alacak
Tedarik zincirlerini bile LLM’lerin belirlediği bir dünyaya gidebiliriz
Platform ‘rafı’ kontrol ediyor, sonra popüler SaaS özelliklerine bakıp kendi markasını çıkarıyor (ör. Great Value, Amazon Basics)
Vergi yazılımları bunun iyi bir örneği olabilir
İlginç olan şu ki, bu yazıda bahsedilen Claude Code’un web tarzı gerçekten de o blogda açıkça görünüyor
JetBrains Mono yazı tipi, Opus 4.6’nın ürettiği web sayfalarının ayırt edici özelliklerinden biri
Son bir ayda JetBrains Mono’yu aşırı kullanan web sayfalarının %99’undan fazlası büyük olasılıkla Opus ile üretildi
Opus 4.6, Drizzle’ı %32,5 oranında seçerken Prisma yalnızca %20,5’te kalıyor
Model ne kadar güçlüyse Prisma’yı o kadar az seçiyor gibi görünüyor — adeta bir zeka kıyaslaması gibi
Başka bir örnek olarak youjustneedpostgres.com da JetBrains Mono’yu gereğinden fazla kullanıyor
Kategori çubuğu tasarımı, dün dalgınlıkla ürettiğim UI ile neredeyse aynıydı
Kart tarzı CSS’in hepsi aynı hissi veriyor; bu blog da o şekilde yapılmış gibi
LLM’lere muğlak promptlar vermiyorum
Bunun yerine 2026’da LLM’lerden doğru bilgiyi nasıl çıkaracağımı yeniden öğreniyorum
2006’daki Google aramasını yeniden öğrenmek gibi hissettiriyor
Bir modelin diğer modelin hipotezini doğrulaması için ‘reverse prompt’ kullanıyorum
Örneğin Opus 4.6’nın sonucundan şüphe duyarsam bunu ChatGPT ya da Codex’e verip açıklarını bulmasını istiyorum
Claude nispeten daha az inatçı, ChatGPT ve Codex ise daha kararlı ama çoğu zaman daha doğru
Gerçekten de bir Docker konteyner sorununda Claude bunun ZFS bug’ı olduğunu söylemişti ama ChatGPT bunun basit bir yapılandırma hatası olduğunu söyledi ve doğru olan da buydu
Bu şekilde LLM’ler arası çapraz doğrulama ile doğru cevaba ulaşıyorum
O zaman gerçekten çok fazla soru soruyor
Ayrıntılı bir plan oluşana kadar sürekli revize ettiriyorum ve daha fazla gerekli soru sormasını sağlıyorum
ChatGPT aboneliğimde limite ulaşmıyorum ama bazen hata verdiğinde başka bir terminalde Claude’u açıyorum
Şirketin Claude bütçesi aylık 750 dolar olduğu için oldukça kısıtlıyız
AWS üzerinde TimescaleDB kullanıyorum
Claude Code, AWS CLI ile EC2 instance’larını yönetiyor
Ama bu sabah Claude bana NeonDB ve Fly.io hesabı açmayı önerdi
AWS tarafında her şey zaten düzgün kurulmuşken yeni servisler önermesi garip geldi
Benim deneyimime göre LLM ajanları mimari kararları berbat veriyor
Gereksiz soyutlamalara ve sürüm yönetimine takıntılı oluyorlar, kod da aşırı karmaşık hale geliyor
Sonunda kodu kendiniz yazmak zorunda kalıyorsunuz
Tüm projelerimde Planetscale kullanmama rağmen Claude bana Neon önerdi
Bu bana basit bir bug gibi görünüyor
Opus 4.6’nın ‘gelecek odaklı’ diye anılması ilginç
4.5’i bir ay kullandıktan sonra 4.6 ile yeni bir projeye başladım ve planlama aşamasında web araması yaptığını gördüm
Model yeterince gelişmiş olsa da, hâlâ asıl mesele koordinasyon ve rol paylaşımı
Eskiden GPT-3.5 ile bir Android uygulamasını gerçekten yayına almıştım (uygulama bağlantısı)
O zamanlar bir hafta süren işler şimdi tek bir prompt ile yapılabiliyor
LLM’leri iyi orkestre ederseniz sonuçları çok daha hızlı alabilirsiniz
LLM ile kod yazarken özellikle web tarafında fark ettiğim şey, npm paket bağımlılıklarının ne kadar azaldığı oldu
Eskiden jwt auth ya da build plugin gibi şeyler kullanırdım, şimdi bunların yerini birkaç satır kod alabiliyor
Kod daha basit ve anlaşılır olduğu için daha güvenilir geliyor
2010’da jQuery JS dünyasının kralıydı ama bugün saf JS çoğu şey için yeterli
Yine de JWT gibi güvenlikle ilgili kodlarda Claude’un yazdığını olduğu gibi kullanmazdım
Şimdi bazı şeyleri doğrudan kendin yazmak daha iyi olabilir
Kod tekrarları artar ama bağımlılık sorunları azalır
Claude’a her zaman hangi kütüphaneleri ve patentli teknolojileri kullanacağını açıkça belirtiyorum
Geliştiricinin modeli iyi yönlendirebilmesi gerektiğini düşünüyorum
Emin olmadığımda ayrı bir pencerede mimariyi ya da artı-eksi yönlerini sorup sonra karar veriyorum
Claude iki projede GitHub Actions’ı otomatik olarak ekledi
Ben istememiştim; üstelik gizli klasörde olduğu için git diff’te gözden kaçırdım
Neyse ki maliyeti 4 cent oldu ama oldukça rahatsız edici bir deneyimdi
Merak ettiğim bir şey var
Neden shadcn/ui bu kadar varsayılan bir UI kütüphanesi haline geldi?
Sadece Claude değil, diğer modeller de bunu varsayılan olarak kullanıyor
shadcn hariç tutulsaydı kalite ya da hız düşer miydi?
Bunun sebebi dokümantasyon ve örneklerin zenginliği mi, yoksa sadece eğitim verisinde aşırı sık geçmesi mi?
Ben de 2025 ortalarında Gemini’nin React dashboard’a varsayılan olarak shadcn koyduğunu görünce şaşırmıştım
shadcn/ui Tailwind tabanlı olduğu için AI bunu tercih ediyor
Gerçekten de npm indirme sayısı Aralık’tan sonra patladı
npm paket bağlantısı
Daha eski pek çok bileşen kütüphanesi varken bunun neden kazandığını bilimsel olarak analiz etmeye değer
Bileşenler tutarlı ve özelleştirmesi kolay, bu da projeye entegre etmeyi kolaylaştırıyor
Gerçekten çok iyi yapılmış bir proje
Artık shadcn’i varsayılan stiliyle kullanan bir site görünce bunun AI tarafından yapılmış bir web sitesi olduğuna dair bir işaret gibi geliyor
Tıpkı 10 yıl önce Bootstrap’te olduğu gibi, varsayılan stil fazla yaygın
Öyleyse bunu mutlaka AI izi olarak görmek gerekir mi?
“10 yıl önceki Bootstrap” benzetmesiyle tam olarak ne kastedildiğini merak ediyorum