GitHub’un Spec Kit’inin avantajları GitHub Copilot’ta da kullanılabiliyor.
GitHub tarafından yapıldığı için elbette denebilir ama diğer araçların çoğu Claude tabanlıydı.

Bunu Hangul için de yapmanın mümkün olabileceği bir düşüncesi birden aklıma geldi... Ama bir bulmaca yapılabilir gibi görünüyor...

Bunu sadece tarama amacıyla iyi kullanacağım

Alım satım emirleri söz konusu olduğunda, prompt injection gibi nedenlerle istenmeyen emirlerin işleme alınması mümkün görünüyor; bu yüzden emir konusu varlık veya tutar sınırı gibi ek özellikler zorunlu olacak gibi duruyor.

Üzgünüm;;

Kiro IDE'yi hatırlatıyor.

Teşekkür ederim.

Evet, ben de aynı düşünüyorum. hıçkırık

Deneyi keyifle izledim.

Başlık atma kursuna mı gittiniz..

Sosyal medyanın zaman kaybı olması bakımından, kumar ya da uyuşturucu gibi daha çok bir pişmanlık ya da utanç hissi vermesi yerinde olurdu.

İlginçmiş. Mantıklı da geliyor.

İçerikten bağımsız olarak, başlıktaki tek satırlık prompt ifadesi nedeniyle bakmak istediği şeyle yazının içeriği farklı olduğu için daha da öyle geliyor sanırım

k9s - Kubernetes kümelerini terminal UI ile yönetmeye yarayan araç

Yazının ortasındaki SDD ayrıntılı tanıtım bağlantısındaki içerik oldukça iyi. Aşağıda bunu yapay zeka ile özetledim.

Spesifikasyon Odaklı Geliştirme (Specification-Driven Development, SDD)

Gücün Tersine Dönüşü

• Kodu merkeze alıp PRD ve tasarım belgelerini yardımcı unsur olarak kullanan akışı tersine çevirerek, spesifikasyonun asıl kaynak ve kodun da belirli bir dil ya da framework üzerinde gerçekleştirilen bir ifade biçimi olduğunu savunuyor
  • Spesifikasyon ile implementasyon arasındaki kalıcı boşluğun belge takviyesi ya da süreç sıkılaştırmasıyla giderilmesinin zor olduğuna dair bir tespit sunuyor
  • Çalıştırılabilir spesifikasyonlar ve uygulama planı kodu üretirse bu boşluk ortadan kalkar ve geriye yalnızca dönüşüm kalır
• Yapay zeka, karmaşık spesifikasyonların yorumlanmasını ve uygulama planlarının oluşturulmasını mümkün kılar; ancak yapısız üretim kaosa yol açtığı için SDD, kaliteyi kesin yapı ve koruyucu sınırlar ile güvence altına alır
• Bakım, spesifikasyonun evrimleşmesi eylemidir; geliştirme niyeti doğal dil, tasarım varlıkları ve temel ilkelerle ifade edilir, kod ise son mil konumundadır
• Hata ayıklamada yanlış kodu düzeltmekten çok spesifikasyonun ve uygulama planının düzeltilmesi öncelik kazanır; refactoring ise açıklığın yeniden yapılandırılması olarak yeniden tanımlanır

Pratikte SDD İş Akışı

• Fikir, yapay zeka ile konuşmalı etkileşim üzerinden PRD'ye dönüştürülerek rafine edilir; yapay zeka soruları, edge case'leri ve kabul kriterlerini somutlaştırır
  • Gereksinim ve tasarımı sürekli bir etkinliğe dönüştürerek ekip düzeyinde branch tabanlı spesifikasyon çalışması, inceleme ve sürümlemeyi destekler
• Araştırma ajanı, kütüphane uyumluluğu, performans, güvenlik ve kurumsal kısıtları (DB standardı, kimlik doğrulama, dağıtım politikası) araştırır ve bunları otomatik olarak spesifikasyona yansıtır
• PRD'den uygulama planı üretilerek gereksinimler ile teknik kararlar izlenebilir biçimde eşleştirilir; yapay zeka da çelişkileri, belirsizlikleri ve eksikleri sürekli doğrular
• Spesifikasyon ve plan yeterince olgunlaştığında kod üretimi başlar; ilk aşamada ise keşif amaçlı üretim ile uygulanabilirlik doğrulanır
  • Alan kavramları veri modeli, kullanıcı hikâyeleri API endpoint'leri, kabul senaryoları ise testler hâline dönüştürülür
