Skip to main content
Proje başlatın

Vibe Coding ve Mühendislik: Yapay Zekâ Kodu Ne Zaman Yeterli, Ne Zaman Değil?

Fazla İyi Geçen Öğleden Sonra

Şöyle bir durum düşün: Bir müşterinin talepleri kaydeden, filtreleyen ve CSV olarak dışa aktaran dahili bir araca ihtiyacı var. Yapay zekâ asistanını açıyorsun, ne istediğini üç paragrafta anlatıyorsun ve iki saat sonra, sanki bir ekip üç hafta uğraşmış gibi görünen bir arayüz çalışıyor. Müşteri çok memnun. Sen de.

Altı ay sonra yeni bir alan eklenmesi gerekiyor. Birden şu ortaya çıkıyor: Doğrulama kodun dört farklı yerinde duruyor, state yarı yarıya bileşende ve local storage’da tutuluyor ve belirli bir isteğin neden iki kez gönderildiğini kimse bilmiyor. Kod çalışıyor ama kimse onu hiç gerçekten okumamış. Sen de okumamışsın.

Bu bir düşünce deneyi, ama şu anda pek çok projede tam olarak böyle yaşandığından eminim. Bu yazının konusu da bu. Vibe coding ne saçmalık ne de kıyamet. Net bir kullanım alanı olan bir araç. Sorunlar ancak onun mühendislikten farkını unuttuğumuzda başlıyor.

Vibe Coding Aslında Ne?

Terim, 2025’in başında onu ortaya atan Andrej Karpathy’ye dayanıyor. Kastedilen bir çalışma tarzı: Yapay zekâya ne istediğini anlatırsın, sonucu ayrıntılı kontrol etmeden kabul edersin ve yalnızca çıktıya bakarak yön verirsin. Çalışıyor mu? Güzel. Hata mesajı mı? Kopyala, yapıştır, devam. Vibe’ları takip edersin ve kod arka planda kendiliğinden oluşur.

Buradaki ayrım önemli. Yapay zekâ önerilerini okuyan, anlayan ve bilinçli olarak kabul eden biri vibe coding yapmıyor; çok hızlı bir pair programming ortağıyla çalışıyor. Dar anlamıyla vibe coding, kodu anlamaktan bilinçli olarak vazgeçtiğin yerde başlıyor.

Peki neden bu kadar cazip? Üç nedeni var:

  • Hız: Fikirden çalışan bir arayüze dakikalar içinde.
  • Düşük eşik: Neredeyse hiç programlama bilmeyen biri bile çalışan bir şey elde ediyor.
  • Akış: Dokümantasyon, arama motoru ve editör arasında gidip gelmek yok.

Açıkçası bu harika hissettiriyor. Tam da bu yüzden, aslında neler olduğuna soğukkanlı bir gözle bakmakta fayda var. Vibe coding’de iş ortadan kalkmıyor, yer değiştiriyor. Kod yazmak ucuzluyor. Anlamak, kontrol etmek ve sorumluluğunu taşımak ise kalıyor ve bu iş daha sonra, genellikle de daha kötü bir zamanda önüne çıkıyor.

Vibe Coding’in Parladığı Yerler

Karşı olduğum izlenimini vermek istemem. Tam olarak doğru tercih olduğu durumlar var.

Prototipler ve fikir doğrulama. Soru, bunu gerçekten kullanacak biri olup olmadığıysa kod kalitesi ikinci planda kalır. Bir öğleden sonrada yapılmış tıklanabilir bir prototip, haftalarca sürecek tartışmalardan kurtarır. Önemli olan, prototipin gerçekten prototip olarak görülmesi ve sonrasında çöpe atılması.

Tek kullanımlık script’ler. Bir kerelik bir veri taşıma işlemi, 300 dosyayı yeniden adlandıran bir script, bu öğleden sonra lazım olan bir analiz. Bir kez doğru çalıştıysa iş bitmiştir. Burada kodu değil, sonucu kontrol etmek yeterli.

Küçük bir grup için dahili araçlar. Hassas verilere dokunmayan ve canlı ortamda hiçbir şeyi bozamayacak, üç iş arkadaşı için bir dashboard. Risk sınırlı, fayda anında ortada.

Öğrenmek ve keşfetmek. Tanımadığın bir kütüphaneyi denemek, iki yaklaşımı karşılaştırmak, bir kavramı düzgünce kurmadan önce kodda görmek. Yapay zekâ bunun için mükemmel bir antrenman ortağı; yeter ki sonrasında her şeyi körü körüne kabul etme.

Bu durumların ortak noktası şu: Hataların vereceği zarar küçük, ömür kısa ve etkilenen kişi sayısı az. Bu üç kriterden biri bile değiştiği anda işler riskli hale geliyor.

İşlerin Sarpa Sardığı Yer

