Spek Odaklı Geliştirmeyi (SDD) Anlamak: Kiro, Spec-Kit, Tessl

• Spec-Driven Development (SDD), yapay zeka destekli kodlamada kod yazmadan önce önce spesifikasyonun (spec) yazıldığı bir yaklaşım; spesifikasyon, geliştirici ve yapay zeka için gerçekliğin kaynağı (source of truth) görevi görür
• SDD, üç uygulama düzeyine ayrılır ve spec-first (önce spesifikasyon), spec-anchored (bakım için spesifikasyonun korunması), spec-as-source (spesifikasyonun ana kaynak dosya olarak kullanılması ve geliştiricinin kodu doğrudan düzenlememesi) olarak kademeli biçimde ilerler
• Kiro, gereksinimler → tasarım → işler şeklinde basit bir 3 aşamalı iş akışı sunar; spec-kit, constitution adlı güçlü bir kural tabanlı iş akışı kullanır; Tessl ise spesifikasyon ile kodu bire bir eşleyen spec-as-source yaklaşımını dener
• Üç araç da küçük hata düzeltmeleri için aşırı süreç gerektirir; Markdown dosyalarını gözden geçirmek kod incelemesinden daha zahmetlidir ve büyük bağlam pencerelerine rağmen yapay zeka tüm talimatları düzgün şekilde izleyemez
• SDD, geçmişteki model odaklı geliştirme (MDD) başarısızlıklarını hatırlatır; hem belirlenimsizlik hem de esneksizlik gibi iki tarafın da dezavantajlarını birlikte taşıma riski olduğundan, gerçek projelerdeki faydasının doğrulanması gerekir

---

Spek odaklı geliştirme (SDD) nedir

• SDD, kod yazmadan önce önce spesifikasyonun yazıldığı “önce dokümantasyon” yaklaşımıdır; spesifikasyon hem geliştirici hem de yapay zeka için tek gerçek kaynak (single source of truth) görevi görür
• GitHub bunu, “yazılım bakımının spesifikasyonun evrimi anlamına geldiği; geliştirmenin ortak dilinin daha üst bir seviyeye taşındığı ve kodun son aşama yaklaşımı olduğu” şeklinde tanımlar
• Tessl ise bunu, “spesifikasyonun kod değil birincil çıktı haline geldiği bir geliştirme yaklaşımı; spesifikasyonun yapılandırılmış ve test edilebilir bir dille niyeti anlattığı ve ajanların buna göre kod ürettiği” şeklinde açıklar
• SDD, üç uygulama düzeyine ayrılır
  • Spec-first: Önce iyi yapılandırılmış bir spesifikasyon yazılır ve yapay zeka destekli geliştirme iş akışında kullanılır
  • Spec-anchored: İş tamamlandıktan sonra da spesifikasyon korunur ve ilgili özelliğin evrimi ile bakımı için kullanılmaya devam eder
  • Spec-as-source: Spesifikasyon zaman içinde ana kaynak dosya olarak kalır; geliştirici yalnızca spesifikasyonu düzenler, koda doğrudan dokunmaz
• Tüm SDD yaklaşımları spec-first’tür; ancak hepsi spec-anchored ya da spec-as-source’u hedeflemez ve zaman içinde spesifikasyonun nasıl korunacağına dair strateji çoğu zaman belirsiz ya da tamamen açıktır

Spesifikasyon (spec) nedir

• Spesifikasyon, yazılım işlevlerini ifade eden ve yapay zeka kodlama ajanına rehberlik eden, doğal dilde yazılmış yapılandırılmış ve davranış odaklı bir çıktıdır
• En tutarlı tanım, spesifikasyonu ürün gereksinimleri dokümanına (PRD) benzetmektir
• Spesifikasyon, kod tabanı için kullanılan genel bağlam dokümanlarından ayrılmalıdır
  • Genel bağlam; kural dosyalarını, ürünün ve kod tabanının yüksek seviyeli açıklamalarını içerir; bazı araçlar buna memory bank der
  • Memory bank dosyaları, kod tabanındaki tüm yapay zeka kodlama oturumlarında ilgilidir; oysa spesifikasyon yalnızca belirli bir özelliği üretme ya da değiştirme görevleri için ilgilidir
• Her SDD varyantı, spesifikasyonun yapısı, ayrıntı seviyesi ve proje içinde nasıl organize edileceği konusunda kendine özgü bir yaklaşım tanımlar

SDD araçlarını değerlendirmenin zorluğu

