Vibe coding nasıl yapılır: prodüksiyona çıkan projelerin kuralları
Vibe coding'i doğru yapmak sohbet etmek değil, disiplin. Kapsamı daralt, küçük adım iste, test et, commit at: devraldığımız projelerin çoğu bu döngüyü atlamış.
Vibe coding'i doğru yapmak, chat ekranında konuşarak kod yazmak değil. Dar bir görev tanımlamak, modelden küçük bir adım istemek, o adımı test etmek, sonra commit atmak demek. Kapsamı daraltmadan tek seferde büyük bir özellik istersen model dağılır: hangi parçanın çalıştığı, hangi parçanın çalışmadığı birbirine karışır. Bu yazı, prodüksiyona çıkan projelerle çıkmayanlar arasındaki farkı yapan pratik kuralları anlatıyor.
TL;DR
Dar kapsam, küçük adım, her adımdan sonra test, her çalışan adımdan sonra commit. AI'nin dört kör noktası var: yetkilendirme, veri erişimi, anahtarlar, ödeme. Bunları modele bırakma, sen test et. Devraldığımız projelerin çoğu bu döngüyü değil, "tek seferde her şeyi iste" yolunu seçmiş.
Genel bir "iyi prompt yaz" tavsiyesi kurulumunu bilmiyor. Bu yazı hangi araçla çalıştığına bakmadan uygulanabilecek bir sıra veriyor: kapsamı nasıl daraltırsın, adımı nasıl küçültürsün, commit'i neden atlamayacaksın, hangi dört noktayı asla modele bırakmayacaksın.
Vibe coding nedir, iki cümlede
Vibe coding, bir yapay zeka aracına (Cursor, Claude Code, Lovable, Bolt, v0, Replit) doğal dille ne istediğini anlatıp kodu onun yazmasına izin vermek. Terim 2025'te yaygınlaştı, pratik daha eski: fark, modelin artık sadece satırı değil, dosya ve klasör yapısını da kendi kararına göre değiştirebilmesi.
Kapsamı daraltmadan başlarsan neden dağılır
"Bir e-ticaret sitesi yap, sepet, ödeme, admin paneli olsun" gibi bir istekle başlarsan model aynı anda çok fazla karar veriyor. Hangi tablo hangi alanı taşıyacak, hangi sayfa hangi route'a bağlanacak, hangi state nerede tutulacak: hepsi tek seferde belirleniyor. Kararların bir kısmı doğru çıkıyor, bir kısmı çıkmıyor. Sorun şu: yanlış kararı hangi adımda verdiğini bilmiyorsun, çünkü hepsi aynı anda geldi.
Adım adım ilerlemenin kuralı: küçük iste, hemen test et
Kural basit: bir seferde tek bir davranış değişsin. "Sepete ürün ekleme çalışsın" ayrı bir adım, "sepetten ürün silme çalışsın" ayrı bir adım. Her adımdan sonra o davranışı gerçekten dene: ekranda tıkla, ya da komutu çalıştır. Çalışıyorsa devam et. Çalışmıyorsa modele "şu adımda şu hata var" diye geri bildir, bir sonraki adıma geçme.
Disiplinli döngü
Adım 3'te test başarısızsa 2'ye dön, model değiştirmeden önce hatayı tarif et. Commit atmadan 5. adıma geçme.
Her adımda commit atmak neden zorunlu
Commit, sadece yedek değil. Hangi adımın çalıştığının kaydı. Adım başına bir commit attığında, bir şey bozulduğunda tam olarak hangi değişikliğin bozduğunu görürsün. İkinci bir tahmin yapmana gerek kalmaz. Özellik başına ayrı pull request de aynı disiplinin bir üst katmanı.
Ölçüm
Komut: git log --oneline -15, lumiasoft.com'un kendi deposunda
Son 15 commit'in her biri tek bir özelliği taşıyor: bir rehber, bir araç, bir navigasyon düzeltmesi. Hiçbiri "genel güncelleme" ya da "çeşitli düzeltmeler" değil. Bu siteyi de aynı kuralla, adım adım yayınlıyoruz.
AI'nin kör noktaları: nerede insan devreye girmeli
Model, istenen arayüzü doğru üretmekte iyi. Ama bazı kontrolleri sunucuya değil, arayüze yazma eğiliminde, çünkü ikisi de kullanıcıya aynı görünüyor. Dört nokta özellikle tekrar ediyor:
Yetkilendirme
Kontrol arayüzde kalır, API isteğinde kontrol edilmez
Veri erişimi
RLS politikası yazılmaz, herkes her satırı görür
Anahtarlar
Gizli anahtar tarayıcıya giden koda karışır
Ödeme
Webhook imzası doğrulanmadan işlem kabul edilir
Bu dördü modele "güvenli yap" demekle çözülmüyor. Her biri ayrı test edilmesi gereken bir madde. Yayına almadan önce hepsini elle doğrulamanın tam listesi güvenlik kontrol listesi yazımızda.
Devraldığımız projelerde en çok tekrar eden dağılma noktaları
Yapay zeka projesi tamamlama işinin büyük kısmı, kapsamı en başta daraltılmamış projeleri düzeltmek. Replit'in ajanının prodüksiyon veritabanını sildiği olay, bir onay katmanı olmadan geri dönüşü olmayan bir komutu çalıştırmasıyla başladı. Tek bir adımda çok fazla yetki verilmişti. Lovable ve Bolt ile yazılan uygulamalarda gördüğümüz açıkların çoğu da aynı kökten geliyor: arayüz çalışıyor, sunucu tarafı hiç kontrol edilmemiş.
Ortak nokta: hepsi demoda düzgün görünüyordu. Kırılma, gerçek kullanıcı ilk beklenmedik şeyi yaptığında ortaya çıktı.
Güvenlik kontrolüne geçmeden önce hazır mısın
Yukarıdaki döngüyü uyguladıysan, adım adım commit attıysan ve kör noktaları ayrı test ettiysen, yayına almadan önceki son adım yapay zeka uygulaması yayına hazırlık kontrolü. Aynı dört kategoriyi 11 soruyla tarıyor, bulguları önem sırasına koyuyor.
Ne zaman kendi başına yeterli, ne zaman değil
Bu kurallar öğrenme projesi, iç araç ya da düşük riskli bir MVP için yeterli. Ödeme akışı, gerçek kullanıcı verisi ya da yasal bir yükümlülük varsa, kör noktalar listesindeki maddelerden en az biri kendi başına kapanmıyor demektir. O noktada ihtiyaç daha fazla prompt değil, kodu okuyup üstlenecek biri.
Kritik maddeler kendi başına kapanmıyorsa, yapay zeka projesi tamamlama hizmetimiz tam bu noktadan devralıyor: kod incelemesi, açık kapatma, prodüksiyon altyapısına taşıma.
Sık sorulan sorular
Vibe coding prodüksiyon uygulamalar için güvenli mi?
Disiplinli ilerlersen ve kör noktaları elle test edersen evet. Tek seferde büyük kapsam istersen hayır, kontrol kaybolur.
Hangi araç disiplinli çalışmayı kolaylaştırıyor?
Adım adım onay isteyen, dosya bazlı diff gösteren araçlar (Claude Code, Cursor) süreci görünür kılıyor. Tek seferde bütün projeyi üreten araçlarda aynı disiplini sen kurmak zorundasın.
Her adımdan sonra gerçekten commit atmak şart mı?
Şart. Commit atmadan ilerlersen, bozulan şeyi bulmak için bütün oturumu geri okumak zorunda kalırsın.
Kör noktaları kendim nasıl test ederim?
Güvenlik kontrol listesi yazımızda her madde için komut ve beklenen sonuç var.
Vibe coding ile başlayıp sonra devretmek normal mi?
Evet, çoğu proje böyle ilerliyor. Demo aşamasında hız, prodüksiyonda dayanıklılık öncelik değiştiriyor. Bu iki farklı iş.