Sorun, prototip sessiz sedasız canlı koda dönüştüğünde başlıyor. Bu sandığından çok daha sık oluyor, çünkü zaten çalışıyor ve müşteri bir sonraki özelliği soruyor.

Güvenlik. Yapay zekâ kodu, makul olmadığında bile makul görünür. Tipik adaylar: eksik girdi doğrulaması, fazla serbest CORS ayarları, istemcide duran gizli anahtarlar ya da string’lerden birleştirilen veritabanı sorguları. Kodu hiç okumazsan bunu fark etmezsin. Saldırganlar ise onu gayet iyi okur.

Bakım kolaylığı. Model "şimdi çalışsın" için optimize eder, "bir yıl sonra da değiştirilebilsin" için değil. Ortaya çoğu zaman tekrar eden kod, tutarsız kalıplar ve yalnızca o anki prompt bağlamında anlam taşıyan soyutlamalar çıkar.

Hata ayıklama. Bedeli en net burada ödersin. Kodu anlamıyorsan bir hatayı daraltamazsın. Bir döngüye girersin: hatayı yapıştır, düzeltmeyi al, yeni hata. Bazen yapay zekâ sorunu gerçekten çözer. Bazen de semptomun etrafına bir geçici çözüm örer ve asıl neden bir katman daha derine iner.

Sorumluluk. Bir müşteri veri kaybettiğinde, kodu hangi modelin yazdığını sormaz. İşi verdiği kişiye sorar. Özellikle freelancer olarak bu, devredemeyeceğim ve devretmek de istemediğim bir konu.

Kimsenin Fark Etmediği Teknik Borç

Klasik teknik borcu herkes bilir: Kestirme bir yol seçtiğini bilirsin ve onu bilerek seçersin. Vibe coding’de ise varlığından bile haberin olmayan borçlar oluşur, çünkü kodu hiç okumamışsındır. Pratikte bu fark gerçekten can yakar.

Günlük frontend işinden bir örnek. Bir asistan istediğinde sana böyle bir şey verir:

async function loadUser(id: string) {
  const res = await fetch(`/api/users/${id}`)
  const data = await res.json()
  return data as User
}

Kod kısa, okunaklı ve testte tam olarak doğru şeyi yapıyor. Yine de içinde epey şey saklı:

  • res.ok kontrolü yok. Bir 404 ya da 500, kodda sözde bir kullanıcı olarak karşına çıkar.
  • as User bir kontrol değil, derleyiciye verilmiş bir söz. Sunucudan başka bir şey dönerse bunu ancak çok uzak bir yerde, anlaşılmaz bir hata mesajıyla fark edersin.
  • id, kontrol edilmeden URL’ye ekleniyor.
  • Hızlı yazarken ya da sayfalar arasında gezinirken istekler birbirini geçebilir, çünkü hiçbir şey iptal edilmiyor.

Gönül rahatlığıyla projeye alacağım bir versiyon:

import { z } from 'zod'

const UserSchema = z.object({
  id: z.string(),
  name: z.string(),
  email: z.email()
})

type User = z.infer<typeof UserSchema>

async function loadUser(id: string, signal?: AbortSignal): Promise<User> {
  const res = await fetch(`/api/users/${encodeURIComponent(id)}`, { signal })

  if (!res.ok) {
    throw new Error(`Kullanıcı yüklenemedi (${res.status})`)
  }

  return UserSchema.parse(await res.json())
}

Daha karmaşık değil ama daha dürüst. Hatalar görünür hale geliyor ve veriler yalnızca tip sisteminde iddia edilmek yerine çalışma zamanında kontrol ediliyor. Mesele yapay zekânın bunu yapamaması değil. Sorarsan yapar. Ama neyi sorman gerektiğini bilmiyorsan ilk versiyonu alırsın. İşte tam da bu bilgi mühendisliktir.

Mühendisliği Yine de Mühendislik Yapan Şey

Yazılım geliştirmenin büyük ölçüde klavyede yazmaktan ibaret olduğu yönünde bir algı var. Böyle düşünen biri yapay zekâyı kaçınılmaz olarak bir ikame olarak görür. Oysa pratikte kod yazmak işin yalnızca bir parçası ve nadiren en zor kısmı.

Benim için mühendislik her şeyden önce kararlar demek:

  • Mimari: Hangi sorumluluk nerede duruyor? Neyin ileride kolayca değişebilmesi gerekiyor, neyin değil? Model prompt’u görür ama şirketi, yol haritasını ya da müşterinin kendine has özelliklerini görmez.
  • Testler: Bir angarya değil, bir şeyi değiştirdikten sonra hâlâ çalıştığını nereden bildiğim sorusunun cevabı. Özellikle üretilmiş kodda en önemli güvenlik ağı.
  • Review: Canlıya çıkmadan önce birinin kodu anlaması gerekir. Bu, iş arkadaşlarından gelen kod için de yapay zekâdan gelen kod için de aynen geçerli. Kod ne kadar hızlı üretilirse review o kadar darboğaza dönüşür.
  • İşletim: Loglama, hata yönetimi, güncellemeler, bağımlılıklar. İlk deployment’tan sonra gelen ve demo videosunda asla görünmeyen her şey.

