Spec Kit mi Kiro mu? SDD Aracı Seçim Rehberi

Spec-driven development (SDD) son bir yılda "vibe coding"e karşı bir denge unsuru olarak öne çıktı: önce spec yaz, sonra AI ajanına uygulat. GitHub'ın açık kaynak Spec Kit'i ile AWS'in kapalı kaynak Kiro'su, bu yaklaşımın iki en olgun aracı — ama felsefeleri tamamen farklı: biri mevcut ajanının üzerine eklenen taşınabilir bir CLI iskeleti, diğeri IDE'den CLI'a kadar kendi yüzeylerini getiren entegre bir ürün. Üçüncü bir seçenek de zaten elinde olabilir: Claude Code'un kendi CLAUDE.md + skill + alt-ajan mekanizması, ek kurulum gerektirmeden benzer bir disiplini sağlıyor. Bu rehber, hangisinin senin iş akışına uyduğunu önce 60 saniyede bir karar tablosuyla, sonra kurulum adımları, notasyon farkları, gerçek komut örnekleri ve bir fiyat karşılaştırmasıyla derinlemesine anlatıyor.

💡 Pro Tip: Spec Kit'i ve Claude Code'un yerleşik spec akışını aynı özellik üzerinde yan yana denemeden karar verme — ikisi de birkaç dakikada kurulur, ama "hissiyat" farkı yalnızca gerçek bir görevde ortaya çıkar.

İçindekiler

• 60 saniyede karar tablosu
• Benimseme asimetrisi — 138K vs 4,3K yıldız ne demek
• Spec Kit: kurulum, akış, taşınabilirlik
• AWS Kiro: EARS notasyonu, IDE entegrasyonu, AWS bağımlılığı
• Claude Code'un yerleşik yolu
• Aynı özelliği üç araçta denemek
• Kim hangisini seçmeli
• SSS
• GitHub Spec Kit ile AWS Kiro arasında hangisini seçmeliyim?
• Spec Kit hangi AI kodlama araçlarıyla çalışır?
• Kiro'nun EARS notasyonu nedir?
• Claude Code içinde spec-driven development nasıl yapılır?
• Spec Kit'in kısa yolu ile tam yolu arasındaki fark nedir?
• Kiro'nun fiyatlandırması Spec Kit ile nasıl kıyaslanır?
• Sonuç
• Kaynaklar

60 saniyede karar tablosu

Üç aracı beş eksende karşılaştırıyoruz: açıklık (lisans), kilitlenme riski, gereksinim notasyonu, ajan desteği ve olgunluk göstergesi (GitHub yıldızı, 2026-09-23 itibarıyla canlı çekildi).

Kısa özet: Spec Kit "mevcut ajanının üzerine eklenen taşınabilir iskelet", Kiro "tek bir ajan harness'ını IDE, CLI, web ve mobil yüzeylerde çalıştıran entegre ürün", Claude Code'un yerleşik yolu ise "hacklenebilir minimal çerçeve".

Benimseme asimetrisi — 138K vs 4,3K yıldız ne demek

GitHub API'den 2026-09-23'te canlı çekilen rakamlar: github/spec-kit 138.408 yıldız, son push 2026-09-22T21:44:09Z — yani ölçüm gününe kadar günlük commit akışı sürüyordu. kirodotdev/Kiro deposu ise 4.328 yıldız, son push 2026-09-15T14:31:12Z; ölçüm gününe kadar bir haftadan uzun süre yeni push yok. Oran kabaca 32x (138.408 / 4.328 ≈ 31,97).

Bu farkı okurken bir nüansı atlamamak gerekiyor: Kiro'nun GitHub deposunun Releases sekmesi tamamen boş, ürün ikili dosyalar üzerinden kiro.dev/downloads adresinden dağıtılıyor. Yani kirodotdev/Kiro deposu ürünün kaynak kodu değil, büyük ölçüde issue-tracker ve topluluk deposu işlevi görüyor — "Report a bug" linki de oraya yönleniyor. Dolayısıyla 138K'ya 4,3K karşılaştırması, "açık kaynak proje popülerliği" ile "kapalı kaynak ürünün topluluk deposu popülerliği"ni yan yana koyuyor; bire bir aynı şeyi ölçmüyor ama yine de gerçek bir sinyal: Spec Kit bir GitHub-native ekosistem kurmuş, Kiro değil.

