Spesifikasyon odaklı geliştirme: tüm kategorinin üzerinde yakınsadığı uygulama

Her ciddi yapay zekâ kod aracı aynı işlevi yaklaşık bir yıl içinde yayına aldı ve bu neredeyse hiç tesadüfen olmaz.

2025’te ilginç soru modellerin ne kadar iyileştiğiydi. 2026’da ilginç soru onlara ne verdiğiniz.

GitHub Spec Kit’i yayınladı. AWS bu fikrin çevresinde kurulmuş bir geliştirme ortamı olan Kiro’yu yayınladı. BMAD-METHOD, OpenSpec ve Tessl birer deneme yaptı. Cursor oraya kural dosyaları üzerinden vardı. Martin Fowler bu gerçekleştirmelerin bir karşılaştırmasını yayınladı. Altı bağımsız ekip on iki ayda aynı cevapta yakınsadığında birbirlerini kopyalamıyorlar. Hepsi aynı duvara çarpıyor.

Duvarın artık bir adı var. Çözümün de.

Spesifikasyon odaklı geliştirme gerçekte nedir

Herhangi bir kod üretilmeden önce gereklilikleri, kısıtları ve başarı ölçütlerini yazın. O belgeyi doğruluğun kaynağı olarak ele alın. Ajanın ona göre kurmasına izin verin.

Hepsi bu. Yeni bir fikir değil: sektörün otuz yıl kötü yaptığı ve sonra büyük ölçüde çok yavaş olduğu gerekçesiyle bıraktığı gereklilik analizi. Değişen şey kavram değil. Değişen şey ekonomi.

Spesifikasyonlar yazması pahalıydı ve sürdürmesi pahalıydı; bu da çoğu ekibin kaba çizgiler yazıp geri kalan her şeyi kod incelemesinde keşfetmesi anlamına geliyordu. Bir mühendislik insanı bir özellik için nasılsa üç hafta gerektirdiği sürece bu makul bir ödünleşmeydi. Üretim hızlandığında makul olmaktan çıktı, çünkü şimdi yavaş kısım spesifikasyon ve tüm yargı yavaş kısımda yaşıyor.

Bunun karşısında icat edildiği arıza biçimi

Komuttan başlayan araçlar spesifikasyonu tümüyle atlıyor. Bir sonuç tanımlıyorsunuz, araç ona benzeyen bir şey üretiyor ve tanımın kapsamadığı her kararı üretici sessizce veriyor.

Hangi kararlar? Önemli olduğu ortaya çıkanlar. Bir posta adresi tek mi ve neyin içinde tek. Feshedilmiş bir hesap hâlâ neyi görebiliyor. İki kişi aynı kaydı değiştirdiğinde ne oluyor. O liste on bin satıra sahip olmadan önce sayfalamaya ihtiyaç duyuyor mu.

Bu soruları kimse sormadı, o yüzden kimse cevaplamadı ama uygulamanın her birine bir cevabı var; hiçbir zaman şirketinizi içermemiş bir bağlamdan çıkarımla seçilmiş.

Aynı dinamik tanım adımını atlayan her araçta ortaya çıkıyor. Bu, yüzde 70 sorununun arkasındaki mekanizma: ilerleme kalan iş zor olduğu için değil, yüzlerce üretim önce sessizce verilmiş ve sistemi sökmeden artık değiştirilemeyen bir mimari karar tarafından engellendiği için duruyor.

Onsuz ne olduğuna dair veriler

DORA’nın 2025 yapay zekâ destekli yazılım geliştirme durumu raporu, mevcut en temiz okuma. Teknolojide çalışan kişilerin yüzde 90’ı artık işte yapay zekâ kullanıyor ve yüzde 80’den fazlası üretkenliklerini artırdığına inanıyor. Ve daha yüksek yapay zekâ kullanımı, teslim verimindeki artışla ve teslim kararsızlığındaki artışla aynı zamanda birlikte gidiyor.

Yayına almada daha hızlı. Şeyleri çalışır durumda tutmada daha kötü. İkisi birlikte.

