Vibe Coding Nedir? Ne Zaman Kazanç, Ne Zaman Borç

Bir öğleden sonrada çalışan bir uygulama çıkardınız. Kod yazmadınız; ne istediğinizi anlattınız, dönen şeyi çalıştırdınız, çalıştı.

İki ay sonra küçük bir değişiklik gerekiyor. Dosyayı açıyorsunuz ve nereye dokunacağınızı bilmiyorsunuz.

O öğleden sonra kazandığınız zaman kaybolmadı. Ertelendi.

Bu yazı tek bir soruyu cevaplıyor: modele kod yazdırarak iş çıkarmak ne zaman gerçek bir kazanç, ne zaman sonradan faiziyle ödenecek bir borç?

Soru kişisel bir merak değil. Ağustos 2026 itibarıyla vibe coding nedir sorgusu Türkiye’den ayda yaklaşık 2.900 kez aranıyor (Semrush, Türkiye veritabanı, 2026-08-03). Aynı tarihte o aramanın ilk on sonucundan dördü, İngilizce sayfaların makine çevirisiydi. Yani soru Türkçe soruluyor, sonuçların önemli kısmı çeviri.

Vibe coding ne demek?

Vibe coding, modele ne istediğinizi anlatıp dönen kodu okumadan kabul etmek ve yalnızca çalışıp çalışmadığına bakarak ilerlemektir. Tanımın ağırlık merkezi “yapay zeka kullanmak” değil, okumamak.

Terimi 2 Şubat 2025’te Andrej Karpathy attı. Kısa bir gönderide “vibe coding dediğim yeni bir kodlama biçimi var” diye başlayıp kendi çalışma şeklini anlattı: modelin önerdiği değişiklikleri her seferinde kabul ediyor, farkları artık okumuyordu. Kodun kendi kavrayışının ötesine büyüdüğünü de aynı gönderide yazdı. Yani “okumamak” terimin sonradan eklenmiş bir eleştirisi değil, ilk tanımının merkezinde duran şey.

Aynı gönderide bunun “atılacak hafta sonu projeleri” için fena olmadığını da söylüyordu — bu yazının ilerleyen bölümlerinde göreceğiniz ömür ayrımı, terimin doğduğu cümlede zaten vardı.

Terim İngilizce doğdu ve Türkçeye çevrilmeden yerleşti. Bu yazıda da öyle kullanılıyor, çünkü okurun aradığı biçim bu.

Çalışma döngüsü kısadır. İstersiniz, kod gelir, çalıştırırsınız. Olmadıysa “olmadı” dersiniz, yeni bir sürüm gelir. Hata mesajını okumadan modele yapıştırırsınız. Bir noktada ekranda doğru sonuç belirir ve iş biter.

Bu döngünün içinde hiçbir aşamada kodu değerlendirmezsiniz. Değerlendirilen şey çıktıdır, kod değil.

Neyi gerçekten kolaylaştırıyor

Bir sözleşmeyi hiç bilmediğiniz bir dilde imzaladığınızı düşünün. Yanınızdaki tercüman “her şey standart” diyor ve siz imzalıyorsunuz. İşlem saniyeler sürüyor, oysa metni öğrenip okumanız aylar alırdı.

Bu benzetme bir yere kadar iyi çalışıyor: ikisinde de bir aracıya güvenip anlamadığınız bir şeyi kabul ediyorsunuz ve karşılığında büyük bir hız kazanıyorsunuz.

Benzetme şurada bozuluyor: tercümanın mesleki sorumluluğu vardır, model çıktısının yoktur. Yanlış çeviriden tercüman hesap verir; yanlış koddan siz hesap verirsiniz.

Kazanç gerçek ve küçümsenmemeli. Daha önce bir yazılımcıya sormadan yapılamayan işler artık tek başına yapılabiliyor: küçük bir hesaplama aracı, bir veri dönüştürme betiği, bir fikri sınamak için tek seferlik bir arayüz. Yazılım bilmeyen biri, ihtiyacını doğrudan çalışan bir şeye çevirebiliyor.

