Vibe Coding Ritüelleri

Önce dürüst bir ayrım

“AI kullanma” demiyorum, ben de kullanıyorum ve ekip de kullanıyor. Ama iki farklı iş var ve aynı yaklaşımla yapılamıyor:

Aradaki ayrımı yapamayanlar, prototip hızıyla yazdıkları kodu üretime alıyor ve faturayı üç ay sonra ödüyor.

Sahadan üç hata

Üçü üç ayrı projeden, o yüzden dilleri de farklı. Ortak noktaları: hepsi testten geçti.

1. Döngü içinde sorgu

Rapor ekranı üretildi, testte anında açılıyordu. Canlıda 40 saniye sürdü. Kod şuydu:

siparisler = SiparisRepo.bul(baslangic, bitis);   // 8.400 kayıt

for (s : siparisler) {
    s.musteri = MusteriRepo.bulById(s.musteriId);   // ← 8.400 sorgu
    s.kalemler = KalemRepo.bulBySiparis(s.id);      // ← 8.400 sorgu daha
}

Ritüel: üretilen her veri erişim kodunda tek soru — “bu döngü 10 bin kere dönerse ne olur?”

2. Var olmayan kütüphane

Bir yardımcı fonksiyon için önerilen paket, adı gayet makul olan ama gerçekte var olmayan bir paketti. npm install hata verdi, iki dakikada anlaşıldı. Bizde ucuz atlatıldı; ama bunu genel kural sanma.

Tehlikeli versiyonu şu: yapay zekânın sık uydurduğu paket adlarını birileri npm ve PyPI’da gerçekten kaydedip içine zararlı kod koyuyor. Adı slopsquatting. O zaman npm install hata vermez, başarıyla çalışır; postinstall betiği kurulum anında koştuğu için kodu hiç çağırmadan bile zarar görürsün.

Daha sessiz versiyonu da var: gerçekten var olan ama terk edilmiş, son güncellemesi dört yıl önce yapılmış bir paketi önermesi. Kurulum çalışır, kod çalışır, güvenlik açığı sessizce içeri girer.

Ritüel: yeni bir bağımlılık eklenirken dört şeye bak — paket gerçekten beklediğin yayıncıdan mı, yoksa bilinen bir paketin adının taklidi mi; son yayın tarihi; haftalık indirme; açık güvenlik uyarısı. Bir dakika sürüyor.

3. Kodu doğrulamayan test

Bu en sinsisi. Kod yazıldıktan sonra “bunun testlerini de yaz” dendi. Testler yazıldı, hepsi geçti. Sonra biri fark etti: testler, kodun ne yapması gerektiğini değil, ne yaptığını doğruluyordu.

// Kodda hata var: indirim yüzde yerine tutar olarak düşülüyor
//   kod:     fiyat - indirim
//   doğrusu: fiyat * (1 - indirim/100)

// Koda bakılarak yazılmış test: kodun çıktısı "beklenen" diye kopyalanmış
test("indirim uygulanir", () => {
  expect(indirimUygula(200, 20)).toBe(180);   // kod 180 veriyor, test geçiyor
});

// Doğrusu 160. Test hatayı "doğru" diye kayda geçirmiş.

Ritüel: testi önce yaz, ya da en azından beklenen değerleri koda bakmadan kendin belirle. Koda bakarak yazılan test, kodu değil kendini doğrular. Bir de girdiyi tesadüfe bırakma: 100 TL’de yüzde 20 de 80 verir, tutar olarak 20 düşmek de 80 verir. İki formülü ayıran bir girdi seç.

On ritüel

Önce bir itiraf: terimi ortaya atan Andrej Karpathy’nin tanımında vibe coding, üretilen kodu okumadan kabul etmek demek. Aşağıdaki on maddenin hepsi ise okumak, sorgulamak ve test etmek üzerine. Yani bunlar teknik olarak vibe coding ritüeli değil; vibe coding’den disiplinli yapay zekâ destekli geliştirmeye geçiş ritüeli. Başlık ekipte öyle yerleşti, öyle kalıyor.

1. Hedefi önce sabitle

Kod istemeden önce, bitmişliği tarif eden iki üç cümle yaz: girdi ne, çıktı ne, hangi uç durumlar önemli. Bu cümleler hem istemi netleştiriyor hem de sonunda “oldu mu?” sorusunu cevaplanabilir kılıyor. En iyisi bunu test olarak yazmak.

2. Küçük adım kuralı

Tek seferde 400 satır kabul etme. Bir fonksiyon, bir dosya, bir davranış iste. Sebebi kalite değil doğrulanabilirlik: 40 satırı okuyup anlayabilirsin, 400 satırı okumuyorsun — ve okumadığın kod, incelenmemiş koddur.

3. Proje kurallarını yazılı ver

Kod tabanında bir kurallar dosyası tut ve her oturumda bağlam olarak ver: hangi kütüphaneler kullanılıyor, hata nasıl yönetiliyor, log formatı ne, katmanlar nasıl ayrılmış.

# Bu projede
- Tarih işlemleri: sadece java.time. Joda YOK.
- Hata: HataKodu taşıyan kendi exception sınıfımız, ham exception fırlatma.
- Veri erişimi: Repository katmanı dışında SQL yazılmaz.
- Log: yapısal log, mesaja string birleştirme yok.
- Test: her servis metodu için en az bir mutsuz yol testi.