• SDD araç ve yaklaşımlarını gerçek kullanıma yakın şekilde değerlendirmek çok zaman alır
  • Farklı büyüklükte problemler üzerinde, greenfield/brownfield projelerde denenmeleri gerekir; ayrıca ara çıktıları yüzeysel değil, ayrıntılı şekilde incelemek ve düzeltmek için zaman gerekir
• GitHub’un spec-kit blog yazısı, “Önemli olan rolünüzün yalnızca yön vermek değil, doğrulamak da olması; her aşamada değerlendirme yapıp iyileştirmeniz gerekir” diye vurgular
• Üç araçtan ikisi, mevcut kod tabanına dahil edilmek için daha fazla iş gerektiriyor gibi görünüyor; bu da brownfield kod tabanındaki faydalarını değerlendirmeyi daha da zorlaştırıyor
• Gerçek kod tabanlarında bunları bir süre kullanmış kişilerin deneyimlerini duymadan önce, pratikte nasıl çalıştıklarına dair çok sayıda yanıtsız soru var

Kiro

• Kiro, üç araç arasında en basit ve en hafif olanı; çoğunlukla spec-first yaklaşımına karşılık geliyor
  • Yalnızca görevler veya kullanıcı hikâyeleri için kullanıldığı örnekler bulundu; zaman içinde birden fazla göreve yayılan şekilde spec-anchored yaklaşımıyla gereksinim dokümanlarının nasıl kullanılacağına dair bir ifade yok
• İş akışı: Gereksinimler → Tasarım → İşler
  • İş akışındaki her aşama bir Markdown dokümanıyla temsil edilir ve Kiro, VS Code tabanlı dağıtımı içinde bu 3 aşamaya rehberlik eder

• Kiro’nun ana bileşenleri

  • Gereksinimler (Requirements)
    • Her gereksinim, “kullanıcı hikâyesi”ni (As a... biçiminde) temsil eden bir gereksinim listesi olarak yapılandırılır
    • Kabul kriterleri GIVEN... WHEN... THEN... biçimini kullanır
  • Tasarım (Design)
    • Bileşen mimarisi diyagramı, veri akışı, veri modeli, hata işleme, test stratejisi, uygulama yaklaşımı, geçiş stratejisi gibi bölümler içerir
    • Bunun göreve göre tutarlı bir yapı mı olduğu yoksa değiştiği mi belirsizdir
  • İşler (Tasks)
    • Gereksinim numaralarıyla izlenen bir görev listesi
    • Görevleri tek tek çalıştırmayı ve görev bazlı değişiklikleri incelemeyi sağlayan ek kullanıcı arayüzü öğeleri sunar

• Kiro’nun memory bank’i

  • Kiro, memory bank kavramını “steering” olarak adlandırır
    • İçeriği esnektir ve iş akışının belirli dosyaların varlığına bağlı olmadığı görülür
  • Kiro, steering dokümanları oluşturması istendiğinde varsayılan olarak product.md, structure.md, tech.md yapısını üretir

Spec-kit

• spec-kit, GitHub’un SDD sürümüdür; farklı genel kodlama asistanları için çalışma alanı kurulumu üretebilen bir CLI olarak dağıtılır
• Yapılandırma kurulduktan sonra, kodlama asistanıyla slash command’ler üzerinden etkileşime girilir
• Tüm çıktılar doğrudan çalışma alanına yerleştirildiği için, burada ele alınan üç araç içinde en özelleştirilebilir olanıdır

• Spec-kit’in iş akışı

  • İş akışı: Constitution → 𝄆 Specify → Plan → Tasks 𝄇
  • spec-kit’in memory bank kavramı, spec-driven yaklaşımın ön koşuludur
    • Buna constitution der ve tüm değişikliklerde daima uygulanması gereken “değişmez” yüksek seviyeli ilkeleri içerir
    • İş akışı boyunca yoğun biçimde kullanılan çok güçlü bir kural dosyasıdır

• Spec-kit nasıl çalışır

  • İş akışının her aşamasında (specify, plan, tasks) bash script’leri ve şablonlar kullanılarak dosyalar ile prompt setleri örneklenir
  • İş akışı, gerekli kullanıcı netleştirmelerini, constitution ihlallerini, araştırma işlerini vb. takip etmek için dosya içi kontrol listelerini yoğun biçimde kullanır
    • Bunlar, her iş akışı aşaması için bir tür “definition of done” işlevi görür (bunu yapay zeka yorumladığı için %100 garanti yoktur)
  • Tek bir spesifikasyon birden fazla dosyadan oluşur
    • Örneğin: data-model, plan, tasks, spec, research, api, component dahil 8 dosya