Yazılım bilen için de kazanç var: tanımadığı bir kütüphaneyle ilk temas, sıkıcı ve tekrarlayan iskelet kodu, hızlı bir fizibilite denemesi. Bunların hiçbiri okunmayı hak edecek kadar uzun yaşamıyor.

Borç nerede birikiyor

Borç kodun kötü olmasından doğmuyor. Model gayet temiz, düzenli, yorumlu kod da yazabilir. Borç, o kodun sizin zihninizde bir karşılığı olmamasından doğuyor.

Bu ayrım yazının merkezi. Klasik teknik borç bir kod kalitesi sorunudur: aceleyle yazılmış, kopyalanmış, düzeltilmesi gereken kod. Buradaki borç bir anlama sorunudur ve kod kusursuz olsa bile durur.

Birikme sırası şöyle işliyor.

Kod kabul edilir. Çalıştı, demek ki doğru. Oysa “çalıştı”, denediğiniz girdilerde çalıştığı anlamına geliyor; denemediklerinizde ne olduğu bilinmiyor.

Zihinsel harita oluşmaz. Kendi yazdığınız kodda hangi parçanın neyi yaptığını hatırlarsınız, çünkü o kararları siz verdiniz. Okunmamış kodda böyle bir harita yoktur.

İkinci istek haritayı daha da bozar. Modele “şunu da ekle” dersiniz, model önceki kodun bir kısmını değiştirir. Neyin değiştiğini görmediğiniz için haritanız yalnızca eksik değil, artık yanlıştır.

Hata çıkınca fatura kesilir. Hata ayıklamak, kodu ilk kez okumak zorunda kalmak demektir. Üstelik en kötü anda: bir şey bozukken, aceleyken ve o kodu tanımayan biri olarak.

Devredilirse borç da devredilir. Kod bir başkasına kalırsa, o kişi sizin hiç girmediğiniz maliyete girer. Kendi kodunuzu okumamayı seçebilirsiniz; başkasının bunu seçme şansı yoktur.

Bu üç maddenin ortak paydası sezgiye aykırı bir sonuç veriyor: kodun kalitesi değil ömrü belirleyici. Kısa ömürlü kötü kod borç üretmez — okumadığınız yere bir daha dönmezsiniz. Uzun ömürlü mükemmel kod ise, okunmamışsa üretir.

Bir kademe derine: borcun faizi neyle çarpılıyor

Bu borcun bir tuhaflığı var: anapara sabit, faiz değişken. Anapara, okumadığınız kod miktarı. Faiz ise o koda kaç kez geri dönmek zorunda kalacağınız.

Bir kez çalışıp atılacak bir betikte faiz sıfırdır. Kodu bir daha açmayacaksınız, dolayısıyla anlamamanın hiçbir bedeli yok. Bu durumda vibe coding yalnızca meşru değil, muhtemelen doğru seçim.

Aynı miktarda okunmamış kod, iki yıl yaşayacak ve ayda birkaç kez değişecek bir sistemde çok farklı bir şey. Her dokunuşta okumadığınız yere geri dönüyorsunuz ve her seferinde daha fazlasını okumak zorunda kalıyorsunuz.

Yukarıda “kaliteyi değil ömrü” derken kastedilen mekanizma bu: ömür, anaparayı değil faizi belirliyor. İki proje aynı miktarda okunmamış kod taşıyabilir; borcu ayıran şey o koda kaç kez geri dönüleceğidir.

Modelle kod yazmak vibe coding değildir

Vibe coding, yapay zekayla kod yazmak demek değildir. Ayrım aracın kullanılıp kullanılmamasında değil, çıkan kodun okunup okunmamasında.

Bir yazılımcı modele yüz satır yazdırıp hepsini okuyabilir, iki yerini düzeltebilir, neden öyle yaptığını anlayabilir. Bu vibe coding değil; bu, bilgisayarın hızlı yazdığı bir taslağı gözden geçirmek. Sorumluluk hâlâ insanda.

