Birkaç yıl önce bir özelliği hayata geçirmenin en yavaş kısmı kod yazmaktı. Artık değil. Bugün bir yapay zekâ agent’ına birkaç cümle yazıp çalışan bir ekran almak dakikalar sürüyor. Ekiplerin çoğunda bunun beklenmedik bir sonucu oldu: hız arttıkça darboğaz yer değiştirdi. Artık asıl sorun kodu ne kadar çabuk ürettiğimiz değil, ne istediğimizi ne kadar net söyleyebildiğimiz.
Spec-driven development tam olarak bu boşluktan doğdu.
Nedir, ne değildir, neden şimdi?
Spec-driven development (SDD), spesifikasyonu sürecin başındaki bir formalite olmaktan çıkarıp kodun türetildiği kaynak haline getiren bir yaklaşım. Thoughtworks’ten Liu Shangqi’nin tanımı sade: iyi kurgulanmış yazılım gereksinim spesifikasyonlarını, yapay zekâ kodlama agent’ları aracılığıyla çalıştırılabilir koda dönüştüren bir geliştirme yöntemi.
Buradaki ilk itiraz tahmin edilebilir: “Bu waterfall’a dönüş değil mi?” Değil, ama neden olmadığını söylemek gerekiyor. Waterfall’ın asıl problemi baştan doküman yazmak değildi; geri bildirim döngüsünün aylarca sürmesiydi. Yazılan doküman ile ortaya çıkan sistem arasındaki mesafe zamanla açılıyor, kimse dokümana geri dönmüyordu. İdeal bir SDD akışında spec versiyonlanıyor, değişiyor ve her değiştiğinde çıktı yeniden üretiliyor — uygulamadan uygulamaya bu döngünün sıkılığı değişse de, yöntemin iddiası bu. Doküman rafta değil, döngünün içinde.
Bunun şimdi konuşuluyor olmasının nedeni de bu. Yapay zekâ agent’ları kod yazmakta iyi, ne kastettiğinizi tahmin etmekte kötü. Belirsiz bıraktığınız her şeyi makul görünen bir varsayımla dolduruyorlar. Kod incelemesinde bu varsayımı yakalasanız bile, spec’te karşılığı yoksa bir sonraki üretimde aynı boşluk yeni bir kılıkta geri geliyor.
Bu alanda araç sayısı hızla artıyor ve her biri kendi akışını dayatıyor; ancak yöntemin kendisi araçtan bağımsız, o yüzden bu yazıda araçlara girmiyorum.
İyi bir spec neye benziyor?
Kısa cevap: pazarlama metnine değil, teknik şartnameye benziyor.
Pratikte işe yarayan spec’lerin ortak yanı şu beş başlığı ayrı ayrı yazmaları: amaç (ne için yapıyoruz), kapsam dışı (kasten yapmadığımız şeyler), kısıtlar, kabul kriterleri ve doğrulama yöntemi. Bunlardan en çok atlanan ikisi kapsam dışı ve kısıtlar. Oysa bir agent’ın en çok savrulduğu yer tam olarak orası.
Kabul kriterlerini yapılandırılmış bir dille yazmak da işi belirgin biçimde kolaylaştırıyor; EARS (Easy Approach to Requirements Syntax) gibi kalıplar (“… olduğunda, sistem … yapacaktır”) tam da bu amaçla var. Yıllardır requirement okurken kendimi hep aynı cümleyi kurarken buluyorum: “Bu bir requirement değil, bu bir temenni.” Fark şurada: “Mükerrer işlem oluşmamalı” bir temenni — niyeti anlatır ama kimin, ne zaman, nasıl doğrulayacağını söylemez. “Aynı işlem numarasıyla gelen ikinci talep alındığında, sistem yeni kayıt oluşturmayacak ve ilk kaydın sonucunu döndürecektir” ise bir kural. İkincisi test edilebilir, birincisi sadece tartışılabilir — ve tartışılabilir olan her şey, agent’ın elinde bir varsayıma dönüşür.
Havacılıkta bunun yarısı zaten vardı
Benim gibi regüle bir sektörde çalışıyorsanız buraya kadarki hiçbir şey size yeni gelmedi. Havacılıkta bir gereksinimin nereden geldiği, hangi tasarım kararına bağlandığı ve hangi testle doğrulandığı zaten kayıt altında olmak zorunda. İzlenebilirlik bir tercih değil, denetimde önünüze konan bir soru. “Bunu neden böyle yaptınız?” sorusunun beş yıl sonra sorulacağını bilerek yazı yazmaya alışıksınız.
Yani spec kültürü bizde yeni değil. Yeni olan şey, o belgeyi artık yalnızca insanların okumaması. Aynı doküman şimdi bir de doğrudan uygulayıcı tarafından okunuyor ve içindeki her boşluk somut bir çıktıya dönüşüyor.
Bu, regüle sektörden gelen analiste ciddi bir avantaj sağlıyor. Uyum sağlaması gereken tek şey belgenin ritmi: onay alıp dondurulan bir doküman değil, sürekli güncellenen canlı bir metin.
Peki bu spec’i kim yazıyor?
Şirkete göre bu kişinin unvanı iş analisti, sistem analisti ya da product owner olabilir. Değişen unvan değil, o kişinin ürettiği çıktının ağırlığı.
İş analisti ile product owner rollerini aynı kişide yürütmenin de kendine özgü bir yükü var; bunu ayrı bir yazıda ele almıştım. Ama unvan ne olursa olsun, spec-driven bir akışta bu kişinin ürettiği metnin ağırlığı aynı: eskiden kötü yazılmış bir kabul kriterinin bedeli bir yanlış anlaşılma ve bir toplantıydı; geliştirici gelir sorardı, konuşulur düzeltilirdi. O tampon ortadan kalkıyor. Belirsiz bırakılan bir cümle artık doğrudan yanlış davranan bir özellik olarak geri dönüyor.
Bu yüzden analistlik işinin ağırlık merkezi kaymış durumda. Değerli olan şey daha uzun doküman yazmak değil; belirsizliği fark etmek, kimsenin sormadığı sınır durumunu sormak, kapsam dışını açıkça yazmak ve iş kuralını temenni değil kural olarak ifade edebilmek. Yapay zekâ bunların hiçbirini sizin yerinize yapmıyor. Yapabildiği tek şey, yaptığınız işin kalitesini eskisinden çok daha hızlı görünür kılmak.
Dürüst olmak gerekirse: bu yaklaşımın sorunları da var
Bunu bir çözüm olarak sunmak yanlış olur. Üç itiraz ciddiye alınmayı hak ediyor.
Birincisi spec şişmesi. Her şeyi yazma dürtüsü, bir süre sonra kimsenin okumadığı yüz sayfalık belgeler üretiyor — waterfall’ı kovup pencereden geri almak.
İkincisi, “spec artık tek doğruluk kaynağıdır” iddiasının abartılı olması. Üretimde çalışan şey hâlâ kod. Spec niyeti tarif eder, testler onu zorlar; ikisi de kodun yerine geçmez.
Üçüncüsü ve bence en önemlisi: bir spec’in ne zaman yeterli olduğunu ölçecek sistematik bir yöntemimiz yok. Thoughtworks’ün kendi yazısında da geçen bir itiraf bu. Değerlendirme ölçütü olmayan bir pratikte “kullanıyoruz ve işler yolunda gidiyor” demek, yöntemin işe yaradığının kanıtı değil; sadece henüz büyük bir hata yapmadığımızın göstergesi.
Nereden başlamalı
Süreci baştan kurgulamaya çalışmayın. Bir sonraki iş için tek bir şey deneyin: kabul kriterlerini yapılandırılmış biçimde, test edilebilir cümlelerle yazın ve geliştirmeden kaç soru geri geldiğini sayın.
Yapay zekâ, analistin işini elinden almıyor. Sadece kötü yazılmış bir gereksinimin bedelini bir toplantıdan bir sürüme yükseltiyor.