Vibe Coding Nedir? Prototip ile Production Arasındaki Sınır

Vibe coding nedir sorusunun cevabı, 6 Şubat 2025'te bir tek tweet'e kadar geri gidiyor. Andrej Karpathy — OpenAI'nin kurucu ortaklarından, Tesla'nın eski AI direktörü — kod yazarken artık "vibe'lara tamamen teslim olduğunu" ve kodun var olduğunu bile unuttuğunu söylediğinde, yıllardır dağınık şekilde var olan bir pratiğe bir isim koymuş oldu. Bu yazı terimin gerçekte ne anlama geldiğini, nerede işe yaradığını ve nerede prototip ile production arasındaki çizgiyi geçtiğini net bir sınır çizerek anlatıyor.

💡 Pro Tip: Vibe coding'i bir araç değil bir _mod_ olarak düşün — aynı editörde, aynı AI asistanla, bir dakika sonra "diff okumadan kabul et" modundan çıkıp "her satırı anlıyorum" moduna geçebilirsin. Sorun aracın kendisinde değil, hangi modda olduğunu bilmemekte.

İçindekiler

• Terimin doğuşu — Karpathy'nin tanımı ve neyi kastettiği
• Vibe coding NE DEĞİLDİR
• Akışın anatomisi: niyet → üretim → çalıştır → düzelt
• Nerede parlıyor: prototip, keşif, atılabilir kod
• Nerede kırılıyor: veri modeli, yetkilendirme, çok kişili kod tabanı
• Yetki açığı derlenir, çalışır ve sessiz kalır
• Görünmez varsayım çakışması
• Sınırı çizen 5 soru (karar listesi)
• Prototipten sonra ne yapmalı — sorumluluk devri
• Devrin üç maddesi
• Devir kademeli de olabilir
• SSS
• Vibe coding nedir?
• Vibe coding terimini kim icat etti?
• Vibe coding ile normal AI destekli kodlama arasındaki fark ne?
• Vibe coding ile production uygulama yazılır mı?
• Vibe coding güvenli mi?
• Vibe coding hangi projelerde işe yarar?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

Terimin doğuşu — Karpathy'nin tanımı ve neyi kastettiği

Karpathy 6 Şubat 2025'te şöyle yazdı: "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." Yani: kodun varlığını unutacak kadar sonuca odaklanmak.

Karpathy bunu soyut bir felsefe olarak değil, kendi günlük pratiği olarak anlatıyor: "I ask for the dumbest things like 'decrease the padding on the sidebar by half' because I'm too lazy to find it. I 'Accept All' always, I don't read the diffs anymore." Diff okumamak, burada bir ihmal değil — tanımın kendisi. Hata mesajı geldiğinde de aynı disiplin devam ediyor: "When I get error messages I just copy paste them in with no comment, usually that fixes it."

Bu tanımın kökleri daha eskiye gidiyor. Karpathy 2023'te, LLM'lerin doğal dille kod üretme yeteneğini özetlerken "en popüler yeni programlama dili İngilizcedir" ("the hottest new programming language is English") demişti. Vibe coding, bu fikrin doğal uç noktası: doğal dil artık yalnızca kodu _tarif etmiyor_, kodun yerine geçiyor.

Tanımın kısa olması bilerek — Karpathy bir metodoloji kitabı değil, gündelik bir alışkanlığını anlatan tek bir tweet paylaştı. Bu kısalık, terimin hızla yanlış anlaşılmasına da zemin hazırladı: bazıları vibe coding'i "AI ile yazılan her satır kod" olarak genişletti, bazıları ise onu tamamen sorumsuz bir pratik olarak karikatürize etti. Oysa Karpathy'nin kendi cümlelerinde hem net bir kapsam sınırlaması ("throwaway weekend projects") hem de bir öz-farkındalık var — kendi pratiğini övmüyor, tarif ediyor.

Vibe coding NE DEĞİLDİR

