Yazılım dünyasında bazen öyle bir eşik geliyor ki, ilk başta kimse tam fark etmiyor. Sonra bir bakıyorsunuz, “deneysel” diye geçilen şey bir anda ekiplerin günlük rutini olmuş. İşin aslı şu ki, agentic coding tarafında da benzer bir kırılma yaşanıyor (en azından benim deneyimim böyle). Bir yıl önce vibe coding konuşuluyordu; hızlı prototip çıkarma, fikirleri çabuk deneme, küçük ekiplerle büyük iş yapma hayali… Güzel tarafı çoktu. Ama açık konuşayım, ortaya çıkan kod kalitesi genelde iç açıcı değildi. Hani masaya hızlıca yemek geliyordu ama tabak biraz dağınıktı.
Şimdi sahneye başka bir yaklaşım çıkıyor: spec-driven development. Yani ajan kod yazmadan önce elinde net, yapılandırılmış, bağlamı bol bir spesifikasyon oluyor. Ben bunu ilk kez 2024 sonbaharında İstanbul’da bir ürün ekibiyle konuşurken duydum; ekip lideri “AI kod yazıyor. Neyi doğru sayacağımızı söylemezsek iş büyüyor” demişti. O cümle kulağıma kazındı. Çünkü mesele artık “AI kod yazabiliyor mu?” sorusu değil, “bu kodu güvenle çalıştırabilir miyiz?” sorusu.
Vibe Coding’den Spec-Driven Dünyaya Geçiş
Bi saniye — Vibe coding’in olayı neydi? Hız. Bir junior geliştirici ya da teknik olmayan biri bile AI yardımıyla fikirden çalışan prototipe çok çabuk gidebiliyordu — bu fena değil, hatta baya işe yarayan bir kapı açtı, inkâr etmek olmaz. Fakat aynı hızla borç da birikti; belirsiz davranışlar, eksik testler, dokümansız kararlar derken sisteme bakarken “bunu kim neden böyle yaptı?” sorusu kaçınılmaz hale geldi (ciddiyim). Kısa vadede tatlı. Uzun vadede baş ağrısı.
Spec-driven development ise ters yönden geliyor. Önce “ne yapılacak?”, sonra “hangi koşullarda doğru sayılır?”, en son “kod nasıl üretilecek?” Bu yaklaşım klasik dokümantasyondan farklı çünkü spec sadece okunmak için durmuyor — ajan onun üzerinden akıl yürütüyor, yani mutfakta tarif kartı var ve şef o kartın dışına çıkınca alarm çalıyor gibi düşünebilirsiniz.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Geçen yıl Mart 2025’te Ankara’da küçük bir SaaS ekibiyle yaptığım görüşmede bunu çok net gördüm. İki haftada çıkan özellikler üç güne indi ama hata oranı tırmanıyordu. Spec’i sürece eklediklerinde işler yavaşlamadı, tam tersine daha az geri dönüş çıktı, “şunu niye böyle yaptık?” toplantıları neredeyse kayboldu. Şaşırtıcıydı doğrusu. Beklemiyordum.
Bir de şu var: bu model herkes için aynı anda sihirli değnek değil (ben de ilk duyduğumda şaşırmıştım). Küçük startup’ta spec hazırlamak bazen fazla formalite gibi gelebilir, anlarım o hissi. Ama enterprise tarafta yüzlerce check-in üreten ajanın önüne geçmek istiyorsanız, kağıt üstünde süper görünen o serbestlik pratikte gerçekten felaket çıkarabiliyor.
Spesifikasyon Neden Güven Modeli Oldu?
Bir şey dikkatimi çekti: İşin kilit noktası güven. Nokta. Ajanın yazdığı koda tek tek insan bakarak yetişmek mümkün değil; hele ekip günde onlarca hatta yüzlerce değişiklik üretiyorsa hiç mümkün değil. Spec burada referans noktası oluyor: sistem ne yapmalı, hangi sınırlar içinde kalmalı, hangi çıktılar kabul edilebilir… Bunlar netleşince AI’ın üretimi rastgele olmaktan çıkıp denetlenebilir hale geliyor.
İşte tam da bu noktada devreye giriyor.
Ben bu mantığı ilk kez 2023’te kendi yan projemde test etmiştim; basit bir otomasyon aracıydı ve küçük hatalar bile zincirleme sorun yaratıyordu, ciddi can sıkıcıydı (evet, doğru duydunuz). Spec ekleyince garip bir şey oldu — geliştirme hızı arttı. Çünkü tartışma azalıyor, herkes kafasındaki şeyi anlatmak yerine belgeye bakıyor (evet, biraz sıkıcı ama işe yarıyor). Tahmin eder misiniz? Açık konuşayım: iyi yazılmış spec çoğu zaman iyi niyetli beyin fırtınasından daha değerli.
Ajanlara güvenmek istiyorsanız önce onlara yorum alanı değil sınır verin; spec tam olarak bunu yapıyor.
İyi spec nasıl görünür?
Kötü spec genelde belirsiz olur: “kullanıcı deneyimi iyileştirilsin”, “performans artırılsın”, “daha güvenli olsun”. Güzel sözler. Ama ajana pek yol göstermez. Neden önemli bu? İyi spec ölçülebilir olur; yanıt süresi belli olur, hata durumları tanımlanır, veri erişim sınırları yazılır — ve bu sınırlara gerçekten uyulup uyulmadığı kontrol edilir. Daha fazla bilgi için 5G Geldi, Şikâyetler Neden Bir Anda Fırladı? yazımıza bakabilirsiniz.
Bak şimdi, Aşağıdaki tabloyu ben pratikte çok kullanıyorum; ekip içinde ilk kontrol listesi gibi davranıyor:
| Kriter | Zayıf Spec | Sağlam Spec |
|---|---|---|
| Amaç | Daha iyi raporlama | Raporların 10 saniye içinde açılması |
| Kabul ölçütü | Kullanıcı memnun olsun | %95 başarı oranı ve <2 sn API gecikmesi |
| Kapsam | Tümü yapılsın | Sadece satış modülü güncellensin |
| Test yaklaşımı | Bakarız | Sınır değer ve hata senaryosu testleri eklensin |
Büyük Kurumlarda Neden Daha Fazla İşe Yarıyor?
Büyük organizasyonlarda problem sadece kodun kalitesi değil. Koordinasyon maliyeti de devreye giriyor. Alt takım başka şey düşünüyor, güvenlik başka yere çekiyor, ürün tarafı bambaşka öncelik istiyor… ve sonunda ortada herkesin biraz haklı olduğu ama kimsenin tam memnun olmadığı bir sürüm kalıyor. Tanıdık geldi mi? Bu konuyla ilgili 2026’de Finans API’leri: MCP ve Agent Dönemi yazımıza da göz atmanızı tavsiye ederim.
Açık konuşayım, Kiro IDE ekibinin kendi ürününü yine Kiro ile geliştirdiği örnek burada önemliydi; feature build sürelerinin iki haftadan iki güne düşmesi kulağa abartılı gelebilir,. Bu tür kazanımlar genelde tek numaralı kahramandan gelmiyor — süreçten geliyor. Amazon tarafında anlatılan projelerde de benzer desen var: ayrıntılı bağlam artı net spec artı otomatik doğrulama eşittir daha az sürpriz. Bu kadar basit. Bu konuyla ilgili CPUID saldırısı: CPU-Z ve HWMonitor indirirken dikkat yazımıza da göz atmanızı tavsiye ederim.
Bir kurumsal projede en büyük hayal kırıklığı genelde hız kaybından çok belirsizliktir. Kimse neden böyle olduğunu bilmiyorsa toplantılar uzar da uzar. İşte spec burada tartışmayı azaltıyor çünkü karar metni elde duruyor, kimse “ama ben öyle anlamıştım” diyemiyor.
Küçük startup ile enterprise arasındaki fark ne?
- Küçük startup’ta amaç hızlı öğrenme olabilir; spec hafif tutulur ama yine de test edilebilir olmalı.
- Enterprise’da audit izi gerekir; kim neyi neden yaptı sorusunun cevabı şarttır. — bunu es geçmeyin
- Startup daha esnek hareket ederken kurumda risk yönetimi ağır basar.
- Her iki tarafta da ortak nokta aynı: belirsizlik pahalıdır. (bence en önemlisi)
Sadece Yazmak Yetmiyor: Test ve Doğrulama Katmanı
Kendi deneyimimden konuşuyorum, Ajanların güvenli çalışması için ikinci can alıcı parça doğrulama katmanı. Property-based testing ya da spekülatif davranışları tarayan otomatik test setleri burada devreye giriyor. Mesela elle yazılmış birkaç test yetmeyebilir; çünkü ajan beklenmedik kombinasyonlar üretebilir ve insanın aklına gelmeyen kenar durumları pat diye ortaya çıkabilir — hem de en kötü zamanda.
{
"spec": {
"feature": "checkout-after-purchase",
"rules": [
"order must be completed before add-to-delivery",
"items can be added within 30 minutes",
"payment status must remain consistent"
]
}
}Şöyle ki, Nisan 2025’te İzmir’de görüştüğüm orta ölçekli bir e-ticaret ekibi bu yüzden zorlanmıştı; AI’ın önerdiği kod çalışıyordu. Edge case’lerde saçmalıyordu, özellikle iade akışında. Test katmanını güçlendirince sorunların yarısı zaten masada yakalandı. İşi güzelleştiren şey hız değilmiş meğer. Tutarlılıkmış.
Aman ha, unutmayın: pratik noktalar
Önce dar kapsamla başlayın. Tüm sistemi aynı anda agentic moda sokmaya kalkarsanız hem maliyet artar hem de ekip neyin nerede bozulduğunu anlayamaz — ve o kaos gerçekten bunaltıcı olabiliyor.
Bir de gözden kaçan konu şu: spesifikasyon yaşayan bir belge olmalı, yani değiştikçe güncellenmeli. Yoksa üç hafta sonra raf tozu tutmuş bir PDF’e dönüşür ve kimse dönüp bakmaz. Oluyor böyle şeyler. Çok oluyor. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Süreç Nasıl Kurulur? Basit Bir Akış Örneği
Lafı gevelemeden söyleyeyim: iyi çalışan akış karmaşık olmak zorunda değil. Önce gereksinim netleşir. Sonra kabul kriterleri çıkarılır. Ardından ajan görev alır ve en sonda otomatik testler sonucu onay verir ya da geri çevirir. Bu zincirin herhangi bir halkası gevşek olursa sonuç hemen hissediliyor — genellikle de en kötü anda (ciddiyim)
# Basit is akışı
1) Problem tanimi
2) Spec oluşturma
3) Ajan ile kod uretimi
4) Otomatik test / property-based validation
5) Insan incelemesi
6) Merge karari
E tabi bunun kusursuz versiyonu yok. Küçük takımlarda fazla bürokrasi boğabilir; büyük takımlarda bir düşüneyim… ise yetersiz spec kaosa davetiye çıkarır. Benim gördüğüm en dengeli model şu oldu: kritik yollar için sıkı spec, düşük riskli işler için hafif şablonlar. Ortası bulunabiliyor yani, biraz sabır istiyor sadece. Bu konuyla ilgili Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza da göz atmanızı tavsiye ederim.
Bazıları Neden Hâlâ Direniyor?
Şunu söyleyeyim, Direncin sebebi çoğu zaman teknik değil psikolojik. Dur, bunu biraz açayım. Teknik taraf kolaylaşınca insanlar rollerinin küçüleceğini sanabiliyor — oysa kod yazan kişi neredeyse tamamen ortadan kalkmıyor, daha çok mimariyi okuyan, karar veren ve kaliteyi yöneten role kayıyor. Aslında bu kötü haber değil, hatta daha az angarya demek. Bu ne anlama geliyor? Beklediğim kadar değildi diyenler genelde bunu erken fark etmeyenler oluyor.
Ekiplerin buna alışması vakit alıyor. Hız kazanımı hemen görünse de güven inşası biraz pişmek istiyor, aceleden olmuyor. Neyse uzatmayayım: iyi çalışan kurumlar önce pilot başlatıp sonra yayılıyor. Bu kadar basit görünüyor. Uygulaması ayrı dert tabi.
Sıkça Sorulan Sorular
Spec-driven development nedir?
Ajanın kod yazmadan önce yapılandırılmış bir spesifikasyona göre çalıştığı geliştirme yaklaşımıdır. Amaç sadece üretmek değil, doğru şeyi üretmektir.
Neden agentic coding için önemli?
İtiraf edeyim, Çünkü ajanların ürettiği kodun manuel olarak tek tek incelenmesi zorlaşıyor.Spec sayesinde beklenti netleşiyor ve doğrulama kolaylaşıyor.
Küçük ekipler de kullanabilir mi?
Dürüst olmak gerekirse, Evet.Küçük ekiplerde hafif tutulmuş specler gayet iş görüyor.Fazla bürokrasi kurmadan temel kabul kriterlerini belirlemek yeterli olabilir.
En büyük risk nedir?
Speclerin güncel kalmaması.En güncel olmayan belge yanlış yönlendirme yapar ve pek çok akışı zayıflatır.Güncelleme disiplini şarttır.
Kaynaklar ve İleri Okuma
GitHub Ana Sayfası ve Proje Kaynakları
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