• Spec-kit’in yaklaşımı

  • GitHub başlangıçta spec-anchored yaklaşımını hedefliyor gibi görünür
    • “Spesifikasyonları statik dokümanlar değil, projeyle birlikte evrilen yaşayan ve çalıştırılabilir çıktılar olarak yeniden düşünüyoruz; spesifikasyon ortak gerçeklik kaynağı oluyor.”
  • Ancak spec-kit, üretilen her spesifikasyon için bir branch oluşturur; bu da spesifikasyonu özelliğin ömrü boyunca değil, değişiklik talebinin ömrü boyunca yaşayan bir çıktı olarak gördüğü şeklinde yorumlanabilir
  • Topluluk tartışmalarında da bu kafa karışıklığından söz ediliyor; spec-kit hâlâ yalnızca spec-first’e denk geliyor ve zaman içinde spec-anchored olmadığı anlaşılıyor

Tessl Framework

• Tessl Framework, kapalı beta aşamasında ve spec-kit gibi farklı kodlama asistanları için çalışma alanı ile yapılandırma iskeleti üretebilen bir CLI olarak dağıtılıyor
• CLI komutları MCP sunucusu olarak da çalışıyor

• Tessl’in özellikleri

  • Üç araç arasında spec-anchored yaklaşımını açıkça hedefleyen tek araç ve aynı zamanda spec-as-source düzeyindeki SDD’yi de araştırıyor
  • Tessl spesifikasyonları, bakım yapılan ve düzenlenen birincil çıktı rolünü üstlenebilir; kodun üst kısmında // GENERATED FROM SPEC - DO NOT EDIT yorumu bulunur
    • Şu anda spesifikasyon ile kod dosyası arasında 1:1 eşleme vardır; yani tek bir spesifikasyon, kod tabanındaki tek bir dosyaya dönüşür
    • Hâlâ beta aşamasında olduğundan ve farklı sürümler denendiğinden, ileride tek bir spesifikasyonun birden fazla dosyadan oluşan bir kod bileşenine eşlenmesi de mümkün olabilir

• Tessl spesifikasyon yapısı

  • @generate ya da @test gibi etiketler, Tessl’e neyin üretileceğini söyler
  • API bölümü, kod tabanının diğer parçalarına açılan asgari arayüzün spesifikasyon içinde tanımlanması fikrini gösterir ve üretilen bileşenin önemli kısımlarının bakımı yapan kişinin tam kontrolü altında kalmasını sağlar
  • tessl build çalıştırıldığında ilgili JavaScript kod dosyası üretilir

• Tessl’in soyutlama seviyesi

  • spec-as-source için spesifikasyonun kod dosyası başına oldukça düşük bir soyutlama düzeyine yerleştirilmesi, LLM’in atması gereken adım ve yapması gereken yorum miktarını, dolayısıyla hata olasılığını azaltır
  • Ancak bu kadar düşük soyutlama seviyesinde bile, aynı spesifikasyondan birden fazla kez kod üretildiğinde belirlenimsizlik gözlemlenmiştir
    • Spesifikasyonu tekrar tekrar yazarak kod üretiminin tekrar edilebilirliğini artırmak için onu giderek daha somut hale getirme süreci, belirsiz olmayan ve eksiksiz spesifikasyon yazmanın tuzaklarını ve zorluklarını hatırlatır

Gözlemler ve sorular

• Tek bir iş akışı her ölçeği karşılayabilir mi?

  • Kiro ve spec-kit’in her biri dogmatik tek bir iş akışı sunuyor; ancak ikisinin de gerçek dünyadaki çoğu kodlama problemine uygun olmayabileceği düşünülüyor
  • Problem boyutuna göre yeterli çeşitlilik sunup sunmadıkları belirsiz
    • Kiro ile küçük bir hatayı düzeltmeye çalışıldığında, iş akışı ceviz kırmak için balyoz kullanmak gibi hissettirdi
    • Gereksinim dokümanı, küçük bir hatayı toplam 16 kabul kriterine sahip 4 “kullanıcı hikâyesi”ne dönüştürdü
  • spec-kit kullanılırken de hangi büyüklükteki problemlerde kullanılmasının uygun olduğu belirsizdi
    • Geçmişte ekipte 3-5 puanlık hikâye olacak bir özellik denendiğinde, spec-kit’in attığı adım sayısı ve ürettiği Markdown dosyası miktarı problem boyutuna göre aşırı geldi
    • Aynı sürede “normal” yapay zeka destekli kodlamayla bu özellik uygulanabilirdi ve çok daha fazla kontrol hissedilirdi
  • Etkili bir SDD aracının, farklı boyut ve türdeki değişiklikler için en az birkaç farklı temel iş akışında esneklik sunması gerekir