En yaygın kafa karışıklığı burada başlıyor: "AI ile kod yazmak" ile "vibe coding" eş anlamlı değil. Karpathy'nin kendi tanımı, pratiği baştan sınırlıyor — bunu "atılabilir hafta sonu projeleri" ("throwaway weekend projects") için "çok da kötü olmayan" bir yöntem olarak tarif ediyor, üretim kalitesinde mühendislik yöntemi olarak değil.

Ayrım şu satırda net görülüyor:

1AI-destekli geliştirme:  öner → oku → anla → düzenle → test et → commit et
2Vibe coding:             öner → "Accept All" → çalıştır → hata varsa yapıştır → tekrar

Bir geliştirici Claude Code veya Cursor gibi bir asistanla çalışırken her diff'i okuyor, testleri kendisi yazıyor ve neyi neden değiştirdiğini açıklayabiliyorsa — bu AI destekli mühendisliktir, vibe coding değil. Aradaki fark araç değil, incelemenin var olup olmadığı.

Akışın anatomisi: niyet → üretim → çalıştır → düzelt

Karpathy'nin tarif ettiği döngü dört adıma indirgenebilir, kendi cümlesiyle: "I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works."

Bu akışın kritik özelliği, geliştiricinin debugging yapmaması: hata ayıklama disiplini yerine, hatayı ortadan kaldırana kadar asistanla diyaloğu sürdürmek var. Karpathy'nin kendi ifadesiyle bu "mostly works" — çoğunlukla işe yarıyor, ama "mostly" kelimesi burada kilit nokta.

Bu döngü metin olarak şöyle görünür — geliştirici hatanın _neden_ oluştuğunu sormaz, sadece hatayı asistana geri iletir:

1# Temsili örnek — vibe coding döngüsü, Karpathy'nin tarifiyle:
2$ npm run dev
3Error: Cannot read properties of undefined (reading 'map')
4    at ProfileList (ProfileList.tsx:42)
5 
6# Geliştirici hata mesajını yorumsuz kopyalar, asistana yapıştırır.
7# Kök nedeni sormaz: "neden undefined geldi?" sorusu atlanır.
8# Asistan düzeltmeyi önerir, "Accept All" ile kabul edilir, döngü tekrar başlar.

Nerede parlıyor: prototip, keşif, atılabilir kod

Bu akışın gerçek dünya karşılığı büyük: Y Combinator yönetici ortağı Jared Friedman, Mart 2025 başında W25 kohortundaki startup'ların dörtte birinin kod tabanının %95'inin AI tarafından üretildiğini açıkladı. Friedman'ın yorumu akışın hızını özetliyor: "A year ago, they would have built their product from scratch — but now 95% of it is built by an AI."

Bu, teknik bilgisi olmayan kişilerin değil, "highly technical" kurucuların bile üretim hızını bu şekilde artırdığı anlamına geliyor. Aynı görüşmede YC ortağı Diana Hu, vibe coding'in iyi kullanımının hâlâ bir beceri gerektirdiğini vurguluyor: "You have to have the taste and enough training to know that an LLM is spitting bad stuff or good stuff." Yani araç otomatik olsa da, çıktıyı değerlendiren göz hâlâ insan.

Pratikte vibe coding'in en güçlü olduğu alanlar üç başlıkta toplanabilir:

• Prototipleme: Bir fikri saatler içinde çalışan bir demoya dönüştürmek — Lovable ile prompttan full-stack uygulama veya Bolt.new ile tarayıcıda AI full-stack geliştirme rehberlerinde anlatılan akışlar tam olarak bu kategoriye giriyor.
• Keşif: "Bu mimari çalışır mı?" sorusuna kod yazmadan önce, kod yazarak cevap aramak.
• Kişisel/atılabilir araçlar: Bakımı gerekmeyen, tek seferlik ya da "software for one" dediğimiz küçük yardımcı programlar.

Bu üç alanın ortak noktası, hata payının düşük olması. Bir prototip çöktüğünde kaybedilen tek şey birkaç dakikalık yeniden deneme; kimsenin verisi, parası ya da yetkisi risk altında değil. Vibe coding'in hız avantajı tam olarak bu düşük-riskli bölgede maksimuma çıkıyor — çünkü "Accept All" refleksinin maliyeti de düşük kalıyor.

