Spec Driven Development - vibe coding'i daha da güçlü hale getirmek

Girişten önce

Kiro adlı IDE daha önce GeekNews'te ele alınmıştı.

Ancak Kiro'nun yöneldiği geliştirme metodolojisinin düşüncesi olan Spec Driven Development(SDD) açısından bir tanıtım yapılmamıştı.

Spec Driven Development'ı anlamak için iyi bir video yayımlandığı için bunu tanıtıyorum.

---

Kiro

• Ajan tabanlı IDE: Doğal dille geliştirmeye yardımcı olurken, “spec'i birinci sınıf artifact” olarak gören bir eğilime sahip bir IDE.

• Mevcut ajan IDE'lerinin “vibe coding” hızını korurken, kararları, varsayımları ve kısıtları spec belgeleriyle tanımlar.

• İş akışı: Bir fikir girildiğinde hemen requirements / design / tasks olmak üzere 3 dosya oluşturarak başlar. Editör, Code OSS fork'u üzerine “Specs / Hooks / Steering” sekmeleri eklenmiş bir yapıdadır.

  • Specs: Gereksinimleri yapılandırır (kullanıcı hikâyesi + EAR formatında kabul kriterleri) ve sonrasında uygulama, test ve değişiklikleri spec ile ilişkilendirir.
  • Hooks: Dosya/kod değişikliklerini izleyerek spec iş akışını tetikler.
  • Steering: Depo kökündeki .kiro/ altında kuralları (markdown) takım rehberi olarak check-in eder — örn. TDD kuralları ekleyerek ajan davranışını tutarlı hale getirir.

Spec Driven'a neden ihtiyaç var?

• vibe coding'in sınırlarını tamamlama: Sohbet üzerinden gidip gelerek hızlıca kod üretildiğinde, kararların dayanakları sohbet akışında gömülü kalır ve sonradan “neyi neden yaptığımız” belirsizleşir. SDD, önce davranış (behavior) odaklı bir spesifikasyon kurarak bunu istikrarlı bir pusula haline getirir.

• Spec'in tanımı (davranış, özellikler, invariant'lar): Uygulamayı değil, sistemin nasıl davranması gerektiğini tanımlar — safety/liveness özellikleri ve invariant kavramlarını alır, ancak geliştirici dostu bir sözdizimiyle erişilebilir kılmayı amaçlayan bir felsefeye sahiptir.

SDD'nin avantajları

• Karar alma süreçlerinin görünür olması ve yeniden kullanım: Spec, kod değişikliklerinin “kaynağı” haline gelir; bu da review ve uzlaşmayı kolaylaştırır, ayrıca özellik değişse bile niyetin (behaviors) kalmasını sağlar.

• Birleştirilebilir, yaşayan spec'ler: Kullanıcı senaryoları, kabul kriterleri, arayüz/veri sözleşmeleri, performans/SLA'ler vb. modüler hale getirilerek yeniden kullanılabilir ve birleştirilebilir (servis → sistem seviyesi).

• Tüm SDLC'ye uygulanabilirlik: Gereksinim ve tasarımın başında hizalanmadan, dağıtım sonrası sorunların geri bildirim döngüsüne kadar — AI çağındaki kod üretim hızında bile review/kalite/tutarlılığı koruma yaklaşımı.

SDD demosu

• Main link'te yayımlanan videonun demo başlangıç noktası için şu URL'ye bakın: https://youtu.be/olMxlFSxydc?si=sei-bBZ0Q0yszaWn&t=1085

SDD akışı

A. İlk kurulum

1. Proje ayarları - Hooks, Steering, MCP
2. TDD ayarları (önerilir)
3. Spec ayarları - EAR formatı tabanlı (önerilir) spec yazımı (AI aracılığıyla mevcut proje analizi üzerinden otomatik üretilebilir)

B. Özellik geliştirme

1. Spec türetme - Yeni gereksinimleri spec'e yansıtma/güncelleme
2. Guardrail ayarları (önerilir) - Test stub'ları, kural yazımı
3. Uygulama <-> test - Bu bölüm çoğunlukla AI üzerinden tekrar tekrar yürütülür ve geliştirici yalnızca AI'ın iyi düzeltemediği küçük kod değişikliklerine müdahale eder

• Proje yapısı tamamlandıktan sonra, özellikler 'B. Özellik geliştirme' aşamasının tekrarıyla genişletilir

Dikkat edilmesi gerekenler

• Spec belge kalitesi belirli bir seviyeye ulaşmazsa çalışmaz.
• Videodaki spec belge standardı kuralları ayrıntılı biçimde açıklanmıyor. (Referans: https://kiro.dev/docs/specs/)
• TDD kullanımı önerilir; ancak TDD uygulanmamış projelerin çoğunun bu metodolojiden etkili bir fayda görmediği söyleniyor.

---

Kişisel değerlendirme

• AI'ı iyi kullanmak için önerilen başka bir bakış açısından çıkan metodolojilerden biri.
• Her zaman 'iyi' yazılmış belgelerin çok büyük avantajları vardır. Ancak epey çok belgenin bakımının iyi yapılamadığı yönündeki gerçekçi deneyim düşünüldüğünde, bunun ne kadar çok kişiden ortak kabul görebileceği kritik nokta gibi görünüyor.
• Şu anda AI + TDD geliştirme stratejisi, birçok geliştiricinin üzerinde uzlaştığı ve belli ölçüde doğrulanmış bir metodolojidir. Yalnızca TDD'nin kullanıldığı durumlarla SDD'nin birlikte kullanıldığı durumların karşılaştırılmasıyla etki doğrulanırsa çok daha geniş kabul görebileceğini düşünüyorum.