• Kod incelemesi yerine Markdown incelemesi mi?

  • spec-kit, gözden geçirilmesi gereken çok sayıda Markdown dosyası üretir
    • Bunlar hem birbirini tekrar eder hem de mevcut kodla tekrar içerir
    • Bazıları zaten kod da içerdiğinden, genel olarak çok uzun ve incelemesi yorucudur
  • Kiro’da yalnızca 3 dosya elde edilir ve “gereksinimler > tasarım > işler” zihinsel modelini anlamak daha sezgiseldir; bu yüzden biraz daha kolaydır
    • Ama Kiro da düzeltilmesi istenen küçük hata için gereğinden fazla uzundur
  • Açıkçası, tüm bu Markdown dosyaları yerine kodu gözden geçirmek daha iyi görünüyor
  • Etkili bir SDD aracının çok iyi bir spesifikasyon inceleme deneyimi sunması gerekir

• Yanlış bir kontrol hissi mi?

  • Tüm bu dosyalar, şablonlar, prompt’lar, iş akışları ve kontrol listelerine rağmen, ajanların sonuçta tüm talimatları izlemediği durumlar sık görülüyor
  • Daha büyük bağlam pencereleri, SDD’yi mümkün kılan etkenlerden biri olarak gösterilse de, pencerenin büyük olması yapay zekanın içindeki her şeyi doğru kavradığı anlamına gelmiyor
  • Örnekler
    • spec-kit, planlama sırasında araştırma aşamasına sahipti ve mevcut kod üzerinde çok araştırma yaptı; ama ajan, bunun mevcut sınıfın açıklaması olduğunu görmezden gelip bunu yeni bir spesifikasyon olarak algıladı ve her şeyi yeniden üreterek kopya çıktı oluşturdu
    • Sadece talimatları yok sayan örnekler değil, bir talimatı (örneğin constitution maddelerinden birini) fazla ciddiye alıp aşırı uygulayan ajanlar da görüldü
  • Geçmiş deneyimlere göre, inşa edileni kontrol etmenin en iyi yolu küçük ve yinelemeli adımlardı; bu yüzden çok fazla önceden yapılan spesifikasyon tasarımına ciddi şüpheyle bakılıyor
  • Etkili bir SDD aracının yinelemeli yaklaşımı benimsemesi gerekir; ancak küçük iş paketleri SDD fikrine neredeyse ters düşüyor gibi görünüyor

• İşlevsel spesifikasyon ile teknik spesifikasyon nasıl etkili biçimde ayrılır?

  • SDD’de işlevsel spesifikasyon ile teknik uygulama arasında ayrım yapılması genel bir fikirdir
    • Temel arzu, nihayetinde yapay zekanın tüm çözüm ve ayrıntıları doldurabilmesi ve aynı spesifikasyonla farklı teknoloji yığınlarına geçilebilmesidir
  • Pratikte spec-kit denenirken, ne zaman işlevsel seviyede kalınması ve ne zaman teknik ayrıntı eklenmesi gerektiği sık sık kafa karıştırıcıydı
    • Eğitim içerikleri ve dokümantasyon da bu konuda tutarlı değildi; “salt işlevsel” ifadesinin gerçekte ne anlama geldiğine dair farklı yorumlar vardı
  • Gereksinimlerle uygulamayı düzgün ayıramayan birçok kullanıcı hikâyesi hatırlandığında, sektörün genel olarak bunu iyi yaptığını söylemek zor

• Hedef kullanıcı kim?

  • Birçok spec-driven geliştirme aracının demosu ve eğitiminde ürün ve özellik hedeflerinin tanımlanması gibi şeyler bulunuyor; “kullanıcı hikâyesi” gibi terimler de kullanılıyor
  • Buradaki fikir, yapay zekayı cross-skilling için bir kolaylaştırıcı olarak kullanıp geliştiricilerin gereksinim analizine daha aktif katılmasını sağlamak olabilir
    • Ya da geliştirici bu iş akışında çalışırken ürün yöneticisiyle eşleşiyor olabilir mi?
  • Bunların hiçbiri açıkça anlatılmıyor; geliştiricinin tüm bu analizi yapması sanki doğal kabul ediliyor
  • Öyleyse SDD hangi boyut ve türde problemler için?
    • Muhtemelen hâlâ çok belirsiz olan büyük özellikler için uygun olmayacaktır; çünkü bu durumda daha uzman ürün ve gereksinim becerileri, ayrıca araştırma ve paydaş katılımı gibi birçok ek adım gerekir

