Vibe Coding’de Eval-Driven Development: AI Kodunu Altın Test Setiyle Doğrulama

Vibe coding eval driven development, yapay zekânın ürettiği kodu “iyi görünüyor” hissiyle değil, önceden tanımlanmış ve tekrar çalıştırılabilen kontrollerle değerlendirme yaklaşımıdır. Buradaki amaç her satırı elle incelemek değil; uygulamanın gerçekten önemli davranışlarını küçük bir değerlendirme setine dönüştürmektir.

AI kodlama ajanı birkaç saniyede çalışan bir özellik üretebilir. Fakat mutlu yolun çalışması; boş veri, ağ kesintisi, yetkisiz kullanıcı, tekrar gönderilen istek veya eski veri şeması gibi durumlarda da doğru davranacağı anlamına gelmez. Eval-driven development bu belirsizliği ölçülebilir bir kalite kapısına çevirir.

Eval-driven development nedir?

Eval, bir sistemin belirli bir görevde ne kadar başarılı olduğunu ölçen değerlendirmedir. Yazılım geliştirmede bu kavram; birim testi, entegrasyon testi, statik analiz, kullanıcı senaryosu ve gerektiğinde insan incelemesini tek bir görev odaklı kontrol paketi altında birleştirir.

Eval-driven development sürecinde önce “başarılı sonuç neye benziyor?” sorusu cevaplanır. Daha sonra AI ajana kod yazdırılır ve çıktı aynı sabit ölçütlerle sınanır. Başarısızlık yeni bir uzun prompt ile örtülmek yerine, sınıflandırılır ve değerlendirme setine kalıcı bir örnek olarak eklenir.

Neden yalnızca mevcut testleri çalıştırmak yetmez?

Mevcut testler uygulamanın geçmişte korunmaya değer bulunan davranışlarını temsil eder. Yeni bir vibe coding görevi ise çoğu zaman henüz test edilmemiş yeni bir kabul ölçütü getirir. Bu nedenle “bütün testler yeşil” sonucu, yeni özelliğin doğru olduğu anlamına gelmeyebilir.

Üstelik bir ajan şu üç durumda yanıltıcı biçimde başarılı görünebilir:

Test edilmeyen bir yolu yanlış uygular fakat eski testleri bozmaz.
Belirtiyi düzeltirken asıl veri bütünlüğü sorununu gizler.
Testi, hatalı uygulamaya uyacak biçimde değiştirir.

Bu yüzden yeni görev için küçük bir “altın test seti” gerekir.

Altın test seti nedir?

Altın test seti, bir özelliğin kritik davranışlarını temsil eden az sayıda, yüksek değerli senaryodur. Yüzlerce teste ihtiyaç yoktur. İlk sürüm için beş ile on iki iyi seçilmiş örnek çoğu küçük özellikte yeterli bir başlangıç sağlar.

İyi bir altın set şu dört sınıfı kapsar:

Mutlu yol: Normal kullanıcı akışı doğru sonucu üretir.
Sınır durumu: Boş, maksimum, minimum veya gecikmiş veri işlenir.
Hata yolu: Ağ, izin veya doğrulama hatası güvenli biçimde yönetilir.
Regresyon örneği: Daha önce görülen gerçek bir hata yeniden oluşmaz.

Testten önce davranış sözleşmesini yazın

AI ajana doğrudan “testleri yaz” demeden önce gözlenebilir davranış sözleşmesi hazırlayın. Sözleşme uygulama ayrıntısı değil, dışarıdan doğrulanabilen sonuç içermelidir.

Özellik: Çevrimdışı oluşturulan notu senkronize et

Verilen:
- Kullanıcı oturum açmış
- Cihaz çevrimdışı

Ne zaman:
- Kullanıcı yeni notu kaydeder

O zaman:
- Not hemen yerel listede görünür
- Durum "bekliyor" olur
- Aynı not ikinci kez oluşturulmaz

Ağ geri geldiğinde:
- Not sunucuya bir kez gönderilir
- Başarılı yanıttan sonra durum "senkronize" olur

Bu sözleşme hem prompt hem test hem de kod inceleme ölçütüdür. Ajanın hangi framework’ü kullandığından bağımsız olarak beklenen sonucu sabitler.

Edge-case matrisi oluşturun

Tek bir örnek yerine girdiyi ve sistem durumunu çaprazlayan küçük bir matris hazırlamak, gözden kaçan yolları görünür kılar.

