Rehber
Vibe coding kötü mü? Neler ters gider ve kodunuzu nasıl kontrol edersiniz
Vibe coding kendi başına kötü değil; risk, kimsenin okumadığı kodu yayına almak. Asistanların tekrarladığı hatalar, ne zaman önemli oldukları ve nasıl yakalanacakları.
· 7 dk okuma · Yazan: vetkit ekibi
Kısa cevap
Hayır, vibe coding kendi başına kötü değil. Çalışan bir yazılıma ulaşmanın hızlı bir yolu; prototipler, şirket içi araçlar ve öğrenme için çoğu zaman doğru tercih. Sorun belirli bir noktada başlar: kimsenin okumadığı kod gerçek kullanıcılarla, gerçek verilerle ya da gerçek parayla iş görmeye başladığında. Risk, kodu bir yapay zekânın yazmış olması değil. Risk, kimsenin onu kontrol etmemiş olması.
Bu yüzden asıl soru “vibe coding kötü mü?” değil, “bu yayına girmeden önce neyi kontrol etmem gerekiyor?” sorusudur. Bu rehberin geri kalanı bu soruyu yanıtlıyor.
Vibe coding ne demek
Vibe coding, ne istediğinizi bir yapay zekâ asistanına anlatıp yazdığı kodu çoğunlukla okumadan kabul ederek yazılım geliştirmektir. Terimi, Andrej Karpathy 2025’in başında, kendinizi akışa bıraktığınız ve kodun var olduğunu bile unuttuğunuz bir çalışma biçimi için ortaya attı. Sonucu değişiklikleri inceleyerek değil, uygulamayı çalıştırarak değerlendirirsiniz.
Bu, yapay zekâ destekli geliştirmeden farklıdır: orada geliştirici aynı araçları kullanır ama her değişikliği yine okur, test eder ve sorumluluğunu üstlenir. Gerçek projelerin çoğu ikisinin arasında bir yerde durur ve teslim tarihleri sıkıştıkça vibe coding’e doğru kayar.
Neler ters gider
Yapay zekâ asistanları çalışan kod üretmekte iyidir. Uygulamaya bir kez tıklayıp bakınca ortaya çıkmayan konularda ise daha az güvenilirdirler. Aynı hatalar tekrar tekrar karşımıza çıkar:
| Sorun | Nasıl görünür | Neden fark etmezsiniz |
|---|---|---|
| Yanlış yerdeki gizli bilgiler | Depoya commit edilmiş ya da tarayıcı paketine gömülmüş bir API anahtarı | Uygulama iki durumda da aynı şekilde çalışır |
| Eksik erişim kontrolleri | Oturum açmış herhangi bir kullanıcı başka bir kullanıcının kayıtlarını okuyabilir; satır düzeyinde kuralı olmayan veritabanı tabloları | Hep yalnızca kendi hesabınızla test edersiniz |
| Var olmayan paketler | Asistan akla yatkın bir paket adı uydurur ve bu adı başka biri kaydetmiş olabilir | Kurulum komutu başarıyla tamamlanır |
| Yarım kalmış kod | Ana akışta bırakılmış yer tutucu fonksiyonlar, TODO dalları ve yutulan hatalar | Sorunsuz senaryo yine de geçer |
| Doğrudan kullanılan güvenilmeyen girdi | İstek verisinin SQL’e, kabuk komutlarına, dosya yollarına ya da HTML’e eklenmesi | Normal girdi normal davranır |
| Hata durumu için hiçbir şey | Zaman aşımı olmayan HTTP çağrıları, döngü içindeki sorgular, hata raporlamasının olmaması | On satır veri ve tek kullanıcıyla hızlıdır |
Bunların hiçbiri yeni değil. Geliştiriciler, yapay zekâ asistanları ortaya çıkmadan önce de bu hataların her birini yaptı. Vibe coding ile değişen, hacim ve eksik inceleme adımıdır: daha fazla kod daha hızlı gelir ve sorunu yakalayacak kişi onu hiç okumaz. Bunlardan üçü bu sitede ayrıntılı olarak ele alınıyor: tarayıcıdaki API anahtarları, uydurulan paketler ve sızdırılan gizli bilgiler.
Ne zaman önemli, ne zaman değil
Bir hatanın bedeli düşükse vibe coding makul bir tercihtir:
- Atılacak ya da yeniden yazılacak bir prototip veya demo.
- Kişisel bir betik ya da hassas veri içermeyen bir şirket içi araç.
- Yeni bir framework öğrenmek ya da bir fikri denemek.
Bir hatanın bedeli yüksekse yayından önce kontrol gerekir:
- Uygulamada kullanıcı hesapları, ödemeler ya da kişisel veriler var.
- Bir LLM sağlayıcısı ya da veritabanı gibi başka servislerin kimlik bilgilerini tutuyor.
- Başkaları onun ayakta kalmasına güvenecek ya da bakımını başka biri üstlenecek.
Çizgiyi kodun nasıl yazıldığı değil, kod yanlışsa ne olacağı belirler. Pek çok proje bu çizgiyi kimse karar vermeden geçer: demo ilk gerçek kullanıcılarına kavuşur ve kimse dönüp kodu okumaz.
Hızı koruyup riski nasıl atarsınız
Hızdan vazgeçmeniz gerekmiyor. Vibe coding’in atladığı kontrolü geri eklemeniz gerekiyor.
- Parayla, girişle ve veriyle ilgili değişiklikleri okuyun. Arayüz düzeni kodunu okumayı atlayabilirsiniz. Kimlik doğrulamayı, yetkilendirmeyi, ödemeleri ve veritabanına yazan her şeyi atlayamazsınız. Yapay zekâ tarafından üretilen kod için inceleme kontrol listesi nelere bakmanız gerektiğini sıralıyor.
- İki hesapla test edin. Bir kullanıcı olarak oturum açın ve başka bir kullanıcının kayıtlarını okumayı ya da değiştirmeyi deneyin. Bu tek test, vibe coding ile yazılmış uygulamalardaki en zararlı hata sınıfını ortaya çıkarır.
- Her yeni bağımlılığı kontrol edin. Paketin gerçekten var olduğunu, kastettiğiniz paket olduğunu ve geçen hafta yayımlanmadığını doğrulayın.
- Yayına almadan önce depoyu tarayın. Otomatik bir denetim mekanik sorunları bir insandan daha hızlı bulur: commit edilmiş gizli bilgiler, açıkları olan ya da var olmayan bağımlılıklar, eksik zaman aşımları ve girdinin güvensiz işlenmesi. vetkit’in kontrol kataloğu çalıştırdığı kuralları gösterir; ücretsiz Security Quick Scan ise gizli bilgileri, bilinen bağımlılık açıklarını ve temel güvenlik yapılandırmasını kapsar.
- Taramanın bulduklarını asistana düzelttirin. Bulguların aynı konuşmaya geri gelmesi için tarayıcıyı kodlama ajanınıza bağlayın. MCP rehberi bunun nasıl yapılacağını gösteriyor.
Yayına hazır olduğunuzda, vibe coding ile yazılmış bir uygulamayı yayına almadan önceki güvenlik kontrol listesi yayın kararını adım adım ele alıyor.
Kaynaklar ve sınırlar
Sık görülen sorunlar listesi, vetkit’in yapay zekâ kodu riskleri, güvenlik, dayanıklılık ve veri erişimi için kendi geliştirdiği kuralların kapsadığı kategorileri yansıtır; 10 Kasım 2026’da kontrol edilmiştir. Tekrarlayan kalıpların bir tarifidir, ne sıklıkla görüldüklerinin bir ölçümü değildir. “Vibe coding” terimi Andrej Karpathy’nin Şubat 2025 tarihli paylaşımından gelir.
Otomatik bir tarama, bir uygulamanın güvenli olduğunun kanıtı değil, incelenecek bir bulgudur. Kaynak kodu okur; yayındaki izinlerinizi, barındırma yapılandırmanızı ya da iş kurallarınızı test etmez. Yukarıdaki iki hesaplı test ve elle inceleme yine sizin işinizdir.