• Spec-anchored ve spec-as-source: Geçmişten ders alınıyor mu?

  • Birçok kişi SDD ile TDD ya da BDD arasında benzerlik kuruyor; ancak özellikle spec-as-source için bakılması gereken bir diğer önemli benzerlik MDD’dir (model odaklı geliştirme)
  • Kariyerin başlarında MDD’nin yoğun kullanıldığı bazı projelerde çalışılmış ve Tessl Framework denenirken bu sürekli hatırlanmıştır
    • MDD’deki modeller aslında bir tür spesifikasyondu; fakat doğal dil yerine özel UML ya da metinsel DSL ile ifade ediliyordu
    • Bu spesifikasyonları koda dönüştürmek için özel kod üreticileri inşa ediliyordu

• MDD ile SDD karşılaştırması

  • Sonuçta MDD, iş uygulamalarında başarılı olamadı; çünkü soyutlama seviyesi hantaldı ve çok fazla ek yük ile kısıt üretiyordu
  • Ancak LLM’ler, MDD’nin bu ek yük ve kısıtlarının bir kısmını ortadan kaldırıyor; böylece artık spesifikasyon yazmaya odaklanıp kod üretme yönünde yeni bir umut doğuyor
  • LLM kullanıldığında önceden tanımlanmış ve ayrıştırılabilir bir spesifikasyon diline mahkûm olunmuyor; ayrıca karmaşık kod üreticileri kurmaya da gerek kalmıyor
    • Bunun bedeli elbette LLM’in belirlenimsizliği
  • Ayrıştırılabilir yapıların avantajı ise, geçerli, eksiksiz ve tutarlı spesifikasyon yazımı için yazara çok sayıda araç desteği sunabilmesiydi; şimdi bu avantaj kaybediliyor
  • spec-as-source, hatta spec-anchoring bile hem MDD’nin hem de LLM’lerin dezavantajlarıyla sonuçlanabilir: esneksizlik ve belirlenimsizlik
  • Geçmişteki spec-from-code girişimlerine bakılmalı ve bugün spec-driven yaklaşımlar incelenirken buradan ders çıkarılmalıdır

Sonuç

• Kişisel olarak, yapay zeka destekli kodlama kullanırken kodlama ajanına verilecek spesifikasyon biçimini dikkatle yazmaya zaman ayırma durumu sık yaşanıyor
  • Bu yüzden spec-first’in genel ilkesi birçok durumda kesinlikle değerlidir
• Spesifikasyonun nasıl yapılandırılacağına dair farklı yaklaşımlara ciddi ihtiyaç var ve bu, bugün pratisyenlerden en sık gelen sorulardan biri
  • “Memory bank’i nasıl yapılandırıyorsunuz?”, “Yapay zeka için iyi bir spesifikasyon ve tasarım dokümanı nasıl yazılır?”
• Ancak “spec-driven development” terimi henüz iyi tanımlanmış değil ve anlamı şimdiden dağılmaya başlamış durumda
  • Son zamanlarda “spec” kelimesinin temelde “ayrıntılı prompt” eşanlamlısı gibi kullanıldığı da duyuluyor

• Araçlara dair değerlendirme

  • Bazıları mevcut iş akışlarını yapay zeka ajanlarına fazla kelimesi kelimesine vermeye çalışıyor; bu da sonuçta inceleme yükü ve halüsinasyon gibi mevcut sorunları büyütebilir
  • Özellikle çok sayıda dosya üreten daha gelişmiş yaklaşımlar söz konusu olduğunda, Almanca birleşik sözcük “Verschlimmbesserung” (iyileştirmeye çalışırken daha kötü hale getirmek) akla geliyor
    • Bir şeyi daha iyi yapmaya çalışırken aslında daha kötü hale getiriyor olabilir miyiz diye düşündürüyor

[aer0700]

Daha önce document driven develope ya da readme driven develope gibi anlatılan şeylere benziyor gibi görünüyor.
https://tr.news.hada.io/topic?id=15502

[GN⁺]

Hacker News görüşleri

