- Spec-Driven Development (SDD), kodlamadan önce kapsamlı belgeler yazmayı gerektiren waterfall tarzı yaklaşımı yeniden canlandıran bir yöntem olarak ortaya çıkıyor; amacı AI kodlama yardımcıları için yapı sağlamak olsa da çevikliği zayıflatma riski taşıyor
- Açık kaynak topluluğu, ilk prompt ve yönergeleri temel alarak spesifikasyon, uygulama planı ve görev listesini otomatik üreten araçlar geliştirdi; öne çıkan örnekler arasında Spec-Kit, Kiro, Tessl, BMad Method yer alıyor
- Ancak gerçek kullanımda bağlam farkındalığı eksikliği, aşırı dokümantasyon, çift kod incelemesi, sahte güven duygusu gibi çeşitli sınırlamalar ortaya çıkıyor ve büyük kod tabanlarında verimlilik hızla düşüyor
- Yazı, SDD'nin geliştiriciyi ikame etmeye çalışan bir yaklaşım olarak waterfall modelinin başarısızlığını tekrar ettiğini savunuyor; bunun yerine doğal dil tabanlı yinelemeli geliştirme yaklaşımını öneriyor
- Agile ve Lean Startup ilkelerini birleştiren yaklaşımın, kodlama ajanlarıyla yapılan modern geliştirmeye daha uygun olduğu; bir sonraki önemli adımın ise görsel etkileşim araçlarının gelişmesi olduğu belirtiliyor
Spesifikasyon Odaklı Geliştirmenin (SDD) Ortaya Çıkışı
- Spec-Driven Development (SDD), AI kodlama yardımcıları için yapılandırılmış bir geliştirme yöntemi sağlamak amacıyla, kodlamadan önce spesifikasyon belgeleri yazma sürecini devreye sokuyor
- LLM, ilk prompt ve yönergelere dayanarak ürün spesifikasyonu, uygulama planı ve görev listesi oluşturuyor
- Her belge bir önceki aşamaya dayanıyor ve kullanıcı bu belgeleri düzenleyerek spesifikasyonu rafine ediyor
- Tamamlanan belgeler, kod yazımında kullanılmak üzere Claude Code, Cursor, Copilot gibi kodlama ajanlarına aktarılıyor
- Temsilci araçlar arasında GitHub'ın Spec-Kit'i, AWS'nin Kiro'su, Tessl, BMad Method (BMM) bulunuyor
- İlgili bir karşılaştırmalı analiz olarak Birgitta Böckeler'in Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl yazısına değiniliyor
Markdown ile Dokümantasyonun Sorunları
- SDD spesifikasyonları çoğunlukla Markdown dosyaları biçiminde hazırlanıyor; örnek olarak GitHub Spec-Kit ile yapılan basit bir özellik geliştirmesi 8 dosya, 1.300 satıra ulaşıyor
- Kiro kullanılarak Atomic CRM'e “referred by” alanı eklenmesi örneği de çok sayıda belgeye bölünüyor
- Gerçek kullanımda şu dezavantajlar öne çıkıyor
- Bağlam farkındalığı eksikliği (Context Blindness): Mevcut fonksiyonlar ya da kod bağlamı gözden kaçtığı için uzman incelemesi hâlâ gerekli
- Aşırı dokümantasyon (Markdown Madness): Uzun belgeler yüzünden basit hataları bulmak için bile çok zaman harcanıyor
- Sistematik bürokrasi (Systematic Bureaucracy): Gereksiz tekrarlar ve aşırı ayrıntılandırma verimsizlik yaratıyor
- Sahte Agile (Faux Agile): “User Story” kavramının yanlış kullanımı dağınıklığa yol açıyor
- Çift kod incelemesi (Double Code Review): Hem spesifikasyondaki kodun hem de gerçek uygulamanın ayrı ayrı incelenmesi gerekiyor
- Sahte güven duygusu (False Sense of Security): Ajanlar spesifikasyona her zaman tam olarak uymuyor
- Azalan getiri (Diminishing Returns): İlk aşamadaki projelerde faydalı olsa da ölçek büyüdükçe geliştirme hızını düşürüyor
- Çoğu kodlama ajanı zaten plan mode ve görev listesi özellikleri sunduğundan, SDD'nin sağladığı ek fayda sınırlı kalabiliyor; hatta geliştirme maliyetini artırabiliyor
Proje Yöneticisinin İntikamı
- SDD'nin sınırları araçların olgunlaşmamış olmasından kaynaklanıyor olabilir; ancak esas sorun temelde yanlış tanımlanmış bir problemden doğuyor
- Temel varsayım, “geliştiriciyi yazılım geliştirme sürecinden çıkarmanın yolu”nu bulmak
- Yapı, geliştiriciyi kodlama ajanıyla değiştirmeye ve bunu ayrıntılı planlarla kontrol etmeye çalışıyor
- Bu yaklaşım waterfall modeliyle benzerlik taşıyor; kapsamlı dokümantasyon yoluyla geliştiriciyi yalnızca bir çevirmen rolüne indirgemeye çalışıyor
- Oysa yazılım geliştirme deterministik olmayan (non-deterministic) bir süreç ve yalnızca plan yaparak belirsizlik ortadan kaldırılamaz (No Silver Bullet makalesine atıf yapılıyor)
- SDD, gereksinim aşamasında iş analisti, tasarım aşamasında ise geliştirici uzmanlığı gerektirdiğinden, pratikte ancak her iki rolü de üstlenebilen az sayıda kişi tarafından kullanılabiliyor
- Sonuç olarak, No Code araçlarında olduğu gibi “geliştiricisiz geliştirme” vaadinde bulunsa da sonunda yine geliştiriciye ihtiyaç duyuyor
Yeni Alternatif: Doğal Dil Tabanlı Yinelemeli Geliştirme
- Agile metodolojisi, öngörülebilirlik yerine uyum sağlama yeteneğini seçerek deterministik olmayan geliştirme sorununu çözmeye çalıştı
- Karmaşık gereksinimleri birden çok basit probleme bölmek, kodlama ajanlarından yararlanmanın temel noktası olarak görülüyor
- Lean Startup ilkelerine dayanan basit bir yineleme süreci öneriliyor
- Üründeki en riskli varsayımı belirle
- Bunu doğrulamak için gereken en küçük deneyi tasarla
- Deneyi geliştir ve sonuca göre yinele
- Örnek olarak, Claude Code kullanılarak yaklaşık 10 saat içinde 3D heykel aracı (sculpt-3D) geliştirildiği anlatılıyor
- Spesifikasyon olmadan, kısa talimatlarla özellikler kademeli olarak eklendi
- Hatalı uygulamalar anında düzeltilerek hızlı yinelemeler yapıldı
- Bu yöntem, waterfall tarzı dokümantasyon olmadan da hızlı yakınsama sağlayabiliyor ve Agile ile kodlama ajanlarının birleşimi sayesinde gerçek zamanlı ürün geliştirmeyi mümkün kılıyor
- Ancak kodlama ajanları hâlâ metin merkezli olduğundan görsel etkileşim zayıf; gelecekte görsel arayüzleri güçlendiren araçların geliştirilmesi gerekiyor
Sonuç
- Agile metodolojisi, spesifikasyon belgelerini zaten büyük ölçüde gereksiz hâle getirmişti; SDD ise bunları yeniden canlandırma girişimi olarak değerlendiriliyor
- SDD, geliştiriciyi dışlamaya çalışan teori ağırlıklı bir yaklaşım olarak, kodlama ajanlarıyla yeni nesil geliştiricilerin güçlendirilmesi fırsatını kaçırıyor
- Kodlama ajanları içten yanmalı motora benzetiliyor; SDD bu motoru yalnızca lokomotife bağlamak isterken, bizim onu otomobil, uçak ve başka pek çok biçime genişletmemiz gerektiği savunuluyor
- Son olarak, çevresel etkiler de düşünülüyorsa kodlama ajanlarının ölçülü kullanımı gerektiği vurgulanıyor
1 yorum
Hacker News yorumları
Bir geliştirici olarak elde ettiğim en büyük verimlilik artışı, her işi önceden planlama alışkanlığı edinmek oldu
Her bilet geldiğinde onu büyük bir TODO listesine bölüp tasarımı, bağımlılıkları ve gereksinimleri baştan netleştiriyorum
Böyle yapınca programlama sırasında akış durumuna (flow) daha sık girebiliyorum
Bu yaklaşımın AI kodlama ajanları için de etkili olmasının nedeni, düşünme sürecini önceden dışsallaştırması
Ayrıntıları yazımda anlattım
Aslında problemi küçük parçalara ayırmak ve gereksinim yazmak iyi bir şey
Sorun çıkaran şey değiştirilemeyen spesifikasyonlar. Uygulamaya ancak aylar sonra başlanırsa spesifikasyon katılaşıyor
Buna karşılık Agile çoğu zaman stratejik planlamayı ertelemenin bahanesi olarak kullanılıyor. Sonuç da bolca yeniden iş
Sonuçta bu bir denge meselesi ve “It depends” ifadesinin hem hayat hem geliştirme için iyi bir motto olduğunu düşünüyorum
LLM spesifikasyonları yönetirse bakım yükünü azaltma gibi bir avantaj olabilir
İlgili yazı burada
Tahmin etmesi zor durumlarda önce spike yapıp kodu ve kütüphaneleri keşfediyoruz
İdeal yapı diyagramı ile gerçekçi kısıtları yansıtan diyagramı birlikte hazırlayarak uzun vadede mimari tuzaklardan kaçınıyoruz
Birkaç ay vibe coding yaptıktan sonra son 6 aydır spec-driven development yaklaşımına geçtim
Günde 2-3 saat gereksinim yazıyor, aynı gün içinde test edilmiş özelliği yayına alıyorum
Gereksinim yazmak beni daha az çevik yapmadı. Aksine 8 saatlik hızlı yinelemeler mümkün oldu
Gereksinim bir prompt değil, doğruluğu değerlendirme ölçütü
İyi tanımlanmış uçtan uca testler, AI'ın hatalarını ciddi ölçüde azaltıyor
Her çalıştırmada sonuç değişiyor ve sonunda yine insan incelemesi gerektiği için verimsiz olabilir
Bir günlük işe ‘spesifikasyon’ demek yanıltıcı. Sonuçta mevcut sürece yeni ad vermiş oluyorsun
Basit mantık ifadelerini bile sık sık yanlış yorumladıkları için doğal dilde yazılmış gereksinimleri anlamalarına güvenmek riskli
Sonra bunu ajana veriyorum, o da uygulamayı yapıyor; ben sadece arada kontrol ediyorum
AI çalışırken ben de yarış arabamla uğraşıyorum, tam bir kazan-kazan
Sonuçta önemli olan tek şey kodun testleri geçmesi
Bu yazı, “spec-based development bana göre değil” sonucuna zaten varmış kişiler için yazılmış gibi
Ben spesifikasyonu LLM için bağlama giriş noktası olarak görüyorum
Projenin yapısını, modellerini, fonksiyonlarını ve gereksinimlerini yeterince verirseniz LLM bağlamı anlayıp genişletebilir
Üstelik LLM'nin spesifikasyonu kendisinin güncellemesini sağlarsanız Agile tarzı yinelemeler de mümkün olur
Testler, LLM için gerçekliğe sabitleme (grounding) işlevi görerek halüsinasyonları önler
Testler hem dokümantasyon hem kalite ölçütü olur ve LLM'yi junior geliştirici gibi yönetmek gerekir
Birden fazla ajanı paralel çalıştırıp test katmanı üzerinden birbirlerini doğrulamalarını sağlarsanız şaşırtıcı sonuçlar çıkıyor
Sadece LLM sayesinde tüm spesifikasyonu ucuz ve hızlı biçimde yineleyebiliyorsunuz; özü aynı
Çok uzun spesifikasyonlar tersine keşifçi düşünmeyi engelliyor
LLM'ler deterministik değil, olasılıksal sistemler; bu yüzden artık kodu değil, spesifikasyonu debug etmemiz gerekiyor
Geliştiriciler de artık bilişsel sistem mimarı (cognitive systems architect) rolüne evrilmeli
Üst seviye spesifikasyonlarla ayrıntılı bileşen spesifikasyonları aynı anda var oluyor
GitHub'ın Spec-Kit aracıyla bir CLI aracı yapmayı denedim ama çok fazla düzeltme, analiz ve yeniden yazma süreci gerekti
Waterfall'daki gibi yinelemeli geri bildirim az olduğu için bunaltıcıydı
Sonunda hatalı koda bakıp kök nedeni aramaktansa baştan başlamak daha iyi geldi
LLM ile birlikte kod yazmak güzel ama SDD bana ağır ve verimsiz bir iş akışı gibi hissettirdi
LLM bağlamı sevdiği için tekrar tekrar net talimat vermek gerekiyor
Örneğin bir NextJS uygulaması yaparken giriş, RBAC ve test öncelikli geliştirme gibi şeyleri açıkça yazıyorum
Küçük parçalarla başlayıp zamanla özellik eklemek daha uygun bir yaklaşım
Waterfall'un sorunu uzun teslim süreleri ve pahalı yineleme maliyetleriydi
SDD'de bu ikisi çözüldüğü için bence sorun yok
Birkaç saatlik spesifikasyona Waterfall demek abartı
Karmaşık çözüm alanına çok erken girerseniz basit çözümlere ulaşmak zorlaşıyor
Agile ise küçük bir alandan başlayıp aşamalı biçimde genişliyor
Spesifikasyon yeterince ayrıntılı olursa yineleme yavaşlıyor, yetersiz olursa LLM düzgün çalışmıyor
Sonuçta yöneticilerin sevdiği Waterfall çelişkisini aynen koruyor
LLM'ler de en iyi, küçük parçalara ayrılmış net talimatlarla çalışıyor
Yıllarca süren spesifikasyonlar yazıp her 6 ayda bir LLM çalıştıracaklar, başarısız olursa da suçu geliştiricilere atacaklar
Yazının yazarı benim
Hâlâ Waterfall vs Agile tartışmasının bu kadar canlı olması ilginç geliyor
SDD'yi değerli bulan insanların geçmişlerini okumak da eğlenceli
Ama ben zaten uygulamadan önce Plan modu kullandığım için SDD bana ek bir değer katmıyor
Kodlama ajanlarının bir şeyi tek seferde kusursuz uyguladığına da neredeyse hiç rastlamadım
Sonuçta yineleme gerekiyor, bu yüzden Big Design Up Front anlamını yitiriyor
Yine de kodlama ajanlarının yeni bir geliştirme paradigmasının kapısını açtığına inanıyorum
Eskiden izlediğim şu video aklıma geldi
Mühendislerle programcıların birbirlerinden öğrenebileceklerini anlatıyordu; özellikle önceden plan yapmanın önemi etkileyiciydi
Agile'ın gereksinim belgelerini öldürdüğü söyleniyor ama aslında olan şey, bunların binlerce Jira biletine bölünmesi oldu
AI bu dağınık kararları ve bağlamı eksiksiz kaydedebilir ve geçmiş tercihlerle çeliştiğinde soru sorabilir
“Jim bu kodu 5 yıl önce neden böyle yazdı, bunun gerekçesi hâlâ geçerli mi?” gibi geri bildirim verebilir
Bu yazı bana biraz tuhaf geldi
Eksik gereksinim alıp deneme-yanılmayla çözmek hem insan geliştirici hem AI için aynı şey
Bir şeyi net biliyorsanız ayrıntılı talimat vermek zaten doğru yaklaşım
Belki yazının asıl derdi “kötü spesifikasyon”dur
Genel olarak Agile endüstrisinin kendini savunma söylemi gibi görünüyor
Birden fazla Markdown spesifikasyon dosyasıyla SDD denedim; gerçekten verimli bulduğum şey ** beads** oldu
Ajanın görev ağacını takip ederek odaklanmasına yardımcı oluyor
Her görevi TDD ile bölüyor ve testler geçmeden bir sonraki adıma geçmesine izin vermiyor
Ajan, inceleme komutlarını bile söylüyor; bu da kod incelemeyi kolaylaştırıyor
Spec-Kit fazla ağır, beads ise çok daha pratik
Tamamen vibe odaklı yaptığım zmx projesini de sonradan ajan kodunu referans alarak baştan yazdım