Claude Code çerçeve savaşları
(shmck.substack.com)- Geliştiriciler artık yapay zekayla işbirliği yapma biçimini öğrenme aşamasında ve Claude’un değeri, basit bir sohbet botu değil bir çerçeve olarak kullanıldığında en üst düzeye çıkıyor
- Toplulukta Claude’un nasıl yapılandırılıp kullanılacağına dair çeşitli denemeler sürüyor; deneyler o kadar yoğun ki buna Claude Code Framework Wars deniyor
- Bunun sonucunda Claude’u proje yöneticisi, mimar, geliştirici, gözden geçiren gibi birden çok rolde kullanma yönünde bir akım oluşuyor
- Çerçeve tasarımında iş yönetimi, yönerge sağlama, ajan işbirliği, oturum yürütme, araç erişimi, kod geliştirme, teslimat, bağlamı koruma dahil 8 ana karar gerekiyor
- Temel ders, yapay zekanın geliştiricinin yerini alması değil; yapılandırılmış kurallar ve roller aracılığıyla üretkenliği katlayan bir ekip arkadaşı haline gelmesi
Giriş
- Temel fikir: Claude’u basit bir konuşma aracı değil bir çerçeve olarak görmek; açık kurallar ve iş akışlarıyla öngörülebilir ve değerli sonuçlar üretmek
- Geliştiriciler kod yazmaktan, yüksek katma değerli rollere (proje yönetimi, tasarım, mimari) kayıyor
- Claude Code çerçevesi, kod yazmadan yapılandırılmış prompt’larla çalışıyor
- Claude Code çerçeve savaşları: Geliştirici topluluğu, üretken yapay zeka kullanımını artırmak için farklı yaklaşımlar deniyor
- Onlarca açık kaynak proje, iş akışları ve rol yapılarını tanımlayarak yarışıyor
- Örnek: Agent OS, Claude-Flow
Çerçeve tasarlanırken dikkate alınması gereken başlıca seçenekler
1. İş yönetiminin yeri
- Claude’un başvurabileceği bir iş kaynağı tanımlamak gerekiyor
- Markdown backlog: İşleri Markdown biçiminde bir yapılacaklar listesi olarak yönetmek
- Örnek: Backlog.md, ReqText
- Yapılandırılmış metin: Ürün spesifikasyonlarını işlere dönüştürmek
- Örnek: Agent OS
- Issue/ticket: Spesifikasyonları GitHub Issues veya Jira ticket’larında saklayıp kod incelemesine bağlamak
- Örnek: ccpm
- Markdown backlog: İşleri Markdown biçiminde bir yapılacaklar listesi olarak yönetmek
- Öz: Görevler, Claude’un erişebildiği ve takip edebildiği bir yerde saklanmalı
2. Claude’a rehberlik nasıl verilir
- Belirsiz prompt’lar yerine Claude’a açık bir yapı ile yönerge vermek
- Komut kütüphanesi: /create-tasks, /review gibi önceden tanımlanmış slash komutları
- Kodlama standartları: Teknoloji yığını ve kodlama yönergelerini açıkça belirtmek
- Tamamlanma tanımı: Bir görevin tamamlandığını belirleyen ölçütleri kodlaştırmak
- Tetikleyici doğrulama hook’ları: Her değişiklikte linting ve testleri zorunlu kılmak
- Claude gözden geçireni: Claude’un hem geliştirme hem inceleme yapması
- Öz: Açık ve tekrarlanabilir kurallar, Claude’un iş kalitesini artırır
3. Ajan işbirliği yapısı
- Birden fazla Claude ajanı kullanıldığında bunları roller ve planlama ile koordine etmek
- Rol simülasyonu: Yapay zekanın PM, mimar, geliştirici, testçi rollerini üstlenmesi
- Örnek: Agent OS
- Swarm paralel işleme: Spesifikasyon → sözde kod → kod → test şeklindeki yapısal akışta çok sayıda ajanı aynı anda çalıştırmak
- Örnek: Claude-Flow
- Repository-native artifact’lar: Görevleri, log’ları ve mimari karar kayıtlarını (ADR) kod tabanında tutarak belleği sürdürmek
- Örnek: Roo Commander
- Rol simülasyonu: Yapay zekanın PM, mimar, geliştirici, testçi rollerini üstlenmesi
- Öz: Koordinasyon, çok sayıdaki yapay zeka çalışanının çakışmasını önler
4. Oturum yürütme biçimi
- Yapay zeka çıktısındaki karmaşayı önlemek için oturumları çalışma ortamı olarak tanımlamak
- Terminal orkestrasyonu: Claude’un komutları, pencereleri ve log’ları kontrol etmesi
- Örnek: Symphony, Claude-Squad
- Paralel worktree’ler: Git Worktrees ile birden fazla branch’i paralel yürütmek
- Örnek: Crystal
- Paralel container’lar: Claude’u bağımsız container’larda çalıştırarak çakışmaları önlemek
- Örnek: ClaudeBox
- Terminal orkestrasyonu: Claude’un komutları, pencereleri ve log’ları kontrol etmesi
- Öz: Paralel çalışma, çakışma olmadan üretkenliği en üst düzeye çıkarır
4. Oturum çalıştırma biçimi
- Yapay zeka çıktısındaki karmaşayı önlemek için oturumları çalışma ortamı olarak tanımlamak
- Terminal orkestrasyonu: Claude’un komutları, pencereleri ve log’ları kontrol etmesi
- Örnek: Symphony, Claude-Squad
- Paralel worktree’ler: Git Worktrees ile birden fazla branch’i paralel yürütmek
- Örnek: Crystal
- Paralel container’lar: Claude’u bağımsız container’larda çalıştırarak çakışmaları önlemek
- Örnek: ClaudeBox
- Terminal orkestrasyonu: Claude’un komutları, pencereleri ve log’ları kontrol etmesi
- Öz: Paralel çalışma, çakışma olmadan üretkenliği en üst düzeye çıkarır
5. Claude’un araç erişimi
- Claude’un tüm teknoloji yığınına dair bilgisini kullanabileceği şekilde ayarlamak
- MCP entegrasyonu: Tarayıcı, veritabanı, test runner ve UI otomasyon çerçevelerini bağlamak
- Özel araç kütüphanesi: Shell script’leri ve komutlarla oluşturmak
- Örnek: Symphony
- Veritabanı erişicileri: Güçlü veritabanı erişim araçları
- Örnek: Claudable with Supabase
- Test ve doğrulama hook’ları: İş tamamlanmadan önce Vitest, Jest vb. ile test çalıştırmak
- Örnek: Agent OS
- Öz: Araç entegrasyonu, Claude’u basit bir otomatik tamamlamadan aktif bir ekip üyesine dönüştürür
6. Kod geliştirme biçimi
- Claude, gereksinime göre farklı roller üstlenebilir
- Proje yöneticisi (PM): Ürün spesifikasyonlarını görevlere ve backlog’a dönüştürmek
- Mimar: Genel yapıyı tasarlamak, arayüzleri tanımlamak, kodlamadan önce kuralları belirlemek
- Uygulayıcı: Testlere ve standartlara göre kod yazmak
- QA: Görevlerdeki sorunları incelemek
- Örnek: BMAD-code
- Gözden geçiren: PR kalitesi, okunabilirlik ve risk denetimi yapmak
- Öz: Yazılım yaşam döngüsünün tamamında yapay zekadan yararlanmak
7. Kodun teslim edilme biçimi
- Kodun repository’ye nasıl ulaşacağını tanımlamak
- Öz: Üretim için güvenli iterasyonlar ya da prototip için scaffold yaklaşımı arasında seçim yapmak
8. Bağlamı koruma biçimi
- Claude’un unutkanlık sorununu çerçeve belleği ile çözmek
- Belgeler ve günlükler: CLAUDE.md, mimari notlar ve proje günlüklerini güncel tutmak
- Örnek: Claude Conductor
- Kalıcı bellek ve kontroller: Son çalışmaların özetini, proje sağlık kontrollerini ve kararları saklamak
- Örnek: Claude-Flow
- Belgeler ve günlükler: CLAUDE.md, mimari notlar ve proje günlüklerini güncel tutmak
- Öz: Bellek olmadan yapay zeka hataları tekrarlar; bellekle ilerleme birikir
Birleştirme yaklaşımı
- Bu seçenekleri bir menü gibi düşünmek; her şeyi bir anda kurmak gerekmez
- Başlangıç kurulumu: Markdown backlog + ticket farkları
- Yapılandırılmış ekip: Ürün spesifikasyonları + standartlar + rol simülasyonu
- Deney odaklı: Repository artifact’ları + paralel oturumlar
- Prototip modu: Uygulama oluşturucu + belge scaffold’u
Sonuç ve çıkarımlar
- Temel ders: Claude en iyi performansı yapılandırılmış ortamlarda gösteriyor
- Geliştiricinin rolünü değiştirmekten çok, boilerplate işleri azaltarak spesifikasyon tanımı, tasarım incelemesi ve mimari tanıma odaklanmayı sağlıyor
- İşler yanlış giderse hızla raydan çıkabilir; yapısal yönetim şart
- Şu an hâlâ erken aşamada olsa da çerçeveler, yapay zekayı bir sihirli kutu değil, yönetilebilir ekip üyeleri kümesi haline getiriyor
- Ne kadar çok yapı sağlanırsa o kadar fazla değer geri dönüyor
- Topluluk, açık kaynak projeler aracılığıyla farklı çerçeveler deniyor ve üretken yapay zekayı nasıl kullanacağını araştırıyor
- Geliştiriciler Claude’u sistemli biçimde kullanarak yüksek katma değerli işlere odaklanabilir ve yapay zekayı ekip üyesi olarak entegre edip üretkenliği en üst düzeye çıkarabilir
1 yorum
Hacker News görüşü
Claude Code için birkaç "framework" denedim ama nesnel olarak performansın arttığını pek söyleyemem.
Sanki karmaşık bir sürecin etrafına kurulmuş ritüellerden ibaret ve bunun gerçekten neden gerekli olduğu belirsiz.
Bu tür framework yaklaşımı, model eğitiminin amacıyla pek uyumlu gelmiyor.
Pratikte modele gereksiz bilgiler yükleyip onu "benim belirlediğim süreç"e uydurmaya çalışarak bağlamı kirletmiş oluyorsunuz.
Bağlam kirliliğini ortadan kaldırmak, yalnızca gerçek iş için gerekli bilgileri vermek ve kademeli olarak iyileştirmek önemli diye düşünüyorum.
Bu tür geleneksel işbirliği yöntemleri, bağlamı sınırlı ajanların bağlamı dışında yürütüldüğünde daha uygun bir yapı sunuyor.
Bu yazıda subagents'tan hiç bahsedilmemesi, bunun ne zaman yazıldığını merak ettirdi.
Ben "memory bank'ten yalnızca mevcut işle ilgili bilgileri getirme" ya da "testleri çalıştırıp sadece başarısızlıkları ve coverage'ı geri bildirme" gibi işleri subagent'lara devrediyorum.
Böylece ana ajanın bağlamının çok hızlı dolmasını engelleyebildim.
https://docs.anthropic.com/en/docs/claude-code/sub-agents
Dev containers ve worktrees gibi birkaç pratik uygulamayı devreye aldıktan sonra hayatım çok daha kolaylaştı.
Proje dosyalarını yönetmek ve worktree oluşturmak için kendi shell script "framework"ümü de yazdım; bu iş yaklaşık iki gün sürdü.
Belirli bir araca bağımlı olmamak özgürlük sağlıyor.
Bağlam kirliliğinin gerçekten dikkat edilmesi gereken bir sorun olduğuna katılıyorum.
Özellikle MCP endpoint tanımlarının bağlamımın önemli bir bölümünü (yaklaşık 20 bin token) kapladığını gördüğümden, MCP seçerken bağlam sorununu mutlaka hesaba katıyorum.
Bu bana gerçek bir proje yöneticisine oldukça benzer bir durummuş gibi geldi.
Benim istediğim şey, Claude'un teklif hazırlama sürecine önce belirsiz noktaları sorma aşamasını dahil etmesi.
Gerçek bir mühendise gereksinimleri ve beklenen çıktıyı verirseniz, uygulamaya geçmeden önce doğal olarak ek sorular sorup işi netleştirir.
Claude'un da bu doğrulama sürecini otomatikleştirebilmesini umuyorum.
Netleştirilmemiş soruları hiç hesaba katmadığı için pek çok hatanın ortaya çıktığını sık sık görüyorum.
Bu tür framework'leri kullanırken pratikte ne kadar özerklik tanındığını ve hangi ortamda (greenfield/brownfield) kullanıldığını merak ediyorum.
Kurumsal yazılımda Claude Code'u bağlayıp güvenle sonuç alabildiğini düşünen biri var mı diye de sormak isterim.
Ben şirkette Claude Code'a nispeten serbest erişebiliyorum ama kendi kod tabanımda özellikle frontend UI veya Playwright dahil olduğunda sonuçlar tutarsız oluyor.
Ne kadar kod artığı kaldığı, ekip arkadaşlarıyla işbirliği yorgunluğu, pull request boyutları, çıkarım maliyeti, paralelleştirme sırasında bunun nasıl yönetildiği gibi gerçek kullanım bilgilerini merak ediyorum.
README belgeleri bazen sisteme özgü terimler, emojiler ve aşırı kişiselleştirilmiş araç kutusu düzenleriyle dolu oluyor; bu da onları satış amaçlı tanıtım metinleri gibi hissettiriyor.
Sonunda Anthropic gibi şirketlerin bu özellikleri kendi CLI'larına dahil edeceğini düşünüyorum.
Ben şahsen bir reasoning modele 10 sayfalık bir spec, katı lint/type check/formatter/hook kuralları, iş kontrol listesi ve red/green TDD veriyorum; sonra GPT-5'e bir kez “go” dediğimde gerekli çıktılar otomatik oluşuyor.
Aynı araçlar elinde olduğunda herkes kendi sistemini kolayca kurabilir.
$200 Max planını kullandığım için çıkarım maliyeti de sabit.
Özellikle yeni özellik ekleme gibi greenfield durumlarında sonuçlar belirgin biçimde iyiydi.
Karmaşık refactoring ya da sistemin derinlerine inen değişikliklerde de (iyi tasarım belgeleri varsa) epey ilerleme sağlanabiliyor; ancak dokümantasyonun zayıf olduğu yerlerde etki çok sınırlı kalıyor.
Başlangıçta çok fazla "iyi olmayan kod" — yani stil, yeniden kullanılabilirlik ve bakım kolaylığı açısından zayıf uygulamalar — ortaya çıkıyordu; fakat CLAUDE.md dosyasını güçlendirdikten ve "elixir-code-reviewer" subagent'ının geliştirici persona tarafından mutlaka kullanılmasını sağladıktan sonra kod kalitesi gözle görülür biçimde arttı.
Platformumuz açık kaynak olduğu için, mevcut Claude command ve subagent yapılandırmamızı burada paylaşıyorum.
https://github.com/Simon-Initiative/oli-torus/tree/master/.claude
Blogda LLM'e özgü üslup çok güçlü hissediliyordu.
Bilgiler faydalı ama yapay zekayı yine yapay zekadan öğreniyor olmak biraz komik.
Son zamanlarda yapay zeka hakkında yazılan pek çok şey bana böyle geliyor.
Gerçekte uzmanlık gerektirmeyen işler dışında Claude Code'u doğrudan izlemek ve yanlış yöne gittiğinde anında müdahale etmek gerekiyor.
Güvenlik açısından ona fazla yetki veremezsiniz ve gerçekte hangi komutları çalıştırdığını da kontrol etmeniz gerekir.
Bugünkü "framework"ler hâlâ alınacak çok yol olduğunu gösteriyor; şimdilik onları "inanılmaz hızda kod üreten junior stajyer" gibi görmek daha gerçekçi.
Yazar ya repo'yu düzgün incelememiş ya da araştırması gerçekten sınırlı kalmış olabilir.
Örneğin superClaude bir MCP sunucusu değil ve metaGPT de Claude Code ile uyumlu görünmüyor.
Agent'ların da insanlar gibi kendi bağlamlarını neden kendilerinin yönetmesine izin verilmediğini hep merak etmişimdir.
Önceki işlerin tüm geçmişinin neden her seferinde tamamen dahil edildiğini anlamıyorum.
Agent'ın hangi bağlamı tutmanın etkili olduğuna karar vermesine ve bağlam yönetiminin artılarını eksilerini kendi kendine öğrenmesine izin verilse, her görevi yerine getirme becerisinin artacağını düşünüyorum.
Sonuçta burada da yine klasik "bitter lesson" tekrarlanıyor gibi.
İnsanlar türlü türlü "framework" geliştiriyor ama bir sonraki nesil model gelip hepsini işe yaramaz hale getiriyor.
http://www.incompleteideas.net/IncIdeas/BitterLesson.html
BMAD-method'dan bahsedilmemesi beni epey şaşırttı.
Benim deneyimime göre BMAD-method, Claude Code için en iyi tamamlayıcılardan biri.
BMAD-method'un ne olduğunu merak ediyorum.
Bunun sadece sistem prompt'u düzeyinde bir şey olup olmadığını ve neden bu kadar faydalı geldiğini bilmek isterim.
https://github.com/bmad-code-org/BMAD-METHOD
BMAD sistemi, yazıda tanıtılan AgentOS'a benziyor gibi görünüyor.
Bu tür bağlam mühendisliği yaklaşımı benim için işe yaradı; hatta Claude'a komutları ve agent'ları doğrudan oluşturtup sonra ihtiyaçlarıma göre düzenledim.
Son dönemde bağlam paylaşımında json ve markdown'ı da aktif biçimde kullanıyorum.
taskmaster da aynı şekilde ama listede yok.
Bağlam yönetimi bana düşük seviyeli programlama gibi geliyor.
Doğru işlemleri yapabilmek için CPU register'larına tam olarak gerekli değerleri koymaya benziyor.
Fark şu ki her görev için eklenecek ya da çıkarılacak bağlam üzerinde bizim çok daha az kontrolümüz var.
B-MAD Framework'ü denedim ve etkisi o kadar farklıydı ki artık bu araç olmadan çalışamıyorum.
Umarım gelecekte bunun gibi daha fazla framework çıkar.
Bu tür framework'leri gerçekten kullanmış biri var mı merak ediyorum.
Gerçekten somut sonuç veriyorlar mı, yoksa sadece modaya kapılmış bir hype mı, bunu bilmek isterim.
Sonuç da beklendiği gibi oluyor: ortada doğrulama olmadan bir sürü özellik, düzgün dokümantasyon olmadan bolca Claude-ism ve pratikte sadece üreticisinin ilgilendiği birkaç projede işe yarayabilecek yapılar.
Gerçekte ancak bunları yapan kişinin ilgilendiği az sayıdaki projede kullanılabilecek seviyedeler.