SDD nasıl işler
Şelale modelinden spesifikasyon odaklı yapay zekâ yürütmesine: ayrıntılı teknik inceleme.
Evrim
Yazılım geliştirme nasıl evrildi
Yazılım geliştirmenin dört dönemi: katı şelale modelinden spesifikasyon odaklı yapay zekâ ajanlarına.
Waterfall
Sıralı aşamalar: gereksinimler, tasarım, uygulama, test, dağıtım. Her aşama bir sonraki başlamadan önce tamamlanır. Değişiklikler pahalıdır; geri bildirim döngüleri aylarla ölçülür.
Öngörülebilir ama yavaş. Tasarım aşamasından sonra bir değişiklik talebi tüm zaman çizelgesini sıfırlayabilirdi.
Agile
Yinelemeli sprintler, kullanıcı hikâyeleri, günlük kısa toplantılar, retrospektifler. Ekipler işi adım adım teslim eder ve değişime uyum sağlar. Ancak hız hâlâ ekip büyüklüğü ve koordinasyon yüküyle sınırlıdır.
Daha hızlı geri bildirim, ancak ölçeklemek için daha fazla kişi gerekir — daha fazla kişi de daha fazla koordinasyon demektir.
AI-Assisted
Kod tamamlama, yapay zekâ yardımcıları (copilot), sohbet tabanlı kod üretimi. Geliştiriciler tek tek hızlanır, ancak geliştirme sürecinin kendisi değişmez. Yapay zekâ yardım eder; işi hâlâ insanlar yapar.
Geliştirici başına %20–40 verimlilik artışı — ama süreç, roller ve darboğazlar aynı kalır.
SDD
Spesifikasyon, yürütülebilir bir sözleşmeye dönüşür. Yapay zekâ ajanları kodu yazar, test eder, belgeler ve dağıtır — tüm yaşam döngüsünü biçimsel spesifikasyonlarla denetleyen kıdemli bir mühendisin yönetiminde.
Daha hızlı geliştiriciler değil — temelden farklı bir süreç. Tek mühendis, önce spesifikasyon, uygulamayı yapay zekâ yapar. Temel kavram
Specification-Driven Development nedir?
Spesifikasyonun doğruluk kaynağı, yapay zekâ ajanlarının ise iş gücü olduğu bir yöntem.
Specification-Driven Development (SDD), her işlevin, servisin ve entegrasyonun tek satır kod yazılmadan önce biçimsel, makinece okunabilir bir spesifikasyon olarak başladığı bir yöntemdir.
Geliştiricilerin gereksinimleri yorumlayıp uygulama kararlarını iş üstünde verdiği geleneksel yaklaşımların aksine SDD, tüm mimari ve iş kararlarını en başta spesifikasyona taşır. Spesifikasyon bir dokümantasyon değildir — yapay zekâ ajanlarının esas aldığı tek doğruluk kaynağıdır.
Sonuç: öngörülebilir çıktı, tutarlı kalite ve spesifikasyonun derinliğiyle ölçeklenen bir geliştirme hızı — ekip büyüklüğüyle değil.
Spesifikasyon koddur
Her işlev biçimsel bir spesifikasyonla başlar: API sözleşmeleri, veri modelleri, iş kuralları, kabul kriterleri. Spesifikasyon, yapay zekâ ajanlarının hiçbir belirsizlik olmadan uygulayabileceği kadar kesindir.
İşi ajanlar yapar
Yapay zekâ ajanları uygulamayı, testleri, dokümantasyonu, CI/CD yapılandırmasını ve yerelleştirmeyi üstlenir. Her ajan, tanımlı bir rol ve katı bağlam sınırları içinde çalışır.
Kontrol insanda kalır
Kıdemli bir mühendis spesifikasyonları yazar, tüm çıktıyı inceler, mimari kararları verir ve kaliteyi doğrular. Yapay zekâ uzmanlığı güçlendirir — muhakemenin yerini almaz.
Mimari
Üç bağlam katmanı
Her yapay zekâ ajanı, tutarlılığı ve kaliteyi güvence altına alan katı bir bağlam hiyerarşisi içinde çalışır.
Sistem bağlamı
Mimari kurallar, teknoloji yığınına ilişkin kısıtlar, kodlama standartları, adlandırma kuralları ve proje genelinde geçerli değişmezler. Bu bağlam her ajan oturumuna yüklenir ve proje ortasında hiçbir zaman değişmez.
Örnek: “Java 21, Spring Boot 3.2, PostgreSQL. Tüm servisler altıgen mimariyi kullanır. REST API'ler OpenAPI 3.1 spesifikasyonuna uyar. ORM yok — jOOQ ile doğrudan SQL.”
İşlev bağlamı
Belirli bir işleve ait gereksinimler, kabul kriterleri, API sözleşmeleri, veri modelleri ve iş kuralları. Bu bağlam yalnızca mevcut görevi kapsar ve ajanın neyi geliştirmesi gerektiğini tanımlar.
Örnek: “Sertifika düzenleme servisi: POST /api/v1/certificates. Depo kapasitesini doğrular, mükerrer seri numaralarını denetler, CertificateIssued alan olayını yayımlar.”
Yürütme bağlamı
Üzerinde çalışılan dosya, fonksiyon kapsamı, test beklentileri ve doğrudan bağımlılıklar. Bu, en dar bağlam katmanıdır — ajana tam olarak nerede olduğunu ve sırada ne üretmesi gerektiğini söyler.
Örnek: “CertificateService.issue() metodunu uygula. Girdi: IssueCertificateCommand. Çıktı: CertificateDTO. Geçmesi gereken testler: CertificateServiceTest, satır 45–78.”
Yaşam döngüsü
SDD yaşam döngüsü
Spesifikasyondan canlı ortama yedi adım; her kritik aşamada insan denetimi.
- 01
Sistem spesifikasyonunun yazılması
Mimari, teknoloji yığını, kodlama standartları, API kuralları ve proje genelindeki kurallar tanımlanır. Bu belge, tüm ajanlar için değişmez sistem bağlamı olur.
- 02
İşlev gereksinimlerinin tanımlanması
Her işlev için: API sözleşmeleri, veri modelleri, iş kuralları, kabul kriterleri ve test beklentileri. Spesifikasyon, uygulamada hiçbir belirsizliğe yer bırakmayacak kadar kesin olmalıdır.
- 03
İnsan incelemesi: spesifikasyon
Mühendis, spesifikasyonu eksiksizlik, tutarlılık ve mimari sağlamlık açısından inceler. Bu, en kritik kontrol noktasıdır — burada yapılan hatalar her yere yayılır.
- 04
Yapay zekâ ajanlarıyla uygulama
Ajanlar spesifikasyonu hayata geçirir: kod yazar, testleri oluşturur, dokümantasyonu üretir, CI/CD'yi yapılandırır. Her ajan kendi rolü ve bağlam sınırları içinde çalışır.
- 05
Otomatik doğrulama
Üretilen tüm kod otomatik olarak derlenir, test edilir ve statik analizden geçirilir. Test kapsamı, tip güvenliği ve kodlama standartları CI işlem hatlarınca zorunlu kılınır — insanlarca değil.
- 06
İnsan incelemesi: çıktı
Mühendis, üretilen kodu doğruluk, uç durumlar, güvenlik ve canlı kullanıma hazırlık açısından inceler. Yapay zekâ çıktısı, insan onayı olmadan asla devreye alınmaz.
- 07
Canlı ortama alma
Onaylanan kod birleştirilir, CI/CD işlem hatları çalışır ve sistem devreye alınır. Spesifikasyondan commit'e, oradan dağıtıma kadar tam izlenebilirlik.
Spesifikasyonunuz, sabit fiyat, çalışan bir sistem.
- 01 NDA imzalanır Hiçbir ayrıntı konuşulmadan önce. Fikriniz korunur.
- 02 Ön görüşme · 30 dk Yalnızca kıdemli mühendis; satış temsilcisi ya da aracı yok.
- 03 Yazılı teklif · 24 saat Sabit kapsam, sabit fiyat veya zaman ve malzeme; tercih sizin.
- 04 48 saat içinde başlangıç Birbirimize uygunsak hemen başlayabiliriz.