{"id":348,"date":"2026-08-28T06:59:43","date_gmt":"2026-08-28T04:59:43","guid":{"rendered":"https:\/\/goktugturan.com\/blog\/?p=348"},"modified":"2026-08-28T07:01:24","modified_gmt":"2026-08-28T05:01:24","slug":"spec-driven-development-analist","status":"publish","type":"post","link":"https:\/\/goktugturan.com\/blog\/spec-driven-development-analist\/","title":{"rendered":"Spec-Driven Development: Yapay Zek\u00e2 Kod Yazarken Analistin \u0130\u015fi Ne Olacak?"},"content":{"rendered":"\n

Birka\u00e7 y\u0131l \u00f6nce bir \u00f6zelli\u011fi hayata ge\u00e7irmenin en yava\u015f k\u0131sm\u0131 kod yazmakt\u0131. Art\u0131k de\u011fil. Bug\u00fcn bir yapay zek\u00e2 agent’\u0131na birka\u00e7 c\u00fcmle yaz\u0131p \u00e7al\u0131\u015fan bir ekran almak dakikalar s\u00fcr\u00fcyor. Ekiplerin \u00e7o\u011funda bunun beklenmedik bir sonucu oldu: h\u0131z artt\u0131k\u00e7a darbo\u011faz yer de\u011fi\u015ftirdi. Art\u0131k as\u0131l sorun kodu ne kadar \u00e7abuk \u00fcretti\u011fimiz de\u011fil, ne istedi\u011fimizi ne kadar net s\u00f6yleyebildi\u011fimiz.<\/p>\n\n\n\n

Spec-driven development tam olarak bu bo\u015fluktan do\u011fdu.<\/p>\n\n\n\n

Nedir, ne de\u011fildir, neden \u015fimdi?<\/h2>\n\n\n\n

Spec-driven development (SDD), spesifikasyonu s\u00fcrecin ba\u015f\u0131ndaki bir formalite olmaktan \u00e7\u0131kar\u0131p kodun t\u00fcretildi\u011fi kaynak haline getiren bir yakla\u015f\u0131m. Thoughtworks’ten Liu Shangqi’nin tan\u0131m\u0131 sade: iyi kurgulanm\u0131\u015f yaz\u0131l\u0131m gereksinim spesifikasyonlar\u0131n\u0131, yapay zek\u00e2 kodlama agent’lar\u0131 arac\u0131l\u0131\u011f\u0131yla \u00e7al\u0131\u015ft\u0131r\u0131labilir koda d\u00f6n\u00fc\u015ft\u00fcren bir geli\u015ftirme y\u00f6ntemi.<\/p>\n\n\n\n

Buradaki ilk itiraz tahmin edilebilir: “Bu waterfall’a d\u00f6n\u00fc\u015f de\u011fil mi?” De\u011fil, ama neden olmad\u0131\u011f\u0131n\u0131 s\u00f6ylemek gerekiyor. Waterfall’\u0131n as\u0131l problemi ba\u015ftan dok\u00fcman yazmak de\u011fildi; geri bildirim d\u00f6ng\u00fcs\u00fcn\u00fcn aylarca s\u00fcrmesiydi. Yaz\u0131lan dok\u00fcman ile ortaya \u00e7\u0131kan sistem aras\u0131ndaki mesafe zamanla a\u00e7\u0131l\u0131yor, kimse dok\u00fcmana geri d\u00f6nm\u00fcyordu. \u0130deal bir SDD ak\u0131\u015f\u0131nda spec versiyonlan\u0131yor, de\u011fi\u015fiyor ve her de\u011fi\u015fti\u011finde \u00e7\u0131kt\u0131 yeniden \u00fcretiliyor \u2014 uygulamadan uygulamaya bu d\u00f6ng\u00fcn\u00fcn s\u0131k\u0131l\u0131\u011f\u0131 de\u011fi\u015fse de, y\u00f6ntemin iddias\u0131 bu. Dok\u00fcman rafta de\u011fil, d\u00f6ng\u00fcn\u00fcn i\u00e7inde.<\/p>\n\n\n\n

Bunun \u015fimdi konu\u015fuluyor olmas\u0131n\u0131n nedeni de bu. Yapay zek\u00e2 agent’lar\u0131 kod yazmakta iyi, ne kastetti\u011finizi tahmin etmekte k\u00f6t\u00fc. Belirsiz b\u0131rakt\u0131\u011f\u0131n\u0131z her \u015feyi makul g\u00f6r\u00fcnen bir varsay\u0131mla dolduruyorlar. Kod incelemesinde bu varsay\u0131m\u0131 yakalasan\u0131z bile, spec’te kar\u015f\u0131l\u0131\u011f\u0131 yoksa bir sonraki \u00fcretimde ayn\u0131 bo\u015fluk yeni bir k\u0131l\u0131kta geri geliyor.<\/p>\n\n\n\n

Bu alanda ara\u00e7 say\u0131s\u0131 h\u0131zla art\u0131yor ve her biri kendi ak\u0131\u015f\u0131n\u0131 dayat\u0131yor; ancak y\u00f6ntemin kendisi ara\u00e7tan ba\u011f\u0131ms\u0131z, o y\u00fczden bu yaz\u0131da ara\u00e7lara girmiyorum.<\/p>\n\n\n\n

\u0130yi bir spec neye benziyor?<\/h2>\n\n\n\n

K\u0131sa cevap: pazarlama metnine de\u011fil, teknik \u015fartnameye benziyor.<\/p>\n\n\n\n

Pratikte i\u015fe yarayan spec’lerin ortak yan\u0131 \u015fu be\u015f ba\u015fl\u0131\u011f\u0131 ayr\u0131 ayr\u0131 yazmalar\u0131: ama\u00e7 (ne i\u00e7in yap\u0131yoruz), kapsam d\u0131\u015f\u0131 (kasten yapmad\u0131\u011f\u0131m\u0131z \u015feyler), k\u0131s\u0131tlar, kabul kriterleri ve do\u011frulama y\u00f6ntemi. Bunlardan en \u00e7ok atlanan ikisi kapsam d\u0131\u015f\u0131 ve k\u0131s\u0131tlar. Oysa bir agent’\u0131n en \u00e7ok savruldu\u011fu yer tam olarak oras\u0131.<\/p>\n\n\n\n

Kabul kriterlerini yap\u0131land\u0131r\u0131lm\u0131\u015f bir dille yazmak da i\u015fi belirgin bi\u00e7imde kolayla\u015ft\u0131r\u0131yor; EARS (Easy Approach to Requirements Syntax) gibi kal\u0131plar (“… oldu\u011funda, sistem … yapacakt\u0131r”) tam da bu ama\u00e7la var. Y\u0131llard\u0131r requirement okurken kendimi hep ayn\u0131 c\u00fcmleyi kurarken buluyorum: “Bu bir requirement de\u011fil, bu bir temenni.” Fark \u015furada: “M\u00fckerrer i\u015flem olu\u015fmamal\u0131” bir temenni \u2014 niyeti anlat\u0131r ama kimin, ne zaman, nas\u0131l do\u011frulayaca\u011f\u0131n\u0131 s\u00f6ylemez. “Ayn\u0131 i\u015flem numaras\u0131yla gelen ikinci talep al\u0131nd\u0131\u011f\u0131nda, sistem yeni kay\u0131t olu\u015fturmayacak ve ilk kayd\u0131n sonucunu d\u00f6nd\u00fcrecektir” ise bir kural. \u0130kincisi test edilebilir, birincisi sadece tart\u0131\u015f\u0131labilir \u2014 ve tart\u0131\u015f\u0131labilir olan her \u015fey, agent’\u0131n elinde bir varsay\u0131ma d\u00f6n\u00fc\u015f\u00fcr.<\/p>\n\n\n\n

Havac\u0131l\u0131kta bunun yar\u0131s\u0131 zaten vard\u0131<\/h2>\n\n\n\n

Benim gibi reg\u00fcle bir sekt\u00f6rde \u00e7al\u0131\u015f\u0131yorsan\u0131z buraya kadarki hi\u00e7bir \u015fey size yeni gelmedi. Havac\u0131l\u0131kta bir gereksinimin nereden geldi\u011fi, hangi tasar\u0131m karar\u0131na ba\u011fland\u0131\u011f\u0131 ve hangi testle do\u011fruland\u0131\u011f\u0131 zaten kay\u0131t alt\u0131nda olmak zorunda. \u0130zlenebilirlik bir tercih de\u011fil, denetimde \u00f6n\u00fcn\u00fcze konan bir soru. “Bunu neden b\u00f6yle yapt\u0131n\u0131z?” sorusunun be\u015f y\u0131l sonra sorulaca\u011f\u0131n\u0131 bilerek yaz\u0131 yazmaya al\u0131\u015f\u0131ks\u0131n\u0131z.<\/p>\n\n\n\n

Yani spec k\u00fclt\u00fcr\u00fc bizde yeni de\u011fil. Yeni olan \u015fey, o belgeyi art\u0131k yaln\u0131zca insanlar\u0131n okumamas\u0131. Ayn\u0131 dok\u00fcman \u015fimdi bir de do\u011frudan uygulay\u0131c\u0131 taraf\u0131ndan okunuyor ve i\u00e7indeki her bo\u015fluk somut bir \u00e7\u0131kt\u0131ya d\u00f6n\u00fc\u015f\u00fcyor.<\/p>\n\n\n\n

Bu, reg\u00fcle sekt\u00f6rden gelen analiste ciddi bir avantaj sa\u011fl\u0131yor. Uyum sa\u011flamas\u0131 gereken tek \u015fey belgenin ritmi: onay al\u0131p dondurulan bir dok\u00fcman de\u011fil, s\u00fcrekli g\u00fcncellenen canl\u0131 bir metin.<\/p>\n\n\n\n

Peki bu spec’i kim yaz\u0131yor?<\/h2>\n\n\n\n

\u015eirkete g\u00f6re bu ki\u015finin unvan\u0131 i\u015f analisti, sistem analisti ya da product owner olabilir. De\u011fi\u015fen unvan de\u011fil, o ki\u015finin \u00fcretti\u011fi \u00e7\u0131kt\u0131n\u0131n a\u011f\u0131rl\u0131\u011f\u0131.<\/p>\n\n\n\n

\u0130\u015f analisti ile product owner rollerini ayn\u0131 ki\u015fide y\u00fcr\u00fctmenin de kendine \u00f6zg\u00fc bir y\u00fck\u00fc var; bunu ayr\u0131 bir yaz\u0131da<\/a> ele alm\u0131\u015ft\u0131m. Ama unvan ne olursa olsun, spec-driven bir ak\u0131\u015fta bu ki\u015finin \u00fcretti\u011fi metnin a\u011f\u0131rl\u0131\u011f\u0131 ayn\u0131: eskiden k\u00f6t\u00fc yaz\u0131lm\u0131\u015f bir kabul kriterinin bedeli bir yanl\u0131\u015f anla\u015f\u0131lma ve bir toplant\u0131yd\u0131; geli\u015ftirici gelir sorard\u0131, konu\u015fulur d\u00fczeltilirdi. O tampon ortadan kalk\u0131yor. Belirsiz b\u0131rak\u0131lan bir c\u00fcmle art\u0131k do\u011frudan yanl\u0131\u015f davranan bir \u00f6zellik olarak geri d\u00f6n\u00fcyor.<\/p>\n\n\n\n

Bu y\u00fczden analistlik i\u015finin a\u011f\u0131rl\u0131k merkezi kaym\u0131\u015f durumda. De\u011ferli olan \u015fey daha uzun dok\u00fcman yazmak de\u011fil; belirsizli\u011fi fark etmek, kimsenin sormad\u0131\u011f\u0131 s\u0131n\u0131r durumunu sormak, kapsam d\u0131\u015f\u0131n\u0131 a\u00e7\u0131k\u00e7a yazmak ve i\u015f kural\u0131n\u0131 temenni de\u011fil kural olarak ifade edebilmek. Yapay zek\u00e2 bunlar\u0131n hi\u00e7birini sizin yerinize yapm\u0131yor. Yapabildi\u011fi tek \u015fey, yapt\u0131\u011f\u0131n\u0131z i\u015fin kalitesini eskisinden \u00e7ok daha h\u0131zl\u0131 g\u00f6r\u00fcn\u00fcr k\u0131lmak.<\/p>\n\n\n\n

D\u00fcr\u00fcst olmak gerekirse: bu yakla\u015f\u0131m\u0131n sorunlar\u0131 da var<\/h2>\n\n\n\n

Bunu bir \u00e7\u00f6z\u00fcm olarak sunmak yanl\u0131\u015f olur. \u00dc\u00e7 itiraz ciddiye al\u0131nmay\u0131 hak ediyor.<\/p>\n\n\n\n

Birincisi spec \u015fi\u015fmesi. Her \u015feyi yazma d\u00fcrt\u00fcs\u00fc, bir s\u00fcre sonra kimsenin okumad\u0131\u011f\u0131 y\u00fcz sayfal\u0131k belgeler \u00fcretiyor \u2014 waterfall’\u0131 kovup pencereden geri almak.<\/p>\n\n\n\n

\u0130kincisi, “spec art\u0131k tek do\u011fruluk kayna\u011f\u0131d\u0131r” iddias\u0131n\u0131n abart\u0131l\u0131 olmas\u0131. \u00dcretimde \u00e7al\u0131\u015fan \u015fey h\u00e2l\u00e2 kod. Spec niyeti tarif eder, testler onu zorlar; ikisi de kodun yerine ge\u00e7mez.<\/p>\n\n\n\n

\u00dc\u00e7\u00fcnc\u00fcs\u00fc ve bence en \u00f6nemlisi: bir spec’in ne zaman yeterli oldu\u011funu \u00f6l\u00e7ecek sistematik bir y\u00f6ntemimiz yok. Thoughtworks’\u00fcn kendi yaz\u0131s\u0131nda da ge\u00e7en bir itiraf bu. De\u011ferlendirme \u00f6l\u00e7\u00fct\u00fc olmayan bir pratikte “kullan\u0131yoruz ve i\u015fler yolunda gidiyor” demek, y\u00f6ntemin i\u015fe yarad\u0131\u011f\u0131n\u0131n kan\u0131t\u0131 de\u011fil; sadece hen\u00fcz b\u00fcy\u00fck bir hata yapmad\u0131\u011f\u0131m\u0131z\u0131n g\u00f6stergesi.<\/p>\n\n\n\n

Nereden ba\u015flamal\u0131<\/h2>\n\n\n\n

S\u00fcreci ba\u015ftan kurgulamaya \u00e7al\u0131\u015fmay\u0131n. Bir sonraki i\u015f i\u00e7in tek bir \u015fey deneyin: kabul kriterlerini yap\u0131land\u0131r\u0131lm\u0131\u015f bi\u00e7imde, test edilebilir c\u00fcmlelerle yaz\u0131n ve geli\u015ftirmeden ka\u00e7 soru geri geldi\u011fini say\u0131n.<\/p>\n\n\n\n

Yapay zek\u00e2, analistin i\u015fini elinden alm\u0131yor. Sadece k\u00f6t\u00fc yaz\u0131lm\u0131\u015f bir gereksinimin bedelini bir toplant\u0131dan bir s\u00fcr\u00fcme y\u00fckseltiyor.<\/p>\n\n\n\n

Kaynaklar<\/h4>\n\n\n\n