GitClear’ın 623 milyon kod değişikliği üzerindeki 2026 analizi hasarın biçimini gösteriyor. 2023 taban çizgisine göre: tekrarlanmış kod blokları yüzde 81 yukarıda, tek bir gönderim içinde kopyala yapıştır 2022’de yüzde 9,4’ten 2026’nın ilk yarısında yüzde 15,7’ye çıktı, hata maskeleyen yapılar yüzde 47 yukarıda. Aynı zamanda dosyalar arası işlev çağrıları, kod yeniden kullanımının mevcut en iyi göstergesi, yüzde 35 aşağıda ve kodu düzenleme çalışması 2022’de değişikliklerin yüzde 21’inden 2026’da yüzde 3,8’e çöktü.

Mühendislik insanları artık kodu düzenlemekten yaklaşık beş kat daha sık kopyalayıp yapıştırıyor. 2022’de bu oran diğer yöne işliyordu.

Bunların hiçbiri model kalitesi meselesi değil. Üretim ucuz ve yapı açıkça kimsenin işi olmadığında ortaya çıkan sonuç.

Üç bağlılık derecesi

Herkes bu ifadeyi aynı biçimde anlamıyor ve farklar pratikte önemli. Martin Fowler’ın çerçevelemesi gördüğüm en temiz olan.

Önce spesifikasyon. Bir spesifikasyon yazıyorsunuz, ondan üretiyorsunuz, sonra kodu elle sürdürüyorsunuz. Spesifikasyon ilk kurmayı besliyor, sonra kademeli olarak tarihsel hale geliyor. Uygulaması en kolay, güvenceleri en zayıf: altı ay sonra belge artık var olmayan bir sistemi tanımlıyor.

Çapa olarak spesifikasyon. Spesifikasyon ve kod birlikte gelişiyor. Spesifikasyonu değiştiriyorsunuz, etkilenen kısımları yeniden üretiyorsunuz, ikisini güncel tutuyorsunuz. Daha fazla disiplin ve ödül, belgenin güvenilir kalması.

Kaynak olarak spesifikasyon. Spesifikasyon değiştirdiğiniz tek yapıntı. Kod, derlenmiş bir dosyanın çıktı olması gibi çıktı: elle yamalanmıyor. En güçlü güvenceler ve ekibin çalışma biçiminde en büyük sıçrama.

Kendini spesifikasyon odaklı diye adlandıran ekiplerin çoğu “önce spesifikasyon” çeşidini uyguluyor. Bu, körlemesine komut vermeye göre gerçek bir iyileşme ve aynı zamanda sessizce çürüyen sürüm.

Spesifikasyona ne girer

Kullanışlı bir sınama: üretici tahmin etmek zorunda kalacaksa belgeye girer.

• Veri modeli. Varlıklar, ilişkiler, çokluk, bir kaydı tek kılan şey, silmede ne olduğu. En değerli kısım ve en sık atlanan kısım.
• Kullanıcı tipleri ve izinler. Kim var, her biri neyi görebiliyor ve yapabiliyor, sınırlarda ne oluyor.
• Değişmezler. Asla ihlal edilmemesi gereken kurallar, açıkça belirtilmiş. “Hataları zarifçe işle” değil, çünkü bu bir kısıt değil bir dilek.
• Başarı ölçütleri. Şeyin çalıştığını nasıl anlayacağınız; çalışıp çalışmadığı tartışmasının çözülebileceği kadar kesin sözlerle.

Ona girmeyen şey: üreticinin sizden daha iyi seçtiği gerçekleştirme ayrıntıları. Değişken adlandıran bir spesifikasyon spesifikasyon değil, daha kötü bir araçla yazılmış koddur.

Herkesin yanlış yaptığı kısım

Spesifikasyon yalnızca metnin dışında bir yerde zorunlu kılınabiliyorsa yardım ediyor.

