--- title: "Vibe Coding ile Production'a Çıkılır mı?" description: "Vibe coding ilk sürümün maliyetini düşürür, yanlış olmanın maliyetini değil. O fatura build'de değil, production'da çıkar." url: https://sade.dev/tr/journal/vibe-coding-ile-production/ lang: tr author: "Muhammet Şafak" published: 2026-06-13 updated: 2026-09-06 section: Journal tags: ["ai-workflow","vibe-coding","production","architecture","opinion"] summary: "Vibe coding ilk sürümün maliyetini düşürdü; veri modeli, güvenlik sınırı ve failure mode hakkında yanılmanın maliyetini değil. O maliyet ertelenir, silinmez — ve ertelenen maliyet faiz işletir; fatura build anında değil, production'da gelir. Çıktının kalitesini belirleyen yazma hızı değil, sorulan sorunun ve yapılan review'un kalitesidir." --- # Vibe Coding ile Production'a Çıkılır mı? > Vibe coding ilk sürümün maliyetini düşürdü; veri modeli, güvenlik sınırı ve failure mode hakkında yanılmanın maliyetini değil. O maliyet ertelenir, silinmez — ve ertelenen maliyet faiz işletir; fatura build anında değil, production'da gelir. Çıktının kalitesini belirleyen yazma hızı değil, sorulan sorunun ve yapılan review'un kalitesidir. "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 **üretim**di; 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](/tr/journal/ai-assisted-engineering-workflow). 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. ## Sık sorulanlar **Vibe coding ile production'a çıkılır mı?** Masada ne olduğuna bağlı. Prototip, throwaway demo, hobi projesi ya da gerçek verisi ve kullanıcısı olmayan bir iç araç için vibe coding doğru araçtır; orada yanlış olmanın maliyeti düşük olduğu için ertelemek rasyoneldir. Denklem gerçek kullanıcı, gerçek veri ya da gerçek para masaya gelince çevrilir — o eşikten sonra direksiyonu tutan birine ihtiyaç var. **Fatura hangi hatalarla production'da çıkıyor?** Dört kalıpla. Göç edemeyen veri modeli — dolu bir tabloya DEFAULT'suz eklenen NOT NULL kolon gibi. Düşman girdiyi hesaba katmayan güvenlik — kimlik kontrolünden geçen ama sahiplik kontrolünden geçmeyen object ID gibi. Ölçeklenmeyi görmeyen erişim deseni — döngü içindeki sorgu gibi. Ve logu, metriği, rollback planı olmayan bir sistem. **Ajanın ürettiği kodun kalitesini ne belirliyor?** Yazma hızı değil; sorulan sorunun ve yapılan review'un kalitesi. Soruyu çerçeveleyemeyen bir elde standart çözüm production'a olduğu gibi çıkar. Senior bir elde ajan bir ikame değil çarpandır: plan yaptır, onayla, adım adım yazdır, bir junior'ın kodu gibi review et ve savunamayacağın satırı merge etme.