Kendinizi sınamak için üç soru yeterli:

Silinse yeniden kurabilir misiniz? Aynı satırları ezberden yazmak değil kastedilen. Aynı sonuca hangi yoldan gideceğinizi biliyor musunuz?

Hata çıksa nereden başlardınız? Bir cevabınız varsa kodun bir haritası zihninizde var demektir.

Başkasına anlatabilir misiniz? Anlatamadığınız kodun sorumluluğunu da alamazsınız.

Üçüne de hayır diyorsanız vibe coding yapıyorsunuz. Bu tek başına bir suçlama değil — bazı işlerde tam olarak doğrusu bu. Ama ne yaptığınızı bilerek yapmakla farkında olmadan yapmak aynı şey değil.

Borcun ödendiği an: bir senaryo

Aşağıdaki senaryo kurgusal, ama tanıdık. Ölçülmüş bir vaka değil, mekanizmayı görünür kılmak için kuruldu.

Bir pazarlama ekibinde çalışıyorsunuz. Her hafta üç ayrı yerden veri indirip elle birleştiriyor ve bir rapor çıkarıyorsunuz. İş üç saat sürüyor ve sıkıcı.

Bir öğleden sonra modele durumu anlatıyorsunuz. Birkaç turda çalışan bir araç çıkıyor. Üç saatlik iş üç dakikaya iniyor. Kazanç gerçek ve haftalarca sürüyor.

İki ay sonra kaynaklardan biri dosya biçimini değiştiriyor. Araç bir hata veriyor. Hatayı modele yapıştırıyorsunuz, model bir düzeltme öneriyor, çalışmıyor. İkinci öneri de çalışmıyor.

Şimdi dosyayı açmak zorundasınız. İçeride hiç okumadığınız birkaç yüz satır var ve hangisinin neyi yaptığını bilmiyorsunuz. Model de bilmiyor, çünkü o da her seferinde sıfırdan bakıyor.

İki gününüz gidiyor. Toplamda kazandığınız zamandan hâlâ kârdasınız — ama kâr sandığınız kadar değil ve fatura en kötü anda geldi: rapor gecikirken.

Senaryonun asıl dersi kaybedilen iki gün değil. Şu an bir seçim noktasındasınız: ya kodu gerçekten okuyup sahiplenirsiniz, ya da bir düzeltme daha yaptırıp aynı yere üçüncü kez dönersiniz. İkinci seçenek her defasında daha ucuz görünür ve her defasında borcu büyütür.

Hangi işte hangisi?

Vibe coding bir teknik değil, bir bahis. Bahsi dört değişken belirliyor ve dördü de yazmaya başlamadan önce bilinebilir.

Dördü de sol sütundaysa okumamak makul bir karar. Dördü sağdaysa okumamak, ödemeyi kabul ettiğiniz bir borçtur ve bunu bilerek yapmalısınız.

Karışık durumlar için pratik bir eşik: kodu ikinci kez açmak zorunda kalacağınızı düşünüyorsanız, ilk seferde okuyun. İlk okuma neredeyse her zaman daha ucuzdur; çünkü o sırada bir şey bozuk değildir ve aceleniz yoktur.

Bir uyarı da ters yönde. Okumak bedava değil. Üretilen her satırı incelemek bazen kodu baştan yazmaktan pahalıya gelir; o eşiğin nerede olduğu ayrı bir konu → Doğrulama Maliyeti Üretim Tasarrufunu Aşarsa: Kazanç Nerede Kayboluyor?

Sınırlar ve yanlış anlamalar