Nerede kırılıyor: veri modeli, yetkilendirme, çok kişili kod tabanı

Aynı hız avantajı, kritik iş mantığına yaklaştıkça bir kırılganlığa dönüşüyor. Vibe coding'in tanımı gereği atladığı adım — diff okumamak, hatayı anlamadan düzeltmek — tam olarak şu üç alanda pahalıya patlıyor:

1. Veri modeli: Bir ilişki yanlış tasarlandığında hata hemen görünmez; veri bütünlüğü sessizce bozulur.
2. Yetkilendirme (authorization): Bir yetki kontrolü "çalışıyor gibi göründüğünde" bile, kapsamı yanlış olabilir — ve bu, incelenmeden geçen bir diff'te fark edilmez. AI kodlama ajanına yetki vermenin prompt injection riskleri tam olarak bu kör noktayı ele alıyor.
3. Çok kişili kod tabanı: Tek kişinin "vibe'ına" göre şekillenen bir değişiklik, başka bir geliştiricinin üzerine inşa ettiği varsayımları görünmez şekilde bozabilir.

Yetki açığı derlenir, çalışır ve sessiz kalır

Basit bir kural-motoru örneğiyle bu farkı somutlaştıralım — aşağıdaki kontrol, "vibe" ile yazılıp test edilmeden kabul edildiğinde neyin kaçırılabileceğini gösteriyor:

1// Vibe coding'de sık görülen "çalışıyor gibi" kontrol:
2function canEditPost(_userId: string, _post: { authorId: string }) {
3  return true; // "Accept All" ile geçti, testte fark edilmedi
4}
5 
6// İncelemeden geçen versiyon:
7function canEditPost(
8  userId: string,
9  post: { authorId: string },
10  role: "admin" | "user",
11) {
12  return role === "admin" || userId === post.authorId;
13}

İlk fonksiyon derlenir, çalışır, demo sırasında hiçbir hata vermez — çünkü hatası bir _çalışma zamanı çökmesi_ değil, bir _yetki açığı_. Bu tür hatalar, tam olarak diff okumanın atlandığı yerlerde saklanıyor.

Görünmez varsayım çakışması

Çok kişili kod tabanında ikinci bir kırılma noktası daha var: bir geliştiricinin "vibe" ile yaptığı değişiklik, başka bir geliştiricinin o dosyada zaten var olan bir varsayımı fark etmeden geçersiz kılabilir. Diff okunmadığı için bu çakışma derleme zamanında değil, haftalar sonra bir üretim hatası olarak ortaya çıkar — ve o noktada kök nedeni bulmak, baştan diff'i okumaktan çok daha pahalıdır.

Sınırı çizen 5 soru (karar listesi)

Karpathy'nin kendi çerçevesinden ve dönemin tartışmalarından süzülen beş soru, bir değişikliğin "vibe" modunda mı yoksa incelemeli modda mı yapılması gerektiğine karar vermede kullanılabilir:

Beş sorudan ikisi veya daha fazlası "inceleme gerektiren cevap" sütununa düşüyorsa, o değişiklik artık vibe coding değil — diff okunması, test yazılması ve açıklanabilir olması gereken normal mühendislik işidir.

Bu beş soruyu tek tek sormak zaman alıcı görünebilir, ama pratikte saniyeler sürüyor — çünkü çoğu değişiklik için cevaplar zaten açık. Bir kişisel hafta sonu projesinde kenar boşluğunu değiştirmek, beş sorunun hepsinde "vibe" sütununa düşer; bir ödeme akışına dokunmak ise ilk soruda bile "inceleme gerektiren cevap" sütununa düşer ve geri kalan dördünü sormaya bile gerek kalmaz. Listenin değeri, kararı bilinçli hâle getirmesinde — "düşünmeden Accept All" ile "bilerek Accept All" arasındaki fark, tam olarak bu birkaç saniyelik durakta saklı.

Prototipten sonra ne yapmalı — sorumluluk devri