• Operasyon aşamasındaki metrikler ve incident'lar, spesifikasyonu güncelleyerek bir sonraki yeniden üretime yansıtılır; performans darboğazları işlevsel olmayan gereksinimler, güvenlik açıkları ise genel kısıtlar seviyesine yükseltilir

SDD Neden Şimdi Önemli?

• Yapay zeka yetenek eşiği: Doğal dildeki spesifikasyonlardan güvenilir biçimde çalışan kod üretmek mümkün hâle geldi; implementasyon çevirisinin mekanik kısmının otomasyonu, keşfi ve yaratıcılığı artırmayı destekliyor
• Karmaşıklığın patlaması: Çok sayıda servis, framework ve bağımlılık nedeniyle niyet-implementasyon uyumunu korumak zorlaştı; bu yüzden SDD'nin spesifikasyon güdümlü hizalamasına ihtiyaç var
• Değişimin hızlanması: Sık pivot yaşanan durumlarda SDD, değişiklikleri belge-tasarım-kod arasında elle yaymak yerine sistematik yeniden üretimle ele alır
  • Örnek olarak what-if simülasyonları ve paralel implementasyonu mümkün kılarak karar alma çevikliği sağlar

Temel İlkeler

• Spesifikasyon = ortak dil: Spesifikasyon birinci sınıf çıktıdır, kod belirli bir stack'in ifadesidir ve bakım da spesifikasyonun evrimi eylemidir
• Çalıştırılabilir spesifikasyon: Doğru, eksiksiz ve yoruma kapalı seviyedeki spesifikasyonlarla çalışan sistem üretilir
• Sürekli rafinasyon: Tek seferlik bir kapı yerine sürekli tutarlılık doğrulaması yapılır
• Araştırma temelli bağlam: Performans, güvenlik ve kurumsal kısıtlar sürekli toplanarak spesifikasyona eklenir
• İki yönlü geri bildirim: Operasyondaki gerçeklik, spesifikasyon güncellemesinin girdisi olur
• Keşif için dallanma: Aynı spesifikasyondan performans, bakım yapılabilirlik, UX, maliyet gibi optimizasyon hedeflerine göre birden çok implementasyon üretilmesi desteklenir

Uygulama Yaklaşımları

• Bugün uygulanabilir kısımda asıl önemli olan, mevcut araçları bir araya getirmek ve disiplini korumaktır; bu da şu unsurlarla mümkündür
  • Spesifikasyonun yinelemeli rafinasyonu için yapay zeka asistanı
  • Teknik bağlam toplamak için araştırma ajanı
  • Spesifikasyondan implementasyona dönüşüm için kod üretim araçları
  • Spesifikasyon öncelikli iş akışına uygun sürüm kontrolü
  • Spesifikasyon belgeleri üzerinde yapay zeka tutarlılık analizi temelli kontrol
• Ortak ilke, spesifikasyonu tek doğruluk kaynağı olarak konumlandırmak ve kodu da spesifikasyonun talep ettiği çıktı olarak ele almaktır

Komutlarla SDD'yi Akıcı Hâle Getirmek

• /specify: Özellik açıklamasını yapılandırılmış bir spesifikasyona dönüştürür; otomatik numaralandırma, branch oluşturma ve şablon tabanlı dizin kurulumunu otomatikleştirir
• /plan: Spesifikasyon analizi → anayasa uyumluluğu incelemesi → teknik çeviri → veri modeli, API sözleşmesi, test senaryoları dokümantasyonu → quickstart doğrulaması üretir
• /tasks: plan.md ve ilgili tasarımı okuyarak uygulanabilir görev listesi üretir; paralel yapılabilecek görevleri işaretler ve güvenli paralel gruplandırma sağlar
• Örnek: sohbet özelliği
  • Geleneksel yaklaşımda yaklaşık 12 saatlik dokümantasyon işini, spesifikasyon, plan ve görev otomasyonuyla yaklaşık 15 dakikalık kurulum düzeyine indiren bir akış örneği sunuluyor
  • Çıktılar arasında spesifikasyon, uygulama planı ve gerekçeleri, API sözleşmesi ve veri modeli, quickstart senaryosu, tasks.md bulunuyor ve bunlar branch içinde sürüm kontrolüne alınıyor