• Son zamanlarda SDD (spec driven development / spesifikasyon güdümlü geliştirme) trendini izliyorum; bu yaklaşım mantıklı gelse de sanki pre-agile dönemin özellik spesifikasyonları ve tasarım dokümanları çağına geri dönüyormuşuz gibi hissettiriyor. Tam anlamıyla Big Design Up Front değil ama giderek “çalışan yazılım == kusursuz dokümantasyon” noktasına gidiyor gibi görünüyor.
  Big Design Up Front hakkında, Agile Manifesto hakkında

  • Özellik spesifikasyonları ve tasarım dokümanları sonuçta doğal dilde kod yazmak gibi. Eskiden birinin bunu yeniden programlama diline çevirmesi gerekiyordu, şimdi ise LLM’ler (büyük dil modelleri) gibi otomatik derleyiciler bu işi üstlenmeye başladı. Böylece süreçte bir adımı atlayabiliyoruz tabii başarı oranı değişken. <br /> Öte yandan agile, yazılımın hangi dille yapıldığıyla ilgilenmez. Esas mesele “yöneticiyi aradan çıkarmak” ve geliştiricinin yönetim işlerini de üstlenmesidir. 12 ilke, yönetici olmadığında geliştiricinin ne yapması gerektiğini daha ayrıntılı anlatıyor.

  • Behaviour Driven Design, Test Driven Design gibi “yaşayan spesifikasyonlar” üretebilir. Alan keşfi ölçütlerinden testlerin geçip geçmediğine kadar her şeyi insanın okuyabileceği dokümanlar halinde bırakır ve bunları doğrudan test harness’iyle bağlayarak mevcut işlevi doğrulayabilir. Böylece BDD raporları üzerinden açıkça doğrulanmış, işbirliğine ve iterasyona uygun spesifikasyon dokümanları elde edilir; üstelik baştan gereksiz iş yapmadan agile, JIT ve YAGNI’nin hepsini de koruyabilirsiniz. Waterfall’a geri dönmeye gerek yok.

  • Küçük ölçekli tasarımla da başlanabilir. Bir iki sayfalık bir spesifikasyon yazıp LLM ile kod ve test üretir, sonra iteratif olarak iyileştirirsiniz. Eğer %100 LLM coding’e güveniyorsanız, spesifikasyon girdilerini (İngilizce prompt’ları) sistemli biçimde yönetmek mantıklı olur. Prompt’ları çöpe atmadan düzenli tutmak, ileride yeniden kullanmayı ya da ek kısıtları net biçimde vermeyi sağlar. <br /> Ama LLM’leri kritik production kodunda kullanmak bana güvensiz geliyor; o yüzden sadece sandbox/test/demo amaçlı deniyorum. Kod kalitesinin o kadar kritik olmadığı yerlerde kullanıyorum.

  • Spec driven development kendi başına iyi bir fikir. Ancak mevcut uygulamaların çoğu yapılandırılmamış markdown dosyalarını agent’e veriyor ve düzgün sonuç çıkmadığı için pratikte hiç tekrar üretilebilirlik yok. Agent spesifikasyonu da yazıyorsa, bu yapı stub koduna ve test koduna otomatik dönüştürülebilecek kadar yapılandırılmış olmalı. Sırf markdown olarak bırakmak yerine code generator ile entegre edilirse çok daha yüksek tekrar üretilebilirlik sağlanır. Gerçekten böyle uygulanırsa tekrarlı kod üretimi için harcanan zaman ciddi ölçüde kısalabilir.

• SpecKit’i kullanırken gerçekten ilginç ve tatmin edici buldum ama gerçek dünyadaki karmaşık örnekleri ya da kullanım biçimlerini bulmakta zorlandım. Eğitimlerin çoğu basit kurulumdan sonra “to-do list app yapalım” seviyesinde kalıyor. Mevcut legacy codebase’i aşamalı olarak iyileştirme veya refactor etme örnekleri ya da spec driven development’ın baştan uygulanmadığı büyük projelere nasıl yaklaşılması gerektiği konusunda gerçek örnekler paylaşılmasını isterdim.

  • Ben de BDD yaklaşımıyla CLI tabanlı coding’i birlikte kullanırken, işlevleri uzun ve ayrıntılı markdown yerine doğrudan gerçek kodla kaydetmenin çok daha etkili olduğunu bizzat gördüm. AI’ın takip etmesi gereken bir checklist gerekiyorsa agents.md gibi bir dosya yeterli. Coding pattern’lerini ve non-functional requirement (NFR) maddelerini bir kez yazmanız, agent’in bunlara net biçimde uymasını sağlayabiliyor.

  • Gerçekten kullanabilmek için template’i ya da source code’u doğrudan okumak gerekiyor; neyin gerçekten nasıl çalıştığını ancak öyle anlayabiliyorsunuz. Bu tür projelerde bunun gayet doğal bir süreç olduğunu düşünüyorum.

