15: Agentic Coding Frameworks - BMAD, SpecKit, OpenSpec, GSD, Superpowers karsilastirmasi

Yeni makaleler: 15-Agentic-Coding-Frameworks (ana makale), 95-Superpowers,
96-GSD, 97-OpenSpec, 98-SpecKit. 99-BMAD-Method guncellendi.
Shared Triad, karar matrisi, decision flowchart, quick decision guide.
README, nav, page-nav guncellendi.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: alperhankendi

15-Agentic-Coding-Frameworks.md

@@ -0,0 +1,59 @@
+# Superpowers - The Discipline Enforcer
+
+GitHub Stars: Growing | License: MIT
+
+Superpowers benzersiz bir niş işgal eder. Öncelikli olarak bir specification framework'ü (SpecKit veya OpenSpec gibi), bir enterprise takım simülatörü (BMAD gibi) veya bir context orkestrasyon motoru (GSD gibi) değildir. Bir **disiplin zorunluluk sistemidir**. GSD'ye en yakın buluyorum, ancak TDD konusunda çok daha katı.
+
+## Onu Farklı Kılan Ne?
+
+### Zorunlu Brainstorming Gate'i
+
+Herhangi bir kod yazılmadan önce, Superpowers geliştirici ve AI agent arasında yapılandırılmış bir diyaloğu zorlar. Bu opsiyonel değildir. Agent, bir tasarım sunulup onaylanana kadar kod yazmaktan, proje iskeletlemekten veya herhangi bir implementation eylemi almaktan açıkça men edilmiştir.
+
+BMAD'in benzer bir analiz fazı vardır, ancak Superpowers'ın gate'i daha serttir: geçici çözüm yoktur, "bu tasarım gerektirmeyecek kadar basit" kaçış kapısı yoktur. GSD'nin milestone ve planlama tartışmaları vardır ama atlanabilir.
+
+### TDD Demir Kuralı
+
+Diğer framework'ler test yazmayı önerir. Superpowers bunu bir **sil-ve-yeniden-yaz kuralıyla** dayatır: agent, başarısız bir test olmadan production kodu yazarsa, kod silinir. Referans için saklanmaz. Uyarlanmaz. **Silinir.**
+
+Bu, bu karşılaştırmadaki herhangi bir framework'ün en agresif test zorunluluğudur.
+
+### İkna Bazlı Koruma Rayları
+
+Superpowers, AI agent'ların psikolojisini açıkça ele alır. Modellerin adımları atlamak için kullandığı rasyonalizasyonları isimlendirir ("bu test etmek için çok basit", "testleri sonra yazacağım", "bunu hızlıca düzelteyim") ve bunları önceden engeller.
+
+Skill'ler sosyal mühendisliğe karşı stres testi yapılmıştır: yaratıcı, aciliyet simüle ederek ve uyumu izleyerek agent'ı köşe kesmeye ikna etmeye kasıtlı olarak çalışır.
+
+### İki Aşamalı Review ile Subagent Dispatch
+
+GSD gibi, Superpowers da context pollution'ı önlemek için taze subagent context'leri kullanır. Ancak GSD paralel çalıştırma hızına odaklanırken, Superpowers **kalite gate'lerine** odaklanır.
+
+Her subagent'ın çıktısı, workflow ilerlemeden önce **spec uyumluluk review'u** ve **kod kalite review'undan** geçer. Muhtemelen GSD ile aynı token kullanım kısıtlamalarına sahiptir. Daha fazlasını yapar. Daha fazla kullanırsınız. Her ikisi de bir maliyeti olan context rot'u önlemeye çalışır, ancak doğruluk muhtemelen maliyetine değer.
+
+## Pratikte Trade-Off
+
+Superpowers'ın temel trade-off'u **güvenilirlik vs hızdır**. Zorunlu brainstorming, TDD dayatması ve iki aşamalı review, bu karşılaştırmadaki herhangi bir framework'ün en tutarlı yüksek kaliteli çıktısını üretir (GSD yakın ikinci olarak). Ancak her kalite gate'i zaman ekler.
+
+Ham bir Claude Code session'ında 10 dakika süren bir görev, Superpowers'ın tam pipeline'ı üzerinden 30 dakika sürebilir. Soru şudur: bug'lardan, yeniden çalışmadan ve mimari hatalardan kaçınarak kazanılan zaman, ön disipline harcanan zamanı aşar mı?
+
+* **Production sistemleri** (bug'ların maliyetli olduğu): cevap neredeyse her zaman **evet**
+* **Prototip ve tek kullanımlık kod**: cevap neredeyse her zaman **hayır**
+
+## Ne Zaman Kullanmalı
+
+* Kalite kritik production sistemleri
+* TDD kültürü olan veya oluşturmak isteyen takımlar
+* Bug maliyetinin yüksek olduğu sektörler (finans, sağlık, altyapı)
+* AI agent'ın disiplinsiz davranma eğiliminin sorun olduğu projeler
+
+## Ne Zaman Gereksiz
+
+* Hızlı prototipleme ve kavram kanıtları
+* Tek kullanımlık script'ler ve deney kodu
+* Test yazmanın anlamsız olduğu basit konfigürasyon değişiklikleri
+
+## Nasıl Karşılaştırılır?
+
+Superpowers bu karşılaştırmadaki en katı görüşlü framework'tür. Esnekliği güvenilirlik karşılığında takas eder. Brainstorming fazını atlayamazsınız. Testlerden önce kod yazamazsınız. Code review'u bypass edemezsiniz.
+
+Bu kısıtlamalar, iyi anladıkları görevlerde hızlı hareket etmek isteyen deneyimli geliştiriciler için süreci yavaşlatır, ancak kod kalitesinin hızdan daha önemli olduğu takımlar için en güvenli seçim haline getirir.

95-Superpowers.md

@@ -0,0 +1,103 @@
+# GSD (Get "Stuff" Done) - The Context Engineering Powerhouse
+
+GitHub Stars: 28.1k | License: MIT | Latest: Active development (March 2026) | [GitHub](https://github.com/gsd-framework/gsd) | [Site](https://gsd.dev)
+
+GSD, specification odaklı framework'lerin büyük ölçüde görmezden geldiği bir probleme saldırır: AI agent'ınızın context window'u dolduğunda ve çıktı kalitesi çöktüğünde ne olur?
+
+## Context Rot Problemi
+
+Context rot, bir AI modelinin tek bir session içinde daha fazla token işledikçe yaşadığı kalite bozulmasıdır. Araştırma ve pratik deneyimler öngörülebilir bir düşüş eğrisi ortaya koyar:
+
+| Context Kullanımı | Kalite Durumu |
+| --- | --- |
+| **%0-30** | Zirve performans |
+| **%50+** | Acele etme, detay atlama, kestirmeler |
+| **%70+** | Halüsinasyonlar artışı |
+| **%80+** | Konuşmanın başında belirlenen gereksinimleri unutma |
+
+Bu teorik bir endişe değildir. Tek bir Claude Code session'ında karmaşık bir feature üzerinde çalışmış herhangi bir geliştirici, uzun konuşma sonrasında modelin çıktı kalitesinin gözle görülür şekilde bozulduğunu deneyimlemiştir. Yirminci dosya düzenlemesi, ikincisinden ölçülebilir şekilde daha kötüdür.
+
+## GSD Bunu Nasıl Çözer?
+
+GSD'nin temel mimari kararı, her çalıştırma birimi için **taze subagent context'leri başlatmaktır**. Tüm görev context'ini giderek şişen tek bir konuşmada biriktirmek yerine, GSD her göreve kendi temiz 200.000 token context window'unu verir. Görev 50, Görev 1 ile aynı context kalitesini alır çünkü sadece ilgili proje artifact'larıyla yüklenmiş taze bir window'dan başlar.
+
+Çalıştırma modeli görevleri bağımlılık sıralı "wave"ler halinde organize eder:
+
+```mermaid
+graph TD
+    W1["Wave 1<br/><small>Bağımsız görevler<br/>paralel çalışır</small>"]
+    W2["Wave 2<br/><small>Wave 1'e bağımlı görevler<br/>paralel çalışır</small>"]
+    W3["Wave 3<br/><small>Önceki tüm wave'lere<br/>bağımlı görevler</small>"]
+
+    W1 --> W2 --> W3
+
+    T1A["Görev A"] & T1B["Görev B"] & T1C["Görev C"] --> W1
+    T2A["Görev D"] & T2B["Görev E"] --> W2
+    T3A["Görev F"] --> W3
+
+    style W1 fill:#132213,stroke:#22c55e,stroke-width:2px,color:#4ade80
+    style W2 fill:#1c1208,stroke:#eab308,stroke-width:1px,color:#facc15
+    style W3 fill:#1a1a3e,stroke:#a855f7,stroke-width:1px,color:#c084fc
+    style T1A fill:#0f2027,stroke:#3b82f6,stroke-width:1px,color:#60a5fa
+    style T1B fill:#0f2027,stroke:#3b82f6,stroke-width:1px,color:#60a5fa
+    style T1C fill:#0f2027,stroke:#3b82f6,stroke-width:1px,color:#60a5fa
+    style T2A fill:#0f2027,stroke:#3b82f6,stroke-width:1px,color:#60a5fa
+    style T2B fill:#0f2027,stroke:#3b82f6,stroke-width:1px,color:#60a5fa
+    style T3A fill:#0f2027,stroke:#3b82f6,stroke-width:1px,color:#60a5fa
+```
+
+Bu wave tabanlı paralelizm, "yatay katmanlar" (önce tüm model'ler, sonra tüm API'ler, sonra tüm UI) yerine **"dikey dilimler"** (uçtan uca feature'lar) yaklaşımını tercih eder. Dikey dilimler görevler arası bağımlılıkları minimize ederek paralel çalışabilecek görev sayısını maksimize eder.
+
+## Multi-Agent Orkestrası
+
+GSD özelleşmiş agent'lardan oluşan bir filo kullanır:
+
+| Agent | Görevi |
+| --- | --- |
+| **4 Paralel Araştırmacı** | Kod tabanını eş zamanlı inceler ve context toplar |
+| **Planlayıcı** | Araştırmayı yapılandırılmış çalıştırma planlarına dönüştürür |
+| **Plan Kontrolcüsü** | Çalıştırma başlamadan önce planları doğrular |
+| **Wave Tabanlı Paralel Uygulayıcılar** | Taze context'lerde görevleri implement eder |
+| **Doğrulayıcılar** | Tamamlanan işi spesifikasyonlara göre doğrular |
+| **Debugger Agent'lar** | Bir şey bozulduğunda bilimsel yöntem hipotez testi uygular |
+
+Debugger agent özel ilgiyi hak eder. "Hangi görevleri yaptık?" diye sormak yerine, GSD doğrulaması **"bunun çalışması için neyin DOĞRU olması gerekir?"** diye sorar. Bu hedefe geriye dönük yaklaşım, implementation detayları yerine gözlemlenebilir davranışları test ederek, görev odaklı doğrulamanın kaçırdığı bug'ları yakalar.
+
+## Güçlü Yanları
+
+GSD, bu karşılaştırmadaki en çalıştırma odaklı framework'tür. SpecKit ve OpenSpec specification üretirken, BMAD kapsamlı dokümantasyon üretirken, **GSD kod gönderir**. Context izolasyon mimarisi, AI destekli geliştirmedeki en büyük pratik problemi doğrudan ele alır: uzun session'lar sırasında kalite bozulması.
+
+Atomik git commit'ler (görev başına bir adet) temiz `git bisect` debugging ve bireysel görev geri alma imkanı sağlar. Amazon, Google ve Shopify'daki mühendisler GSD'yi production'da kullanmaktadır.
+
+## Zayıf Yanları
+
+GSD **token açtır**. Her görev için taze context başlatmak, proje context'ini tekrar tekrar iletmek anlamına gelir ve bu, tek session yaklaşımlarına göre API kredilerini daha hızlı tüketir.
+
+Framework ayrıca planlama fazında daha az konuşma odaklıdır; işbirlikçi specification rafine etme yerine çalıştırma hızı için optimize eder.
+
+Platform desteği SpecKit veya OpenSpec'ten daha dardır; şu anda Claude Code, OpenCode ve Gemini CLI'ı kapsar, ancak entegrasyon daha sorunsuz bir deneyim sunar.
+
+Basit görevler için framework'ün yoğunluğu aşırı olabilir, ancak bant dışı todo'lar, debugging session'ları ve tek seferlik işler için araçlar mevcuttur ve bunlar planlama karışımına entegre edilebilir.
+
+## Pratikte Trade-Off
+
+GSD'nin birinci trade-off'u **token maliyeti vs çıktı kalitesidir**. Taze context'ler düzinelerce görev boyunca tutarlı kalite garanti eder, ama API harcamanızı katlar. Tek session'da 5$ maliyetli 50 görevlik bir feature, GSD'nin context izolasyonuyla 25-40$'a mal olabilir.
+
+İkinci trade-off **çalıştırma hızı vs specification derinliğidir**. GSD, diğer tüm framework'lerden daha hızlı kod yazdırır, ama planlama fazı BMAD'ın veya SpecKit'in fazasından daha az işbirlikçidir. Gereksinimleriniz yanlışsa, GSD yanlış planı çok verimli bir şekilde çalıştıracaktır.
+
+Gerçekte ise temiz context'lerle çalışmanın hassasiyeti (reasoning için önemli) ve birden fazla seviyedeki doğrulama adımları (planlama ve çalıştırma), bu framework'ü spesifikasyonları ve gereksinimleri takip etmede son derece doğru kılar ve maliyetine değer.
+
+## Ne Zaman Kullanmalı
+
+* Büyük, çok dosyalı feature geliştirme
+* Uzun session'larda kalite bozulması yaşanan projeler
+* Paralel çalıştırma ihtiyacı olan refactoring'ler
+* Yeterli API bütçesine sahip takımlar
+* Atomik commit ve kolay geri alma gerektiren projeler
+
+## Ne Zaman Gereksiz
+
+* Küçük, basit değişiklikler
+* Bütçe kısıtlı takımlar
+* Kapsamlı işbirlikçi planlama gerektiren projeler
+* İşbirlikçi specification rafine etme öncelikli senaryolar

96-GSD.md

@@ -0,0 +1,62 @@
+# OpenSpec - The Brownfield-First Alternative
+
+GitHub Stars: 29.5k | License: MIT | Latest: v1.2.0 (Feb 2026) | [GitHub](https://github.com/openspec-dev/openspec) | [Site](https://openspec.dev)
+
+SpecKit sıfırdan yeni sistemler inşa etmek için tasarlandıysa, OpenSpec mevcut kod tabanları üzerinde çalışmanın daha karmaşık gerçekliği için tasarlanmıştır.
+
+OpenSpec'in felsefesi dört karşıtlıkla özetlenir: **"Esnek, katı değil; iteratif, waterfall değil; kolay, karmaşık değil; brownfield için inşa edilmiş, sadece greenfield için değil."** SpecKit katı faz gate'leri dayatırken, OpenSpec herhangi bir artifact'ı herhangi bir zamanda önceden belirlenmiş bir sıra takip etmeden güncellemenize izin verir.
+
+## Delta Spec'ler
+
+Temel inovasyon, **delta marker'lar aracılığıyla değişiklik izolasyonudur**. Mevcut bir işlevselliği değiştirdiğinizde tüm specification'ı baştan yazmak yerine, OpenSpec mevcut duruma göre neyin değiştiğini tanımlamak için `ADDED`, `MODIFIED` ve `REMOVED` marker'larını kullanır.
+
+Her değişiklik kendi klasörünü alır (`openspec/changes/<isim>/`) ve içinde proposal, spec'ler, tasarım dokümanları ve görevler bulunur. Bu, bir değişikliğin diğerine müdahale etmesini önler.
+
+```
+openspec/
+  changes/
+    kullanici-yetkilendirme/
+      proposal.md
+      specs.md
+      design.md
+      tasks.md
+    odeme-entegrasyonu/
+      proposal.md
+      specs.md
+      design.md
+      tasks.md
+```
+
+## Güçlü Yanları
+
+OpenSpec değişiklik başına yaklaşık **250 satır** çıktı üretir, SpecKit'in yaklaşık **800 satırına** kıyasla. Bu overhead azalması, bir üretim sistemine günde beş değişiklik yaptığınızda önem kazanır.
+
+**Fast-forward** komutu (`/opsx:ff`) tüm planlama artifact'larını tek seferde iskeletler, çok adımlı seremoniden kurtarır.
+
+20+ AI aracı desteğiyle SpecKit kadar taşınabilirdir. Mevcut kod tabanlarında iteratif bakım, refactoring ve artımsal feature geliştirme yapan takımlar için OpenSpec en pragmatik seçenektir.
+
+## Zayıf Yanları
+
+SpecKit gibi, OpenSpec'in spec'leri de **statiktir**. Implementation ile otomatik olarak senkronize olmaz. Multi-agent orkestrasyon, paralel çalıştırma ve context izolasyon stratejisi yoktur.
+
+Kapsamlı mimari dokümantasyon gerektiren büyük greenfield projelerde OpenSpec'in hafif yaklaşımı **yetersiz specification derinliği** üretebilir.
+
+## Pratikte Trade-Off
+
+OpenSpec, specification derinliğini hız karşılığında takas eder. Değişiklikleri daha hızlı çıkarsınız, ama birikmiş değişikliklerin tam mimari etkisini delta spec'lerin yakalayamayabileceği riskini kabul edersiniz.
+
+Aylarca süren artımsal modifikasyonlarda, spec'lerin tanımladığı ile sistemin gerçekte yaptığı arasındaki uçurum sessizce büyüyebilir.
+
+## Ne Zaman Kullanmalı
+
+* Legacy modernizasyon ve brownfield projeler
+* Mevcut sisteme iteratif feature ekleme
+* Günlük birden fazla değişiklik yapılan üretim sistemleri
+* Hafif overhead isteyen küçük-orta takımlar
+* Refactoring ve bakım ağırlıklı çalışmalar
+
+## Ne Zaman Gereksiz
+
+* Kapsamlı mimari dokümantasyon gerektiren büyük greenfield projeler
+* Paralel agent çalıştırma ihtiyacı olan senaryolar
+* Spec'lerin otomatik senkronizasyonu zorunlu olan ortamlar

97-OpenSpec.md

@@ -0,0 +1,74 @@
+# SpecKit - GitHub's Gated Process
+
+GitHub Stars: 75.9k | License: MIT | Latest: v0.1.4 (Feb 2026) | [GitHub](https://github.com/speckit/speckit) | [Blog](https://github.blog/speckit)
+
+SpecKit, GitHub'ın spec-driven development alanına resmi girişidir ve yıldız sayısı (bu karşılaştırmadaki en yüksek) GitHub'ın devasa platform erişimini yansıtır.
+
+Temel felsefe belirsizliğe yer bırakmadan ifade edilir: **"Specification'lar koda hizmet etmez; kod specification'lara hizmet eder."** SpecKit, specification'ı implementation'ı yönlendiren bir kılavuz olarak değil, implementation'ın türetildiği otoriter kaynak olarak ele alır.
+
+## Gated Process
+
+SpecKit, explicit checkpoint'ler ile katı, sıralı bir workflow dayatır. Mevcut faz doğrulanmadan bir sonraki faza geçemezsiniz.
+
+```mermaid
+graph LR
+    CONST["Constitution<br/><small>/speckit.constitution<br/>Yönetişim ilkeleri</small>"]
+    SPEC["Specify<br/><small>/speckit.specify<br/>Gereksinimler, kullanıcı yolculukları</small>"]
+    PLAN["Plan<br/><small>/speckit.plan<br/>plan.md, research.md</small>"]
+    TASKS["Tasks<br/><small>/speckit.tasks<br/>Test edilebilir görev listeleri</small>"]
+    IMPL["Implement<br/><small>/speckit.implement<br/>AI agent üzerinden uygulama</small>"]
+
+    CONST --> SPEC --> PLAN --> TASKS --> IMPL
+
+    style CONST fill:#1a1a3e,stroke:#a855f7,stroke-width:1px,color:#c084fc
+    style SPEC fill:#0f2027,stroke:#3b82f6,stroke-width:1px,color:#60a5fa
+    style PLAN fill:#1c1208,stroke:#eab308,stroke-width:1px,color:#facc15
+    style TASKS fill:#132213,stroke:#22c55e,stroke-width:1px,color:#4ade80
+    style IMPL fill:#0f2027,stroke:#3b82f6,stroke-width:2px,color:#60a5fa
+```
+
+**Constitution** (`/speckit.constitution`): Proje için yönetişim ilkelerini belirler.
+
+**Specify** (`/speckit.specify`): Ne inşa edileceğini tanımlar, yapılandırılmış gereksinimler ve kullanıcı yolculukları üretir.
+
+**Plan** (`/speckit.plan`): Teknik implementation stratejileri oluşturur; plan.md, research.md ve ilgili artifact'ları üretir.
+
+**Tasks** (`/speckit.tasks`): Plandan eyleme dönüştürülebilir, test edilebilir görev listeleri üretir.
+
+**Implement** (`/speckit.implement`): Görevleri bağlı AI agent üzerinden çalıştırır.
+
+Opsiyonel fazlar arasında **Clarify** (yetersiz tanımlanmış alanlar için) ve **Analyze** (artifact'lar arası tutarlılık kontrolü için `/speckit.analyze`) bulunur.
+
+## Güçlü Yanları
+
+Gated process, AI coding'deki en yaygın başarısızlık modunu önler: gereksinimler netleşmeden implementation'a koşmak. Framework, canlı dokümantasyon olarak hizmet eden zengin bir artifact seti üretir (spec.md, plan.md, research.md, data-model.md, contracts, quickstart guide'lar).
+
+20+ AI coding agent desteğiyle (Copilot, Claude Code, Cursor, Gemini CLI, Windsurf dahil) SpecKit, mevcut en platform-agnostik seçenektir.
+
+## Zayıf Yanları
+
+Seremoni oldukça ağırdır. Bağımsız değerlendirmeler, feature başına artifact üretimi ve review için **1-3+ saat** raporlamaktadır. Küçük değişiklikler için -- bir config flag eklemek veya bir validation bug'ı düzeltmek gibi -- tam specify-plan-task-implement döngüsünden geçmek, raptiyeye balyozla vurmak gibidir.
+
+Spec'ler statiktir; implementation sırasında otomatik güncellenmez, bu nedenle uzun projelerde **dokümantasyon sapması** gerçek bir risktir.
+
+SpecKit ayrıca **multi-agent orkestrasyon** eksikliğine sahiptir. `/speckit.implement` komutu bağlı olan tek AI agent'a delege eder, ancak paralellik veya agent izolasyonu yönetmez.
+
+## Pratikte Trade-Off
+
+SpecKit, fazla specification'ın maliyetinin her zaman eksik specification'ın maliyetinden düşük olduğuna bahse girer. Belirsiz gereksinimlere sahip greenfield projelerde bu bahis genellikle kazanır. Olgun kod tabanlarına yapılan iyi anlaşılmış değişikliklerde ise specification overhead'i saf sürtünmeye dönüşür.
+
+Feature başına 1-3 saatlik yatırım, yeniden çalışmaya karşı bir sigortadır; bu sigortanın değip değmeyeceği, ilk seferde implementation'ı yanlış yapmanın maliyetine bağlıdır.
+
+## Ne Zaman Kullanmalı
+
+* Belirsiz gereksinimleri olan greenfield projeler
+* Compliance-heavy ortamlar (spec onayı zorunlu)
+* Spec-driven geliştirme kültürü olan takımlar
+* Çoklu AI agent'lar arası geçiş yapan takımlar (platform-agnostik)
+
+## Ne Zaman Gereksiz
+
+* Küçük bug fix'ler veya config değişiklikleri
+* İyi anlaşılmış, rutin değişiklikler
+* Hızlı iterasyon gerektiren prototipler
+* Paralel agent çalıştırma ihtiyacı olan projeler