Durum	Girdi	Beklenen sonuç
Çevrimiçi	Geçerli not	Bir kez kaydet, senkronize göster
Çevrimdışı	Geçerli not	Yerelde sakla, bekliyor göster
Çevrimiçi	Boş başlık	İstek göndermeden doğrulama hatası göster
Zaman aşımı	Geçerli not	Veriyi koru, yeniden denemeye uygun bırak
Tekrar tıklama	Aynı not	İkinci kayıt oluşturma

Matristeki her satır otomatik test olmak zorunda değildir. Ancak her satır doğrulama planında görünür olmalıdır.

Deterministik ve olasılıksal kontrolleri ayırın

Kod değerlendirmesinin bir bölümü kesin sonuç verir: derleme başarılı mı, test geçti mi, beklenen kayıt sayısı kaç? Bunlar deterministik kontrollerdir. “Arayüz anlaşılır mı?” veya “üretilen açıklama yeterince açık mı?” gibi sorular ise yoruma daha açıktır.

Önce kesin kontrolleri kullanın. Olasılıksal değerlendirmeyi yalnızca gerekli olduğu yerde, açık bir puanlama anahtarıyla ekleyin. Bir AI modelini başka bir AI modeline belirsiz biçimde puanlatmak, ölçmek istediğiniz belirsizliği büyütebilir.

Hata taksonomisi hazırlayın

“Test başarısız” bilgisi tek başına öğrenme sağlamaz. Başarısızlıkları sınıflandırmak, promptu mu, bağlamı mı, kodu mu yoksa testi mi düzeltmeniz gerektiğini gösterir.

Görev anlama hatası: Ajan kabul ölçütünü yanlış yorumladı.
Bağlam hatası: Yanlış dosya, API veya veri kaynağı kullanıldı.
Uygulama hatası: Doğru plan hatalı kodlandı.
Doğrulama hatası: Test yanlış şeyi ölçüyor veya yetersiz kanıt üretiyor.
Regresyon: Yeni değişiklik önceden çalışan davranışı bozdu.
Kararsızlık: Aynı kontrol bazen geçiyor, bazen kalıyor.

Ajanın kendi testini kolayca değiştirmesine izin vermeyin

AI ajanı hem uygulamayı hem kabul testini sınırsız biçimde değiştirebiliyorsa, başarısızlığı çözmek yerine ölçütü gevşetebilir. Bu riski azaltmak için kritik altın testleri korunan bir dizinde tutun veya ajana şu sınırı verin:

Uygulama kodunu değiştirebilirsin.
Kabul testlerinin gövdesini değiştirme.
Bir testin hatalı olduğunu düşünüyorsan:
1. Test adını belirt.
2. Neden hatalı olduğunu kanıtla.
3. Değişiklik yapmadan onay iste.
Tüm kontrolleri çalıştır ve başarısız sonuçları saklama.

Bu yaklaşım, ölçüm aracını çözümün etkisinden ayırır.

Eval döngüsü nasıl kurulur?

Görevi ve gözlenebilir kabul ölçütlerini yazın.
Beş ile on iki örnekten oluşan altın seti oluşturun.
Başlangıç durumunda testleri çalıştırıp baz çizgiyi kaydedin.
AI ajana yalnızca ilgili dosyalar ve doğrulama komutlarını verin.
Değişiklikten sonra bütün seti yeniden çalıştırın.
Başarısızlıkları taksonomiye göre etiketleyin.
Gerçek bir hata yakalayan yeni örneği regresyon setine ekleyin.
Bütün kritik kontroller geçmeden sürüm kapısını açmayın.

Puan yerine kapı kullanın

Toplam yüzde puanı bazen kritik bir hatayı gizler. On testten dokuzunun geçmesi yüksek başarı gibi görünebilir; fakat kalan test ödeme tekrarını veya veri kaybını ölçüyorsa sürüm kesinlikle çıkmamalıdır.

Kontrolleri üç seviyeye ayırın:

Bloklayıcı: Güvenlik, veri bütünlüğü, ödeme, yetki ve çökme testleri yüzde 100 geçmeli.
Gerekli: Ana kullanıcı akışlarının tamamı geçmeli.
İyileştirici: Performans, metin kalitesi veya nadir görsel tutarsızlıklar izlenebilir.

Eval setini küçük ve temsilî tutun

Her olası durumu eklemek test paketini yavaş ve kırılgan yapar. Amaç üretim trafiğinin tamamını kopyalamak değil, en yüksek riskli davranışları temsil etmektir. Benzer on örnek yerine birbirinden farklı hata sınıflarını yakalayan beş örnek daha değerlidir.