• Thoughtworks çıkışlı, AI tabanlı delivery uzmanı tanıtımından sonra memory bank konusuna gelinince hemen bağ kurdum. Biz de “AI her şeydir” denilen bir sahada çalıştık ve şunu gördük: memory bank büyüdükçe AI yönünü kaybediyor, çıktılar da karmakarışık oluyor. Sonuçta ürünü gerçekten anlayan birinin AI’ı bizzat yönlendirmesi gerekiyor ki sahada uygulanabilir bir şey çıksın. AI’ın beni kaç kez yanılttığını sayamam; insan yeniden yön verince hep özür diliyor ve anladığını söylüyor ama pratikte hiçbir şey değişmiyor. AI’ın kendi aralarında kullanılan onca dokümanı okuyup doğrulaması da gerçekçi değil. O zamanı doğrudan işe harcamak çok daha mantıklı gibi geliyor.

  • memory bank ile tam olarak ne kastedildiğini ve bunun rolü hakkında somut olarak ne söylenmek istendiğini merak ediyorum.

  • Şu anda memory özelliği daha çok zararlı. Düzgün bir “arama/erişim” stratejisi olmadan kullanılırsa sadece kötü sonuçları büyütüyor. Çoğu memory sistemi tekil sohbet paradigmasına göre tasarlandığı için farklı ortamlarda sorun çıkarıyor. Gerçek “hafıza” dediğimiz şey, ana agent’ten ayrılmış bir “meta-biliş/default mode network” üzerinden asenkron biçimde görev yapısını ve bağlamı tasarlayıp, her prompt’ta bu meta modelin yön vermesiyle çalışmalı. Yani doğru yaklaşım “agent tabanlı hafıza” olmalı.

  • LinkedIn gibi yerlerde insanların kendine “thought leader” unvanı yazmasını da anlamıyorum. Bu sıralar böyle başlıkların ne anlama geldiğini gerçekten kestirmek zor.

• Son iki haftada SpecKit ve Claude Code ile iki yeni projede yaptığım deneyi paylaşmak isterim. İki projeyi de tek başıma geliştirdiğim için denemek rahattı. İlk projede işi tamamen SpecKit’e bıraktım; 10 günde tüm task’lar bitti ama ortaya çıkan testlerin çoğu başarısızdı ve build de bozuktu. Sorunları düzeltmek için de neredeyse aynı süreyi harcamam gerekti; Claude bir şeyi düzeltirken başka bir yeri bozuyordu, bu da güveni ciddi biçimde düşürdü. <br /> İkinci projede küçük parçalarla iterasyon yapmak istedim; SpecKit planning sonrasında slash command ekleyip backlog.md oluşturdum, sonra plan-sprint ile sprint hedeflerini ve iş detaylarını içeren bir dosya ürettim, ardından implement-sprint ile toplu işlettim. Ancak bu süreçte de implement komutlarına uymadığı için, süreci birkaç kez düzeltmeme rağmen ya test üretmedi ya da bazı task’ları atladı. <br /> Bunun üzerine ayarı tekrar değiştirip belirli task’larla ilgilenen bir subagent kullandım ve implement-sprinti yalnızca orchestrator olarak değerlendirdim. Böylece her sprintte kod durumunu gözden geçirebildiğim için güvenilirlik çok arttı. Hâlâ testler başarısız olsa bile “bitti” dediği oluyor ama her şeyi baştan sona kendim incelemekten daha kolay. <br /> Şu anki hipotezim Claude’un TDD’de zayıf olduğu yönünde. Özellikle testleri önce yazma aşamasında sürekli sorun yaşıyor. Bir sonraki denemede testleri implementasyon bittikten sonra yazdırmayı planlıyorum. İdeal değil ama üretkenliği artıracaksa, en azından her şeyi kendim yazmaktan iyi olabilir.

• Birçok aracın büyük ölçüde “önce spesifikasyon” stratejisine göre tasarlanmış olması ve spesifikasyonun bakımının nasıl yapılacağının belirsiz kalması ilgimi çekti. Ben de cofounder’ımla birlikte “spec as source” yaklaşımına tam anlamıyla yükleniyorum. Spesifikasyonu gerçekten source olarak görmek bana en ilginç kullanım gibi geliyor ve bunu hayata geçirmeye çalışıyoruz, ama bunu gerçekten oturtmak çok zor. Bu konuda deneyimi ya da geri bildirimi olan varsa duymayı çok isterim. <br /> Deney yaptığımız specific.dev ile de ilgileniyorsanız deneyip haber vermenizi isterim.

  • Eğer spesifikasyon gerçekten source ise, o zaman spesifikasyonun kendisi çalıştırılabilir bir biçimsel dil, yani bir programlama dili olmak zorunda. Aksi halde spesifikasyon spesifikasyondur, source code ise source code’dur. Sonuçta “iyi kod”un ne olduğunu öğrenmek herkes için hâlâ aynı gereklilik.