Vibe coding ile üretilen bir prototip, tanımı gereği "üretime hazır" değildir. Dönemin tartışmasında ortaya çıkan ortak nokta şu: prototipten production'a geçiş, bir sorumluluk devri gerektiriyor — kod satır satır okunmalı, testler yazılmalı ve en az bir kişi kodu başka birine açıklayabilmeli.

Bu devir sırasında Anthropic'in mühendislik ekibinin ajan sistemleri için yaptığı bir ayrım faydalı bir zihinsel model sunuyor: önceden tanımlı, denetlenebilir kod yolları (workflow) ile modelin kendi sürecini yönettiği açık uçlu sistemler (agent) arasındaki fark. Vibe coding'den çıkarken hedef, "denetlenebilir" tarafa geçmek — yani hangi kod yolunun neden çalıştığını açıklayabilmek.

Devrin üç maddesi

Pratikte bu devir üç adımda özetlenebilir:

1{
2  "handoffChecklist": [
3    "Her diff okundu ve yorum satırlarıyla değil, anlaşılarak onaylandı",
4    "Veri modeli ve yetkilendirme yolları en az bir kişi tarafından ayrıca gözden geçirildi",
5    "Kritik akışlar için test yazıldı (unit + en az bir entegrasyon senaryosu)"
6  ]
7}

Bu üç madde tamamlanmadan bir prototip production'a taşınırsa, hız kazancı geçici; teknik borç kalıcı olur. Cursor AI ile 10x verimlilik ve Claude Code MCP ekosistemi gibi araç rehberleri, bu devri hızlandırmak için kullanılabilecek araçları anlatıyor — ama aracın kendisi devri yapmıyor, disiplin yapıyor.

Devir kademeli de olabilir

Devir, tek seferlik bir olay değil, kademeli bir süreç olarak da işleyebilir: önce en kritik dosyalar (kimlik doğrulama, ödeme, veri modeli) incelemeli moda alınır, geri kalan düşük riskli kısımlar bir süre daha vibe modunda kalabilir. Önemli olan, hangi dosyaların hangi modda olduğunu ekip içinde açıkça bilmek — sessizce "her şey production-ready" varsayımına düşmemek.

SSS

Vibe coding nedir?

Vibe coding, Andrej Karpathy'nin 6 Şubat 2025'te tanımladığı, geliştiricinin AI'nin ürettiği kodu incelemeden ("Accept All") kabul ettiği, hata mesajlarını yorumsuz geri yapıştırarak ilerlediği bir kodlama pratiğidir. Karpathy'nin kendi tanımıyla "vibe'lara tamamen teslim olup kodun var olduğunu unutmak" anlamına gelir.

Vibe coding terimini kim icat etti?

Terim, OpenAI'nin kurucu ortaklarından ve Tesla'nın eski AI direktörü Andrej Karpathy tarafından 6 Şubat 2025'te bir tweet'te ortaya atıldı. Karpathy terimi bir metodoloji önerisi olarak değil, kendi gündelik alışkanlığını tarif ederken kullandı — bu yüzden tanım baştan dar tutulmuştu.

Vibe coding ile normal AI destekli kodlama arasındaki fark ne?

Fark araçta değil, incelemede. AI destekli kodlamada geliştirici diff'leri okur, testler yazar ve değişikliği açıklayabilir. Vibe coding'de bu inceleme adımı bilinçli olarak atlanır — Karpathy'nin kendi ifadesiyle "diff'leri artık okumuyorum."

Vibe coding ile production uygulama yazılır mı?

Karpathy'nin kendi tanımı bunu "atılabilir hafta sonu projeleri" ile sınırlıyor, üretim kalitesinde mühendislik yöntemi olarak sunmuyor. Production'a taşımak için diff inceleme, test yazma ve yetkilendirme/veri modeli gözden geçirmesi gibi bir sorumluluk devri gerekiyor.

Vibe coding güvenli mi?

Vibe coding'in kendisi güvensiz değil, ama incelemesiz bıraktığı alanlar (yetkilendirme, veri modeli) güvenlik açıklarının fark edilmeden üretime sızmasına açık kapı bırakıyor. Bu yüzden kritik iş mantığı içeren kod, vibe modunda değil incelemeli modda yazılmalı.