Burada özellikle sevdiğim bir şey var: İyi mühendislik pratiği ile yapay zekâ kullanımı birbirini dışlamıyor, aksine güçlendiriyor. Strict TypeScript, düzgün yapılandırılmış bir linter ve makul bir test kapsamı, saçmaladığında bir modelin de çarpıp geri döndüğü bariyerlerdir. Bu bariyerlere sahipsen yapay zekâya çok daha fazla güvenebilirsin. Yoksa yüksek hızla körlemesine gidiyorsun demektir.

Yani roller değişiyor: daha az yazmak, daha çok okumak, değerlendirmek ve karar vermek. Bu mesleğin değerini düşürmüyor, hatta tam tersi.

Günlük İş İçin Bir Pratik Kural

Yani soru yapay zekâyı kullanıp kullanmadığın değil, bunu yaparken ne kadar kontrolü elden bıraktığın. Her görevden önce kendime üç soru soruyorum:

  1. Yanlış olursa ne olur? En kötü ihtimalle birinin canı kısa süreliğine mi sıkılır, yoksa veri, para ya da güven mi kaybedilir?
  2. Kod ne kadar yaşayacak? Bugün bir kez çalışıp yarın unutulacak mı, yoksa bir yıl sonra hâlâ geliştirilecek mi?
  3. Daha sonra kimin anlaması gerekecek? Sadece benim mi, bir ekibin mi, yoksa bir gün onu devralacak bir müşterinin mi?

Cevaplar "pek bir şey olmaz", "kısa" ve "sadece ben" ise yapay zekâ çalışabilir: prompt’u ver, sonucu kontrol et, bitti. Cevaplardan biri bile belirgin şekilde farklıysa kontrolü ben alıyorum. Somut olarak bu şu demek:

  • Küçük adımlarla çalışmak. Her istekte bir özellik, tüm uygulama bir kerede değil. Küçük diff’ler gerçekten okunabilir.
  • Çerçeveyi belirlemek. Hangi kütüphaneler, hangi kalıplar, hangi hata yönetimi. Talimatlar ne kadar netse sürprizler o kadar az olur.
  • Kabul ettiğim her satırı okumak. Bir şeyi anlamazsam ya sorarım ya da anlayana kadar yeniden yazarım.
  • Testler önce ya da hemen sonra. Testler de yapay zekâdan gelebilir, ama doğru şeyi mi test ettiklerini, yoksa sadece kodun şu anda yaptığını mı test ettiklerini kontrol etmem gerekir.
  • Tipleri ve linter’ı sıkı ayarlamak. Derleyici ne kadar çok şey yakalarsa benim o kadar az şey bulmam gerekir.

Bu bir fren gibi geliyor ama değil. Okumaya harcadığın zamanı hata ayıklamada katbekat geri kazanırsın.

Sonuç: Vibe’lar Temel Olamaz

Vibe coding, bir fikirden hızla elle tutulur bir şeye ulaşmanın harika bir yolu. Prototipler, script’ler ve küçük dahili yardımcılar için bu yaklaşımı seve seve ve vicdanım rahat kullanıyorum. Ama işin içine gerçek kullanıcılar, gerçek veriler ya da gerçek para girdiği anda vibe’lar artık yetmez.

Bu yüzden tutumum oldukça net: Canlı kod için saf haliyle vibe coding iyi bir fikir değil. Yapay zekâ kötü olduğu için değil, sorumluluk devredilemediği için. Kodu teslim eden kişi onu anlamak, ya da en azından gerektiğinde anlamaya hazır olmak zorunda.

İşin heyecan verici yanı, yapay zekânın mesleği gereksiz kılmaması, ağırlık merkezini kaydırması. Kod üretmek ucuzluyor. İyi olup olmadığını değerlendirmek ise değerli kalıyor. Bunu yapabilen biri, bu araçlarla elinde muazzam bir kaldıraç tutuyor. Yapamayan ise çok hızlı bir şekilde başına çok büyük dertler açıyor.

Aklında kalması gereken tavsiyem: Yapay zekâyı, yetenekli ama deneyimsiz bir iş arkadaşını nasıl kullanıyorsan öyle kullan. Net görevler ver, geri geleni oku ve açıklayamadığın hiçbir şeyi kabul etme. Böylece vibe coding’in hızını ve mühendisliğin güvenilirliğini bir arada elde edersin.