Bir kısıt yalnızca belgede yaşıyorsa bir öneridir. Üretici onu bir kez okudu ve etkilenen on dördüncü dosyada ona saygı gösterebilir de göstermeyebilir de. Kısıtların sistemin denetlediği yere gitmesi gerekiyor: “boş değil” ve “tek” form işleyicide değil veritabanında, tipler bir yorumda değil sınırlarda, yetkilendirme birinin yazmayı hatırladığı bir koşul değil sistemin değerlendirdiği bir ilke.

Bu, bir uygulama olarak spesifikasyon odaklı geliştirme ile bir belge türü olarak spesifikasyon odaklı geliştirme arasındaki fark. Belge, nasıl karar verdiğiniz. Zorunlu kılma, kararı nasıl koruduğunuz.

Gerçekten uyguluyor musunuz nasıl anlaşılır

Dört soru, bilinçli olarak rahatsız edici.

1. Bir şey bozulduğunda kodu mu spesifikasyonu mu düzeltiyorsunuz? Cevap her zaman kodsa, en iyi durumda “önce spesifikasyon” uyguluyorsunuz ve belge çoktan eskimiş.
2. Yeni biri spesifikasyonu okuyup sistemin nasıl davranacağını öngörebilir mi? Bunun için kodu okumak zorunda kalacaksa spesifikasyon bir kaynak değil bir özet.
3. Spesifikasyonda sistemin ihlal edemeyeceği bir şey var mı? Her kural metinse hiçbiri güvence altında değil.
4. Spesifikasyonu mu kod değişikliğini mi gözden geçiriyorsunuz? Binlerce satır üretilmiş kodu gözden geçirmek tiyatro. Tartışma hâlâ ucuzken belge üzerine tartışın.

Bu, araçları nerede bırakıyor

Bugünkü gerçekleştirmelerin çoğu özellikle kod üretimi için spesifikasyon odaklı. Bir spesifikasyon üretiyorlar ve gerçekleştirmeyi ona göre üretiyorlar; üzerinde işledikleri yapıntı ise kod tabanı.

Daha zor sürüm aynı mantığı tüm uygulamaya (veri modeli, programlama arayüzü yüzeyi, kimlik doğrulama sınırı, arayüz) yayıyor; böylece spesifikasyon yalnızca kodun ne yaptığını değil sistemin ne olduğunu kapsıyor. Archie’nin plan aşaması tam olarak bu ve bu yüzden onu bir depoya değil tüm yığına uygulanmış spesifikasyon odaklı geliştirme olarak tanımlıyorum. Farklı kapsam, aynı ilke: üretmeden önce tanımla.

Makul kişiler bunun ne kadar ileri götürüleceği konusunda anlaşmıyor. Ciddi hiç kimse geri dönmeyi savunmuyor.

Bunun bedeli ne

Yargıyı başa kaydırmak bir projenin ilk haftasında daha yavaş ve sonraki her haftada daha hızlı. Bu maliyet gerçek ve tam olarak ivmenin en değerli göründüğü ve bir rakibin görünür bir şey yayına aldığı anda ödeniyor. Bunu atlayan ekibin önde göründüğü iş turları olacak.

Disiplin de çürüyor. Kısıtları yazmak bir arayüzün belirmesini izlemekten daha az keyifli ve bir belgeyi gözden geçirmek kodu gözden geçirmekten daha az doyurucu. Bu alışkanlıklar teslim tarihi baskısı altında eriyor ve bu, onları önemli kılan aynı baskı.

Ve gerçekten her şeye uygulanmıyor. Bu hafta sonu bir fikri sınıyorsanız ve sonucu atmayı planlıyorsanız atın. Bunların hiçbiri iki günlük ömrü olan yazılım için zahmete değmez.

Bunun kalmasının nedeni

Ekipleri önce spesifikasyon yazmaya ikna etmeye yönelik her önceki girişim başarısız oldu ve iyi bir nedenle başarısız oldu: spesifikasyon gerçek işin üstünde ek bir yüktü. Belgeyi yazıyordunuz, sonra nasılsa şeyi kurmak zorundaydınız.