Terimin sabit bir tanımı yok. Kimi “hızlı prototipleme” anlıyor, kimi “sorumsuz üretim”. Aynı kelimeyi kullanan iki kişi farklı şey savunuyor olabilir. Bu yazı tanımı okumama ekseninde kurdu; başka bir eksende kuran biri farklı sonuca varır. Kayma sözlük düzeyinde de görünüyor. Merriam-Webster terimi “kodun nasıl veya neden çalıştığını anlamaya gerek duymamak” diye tanımlıyor; Collins ise 2025’in yılın kelimesi seçtiği aynı terimi “doğal dille yapay zekaya kod yazdırmak” diye, okuma şartından hiç söz etmeden tanımlıyor. Aynı yıl, aynı kelime, iki farklı tanım. Bu yazı birinci ekseni kullanıyor, çünkü ayrımı taşıyan eksen o.

Bu yazı verimlilik ölçmüyor. “Kod asistanları gerçekten hızlandırıyor mu” sorusunun ölçülmüş cevabı ayrı bir konu; o yazı sırada → 8.2.2.1^yakında

Güvenlik ayrı bir başlık. Okunmamış kodun güvenlik yüzeyi bu yazının kapsamı dışında; yukarıdaki tabloda yalnızca bir değişken olarak geçiyor.

Yukarıdaki çerçeve ölçülmüş değil. Dört değişken bir karar aracı, doğrulanmış bir model değil. Kendi işinizde beşinci bir değişken varsa ekleyin.

Beceri tarafı bu yazıda yok. Sürekli okumadan kabul etmenin insanın kendi yetkinliğine ne yaptığı ayrı bir soru → Yapay Zeka Kullanmak Hangi Becerileri Köreltiyor?

Bu konuda anlaşmazlık var: okumadan kabul edilen kod meşru mu?

Görüş A — Meşru. Bu yeni bir soyutlama katmanı. Derleyicinin ürettiği makine kodunu da kimse okumuyor; bir katman yukarı çıkmak yazılım tarihinin normal seyri.

Üstelik her satırı incelemek ölçeklenmiyor: ekipler zaten okumadıkları kütüphaneleri her gün üretime alıyor. Araçlar ve testler olgunlaştıkça model çıktısı da benzer bir güven zeminine oturur.

Görüş B — Değil. Soyutlama katmanları tanımlı, belgelenmiş ve milyonlarca kez test edilmiş sözleşmelerdir. Model çıktısı her seferinde yeni ve sözleşmesiz.

Durum — (Bu bir değerlendirme, ölçülmüş bir tespit değil.) Uzlaşma yok, ama tartışmanın çoğu yanlış yerde dönüyor gibi görünüyor. İki taraf farklı kod ömrü varsayıyor: A tarafı atılacak kodu, B tarafı yaşayan sistemi düşünüyor. Kendi işinizin hangisi olduğunu söylerseniz, tartışma büyük ölçüde konusuz kalıyor.

Özet

Vibe coding, modele kod yazdırıp çıkanı okumadan kabul etmektir. Ayırt edici şey aracın kullanılması değil, kodun okunmaması.

Borç kodun kalitesinden değil, sizde bir zihinsel karşılığının olmamasından doğar. Model kusursuz kod yazsa bile bu borç durur.

Belirleyici değişken kalite değil ömür. Bir kez çalışıp atılacak kodda borç oluşmadan kod ölür; aylarca yaşayacak kodda her dokunuş faizi büyütür.

Karar dört soruyla veriliyor: ne kadar yaşayacak, bakımı kime kalacak, dışarı açık mı, yanlış giderse ne kaybedilir. Pratik eşik ise tek cümle: kodu ikinci kez açacaksanız ilk seferde okuyun.

Sık sorulanlar

İlgili yazılar

Yayında olanlar

Henüz yayında değil — bu başlıklar konu ağacında yerini aldı, yazıları sırada:

• 8.2.2.1^yakında Kod asistanlarının gerçek verimlilik etkisi — “Gerçekten hızlandırıyor mu” sorusunun ölçüm tarafı.
• 8.2.2.3^yakında YZ üretimi kodu inceleme disiplini — Okumaya karar verdiyseniz nasıl okunacağı.
• 7.4.4.1^yakında Makine öğrenmesi sistemlerinde gizli teknik borç — Aynı kelimenin bambaşka anlamı: kod değil sistem borcu.