Yapılandırılmış Otomasyonun Gücü

• Eksik öğeleri önleme: Şablonlar, işlevsel olmayan gereksinimler ve hata işleme dâhil olmak üzere kapsamı genişletir
• Karar izlenebilirliği: Tüm teknik seçimler somut gereksinimlerle ilişkilendirilir
• Yaşayan belge: Spesifikasyon kodu ürettiği için senkronizasyonu korumak kolaylaşır
• Hızlı yineleme: Gereksinim değiştiğinde planı yeniden üreterek dakika ya da saat ölçeğinde yanıt vermek mümkün olur

Şablon Tabanlı Kalite

• Uygulama ayrıntılarının erken sızmasını önleme: WHAT/WHY odaklı, HOW'u dışarıda bırakan kurallarla soyutlama seviyesinin korunması teşvik edilir
• Belirsizlik işaretlemeyi zorunlu kılma: [NEEDS CLARIFICATION] işareti ile tahmini yasaklama ve açık soru sorma teşvik edilir
• Kontrol listesi tabanlı öz denetim: Tamlık, açıklık ve ölçülebilir kabul kriterleri kontrol edilerek kalite kapısı oluşturulur
• Anayasa kapısı: Basitlik kapısı (≤3 proje), anti-abstraction kapısı (framework'ü doğrudan kullanma), entegrasyon öncelikli kapı (sözleşme ve sözleşme testlerini önceleme) gibi ön aşama (-1) kontrolleri uygulanır
• Katmanlı ayrıntı yönetimi: Aşırı kod ve ayrıntı, implementation-details/ altına ayrılarak okunabilirlik korunur
• Test önceliği: Sözleşme → entegrasyon → E2E → birim sırasındaki dosya üretimi ve test önceliği kurallarıyla doğrulanabilirlik sağlanır
• Varsayım ve tahmini özellikleri bastırma: Tahmine dayalı özellik yasağı ve aşama bazlı ön koşulların açıkça belirtilmesiyle kapsam yönetimi güçlendirilir

Anayasal Temel

• memory/constitution.md içindeki değişmez ilkelerle, tüm implementasyonların tutarlı, sade ve yüksek kaliteli kalmasını sağlayan bir geliştirme anayasası benimsenir
  • Article I: Library-First — Her özellik bağımsız bir kütüphane olarak başlar ve modülerlik sağlar
  • Article II: CLI Mandate — Her kütüphane, metin girdi/çıktısı ve JSON destekleyen bir CLI arayüzü sunarak gözlemlenebilirliği ve test kolaylığını güvence altına alır
  • Article III: Test-First — Test onayı ve başarısızlık (red) doğrulanmadan implementasyon yasaktır; önce davranışı tanımlama ilkesi uygulanır
  • Articles VII & VIII: Basitlik ve anti-abstraction — Proje sayısını en aza indirme ve framework'lere doğrudan güvenme ile aşırı mühendislik engellenir
  • Article IX: Integration-First Testing — Gerçek ortama yakın testler tercih edilir ve sözleşme testleri implementasyondan önce zorunlu tutulur
• Şablonlardaki Phase -1 kapısı, anayasa uyumluluğunu kontrol listesi hâline getirir; istisnalar ise Complexity Tracking içinde açık gerekçeyle kaydedilir
• Değişiklik prosedürü sayesinde ilkelerin uygulanma biçimi evrilebilir, ancak çekirdek felsefe korunur

Dönüşüm

• Hedef, geliştiricilerin yerini almak değil; mekanik çeviriyi otomatikleştirerek insan yeteneklerini güçlendirmek ve niyet-implementasyon uyumunu korumaktır
• SDD, spesifikasyonun kodu üretmesini sağlayarak spesifikasyon, araştırma ve kodun sıkı bir geri bildirim döngüsü içinde birlikte evrildiği sürekli dönüşümü hayata geçirir

Büyük Birader kaynak kodu sızdı!

Ayrıca, prompt zincirleme sayısıyla ilgili deneyi de sormuştunuz.

Aslında bu, tersine, yazarın kaba tabirle kolayca hile yapmasına elverişli bir unsurdur.

Geliştirme denen eylemin kendisinde, izlenecek yönde son derece çok seçenek vardır; token kullanımını daha fazla açacak yönde promptları biriktirirseniz, o sayı kartopu gibi daha da büyür.

Araştırmada Cumulative Science diye bir felsefe vardır.

En azından benim ölçütlerime göre, tek seferlik komutta token kullanımıyla ilgili bir araştırmaya şimdiye kadar hiç rastlamadığım için,

hemen N kezlik bir araştırma yapmak yerine, net bir tek seferlik teste ve onun sonucuna odaklandım,

N kezlik araştırma ise bu deneyin ardından çalışmalar sürerse devam edebilir.

İnşaat mühendisliği gibi alanlarda, üniversite derslerinde de zaten kullanılıyor.

Ayrıca, başka bir yazıda kod tabanındaki farklılıklara göre yapay zekanın davranış farklarını ele almıştım.
(Bu da daha önce GeekNews'te tanıtılmıştı: https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/)

Kısaca açıklamak gerekirse, yapay zekaya verilen kod tabanına göre çıktının kalitesinin değiştiğini gösteren testler ve sonuçlar ele alınıyor.

Başlangıçtaki kod tabanının kalitesi ve yönüne bağlı olarak, sonrasında gelen kod kalitesi korunabilir de sürekli kötüleşebilir de.

Yani projenin ilk aşamasındaki refactoring maliyeti ile epey ilerlemiş bir projenin refactoring maliyeti büyük ölçüde farklı olabilir.

Eğer soruyu soran kişi bir geliştiriciyse, muhtemelen 'yelkenli üstündeki uçak gemisi' ifadesini en az bir kez duymuştur,

refactoring'in hangi noktada yapılması gerektiği ya da projenin başında yerleşen yaklaşım ve tasarıma göre maliyetin inanılmaz derecede değişebildiği oldukça derin bir konudur.

Bunu da bir değişken olarak dahil edip sonucu belirsiz hale getirmek yerine,

'en azından kod tabanı kalitesi iyiyse token kullanımının azaldığını' net biçimde açıklayabilen bir test yapılmış oldu.

Tekrar açıklamayı deneyeyim.

Vibe coding yapanların yelpazesi geliştirici olmayanlardan deneyimli geliştiricilere kadar oldukça geniştir. Sahip oldukları bilgi düzeyine göre, bu yazının içeriğinden tamamen bağımsız olarak ortaya çıkan çıktının kalitesi büyük farklılık gösterebilir.
Birileri doğal olarak cursor kullanımını temel alıp .cursorrules içine temel OOP kurallarıyla sınıf/metot ayırma kurallarını koyarak neredeyse hiç refactoring gerektirmeyen bir yapıda çalışıyor olabilir,
birilerinde ise en temel ana noktaları kavrayamama nedeniyle düşük seviyeli kodun sürekli üretiliyor olması söz konusu olabilir.

Hatta temelde proje kuralları ayarlayarak kod kalitesini iyi tutmanız gerektiğini anlatan yazı ve deneyim örnekleri daha önce de çokça vardı.

• Dosya boyutunu küçük tutun: https://medium.com/realworld-ai-use-cases/…
• Kod tabanı büyürken Cursor'ın çalışma hızını yüksek tutmanın yolu: https://forum.cursor.com/t/…
• Windsurf en iyi uygulamaları ve yönergeleri: https://gist.github.com/muratkeremozcan/…

Bu, bazı kişilerin açık bir refactoring yapmadan da token kullanımı açısından kazanç sağlıyor olabileceğine işaret eder.

Ancak yukarıdaki örneklerde, ilgili kural tanımları üzerinden yürütme başına token kullanımında ne kadar net bir azalma olduğu düzenli biçimde ortaya konmuyor. Bu nedenle bu yazıda, kod tabanı kalitesine göre token kullanımı farkını test edip sonuçları derledim.

Yani kullanıcıya bağlı olarak, açık refactoring sayısı başlı başına yeniden 0~n kez arasında değişen bir değişken hâline gelir,

Bu yazının özündeki niyetin, "Neden iyi kalitede bir codebase'e dikkat etmek faydalıdır?" sorusunu açıklamak olduğunu düşünmek daha doğru olur.