Bu artık o ödünleşme değil. Şimdi belge işin çoğu ve kurma ucuz kısım. Altı bağımsız ekip bunu bir yıl içinde fark etti, çünkü modelin iyileşmesinin apaçık sonucuydu.

Bu uygulama tartışmayı kazanmadı. Ekonomi onun altında kaydı.

İlgili okumalar

İlk teşhis: vibe coding sözünü tutmadı. Kategorinin nereye gittiği: vibe coding sonrasında ne var. Aynı savın tüm sistemlere uygulanışı: ilk ilkelerden yapay zekâ öncelikli yazılım tasarımı. Ve aynı fikrin daha eski bir çerçevelemesi: yazılımı iki kez yazmamak.

Sıkça sorulan sorular

Spesifikasyon odaklı geliştirme nedir? Herhangi bir kod üretilmeden önce gereklilikleri, kısıtları ve başarı ölçütlerini yazmak ve o spesifikasyonu, yapay zekâ ajanının karşısında kuracağı doğruluk kaynağı olarak ele almak. 2025 ve 2026’da, komuttan başlayan ve tanım adımını atlayan çalışma biçimlerine doğrudan bir yanıt olarak ortaya çıktı.

Klasik gereklilik belgelerinden nasıl farklı? Kavram aynı; ekonomi değil. Klasik spesifikasyonlar oldukça pahalıydı, o yüzden ekipler kaba çizgiler yazdı ve geri kalanını yürütme sırasında keşfetti. Bir tanesini hazırlamak aylar değil saatler sürdüğünde ve ucuza düzeltilebildiğinde onu bitirmeye ve güncel tutmaya değer.

Spesifikasyon odaklı geliştirmeyi hangi araçlar destekliyor? GitHub Spec Kit, AWS Kiro, BMAD-METHOD, OpenSpec ve Tessl adlandırılmış gerçekleştirmeler; Cursor ise kural dosyaları üzerinden daha hafif bir sürümü destekliyor. Esasen spesifikasyonun koda ne kadar sıkı bağlandığı konusunda ayrışıyorlar: üretimi bir kez mi besliyor, yanında mı gelişiyor, yoksa değiştirdiğiniz tek yapıntı mı?

Spesifikasyon odaklı geliştirmenin üç derecesi hangileri? Önce spesifikasyon: spesifikasyon ilk kurmayı besliyor ve kodu sonradan elle sürdürüyorsunuz. Çapa olarak spesifikasyon: spesifikasyon ve kod birlikte gelişiyor. Kaynak olarak spesifikasyon: spesifikasyon değiştirdiğiniz tek şey ve kod çıktı olarak ele alınıyor. Bunu uygulayan ekiplerin çoğu “önce spesifikasyon” yapıyor.

Spesifikasyon odaklı geliştirme ekipleri yavaşlatıyor mu? İşi eklemek yerine kaydırıyor. Spesifikasyondaki kararlar ya baştan bilinçle ya da sonradan tahmin eden üretici tarafından sessizce veriliyor ve ikinci yol düzeltmelerin kaynağı. İlk haftada daha yavaş, sonrasında daha hızlı.

Spesifikasyona ne girmeli? Üreticinin aksi halde tahmin etmek zorunda kalacağı her şey: ilişkileri ve teklik kurallarıyla veri modeli, kullanıcı tipleri ve izinler, asla ihlal edilmemesi gereken değişmezler ve bir tartışmayı çözecek kadar kesin başarı ölçütleri. Üreticinin sizden daha iyi seçtiği gerçekleştirme ayrıntılarını atlayın.

Spesifikasyon odaklı geliştirme, yapay zekâ öncelikli tasarımla aynı şey mi? Spesifikasyon odaklı geliştirme, üretmeden önce tanımlama uygulaması. Yapay zekâ öncelikli tasarım, kısıtların nerede zorunlu kılındığını, kararların hangi sırada verildiğini ve insan kullanıcıların yanında ajan kullanıcılar için nasıl tasarlanacağını da kapsayan daha geniş bir mimari sonuçlar kümesi.