Vibe coding hangi projelerde işe yarar?

En iyi sonucu prototipleme, mimari keşif ve tek kullanıcılı/atılabilir araçlarda veriyor. Y Combinator verilerine göre W25 kohortundaki startup'ların dörtte biri kod tabanının %95'ini bu şekilde üretiyor — ama bunlar bile hâlâ teknik kurucular tarafından yönetiliyor.

Güncelleme (Eylül 2026)

Wikipedia'nın topladığı kaynaklara göre, terimin kabulü 2025-03-15'ten bu yana hızla genişledi: Collins English Dictionary "vibe coding"i 2025 Yılın Kelimesi seçti. Ocak 2026'da Linus Torvalds'ın Google Antigravity kullanarak bir hobi projesi için küçük bir görselleştirme aracını vibe-code ettiği bildirildi; kendi README notunda "the python visualizer tool has been basically written by vibe-coding" diye yazmıştı — Karpathy'nin orijinal "atılabilir hafta sonu projesi" çerçevesiyle tutarlı, deneyimli bir mühendisin de bu pratiği aynı sınırlar içinde kullandığını gösteren bir örnek.

Bu yazıdan sonra tartışma iki yöne ayrıldı: niyet ile üretim arasına yazılı bir ara adım koyan "spec-driven" akışlar ve ajan yetkilerinin denetimi.

Bu iki başlık aslında bu yazının merkezindeki ayrımın doğal devamı. "Spec-driven" akışlar, niyet ile üretim arasına bir ara adım koyarak — önce ne yapılacağını yazılı olarak netleştirip sonra kodu ürettirerek — vibe coding'in atladığı "anlama" adımını geri getirmeye çalışıyor. Ajan yetkilerinin denetlenmesi ise tam olarak bu yazının "nerede kırılıyor" bölümünde işaret edilen yetkilendirme riskini kurumsal ölçekte ele alıyor. Bu dönemde AI kodlama araçlarının gerçek dünyada nerede yanılttığını derleyen AI ile kodlamada 10 yanılgı yazısı da aynı sınır tartışmasının verili hâlini topluyor.

Sonuç

Vibe coding, Karpathy'nin 6 Şubat 2025'te tanımladığı andan bu yana bir tartışma konusu olmaya devam ediyor — ama tartışmanın çoğu, terimin kendi sınırlarını unutmaktan kaynaklanıyor. Karpathy'nin tanımı zaten dardı: atılabilir, düşük riskli, tek kullanıcılı projeler. Bu sınırın içinde kalındığında vibe coding gerçek bir hız kazancı sağlıyor; sınır aşıldığında — veri modeli, yetkilendirme veya çok kişili kod tabanına dokunulduğunda — aynı hız, sessiz bir risk hâline geliyor.

Prototipten production'a geçerken atılması gereken adımları Lovable ile prompttan full-stack uygulama rehberinde ve Bolt.new tarayıcı akışında somut örneklerle görebilirsin; ajanlara verilen yetkilerin güvenlik riskini ise AI kodlama ajanına yetki vermek yazısında bulabilirsin. Sınırı bilerek kullanılan bir araç, sınırı bilmeden kullanılan aynı araçtan çok daha değerli.

Kaynaklar

• Vibe coding — Wikipedia — terimin kronolojisi ve kaynak zinciri için genel referans.
• Simon Willison — Not all AI-assisted programming is vibe coding — Karpathy'nin orijinal tweet'ini birebir aktaran ana kaynak.
• The Guardian — AI, software coding, and the future of programmer expertise — Karpathy'nin 2023 "İngilizce" alıntısını ve dönemin tartışmalarını aktarıyor.
• TechCrunch — YC W25 kohortunda kod tabanlarının %95'i AI üretimi — Jared Friedman ve Diana Hu alıntıları.
• Anthropic — Building effective agents — workflow/agent ayrımı, sorumluluk devri bölümü için arka plan.