• Kiro’nun spec-driven workflow’unu denedim; inanılmaz miktarda task listesi üretiyor (her task için 4’ten fazla subtask, toplamda 12’den fazla task). Workflow’un kendisi fena değildi ama öngörülemez şekilde kod siliyor ve rollback de yapmıyor. Sanırım IDE olarak tasarlandığı için kaynaklar UI exception handling’e gidiyor. Her şeyi karmaşık biçimde bölmek yerine basitçe iterasyon yapıp iyileştirmek daha kolay. Tam anlamıyla “ceviz kırmak için balyoz kullanmak” gibi.

• Custom slash command’lerle girdileri iyi yapılandırılmış prompt’lara sarmalama yaklaşımını beğendim. agents.md gibi dosyalardan bölünmüş parçaları bağlam olarak birlikte enjekte etmesi de hoşuma gitti. <br /> Ama bütün düğümleri çözmeye çalışırken işin yine balyozla ceviz kırmaya dönmesi, yani gereksiz karmaşıklık üretmesi hoşuma gitmiyor. Yine de sadece gerektiğinde ek slash command’ler (/experiment, /stub gibi) ile bağlam yönetimini seçmeli hale getirmek sistemi hafifletebilir diye düşünüyorum. En sonda da "/wrap-up" gibi yalnızca kapanışa özel bir komutla tüm düğümleri bir arada toplamak mümkün olabilir; sanki ameliyat bittikten sonra doktorun son genel kontrolü yapması gibi.

• SpecKit kullanırken hep şu soruyu sordum: “Bu kadar çok spec ne zaman tek ve gerçek bir referans noktada (ground truth) birleşecek?” Böyle bir aşama hiç yokmuş gibi gelmesi hayal kırıklığı yarattı. <br /> Şimdi ise insanla agent arasındaki iletişim spesifikasyonunun nasıl görünmesi gerektiğini tanımlama ve tasarlama görevi önümüzde duruyor. Birgitta’nın sözünü ettiği “spec anchored” kavramını nasıl gerçekleştirebileceğimizi düşünüyorum.

  • AI ile birlikte artık bu tür standartları gerçekten tanımlamamız gereken noktaya geldiğimizi hissediyorum. İnsanların okuyup yönetebileceği kadar düzenli, aynı zamanda tamamen olmasa da kısmen LLM bağlamına sığabilecek kadar biçimselleştirilmiş spesifikasyonlara ihtiyaç var; ayrıca sadece bilginin bir kısmı ingest edilse bile temel niyeti ve tasarımı koruyarak anlamlı iş üretilebilmesi gerekiyor. <br /> UML ve Rational Rose benzeri girişimlerin başarısız olmasının nedeni bence niyetin somut biçimde yer almaması ve her şeyin sadece diyagram olarak kalmasıydı; bu yüzden yalnızca dokümantasyon, bakım ve refactor aşamalarında işe yaradı. Sonuçta ancak ürün çıktıktan sonra faydalı hale geldiği için anlamını yitirdi. <br /> Bu yüzden artık C4 model gibi daha yeni yaklaşımlar ilgimi çekiyor.

• SDD’nin birden neden bu kadar popüler olduğunu bilmiyorum ama ben kendi adıma, sadece spesifikasyon dosyaları oluşturarak “nihai çıktıyı önceden görmek” ve projeyi küçük parçalara böldüğümde ilerlemeyi takip etmek açısından bunu pratik buluyorum. Ayrı bir araç ya da framework kullanmıyorum, sadece markdown dosyalarıyla ilerliyorum. Bunun ötesindeki karmaşık sistemlerde pek değer görmedim.

• spec-kit’i ilk kullandığımda gerçekten çok umutlanmıştım ama pratikte “mağarada robot inşa etmek” seviyesine kadar uzanan gereksiz görevler üretiyordu. Sadece bir vidayı sıkmak yeterliyken işi aşırı büyütüyor, ben de düzeltmeye çalışırken yorulup bırakıyordum. Bu kadar karmaşık bir workflow’un buna değecek kadar telafi edici olmadığını düşünüyorum.

[jjw9512151]

Aslında bunu, yazılım mühendisliğinde öğrendiklerimizi Markdown ile yapmak gibi düşünürseniz basit ve pratiktir. Gereksinim spesifikasyonunu iyi yazmak bile yeterlidir.