4. “Neden böyle?” sormadan kabul etme

Üretilen koddaki her sıradışı satır için gerekçe iste. Açıklama makul değilse kod da değildir. Bu ritüel iki işe yarıyor: hatayı erken buluyorsun ve öğreniyorsun — ki uzun vadede asıl kazanç bu.

5. Çalışan her adımda commit

Bu, listedeki en pratik madde. AI ile çalışırken kod hızlı değişiyor ve bir noktadan sonra “iki adım önce çalışıyordu” noktasına dönmek imkânsız hale geliyor.

küçük adım → testler yeşil → commit
küçük adım → testler yeşil → commit

# Bozulunca:
git diff                 # commit edilmemiş değişiklikler: bozan adım bu
git reset --hard HEAD    # takip edilen dosyaları son yeşil commit'e döndür
git clean -n             # silinecek yeni dosyaları önce listele
git clean -fd            # emin olunca sil

# Kenara almak istersen, yeni dosyalar dâhil:
git stash -u

6. Yeşil bar kuralı

Testler kırmızıyken bir sonraki özelliğe geçme. Kulağa bariz geliyor ama vibe coding’in doğal akışı tam tersini teşvik ediyor: hız hissi devam etsin diye “onu sonra bakarım” deniyor. Üç “sonra” birikince neyin ne zaman bozulduğunun izi kayboluyor.

7. Tehlikeli bölge listesi

Ekip kuralı tek cümle: bu yerlerde son hali insan yazar. Listemiz şu:

• Kimlik doğrulama, yetkilendirme, oturum yönetimi
• Para hesabı: fiyat, indirim, vergi, iade
• Veri silen veya taşıyan işlemler (migration dâhil)
• Kişisel veri işleyen akışlar
• Dış sistemle mutabakat

Öneri almak serbest; ama son satırı sen yazarsın, satır satır anlayarak. Kopyalayıp geçmek yasak. Bir yerin listeye girme ölçütü basit: yanlış olursa geri dönüşü var mı?

8. Üç deneme kuralı

Aynı hatayı üçüncü kez düzeltmeye çalışıyorsan dur. Döngüye girmişsindir ve her denemede kod biraz daha karışıyordur. Yapılacak şey: son çalışan commit’e dön, hatayı kendin oku, problemi tarif et, sonra yeniden başla.

Bu kural bende en çok zaman kazandıran madde oldu. Döngüde geçen 40 dakika, elle bakılan 10 dakikadan pahalı.

9. Ne yapıştırdığına dikkat

Hata ayıklarken log yapıştırmak çok doğal — ve loglarda müşteri e-postası, token, bağlantı dizesi olabiliyor. Ekip kuralı yazılı olsun; olmayınca herkes iyi niyetle kendi kuralını uyduruyor.

10. Bir kere de kendin yaz

Yeni bir konu öğreniyorsan, üretilen kodu okuyup kapat ve aynı şeyi kendin yaz. Yarım saat kaybediyorsun ama o konu artık senin oluyor. Bunu yapmayan insanlarda gördüğüm şey şu: bir yıl sonra çok iş çıkarmış ama derinleşmemiş oluyorlar ve ilk gerçek krizde tıkanıyorlar.

Kod incelemesinde neye bakılır?

Üretilen kodun kendine has bir kokusu var. İncelemede özellikle şunlara bakıyorum:

Peki gerçekten hızlandırıyor mu?

Evet, ama ölçtüğün yere bağlı. Bizde kabaca şöyle çıktı:

• İlk çalışan sürüme kadar: belirgin şekilde hızlı. Burada tartışma yok.
• İncelemeden geçmiş sürüme kadar: kazanç azalıyor, çünkü inceleme yükü artıyor.
• Canlıda sorunsuz çalışan sürüme kadar: ritüel yoksa kazanç eksiye düşebiliyor.

Yani hız gerçek; ama ölçmen gereken şey “ne kadar hızlı yazdım” değil “ne kadar sürede güvenle canlıya çıktı”.

Bu sadece bizim gözlemimiz değil. METR’in 2025 başının araçlarıyla yaptığı çalışmada 16 deneyimli açık kaynak geliştirici, kendi projelerinde 246 gerçek görev yaptı; her görev rastgele olarak AI’lı ya da AI’sız yapılmak üzere ayrıldı. Geliştiriciler işin sonunda kendilerini yaklaşık yüzde 20 hızlanmış sanıyordu; ölçülen süre yüzde 19 daha uzundu. METR bu sonucun artık güncel olmadığını, bugünkü araçlarla muhtemelen hızlanma olduğunu ama büyüklüğünü güvenilir ölçemediklerini söylüyor. Kalıcı ders rakamda değil: insanların kendi hızlarına dair tahmini, ölçümle ciddi biçimde ayrışabiliyor.

Kontrol listesi

Sonuç

Vibe coding bir yetenek değil bir mod. Doğru anda açıp yanlış anda kapatmayı bilmek gerekiyor. Prototipte aç, ödeme akışında kapat.

Ve baştaki “üç saatte bitirdim” cümlesine dönelim: o cümle yanlış değildi. Eksik olan kısım şuydu — üç saatte yazıldı, ama hiç kimse okumadı. Ritüellerin tamamı aslında tek bir şeyi geri getirmeye çalışıyor: okumayı.