Trend çizgisi de aynı yönü doğruluyor: bağımsız star-history.com grafiğinde spec-kit'in yıldız artışı tek bir haber dalgasına değil, aylara yayılmış istikrarlı bir eğime dayanıyor. Bu yüzden 2026-09-23'te API'den çekilen 138.408 rakamını "bir duyuru gününde şişmiş bir sayı" diye okumak yanlış olur; eğrinin kendisi süreklilik gösteriyor. Tersine, bu tür grafiklerden üç haneli hassasiyette ara değer okumaya çalışma — grafik veri etiketi taşımaz, yalnız eğilimi verir; kesin sayı istiyorsan ölçümü doğrudan api.github.com üzerinden, tarihiyle birlikte kaydet.

Ayrıca lisans farkı da asimetriyi büyütüyor: spec-kit MIT lisanslı, Kiro deposunda API yanıtında license: null görünüyor — yani depo düzeyinde açık bir lisans beyanı yok.

Spec Kit: kurulum, akış, taşınabilirlik

Spec Kit bir npm paketi değil, Python paketi — PyPI üzerinden uv ile kuruluyor:

1# Kurulum (resmi quickstart)
2uv tool install specify-cli
3 
4# Yeni proje başlat, tercih ettiğin ajanı seç
5specify init taskify --integration copilot

Kurulumdan sonra proje kısa yol (short path) ile 5 komutta ilerliyor:

1/speckit-specify    # 1. Ne inşa ediyorsun — spec.md üretir
2/speckit-plan        # 2. Nasıl inşa edeceksin — plan.md
3/speckit-tasks        # 3. Görev listesine böl — tasks.md
4/speckit-implement    # 4. Ajan görevleri sırayla uygular
5/speckit-converge     # 5. Spec ile kodun tutarlılığını doğrular

Üretim özellikleri için "full path" bu beşe üç kalite kapısı daha ekliyor: /speckit-clarify, /speckit-checklist, /speckit-analyze — böylece spec belirsizken plana geçilmiyor, plan tutarsızken görevlere bölünmüyor. Resmi quickstart'ta tam yol, proje başına bir kez çalıştırılan /speckit-constitution ile birlikte dokuz adım olarak sıralanıyor:

1/speckit-constitution   # 1. Proje başına bir kez: temel kurallar (güvenlik, mimari, dokümantasyon)
2/speckit-specify        # 2. Ne inşa edilecek
3/speckit-clarify        # 3. Belirsizlikleri çöz (ör. kart davranışı, yorum izinleri)
4/speckit-plan           # 4. Teknoloji yığınını seç
5/speckit-checklist      # 5. Spec'i doğrula
6/speckit-tasks          # 6. İşi parçalara böl
7/speckit-analyze        # 7. Tutarlılık denetimi
8/speckit-implement      # 8. Görevleri bağımlılık sırasına göre uygula
9/speckit-converge       # 9. Kodu spec/plan/tasks'a karşı doğrula

Bu zincirde iki ayrıntı pratikte fark yaratıyor. /speckit-implement, tasks.md'deki görevleri bağımlılık sırasına göre yürütüyor ve uygulamadan önce checklist kutucuklarının durumunu bir kapı olarak okuyup işaretlenmemiş madde varsa devam etmeden önce soruyor; checklist dosyalarını kendisi değiştirmiyor. /speckit-converge ise kod tabanını spec, plan ve görevlere karşı kontrol edip boşluk bulursa tasks.md'ye yeni görevler ekliyor — "Converged" raporunu alana kadar implement ve converge'ü tekrarlıyorsun.