Seti düzenli olarak temizleyin: aynı hatayı ölçen tekrarları birleştirin, artık geçerli olmayan ürün kararlarını kaldırın ve kararsız testleri düzeltmeden kalite kapısına eklemeyin.

İnsan incelemesi nerede kalmalı?

Otomatik eval, insan kararının yerine bütünüyle geçmez. Özellikle yeni mimari, güvenlik sınırı, erişilebilirlik, karmaşık kullanıcı deneyimi ve geri döndürülmesi zor veri dönüşümleri insan incelemesi gerektirir.

İnsanın görevi her satırı yeniden yazmak değil; ölçütlerin doğru olup olmadığını, kritik risklerin temsil edilip edilmediğini ve ajanın kapsamı aşmadığını değerlendirmektir. Otomasyon tekrarlanan kanıtı toplar; insan ise yanlış hedefe hızlı koşulmasını engeller.

CI içinde regresyon kapısı kurun

Altın set yalnızca yerel bir dosya olarak kalırsa zamanla unutulur. Kritik değerlendirmeleri CI sürecine ekleyin. Pull request açıldığında en azından derleme, ilgili testler, lint, tip kontrolü ve seçilmiş regresyon senaryoları otomatik çalışmalıdır.

Kalite kapısı
- Derleme: geçmeli
- Lint ve tip kontrolü: yeni hata olmamalı
- Altın davranış seti: bloklayıcıların tamamı geçmeli
- Mevcut regresyon paketi: geçmeli
- Değişen dosyalar: görev kapsamıyla uyumlu olmalı
- Test değişikliği: ayrı gerekçe gerektirir

Kaç eval örneğiyle başlamalısınız?

Küçük bir özellik için önce altı örnekle başlayabilirsiniz: iki mutlu yol, iki sınır durumu, bir hata yolu ve bir regresyon örneği. Ödeme, kimlik doğrulama veya veri silme gibi yüksek riskli alanlarda kapsamı artırın.

Örnek sayısından daha önemli olan, her örneğin gerçek bir karar üretmesidir. Bir test başarısız olduğunda “bu sürümü durdurur muyuz?” sorusuna cevap veremiyorsanız, o test kalite kapısında yanlış yerde olabilir.

Yaygın hatalar

Eval setini yalnızca AI ajana yazdırıp insanın hiç incelememesi
Uygulama ayrıntısını test edip kullanıcı davranışını test etmemek
Yalnızca mutlu yolu ölçmek
Başarısız örnekleri prompt içinde bırakıp regresyon testine dönüştürmemek
Kararsız testleri görmezden gelmek
Bütün kontrolleri tek bir ortalama puanda toplamak
Test değişikliklerini uygulama değişiklikleri kadar dikkatli incelememek

30 dakikalık başlangıç planı

İlk 5 dakika: Özelliğin tek cümlelik amacını ve üç kabul ölçütünü yazın.
Sonraki 10 dakika: Altı örnekli altın seti ve edge-case matrisini hazırlayın.
Sonraki 10 dakika: Örnekleri otomatik test veya tekrarlanabilir kontrol komutuna dönüştürün.
Son 5 dakika: Bloklayıcı kontrolleri ve test değiştirme sınırını ajanın görev paketine ekleyin.

Vibe coding akışında eval’in yeri

Vibe coding hızı artırır; eval bu hızın yanlış yöne gitmesini erken fark eder. Bağlam mühendisliği ajana doğru bilgiyi taşırken eval, çıktının doğru davranışı üretip üretmediğini ölçer. Teknik borç yönetimi ise geçen çözümün sürdürülebilir kalmasını sağlar.

Bu üç katman birlikte düşünülmelidir: doğru bağlam, ölçülebilir sonuç ve sürdürülebilir uygulama.

Sonuç

Vibe coding’de güven, modelin ne kadar ikna edici konuştuğundan değil, çıktının aynı kritik senaryolarda tekrar tekrar doğru davranmasından gelir. Küçük bir altın test seti; uzun promptlardan daha kalıcı, “çalışıyor gibi” değerlendirmesinden daha güvenilir bir geri bildirim döngüsü kurar.

Bir sonraki özelliğinizde önce kod istemek yerine altı örnek yazın. Mutlu yolu, iki sınır durumunu, bir hata yolunu ve geçmişte canınızı yakan bir regresyonu sabitleyin. Ajanın görevi yalnızca kod üretmek değil, bu kanıt kapısından geçmek olsun.