Yazılımı iki kez yazmamak: spesifikasyon odaklı geliştirme ve yeniden yazmaların sonu
Yazılım neden her zaman iki kez yazıldı, bir kez spesifikasyonlarda ve bir kez kod olarak, ve o ikinci yazım neden nihayet ortadan kalkıyor.
Yazılım geliştirmede, doğru yapıldığında, yazılımı iki kez yazmamız gerekiyor: önce yazılımın tam olarak ne yapması gerektiğini açıklayan ayrıntılı spesifikasyonlarda, sonra o spesifikasyonları hayata geçiren kod olarak. Ama işte sert gerçek: bu ilk seferde nadiren doğru yapılıyor.
Süreç sıkça dağılıyor, çünkü kapsamlı spesifikasyonlar oluşturmak zaman alıyor ve ekipler ihtiyaç duydukları tüm ayrıntıları nadiren baştan topluyor. Bu, boşluklara, varsayımlara ve pahalı düzeltmelere yol açıyor. Sonuç olarak projeler bütçeyi aşıyor, teslim tarihlerini kaçırıyor ve herkesi hüsrana uğramış halde bırakıyor.
Yazılımı iki kez yazmanın gizli maliyetleri
İki kez yazmanın neden gerekli ama nadiren iyi yapıldığını anlamak için iki aşamayı ayıralım.
1. İlk yazım: doğal dilde spesifikasyonlar
Yazılımı ilk yazdığınızda hiç kod yazmıyorsunuz. Gereklilikler, kullanıcı öyküleri ve doğal dilde yazılmış tasarım belgeleri ortaya çıkıyor. Burada ekipler yazılımın nasıl çalışması gerektiğini, kullanıcıların ne yapabileceğini ve deneyimin ne olması gerektiğini tanımlıyor.
Ama işte sorun: hiçbir ekip tüm ayrıntıları yazma lüksüne sahip olmuyor. Ürün insanları sıkça sıkışık teslim tarihlerine sığmak için acele etmek zorunda kalıyor ve bazı projelerde profesyonel bir ürün rolü bile yok. Kaba çizgiler çekiliyor ama önemli özellikler ve etkileşimler kaçıyor. Steve Jobs’un ünlü sözü, “büyük ürünler 5000 küçük karardan doğar” ama çoğu projede bu kararları baştan vermiyoruz. Sonradan mühendislik tarafından yorumlanmaya bırakılıyorlar; bu da ikinci adıma götürüyor.
2. İkinci yazım: spesifikasyonları koda çevirmek
Spesifikasyonlar teslim edildiğinde mühendislik o tanımları çalışan koda dönüştürmekten sorumlu oluyor. Ama ilk yazım eksik olduğunda boşlukları doldurmak için hayal gücünü kullanmak zorunda kalıyor. Varsayımlar oluşuyor ve mühendislik insanları teknolojiye iyi hâkim olsa bile ürün vizyonunun tam resmine sahip olmayabiliyorlar.
Sorunlar burada yüzeye çıkıyor:
- Eksik ayrıntılar sürtünme yaratıyor: ürün ekipleri önemli bir özelliği ya da kullanım durumunu tanımlamadığında mühendisliğin tahmin etmesi ya da doğaçlaması gerekiyor. Bu sıkça beklentileri karşılamayan bir işlevsellik veriyor.
- Varsayımlar düzeltmelere yol açıyor: mühendislik boşlukları doldurduğunda özellikleri ürün vizyonuyla tutarsız biçimde kurabiliyor; bu da projede sonradan büyük düzeltmelere neden oluyor.
- Parmakla işaret etmek kaçınılmaz hale geliyor: teslim tarihleri kaydığında ve bütçeler patladığında ekipler suçu birbirine atıyor. Ürün ekipleri mühendisliği “anlamamakla” suçluyor, mühendislik ise belirsiz spesifikasyonları gösteriyor.
Sonuç, kaçırılan teslim tarihlerine, aşılan bütçelere ve tatmin etmeyen çıktılara götüren bir sorun çığı. Standish Group’un CHAOS araştırması yıllardır projelerin çoğunun bütçeyi aştığını ve teslim tarihlerini kaçırdığını gösteriyor. McKinsey’in Oxford Üniversitesi ile yaptığı bir araştırma, büyük bilgi teknolojisi projelerinin bütçeyi ortalama yüzde 45 ve süreyi yüzde 7 aştığını, aynı zamanda öngörülenden yüzde 56 daha az değer teslim ettiğini ve büyük bilgi teknolojisi projelerinin yüzde 17’sinin o kadar kötü gittiğini, şirketin varlığını tehdit ettiğini buldu.
Açıkça bu süreçte bir şey bozuk.
Bu uygulamanın artık bir adı var
Sektör bir terimde anlaştı, çoğu insan komutlar üzerine tartışırken: spesifikasyon odaklı geliştirme. Önce gereklilikleri, kısıtları ve başarı ölçütlerini yaz. O spesifikasyonu doğruluğun kaynağı olarak ele al. Ajanın ona göre kurmasına izin ver.
GitHub Spec Kit’i yayınladı. AWS Kiro’yu yayınladı. BMAD-METHOD, OpenSpec ve Tessl birer deneme yaptı. Martin Fowler bunun hakkında yazdı. Yakınsama bir tesadüf değil: tüm bir kategori aynı anda aynı arıza biçimini keşfettiğinde olan şey.
Ve o arıza biçimi yukarıda tanımlandı. Komuttan başlayan araçlar ilk yazımı tümüyle atlıyor. Doğrudan ikinciye gidiyor, spesifikasyonun hiç vermediği her kararda tahmin ediyorlar. Bu bir gösterim için sorun değil, bir ürün için yıkıcı.
Spesifikasyon odaklı geliştirme ilk yazımı ortadan kaldırmıyor. Onu insan yargısı gerektiren tek yazım haline getiriyor.
Yeni ilk yazım: gerçekten bitirebileceğiniz spesifikasyonlar
Değişen şey bu. Kimsenin eksiksiz spesifikasyon yazmamasının nedeni asla isteksizlik değildi: iş, kendini haklı çıkaracak kadar hızlı değildi. İlk iş turunun ilk temasında yaşlanan bir belge için haftalarca keşif. Dolayısıyla ekipler kaba çizgiler çizdi ve 5000 küçük kararı sonradan, birer birer yorumlanarak keşfedilmeye bıraktı.
Bir spesifikasyon hazırlamak aylar değil saatler sürdüğünde hesap tersine dönüyor. Konuyu tüketmeyi karşılayabiliyorsunuz. İşlevsel gereklilikler, görsel tasarım, veri modeli, kenar durumlar: düzenleyiciyi açmadan önce toplanmış ve bir şey öğrendiğinizde düzeltmesi yeterince ucuz.
Bu son kısım önemli. Ucuza düzeltemediğiniz bir spesifikasyon, gerçeklik geldiği anda bir yalana dönüşüyor. Bu, önce programlama arayüzü ile kurmanın arkasındaki aynı içgüdü: taşıyıcı kararları biri bir ekran yazmadan önce iyi vermek; geri kalanı onu izliyor.
Yeni ikinci yazım: çeviri değil kod üretimi
Spesifikasyon eksiksiz olduğunda ikinci yazım bir çeviri sorunu olmaktan çıkıyor. Bir üretim sorunu haline geliyor. Standart diller: JavaScript, TypeScript, Python. Standart çatılar: React, Next.js. Mühendisliğin zaten bildiği biçimlerde gerçek kod; her kararı çoktan vermiş bir belgeden türetilmiş.
Fark, mühendisliğin daha hızlı çalışması değil. Mühendisliğin hiç mühendislik olmamış kısmı yapmayı bırakması: başka birinin çoktan verdiği kararların makine gibi tekrarlanması.
Sonrasında ne değişiyor
Üç şey birlikte değişiyor:
- İlk yazım bitiyor: spesifikasyon işi aylar değil saatler sürdüğünde ekipler küçük kararları baştan vermeyi karşılayabiliyor, onları gözden geçirmede keşfetmek yerine.
- Boşlukları kimse doldurmuyor: eksiksiz bir spesifikasyondan üretilen kod, kimsenin ürün ekibinin ne demek istediğini tahmin etmesini gerektirmiyor. Tahmin her zaman kusurların kaynağıydı.
- Düzeltmeler birikmeyi bırakıyor: amaç ile gerçekleştirme uyumlu başlıyor. Daha önce yeniden yazma olan şey, spesifikasyonda bir değişikliğe dönüşüyor.
Yazılım yazmanın geleceği: doğal dil
İnsanlar yazılım yayına aldığından beri iş, onu iki kez yazmayı gerektirdi: bir kez doğal dilde, bir kez kod olarak. O ikinci yazım hiçbir zaman değerli kısım değildi. Başka bir yol olmadığı için ödediğimiz bir geçiş ücretiydi.
Bu, yapay zekâ uygulama oluşturucularının sonraki kuşağının çevresinde düzenlendiği hamle: koddan önce netlik. Uygulamayı bir plan olarak tanımla, mimariyi doğru kur, kodun ona göre üretilmesine izin ver. Tanım işini atlayan bir kısayol değil, onu nihayet düzgün yapmak için bir neden.
Artık başka bir yol var. Yazılım her zaman bir kez yazılmalıydı.
İlgili okumalar
Bu uygulamanın tam rehberi: spesifikasyon odaklı geliştirme. Komuttan başlayan kuşağın bu adımı neden atladığı vibe coding sözünü tutmadı yazısında, yerini neyin aldığı vibe coding sonrasında ne var yazısında.
Sıkça sorulan sorular
Spesifikasyon odaklı geliştirme nedir? Spesifikasyon odaklı geliştirme, 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 anlamına geliyor. 2025’te, komuttan başlayan ve tanım adımını tümüyle atlayan çalışma biçimlerine doğrudan bir yanıt olarak ortaya çıktı.
Spesifikasyon odaklı geliştirme klasik bir gereklilik belgesi yazmaktan nasıl farklı? Belge aynı fikir; ekonomi değil. Klasik spesifikasyonlar oldukça pahalıydı, o yüzden ekipler kaba çizgiler yazdı ve geri kalanını kod incelemesinde keşfetti. Bir spesifikasyon 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, kodun yanında mı gelişiyor, yoksa değiştirdiğiniz tek yapıntı mı?
Spesifikasyon odaklı geliştirme ekipleri yavaşlatıyor mu? İşi ekliyor değil kaydırıyor. Bir spesifikasyonda toplanan kararlar zaten biri tarafından veriliyor: ya baştan bilinçle ya da sonradan mühendislik veya model tahmin ettiğinde sessizce. İkinci yol, düzeltmelerin kaynağı.
Kod spesifikasyondan üretiliyorsa mühendisliğe ne oluyor? Başkasının kararlarının makine gibi tekrarlanması ortadan kalkıyor. Mimari, ödünleşmeler, doğruluk ve neyin kurulmayacağı hakkındaki yargı ortadan kalkmıyor. Bunlar her zaman bir mühendislik insanı gerektiren kısımlardı.