Taşınabilirlik iddiasının arkasında somut rakamlar var: Spec Kit resmi sitesi 38 ajan/editör entegrasyonu ("Copilot, Gemini, Codex, Kilo Code, Zed, Claude, Forge, Kiro ve daha fazlası... No lock-in") ile 157 topluluk eklentisi (90'dan fazla yazar) ve 33 hazır preset listeliyor. En son sürüm v1.0.10, 2026-09-22'de yayınlandı.

AWS Kiro: EARS notasyonu, IDE entegrasyonu, AWS bağımlılığı

Kiro yalnızca bir CLI değil; resmi dokümanının kendi tanımıyla "tek bir birleşik ajan harness'ı" etrafında kurulmuş, IDE, CLI, web ve mobil (iOS) yüzeyleri olan entegre bir ürün — aynı ajan, aynı oturumlar ve aynı yapılandırma her yüzeyde geçerli. Spec Kit ise bunun karşısında mevcut ajanının üzerine eklenen bir CLI iskeleti; fark "CLI mi IDE mi" değil, "ürünün tamamını mı benimsiyorsun, yoksa yalnızca süreç katmanını mı ekliyorsun" sorusunda. Kiro gereksinimleri serbest Markdown yerine EARS notasyonu (Easy Approach to Requirements Syntax) ile yazdırıyor — kalıp şu şekilde:

1WHEN a user submits a form with invalid data
2THE SYSTEM SHALL display validation errors next to the relevant fields

Bu kalıbın amacı, hem insanın hem AI ajanının aynı cümleyi tek bir şekilde okuyup yorumlaması — "belirsiz gereksinim" riskini azaltıyor.

Kiro'nun Feature Specs akışı iki varyant sunuyor:

• Requirements-First: Requirements → Design → Tasks (klasik sıra, her aşamada onay kapısı)
• Design-First: Design → Requirements → Tasks (önce mimariyi netleştirip sonra gereksinime dönmek isteyenler için)

Hızlı, tek oturumluk işler için üçüncü bir mod da var: Quick Spec, üç fazı onay kapısı olmadan otomatik çalıştırıyor.

Fiyatlandırma kredi bazlı — resmi fiyat sayfasında (kiro.dev/docs) listelenen paketler:

Free katman Claude Sonnet 4.5 ve açık ağırlıklı modelleri içeriyor; ücretli paketlerde kredi başına maliyet sabit ($0,02), yalnız paket büyüklüğü değişiyor — aşım kredisi iki katı ($0,04) fiyatlanıyor.

AWS bağımlılığı soyut bir risk değil, ilan edilmiş bir yol haritası: AWS'in kendi DevOps blogundaki duyuruya göre Amazon Q Developer IDE eklentileri ve ücretli abonelikleri 30 Nisan 2027'de destek sonuna ulaşacak ve müşterilere Kiro'ya geçmek için on iki ay veriliyor. Aynı duyuru Kiro'yu "spec-driven development için sıfırdan inşa edilmiş, ajanik bir geliştirme ortamı (IDE, CLI)" diye tanımlıyor ve Q Developer'da halihazırda kullanılan ajanik kodlama, satır içi sohbet, terminal entegrasyonu ile MCP desteğinin Kiro'da da bulunduğunu söylüyor. Model tarafında da ayrışma var: 29 Mayıs 2026'dan itibaren Opus 4.6 Q Developer Pro'da sunulmuyor, en yeni kodlama modelleri yalnızca Kiro üzerinden veriliyor. Kiro'nun dokümanlarındaki /docs/upgrade-guides/migrating-from-q-developer/ rehberi de bu geçişin operasyonel karşılığı.

Bir ikincil kaynağın aktardığına göre 2025 Ağustos'unda Kiro, "vibe request" ve "spec request" diye ikiye bölünmüş bir kredi modeli denemiş, ayrıca bir metering hatası kullanıcıların kredisini beklenmedik şekilde tüketmiş; bu durum topluluktan sürekli tepki almış (codemyspec.com). 2026-09-23 itibarıyla geçerli olan tek-kredi modeli, bu geri adımın sadeleştirilmiş hali olarak konumlanıyor.

Claude Code'un yerleşik yolu

Claude Code, ayrı bir SDD aracı kurmadan da spec-benzeri bir disiplin sağlıyor — üç yapı taşıyla:

• CLAUDE.md / AGENTS.md: Projeye kalıcı bağlam veren talimat dosyası; her oturumda otomatik yüklenir.
• .claude/skills/<ad>/SKILL.md: Prosedürel bilgi paketleri — yalnız kullanıldığında yüklenir, bağlamı şişirmez.
• Alt-ajanlar (subagents): Ayrı bağlam penceresinde çalışan, iş bölümü yapan yardımcı ajanlar.

Resmi dokümana göre yerleşik Explore ve Plan alt-ajanları, hızı korumak için CLAUDE.md dosyalarını ve git status anlık görüntüsünü varsayılan olarak atlıyor — yani "keşif hızlı ve ucuz" kalsın diye tasarlanmışlar; özel alt-ajanlar istenirse CLAUDE.md'yi açıkça yükleyebiliyor.

Pratikte bu üç yapı taşını birleştirmek şöyle görünüyor — CLAUDE.md içine kısa bir spec-disiplini kuralı eklemek:

1# Çalışma kuralı
2 
3Yeni özellik isteklerinde önce Plan Mode'da bir mini-spec
4üret (ne yapılacak, hangi dosyalar değişecek, hangi riskler var),
5onay al, sonra uygula. Spec, PR açıklamasına kopyalanır.

Bu, Spec Kit'in spec.md dosyasının minyatür bir karşılığı — ayrı bir CLI kurmadan, mevcut CLAUDE.md mekanizmasının üzerine yazılıyor.

Bu üçü birlikte "spec + plan + execute" düzenini kuruyor, ama Spec Kit veya Kiro'nun aksine ayrı bir CLI kurulumu, ayrı bir notasyon veya ayrı bir dosya şeması dayatmıyor — repo-yerel, düz metin ve editör-agnostik. Claude Code Plan Mode rehberimiz bu planlama akışını, Claude Code Hooks rehberimiz ise otomasyon katmanını daha derinlemesine ele alıyor.

Aynı özelliği üç araçta denemek

Üç aracın resmi dokümanındaki komut zincirlerini tek bir istek üzerinde yan yana koyunca fark somutlaşıyor.

Senaryo: "Kullanıcı profiline avatar yükleme özelliği ekle."

Spec Kit'in dokümante ettiği akışta komut zinciri şöyle işliyor:

1/speckit-specify "Kullanıcı profiline avatar yükleme özelliği ekle"
2/speckit-plan
3/speckit-tasks
4/speckit-implement

Her komut bir dosya üretir (spec.md, plan.md, tasks.md) ve bunlar repo'da düz Markdown olarak kalır — istersen git diff ile spec değişikliğini kod değişikliğinden ayrı gözden geçirebilirsin.

Kiro'da aynı istek requirements.md dosyasında EARS kalıbına dönüşür, ardından design.md ve dependency-sıralı tasks.md üretilir — hepsi .kiro/specs/ altında, onay kapılarıyla. Buradaki asıl ağırlık design.md tarafında: resmi doküman bu dosyayı teknik mimariyi, sekans diyagramlarını ve uygulama değerlendirmelerini tutan yer olarak tanımlıyor ve içeriğini altı başlık altında dallandırıyor — Architecture, Data Flow, Interfaces, Data Models, Error Handling ve Unit Testing Strategy. Yani Kiro'da "tasarım" bir paragraflık niyet beyanı değil, bileşenlerin ve aralarındaki etkileşimlerin büyük resmini veren yapılandırılmış bir belge; avatar yükleme gibi küçük görünen bir istek bile depolama arayüzü, hata durumları ve test stratejisi satırlarını doldurmaya zorluyor. Bir ikincil kaynağa göre bu üç dosya tek bir prompt'tan türetiliyor ve görevler bağımlılık sırasına göre diziliyor (codemyspec.com).

Claude Code'un yerleşik yolunda ise resmi bir "spec komutu" yok; disiplin sana ait: CLAUDE.md'ye "yeni özellik önce plan modunda tasarlanır" kuralını yazman, ya da bir SKILL.md ile kendi spec şablonunu tanımlaman gerekiyor. Daha az tören, daha çok esneklik — ama kurumsal bir ekip için "her ajan aynı formatı kullanıyor mu" garantisi Spec Kit veya Kiro kadar güçlü değil.

Üç yaklaşımın ürettiği dosyaları yan yana koyunca fark netleşiyor:

Kim hangisini seçmeli

• Solo geliştirici / indie: Spec Kit. Ücretsiz, MIT lisanslı, mevcut ajanına (Claude Code dahil) eklenir, AWS hesabı gerektirmez.
• Küçük ekip, çoklu ajan kullanan (bazıları Copilot, bazıları Claude Code): Yine Spec Kit — 38 entegrasyon ve "no lock-in" ilkesi, ekip içi araç çeşitliliğini spec seviyesinde birleştiriyor.
• AWS-native kurumsal ekip veya Amazon Q Developer'dan geçiş yapan ekip: Kiro mantıklı — EARS notasyonu denetim/uyum gerektiren regülasyonlu sektörlerde (finans, sağlık) izlenebilirlik sağlıyor, IDE içi onay kapıları kurumsal süreçle örtüşüyor.
• Zaten Claude Code kullanan ve ek araç kurmak istemeyen herkes: Önce yerleşik yolu dene (CLAUDE.md + skill + alt-ajan); yetmiyorsa Spec Kit'i Claude Code'un üzerine ekle — ikisi çakışmıyor, aksine tamamlıyor.

Bu dört maddenin altında tek bir eksen var: "hangi araç kazanıyor" değil, süreç derinliği ile taşınabilirlik arasında nerede durmak istediğin. Kiro derinliği seçiyor — EARS, altı başlıklı tasarım belgesi ve onay kapıları — ama bunu kendi yüzeylerine ve kredi sistemine bağlı kalarak veriyor. Spec Kit taşınabilirliği seçiyor: aynı disiplini hangi ajanla çalışırsan çalış yanında taşıyorsun, karşılığında her şeyi kendin kurmuş oluyorsun. Claude Code'un yerleşik yolu ise üçüncü bir denge: derinliği sen tanımlıyorsun, o yüzden hem en esnek hem de ekip ölçeğinde en kırılgan olan seçenek.

SSS

GitHub Spec Kit ile AWS Kiro arasında hangisini seçmeliyim?

Spec Kit, MIT lisanslı ve 38 ajan/editörle (resmi listede Copilot, Gemini, Codex, Kilo Code, Zed, Claude, Forge ve Kiro sayılıyor) çalışan taşınabilir bir CLI iskeletidir; spec'ler repo'nda düz Markdown olarak kalır. Kiro ise AWS'in, spec üretimini IDE, CLI, web ve mobil yüzeylerinde otomatikleştiren entegre bir ürünüdür ama seni AWS ekosistemine ve kredi bazlı fiyatlandırmaya bağlar. Çoklu-ajan ve taşınabilirlik önceliğinse Spec Kit, AWS-native kurumsal bir ortamdaysan veya Amazon Q Developer'dan geçiyorsan Kiro daha mantıklı.

Spec Kit hangi AI kodlama araçlarıyla çalışır?

Spec Kit ajan-agnostik tasarlandı; resmi sitesine göre toplam 38 ajan/editör entegrasyonunu destekliyor ve "no lock-in" ilkesini benimsiyor. Ana sayfada adı geçenler arasında Copilot, Gemini, Codex, Kilo Code, Zed, Claude, Forge ve — rakip olmasına rağmen — Kiro var; tam liste resmi entegrasyon kataloğunda duruyor.

Kiro'nun EARS notasyonu nedir?

EARS (Easy Approach to Requirements Syntax), Kiro'nun requirements.md dosyalarında kullandığı yapılandırılmış gereksinim formatıdır; temel kalıbı "WHEN [koşul/olay] THE SYSTEM SHALL [beklenen davranış]" şeklindedir. Amaç, hem geliştiricinin hem AI ajanının aynı cümleyi tahmin yapmadan, aynı şekilde ayrıştırabilmesidir.

Claude Code içinde spec-driven development nasıl yapılır?

İki yol var: birincisi Spec Kit'i Claude Code entegrasyonuyla kurup /speckit-* komut zincirini kullanmak — önce kısa bir spec yazılır, bir görev planına dönüştürülür, Claude Code her görevi adımlar arasında onayla uygular. İkincisi, Claude Code'un kendi CLAUDE.md + SKILL.md + alt-ajan sistemiyle daha hafif, repo-yerel bir spec disiplini kurmaktır.

Spec Kit'in kısa yolu ile tam yolu arasındaki fark nedir?

Kısa yol beş komuttan oluşur (/speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement, /speckit-converge) ve hızlı iterasyon için tasarlanmıştır. Tam yol bunlara /speckit-clarify, /speckit-checklist ve /speckit-analyze kalite kapılarını ekler; üretime giden, birden fazla kişinin dokunacağı özellikler için önerilir.

Kiro'nun fiyatlandırması Spec Kit ile nasıl kıyaslanır?

Spec Kit'in kendisi ücretsiz — maliyet yalnızca bağlandığın AI ajanının (Claude Code, Copilot vb.) kendi aboneliğinden geliyor. Kiro ise ayrı bir kredi sistemi işletiyor: Free katmanda 50 kredi, ücretli paketlerde ($20-$200 arası) kredi başına sabit $0,02, aşımda ise $0,04. Yani Spec Kit'i tercih etmek, ek bir araç faturası eklemez; Kiro'yu tercih etmek IDE'yi kullanan her kişi/ekip için ayrı bir bütçe kalemi demektir.

Fiyat ve kilitlenme riskini bir arada değerlendirmek istiyorsan, önce küçük bir pilot özellik üzerinde Free katmanı deneyip günlük kredi tüketimini ölçmek, ardından ekip büyüklüğüne göre paket seçmek en güvenli yol. Kiro'nun Ağustos 2025'teki bölünmüş kredi modeli deneyiminin topluluk tepkisi çekmiş olması da (bkz. "Benimseme asimetrisi" ve "AWS Kiro" bölümleri), fiyatlandırma değişikliklerini takip etmenin neden önemli olduğunu gösteriyor.

Sonuç

Spec-driven development'ı "hangi araç en iyisi" sorusuyla değil, "hangi risk profiline karşı ne kazanıyorum" sorusuyla seçmelisin. Spec Kit taşınabilirlik ve açıklık satıyor; Kiro yapılandırılmış izlenebilirlik ve AWS entegrasyonu satıyor; Claude Code'un yerleşik yolu ise minimum tören ile maksimum esneklik sunuyor. Üçü birbirini dışlamıyor — birçok ekip Claude Code'u günlük sürücü olarak kullanırken kritik özelliklerde Spec Kit'in kalite kapılarını devreye sokuyor.

Konuyu derinleştirmek istersen Claude Code Multi-Agent Teams rehberimiz paralel ajan koordinasyonunu, Claude Code MCP rehberimiz araç/plugin entegrasyonunu, GitHub Copilot vs Claude Code vs Cursor karşılaştırmamız günlük editör tercihini, Vibe Coding Güvenlik Kontrol Listesi ise AI-üretimi kodun güvenlik denetimini ele alıyor. Vibe coding'den production'a geçişte spec disiplininin nereye oturduğunu görmek için Vibe Coding MVP'sini Production'a Taşıma Rehberi makalemize bakabilirsin.

Kaynaklar

• GitHub Spec Kit API — stargazers/pushed_at — canlı yıldız sayısı (138.408) ve son push tarihi (2026-09-22).
• AWS Kiro API — stargazers/pushed_at — canlı yıldız sayısı (4.328), son push (2026-09-15) ve license: null.
• Spec Kit Quickstart — resmi doküman — kurulum, /speckit-* komut zinciri, kısa yol/tam yol ayrımı.
• Spec Kit resmi ana sayfa — 38 entegrasyon, 157 topluluk eklentisi, 33 preset, "no lock-in".
• Kiro Feature Specs — resmi doküman — EARS notasyonu, Requirements-First/Design-First akışları, Quick Spec.
• Kiro fiyatlandırma — resmi doküman — Free/Pro/Pro+/Pro Max/Power kredi paketleri ve aşım ücreti.
• Spec Kit vs Kiro karşılaştırması — mimari özet ve Ağustos 2025 kredi modeli tartışması.
• Amazon Q Developer destek sonu duyurusu — AWS DevOps Blog — 30 Nisan 2027 destek sonu, 12 aylık Kiro geçişi ve model değişiklikleri.
• Kiro dokümantasyon indeksi (llms.txt) — birleşik ajan harness'ı; IDE, CLI, web ve mobil yüzeyleri.
• Star History — github/spec-kit — yıldız büyüme eğilimi (bağımsız doğrulama).
• Claude Code Sub-agents — resmi doküman — Explore/Plan alt-ajanlarının CLAUDE.md'yi atlama davranışı.
• Claude Code Memory — resmi doküman — CLAUDE.md/AGENTS.md kalıcı bağlam mekanizması.