Vibe Coding ile Production'a Çıkılır mı?

“Yerelde çalışıyordu” cümlesinin yeni bir akrabası var: “demoda çalışıyordu.” Bir hafta önce tarif edilip dakikalar içinde ayağa kalkan, ilk kullanıcılarını bile almış bir ürün — sonra ilk gerçek yük geldiğinde yavaşlıyor, ilk meraklı kullanıcı başkasının faturasını görüyor, ilk şema değişikliği migration’da patlıyor. Üreten kişi şaşırıyor: kod çalışıyordu.

Çalışıyordu. Ama vibe coding’in düşürdüğü maliyet üretimdi; yanlış olmanın maliyeti değil. O maliyet ertelenir, silinmez — ve ertelenen maliyet faiz işletir.

Vibe coding’in ucuzlattığı şey gerçek

Strawman kurmayalım. Bir ilk sürümü çıkarmak hiç bu kadar ucuz olmamıştı: bir CRUD ekranı, bir REST uç noktası, bir form doğrulaması — tarif et, çalışsın. Prototip, throwaway, iç araç, öğrenme projesi için bu mükemmel bir hızlandırıcı.

Ucuzlatmadığı tek şey var: veri modeli, güvenlik sınırı ve failure mode hakkında yanlış olmanın bedeli. Bu üç şey production’da yanlışsa, fatura build anında değil, çok sonra — genelde gece 2’de — gelir.

Fatura build’de değil, production’da görünür

Vibe coding ile çıkan sistemlerde tekrar tekrar gördüğüm dört kalıp. Hiçbiri “kod derlenmiyor” tipinde değil; hepsi intent ile gerçeklik arasındaki boşlukta yaşıyor.

1. Göç edemeyen veri modeli. Dolu bir tabloya NOT NULL kolon, DEFAULT’suz. Boş tabloda sorunsuz, production tablosunda fail. Daha derini: ilişkileri yanlış kurulmuş bir şema altı ay sonra basit bir özelliği imkânsız kılar. Veri modelini sonradan düzeltmek bir refactor değil, bir veri göçü riskidir — ve en pahalı anda, gerçek veriyle yapılır.

2. Düşman girdiyi hesaba katmayan güvenlik. Kimlik kontrolünden geçen ama sahiplik kontrolünden geçmeyen object ID’ler (IDOR), query’ye ulaşan kullanıcı girdisi, koda gömülü secret. Agent’ın ürettiği “standart” çözüm, girdinin düşman olabileceğini varsaymaz; çünkü ona sorulan soru “bu çalışsın” idi, “bu saldırıya dayansın” değil.

3. Ölçeklenmeyi görmeyen erişim deseni. Döngü içinde sorgu (N+1), SELECT *, pagination’sız liste, eş zamanlı olması gereken yerde senkron çağrı. On satırlık tabloda görünmez; yüz binlik tabloda p95’i uçurur.

4. Gözlemlenemeyen ve geri alınamayan sistem. Log yok, metrik yok, rollback planı yok. Kırıldığında neden kırıldığını göremezsiniz — ki vibe-coded sistemde en çok ihtiyaç duyacağınız şey budur.

Ortak payda şu: araç en güvenli göründüğü yerde en tehlikeli. Yaygın kalıpları sağlam yazar; problemin kendine özgü boyutunu görmeden “standart” bir çözüm verir. Standart çözüm, sormadığınız problemin cevabıdır.

Çıktının kalitesini belirleyen: yazma hızı değil, denetim

Aynı agent’ı üç farklı elde düşünün. Fark, kimin daha hızlı yazdırdığı değil; sorulan sorunun ve yapılan review’un kalitesi.

• Hiç/çok az bilgi. Soruyu çerçeveleyemez, çıktıyı eleştirel okuyamaz. “Standart çözüm” yukarıdaki dört kalıpla birlikte production’a olduğu gibi çıkar. “Çalışıyor” ile “doğru çalışıyor” arasındaki farkı henüz hissedemez.
• Az-orta bilgi. Bazı soruları doğru kurar, çıktının bir kısmını yakalar. Tavanı sistemin sınırlarında: yük altında nerede kırılır, bu soyutlama doğru mu, bu veri modeli hangi değişikliği kaldırır. Sonuç: iyi parçalar, kırılgan bütün.
• Senior + sistem mimarisi. Agent bir ikame değil, bir çarpan. Plan yaptır → onayla → adım adım yazdır → bir junior’ın kodu gibi review et → savunamayacağın satırı merge etme. Bu disiplinin somut hâli ayrı bir yazıda: AI-Assisted Engineering Workflow’um. Bu elde hız artar, kalite düşmez — çünkü muhakeme insanda kalır.

Bu bir bütçe ifadesidir, ideoloji değil: senior, ertelenen maliyete karşı en ucuz sigortadır. Doğru veri modelini baştan kurmak bir öğleden sonra; yanlışını canlı sistemde düzeltmek bir çeyrek. “Para kazanınca düzeltiriz” bu yüzden absürt — para kazandıran ürün, aynı zamanda elinizi bağlayan, göçü en riskli üründür. Senior sonradan değil, önceden ucuzdur.

Ne zaman vibe coding doğru cevap?

Her öneri gibi bunun da bir geçerlilik sınırı var — ve sınırı söylemeden öneri yapmam.

Vibe coding doğru araçtır: prototip, throwaway demo, hobi, gerçek verisi/kullanıcısı olmayan iç araç, öğrenme. Buralarda yanlış olmanın maliyeti düşük olduğu için ertelemek rasyoneldir.

Denklem şu üç şeyden biri masaya gelince çevrilir: gerçek kullanıcı, gerçek veri, gerçek para (ya da gerçek uptime taahhüdü). O eşikten sonra ertelenen maliyet faizini ödetmeye başlar ve direksiyonu tutan birine ihtiyaç doğar.

---

Yapay zekâ agent’larıyla üretim mümkün, hatta gerçekten hızlı. Ama agent, kodu kimin yazdığını değiştirdi; kimin sorumlu olduğunu değil. Vibe coding üretimi ucuzlattı, yanlış olmanın maliyetini değil — ve o maliyet, production’a kimin elinde çıktığına bakar.