AI ile kod yazmak, vibe coding’den agentic coding’e

Vibe coding nedir, agentic coding’den farkı ne?

Önceki yazılarda kodlama ajanlarının parçalarını tek tek anlattık: hook’lar, alt ajanlar, skill’ler, worktree’ler, auto mode ve sandbox. Bu yazı hepsini tek bir soruda topluyor: vibe coding’i iyi yapmak için ne gerekir, nerede tuzağa düşülür? Her alışkanlığı kısaca anlatıp ayrıntısını yazdığımız yazıya bağladık.

Terimi Andrej Karpathy 2 Şubat 2025’te X’te ortaya attı. Wikipedia’nın aktardığı paylaşımında nasıl çalıştığını şöyle anlatıyordu: her değişikliği “Accept All” ile kabul ediyor, diff’leri artık okumuyor, hata mesajını hiçbir şey eklemeden ajana yapıştırıyordu. Kendi deyişiyle bu, hafta sonu yapılıp atılacak projeler için fena değildi. Kısacası vibe coding, kodu okumadan yapay zekâya yazdırıp yalnızca sonuca bakmak.

Simon Willison’ın 6 Mayıs 2026 tarihli yazısı ayrımı netleştiriyor. Ona göre vibe coding, koda hiç bakmadan çalışmak: program yazmayı bilmeyebilirsiniz bile, ne istediğinizi söylersiniz, çalışıyorsa tamamdır. Yalnızca sizin kullandığınız, hatası yalnızca size dokunan bir araçta bunun sakıncası yok. Başkaları için yazılım yapıyorsanız ise vibe coding “büyük bir sorumsuzluk”, çünkü sizin hatanızdan başkaları zarar görüyor. Agentic engineering bunun karşı ucu: güvenliği, bakımı, operasyonu ve performansı bilen bir yazılım mühendisinin bu araçları kullanması. Araçların kendisine ise agentic coding aracı deniyor: Anthropic’in tanımıyla kodu okuyan, dosyaları düzenleyen ve komut çalıştıran bir ajan. Kısacası agentic coding, ajanın kodu kendi başına yazıp çalıştırdığı çalışma biçimi; vibe coding ile agentic engineering arasındaki fark ise sizin sonucu okuyup sorumluluğunu alıp almamanızda.

Bu yazıdaki öneriler de bu ayrıma dayanıyor. Kendi kullandığınız bir araçta, bir prototipte ya da bir şey öğrenirken vibe coding’in sakıncası yok. Başkalarının kullandığı, kullanıcı verisi tutan, giriş ya da ödeme alan kodu ise okumadan yayımlamayın. Aşağıdaki alışkanlıklar, vibe coding’i sorumluluğu alınmış bir agentic coding’e yaklaştıran şeyler.

Terimin oturmuş bir Türkçe karşılığı yok; çoğunlukla İngilizcesiyle kullanılıyor. “Yapay zekâ ile kod yazmaya ne denir?” sorusunun genel cevabı yapay zekâ destekli kodlama; vibe coding bunun kodu hiç okumadan yapılan ucu. Sık karıştırılan iki terim daha var. Spec-driven development neredeyse tersi: ajan koddan önce spec, plan ve görev listesi yazıyor. Harness engineering ise başka bir konu: modelin etrafına kurduğunuz yapıyı anlatıyor.

Bu sonbahar kodlama araçlarında ne değişti?

Beş araçta da Eylül ve Ekim’de aynı yönde değişiklikler geldi: ajan size daha az soruyor, daha uzun süre kendi başına ve daha çok paralel çalışıyor. Sürüm notlarından:

Kaynak: araçların sürüm notları, 21 Ekim 2026. Sürümler: Claude Code 2.1.284 ve 2.1.286, Codex CLI 0.162.0, Antigravity CLI 1.3.5; Copilot satırı VS Code’un Eylül sürümlerinden. Google, Gemini CLI’ı Google AI Pro ve Ultra aboneleri ile ücretsiz kullanıcılar için 18 Haziran 2026’da kapattı ve yerine Antigravity CLI’ı koydu; şirketler ve ücretli API anahtarı kullananlar Gemini CLI’ı kullanmaya devam edebiliyor.

Ortak yön belli: ajan bir işi daha uzun süre size sormadan yürütüyor. Onay sorularına zaten çoğu zaman okunmadan evet deniyordu; satıcıların bununla ilgili ölçümlerini auto mode ve sandbox yazısında anlattık. Asıl kontrolün ajanın döngüsünde, siz başında değilken de çalışması gerekiyor: bir test, bir hook, CI. Claude Code’un verify değişikliği de tam bunu yapıyor: commit’ten önce sizin yazdığınız kontrolü çalıştırtıyor.

Araştırmalar vibe coding’le yazılan uygulamalar hakkında ne diyor?

Ağustos ve Eylül’de üç çalışma yayımlandı ya da güncellendi; üçü de arXiv’de, hakem değerlendirmesinden geçmemiş ön baskı (preprint). En büyüğü Deng, Fan ve Meng’in çalışması; son sürümü 14 Eylül 2026 tarihli. Araştırmacılar Claude Code ve Lovable ile yazılmış 9.041 açık kaynak uygulama topladı, bunlardan yayında olan 200 tanesini denetledi ve 1.186 güvenlik açığı buldu. Açık adaylarını önce yapay zekâ denetçileri çıkardı; her birini güvenlik bilen iki yazar ayrı ayrı inceledi ve ikisi de istismar edilebilir bulduysa açık saydı.

Sonuç: uygulamaların %91’inde en az bir açık vardı, açıkların %65,77’si kritik ya da yüksek önemdeydi. Açıklar en çok yetki kontrolünde (broken access control), enjeksiyonda ve kimlik doğrulamada toplanıyor. Yetki kontrolü, bir kullanıcının yalnızca kendi verisine erişebilmesini sağlayan kısım; eksikse uygulama yine çalışıyor, o yüzden bir demoda fark edilmiyor.

Araştırmacılar bu açıkların bir kısmını yeniden üretip neyin işe yaradığına da baktı. Açıkları en çok iki şey azalttı: işin bitmiş sayılması için kodun üretime hazır olmasını şart koşan bir prompt ve güvenlik kontrolleri eklenmiş bir harness. Ama hiçbir ayar hepsini ortadan kaldırmadı. Dikkat çekici bir sonuç daha var: açığın tetiklendiği 434 koşunun 90’ında (%20,7) ajan riski kendisi fark etti ve güvensiz kodu yine de yazdı; çoğu zaman düzeltmek yerine bir uyarı ya da yorum bıraktı. Ajanın riski bilmesi yetmiyor; kontrolün iş bitmeden çalışması gerekiyor.

Andročec’in 21 Ağustos 2026 tarihli çalışması küçük ama doğrudan bir soru soruyor. 6 web uygulamasının her birini aynı ajana ve aynı modele iki kez, tek seferde yazdırdı. İki prompt arasındaki tek fark, ikincisinin sonuna eklenmiş bir güvenlik şartları bölümüydü. Güvenlik şartlı sürümde her uygulamada daha az doğrulanmış bulgu çıktı (24’e karşı 51) ve hiçbiri kritik ya da yüksek önemde değildi. En ciddi bulguyu ise yalnızca elle yapılan test yakaladı. Yazar da uyarıyor: örnek küçük, her sürüm bir kez üretildi; sonuçlar istatistiksel bir etki değil, gözlem.

Kraishan’ın çalışması (12 Eylül 2026) başka bir yere bakıyor: ajanların açtığı pull request’ler merge’ten sonra ne oluyor? Beş ticari ajanın 37.623 pull request’ini aynı depolardaki insanların pull request’leriyle karşılaştırdı. Sonuç “satıcıya göre değişiyor, tek tip değil”: merge’ten sonraki 90 günde beş ajandan 3’ünün geri alınma oranı insanlarınkinden istatistiksel olarak ayırt edilemedi, biri daha seyrek, biri daha sık geri alındı. Ajanların kodunda gömülü parola ya da eval gibi şüpheli kalıplar insanlarınkinden daha az çıktı; ama bu bir kalıp taraması, doğrulanmış açık değil. Veri Aralık 2024 ile Temmuz 2025 arasından; bugünkü araçların ve modellerin sırasını söylemiyor. Böyle bir karşılaştırmayı nasıl okumanız gerektiğini SWE-bench yazısında anlattık.

Geliştiriciler de en çok doğrulayabildiklerine güveniyor. Stack Overflow’un 6 Ekim’de yayımladığı 2026 anketinde (30.000’den fazla katılımcı; rastgele seçilmiş değil, gönüllü yanıtlar) katılımcıların %48’i yapay zekâya, cevabını kolayca doğrulayabildiğinde güvendiğini söyledi. Aşağıdaki alışkanlıkların çoğu da bunu kolaylaştırmak için var.

Beş aracın rehberi hangi konularda aynı şeyi söylüyor?

Beş aracın da kendi best practices rehberi var. 21 Ekim 2026 günü hepsini okuyup aynı konudaki önerileri yan yana koyduk. Copilot için GitHub’ın üç rehberini (VS Code, Copilot CLI ve bulut ajanı) birlikte okuduk; Cursor’ınki 9 Ocak 2026 tarihli bir blog yazısı, ötekiler tarihsiz. Altı alışkanlığın kaç rehberde geçtiği:

Beş rehber 3 alışkanlıkta birleşiyor. Öteki 3’ünü 4 rehber öneriyor; Antigravity CLI’ın rehberi bunlardan söz etmiyor, ama büyük işlerde arka planda paralel alt ajan çalıştırmayı öneriyor ve CLI’da değişiklikleri gösteren bir /diff görünümü var. Her rehberin ne dediği:

Kaynak: beş aracın best practices rehberleri, 21 Ekim 2026. Copilot sütunu VS Code’un, Copilot CLI’ın ve Copilot bulut ajanının rehberlerinden. Hücreler rehberdeki cümlenin kısa Türkçesi. “Rehberinde yazmıyor”: o gün okuduğumuz rehberde bunu söyleyen bir cümle bulamadık; aracın başka belgelerinde olabilir.

Kontrol. Ajan, iş bitmiş göründüğünde duruyor. Claude Code’un rehberine göre çalıştırabileceği bir kontrol yoksa “bitmiş görünmek” elindeki tek işaret oluyor ve her hatayı sizin fark etmeniz gerekiyor. Test, build, linter ya da çıktıyı bir örnekle karşılaştıran bir betik; geçti ya da kaldı diye okunabilen her şey işe yarar. Ajan “testler geçti” dediğinde çalıştırdığı komutu ve çıktısını isteyin. Arayüzü ajan tarayıcıda kontrol edebilir; bunu kalıcı bir Playwright testine çevirmeyi computer use yazısında anlattık.

Plan. Plan, ajanın yanlış problemi çözmesini önlüyor. Claude Code’un rehberi planı ne zaman atlayacağınızı da söylüyor: diff’i tek cümleyle anlatabiliyorsanız gerek yok; yaklaşımdan emin değilseniz, değişiklik birden çok dosyaya dokunuyorsa ya da kodu tanımıyorsanız plan yaptırın. Cursor’ın rehberi de küçük ve daha önce çok kez yaptığınız işlerde doğrudan ajana geçmeyi uygun buluyor. Büyük bir özellikte planın bir adım ötesi spec; ne zaman işe yaradığını spec-driven development yazısında anlattık.

Kural dosyası. Codex ve Cursor aynı yolu öneriyor: kısa başlayın, ajan aynı hatayı tekrarlayınca bir kural ekleyin. Codex’in rehberi, ajan aynı hatayı iki kez yaptığında ondan bir değerlendirme isteyip AGENTS.md’yi güncellemenizi söylüyor. Hangi aracın hangi dosyayı okuduğunu AGENTS.md ve CLAUDE.md yazısında anlattık. Her seferinde mutlaka olması gereken bir kural için dosya yetmez; Claude Code’un rehberine göre talimat bir öneri, hook ise her seferinde çalışıyor (hook yazısı). Sürekli tekrarladığınız bir prompt da bir skill olabilir. Aynı dosya incelemede de işe yarıyor. Yapay zekâ kod inceleme aracımız diffox, pull request’i incelerken deponun AGENTS.md’sini (yoksa CLAUDE.md’sini) pull request’in birleşeceği branch’ten okuyor. İçindeki zorunluluk bildiren cümleleri (“must”, “never”, “-malıdır”, “asla” gibi) neyin hata sayılacağını belirleyen kurallar olarak kullanıyor.

Değişikliği okumak. Cursor’ın rehberi nedenini kısaca söylüyor: yapay zekânın yazdığı kod doğru görünüp ince bir yerde yanlış olabilir ve ajan ne kadar hızlı çalışırsa inceleme o kadar önemli hâle geliyor. Claude Code’un rehberi incelemeyi yeni bir bağlamda yaptırmayı öneriyor: yalnızca diff’i ve kriterleri gören bir alt ajan, değişikliği yazan oturumun gerekçelerinden etkilenmiyor. Alt ajanın nasıl çalıştığını alt ajan yazısında, insanın neye bakması gerektiğini yapay zekânın yazdığı kodu inceleme yazısında anlattık.

Paralel işler. Aynı klasörde çalışan iki ajan birbirinin dosyasını değiştirebilir. Codex’in rehberi aynı dosyalarda worktree’siz paralel görev çalıştırmayı hata sayıyor; Claude Code, Cursor ve Copilot da her oturumu ayrı bir worktree’de ya da klasörde çalıştırmayı öneriyor. Worktree’nin neyi ayırıp neyi ayırmadığını git worktree yazısında anlattık.

Temiz oturum. Konuşma uzadıkça bağlam ilgisiz ayrıntıyla doluyor ve ajanın performansı düşüyor. Claude Code’un rehberi, aynı konuda iki kez düzelttiğiniz hâlde ajan hâlâ yanlış yapıyorsa oturumu temizleyip öğrendiklerinizi içeren daha iyi bir prompt’la baştan başlamanızı öneriyor. Uzun bir işte özetlemenin neyi kaybettirdiğini auto compact yazısında anlattık.

Rehberler nerede ayrılıyor?

Rehberler her konuda aynı şeyi söylemiyor. Ayrıldıkları dört yer var; hangisinin size uyduğu işinize bağlı.

• Başta ne kadar ayrıntı vermeli? Codex her prompt’ta dört şey istiyor: amaç, bağlam, kısıtlar ve işin ne zaman bitmiş sayılacağı. Copilot’un bulut ajanı rehberi net bir tanım, eksiksiz kabul kriterleri ve hangi dosyaların değişeceğini yazmanızı istiyor, ama dosya yolunu yazmasanız da ajanın çoğu zaman doğru kodu bulabildiğini ekliyor. Claude Code da dosyaları, kısıtları ve örnek kalıpları belirtmenizi istiyor. Cursor ise dosyayı biliyorsanız etiketlemenizi, bilmiyorsanız ajana bırakmanızı söylüyor; ilgisiz dosyalar ajanın kafasını karıştırabiliyor.
• İnceleme bulgularının hepsini düzeltmeli mi? Claude Code’un rehberi uyarıyor: eksik bulması istenen bir inceleyici, iş sağlam olsa bile genellikle bir şey bulur. Her bulguyu kovalamak gereksiz katmanlara, savunmacı koda ve olamayacak durumlar için testlere götürür. Rehber, inceleyiciye yalnızca doğruluğu ve istenen şartları etkileyen eksikleri yazdırmayı öneriyor. Cursor’ın ve Copilot’un rehberleri inceleme araçlarını bu uyarı olmadan anlatıyor.
• Ne zaman otomatikleştirmeli? Codex’in rehberi elle güvenilir çalışmayan bir işi zamanlamayı hata sayıyor: önce skill’e çevirin, iş öngörülebilir olunca zamanlayın. Bu sonbaharın yenilikleri ise zamanlamayı kolaylaştırıyor; Copilot’un otomasyonları ve Cursor’ın Projects özelliği işleri siz istemeden çalıştırabiliyor. Bunları açmadan önce Codex’in sorusunu sorun: bu iş elle güvenilir çalışıyor mu?
• Hangi işi ajana vermemeli? Bunu açıkça yazan tek rehber Copilot’unki. Ajana vermek yerine kendiniz yapmak isteyebileceğiniz işleri sayıyor: üretimdeki kritik sorunlar; güvenlik, kişisel veri ya da kimlik doğrulama içeren işler; tanımı belirsiz işler ve kendiniz öğrenmek istediğiniz konular. Öteki dört rehberde böyle bir liste yok.

Vibe coding’in tuzakları neler?

İki rehber yaygın hataları ayrıca listeliyor: Claude Code’unkinde 5, Codex’inkinde 8 madde var. İki listenin kesiştiği yerler şunlar: her işi tek bir uzun oturumda yürütmek, ajana işini kontrol edecek bir yol vermemek ve kuralları yanlış yere koymak (Claude Code’a göre CLAUDE.md’yi şişirmek, Codex’e göre kalıcı kuralları her prompt’a yazmak). Claude Code’un listesindeki bir cümle bu yazının özeti gibi: doğrulayamıyorsanız yayımlamayın.

Aşağıdaki beş tuzağa biz kendi depomuzda kodlama ajanlarıyla çalışırken düştük; her birinden sonra depomuzun kural dosyasına bir kural yazdık. Hepsi tek bir depodan, yani bir istatistik değil; ama her birinin arkasında yaşanmış bir hata var. Ajan “bitti” dediğinde sorduğumuz sorular:

• Yerelde geçen test CI’da da geçti mi? Bizde yerel ortam CI’dan birkaç yerde ayrılıyordu: yerelde okunan bir .env dosyası, paketin CI’da farklı kurulması ve yalnızca CI’da çalışan bir kontrol. Ortam değişkenlerini silmek .env dosyasını okunmaz yapmıyordu; eksik bir kurulum seçeneği de doğru bir branch’i kırmızı gösterip yanlış teşhise yol açtı. Kuralımız artık şu: yerel sonuç CI sonucu diye raporlanmaz, CI hatası .env’siz temiz bir klonda yeniden üretilir ve push’tan sonra CI’ın kendisine bakılır.
• Boş sonuç, adım çalıştığı için mi boş? Kayıtlarımızdan birinde temiz bir çalışma ile adımlarının bir kısmı başarısız olmuş bir çalışma birebir aynı görünüyordu; ikisi de boş bir bulgu listesi bırakıyordu. Artık kayıt, adımların çalışıp çalışmadığını ve kaç sonuç ürettiğini de tutuyor; boş bir sonuçla ölü bir adım kayda bakınca ayrılıyor. Ajanın yazdığı kodda hatayı yakalayıp boş liste döndüren bir satır görürseniz aynı soruyu sorun.
• Olmayan değer 0 mı okundu? Raporlarımızdan biri hiç ölçülmemiş bir değeri 0 okudu ve gerçekten yapılmış bir işin yanına “%100 tasarruf” yazdı; aynı hata bir kontrolü de sessizce devre dışı bıraktı. Ölçülmemiş değer None kalmalı ve anahtarın varlığına bakılarak okunmalı:

# Örnek: ölçülmemiş bir değer 0 değil, None olmalı
seconds = record.get("seconds") or 0   # yanlış: anahtar yoksa 0 olur
seconds = record["seconds"] if "seconds" in record else None   # doğru

or 0, olmayan anahtarı da None’ı da sıfıra çeviriyor. O sıfır sonra bir ortalamaya ya da bir eşiğe giriyor ve ölçülmemiş işi bedava ya da başarılı gösteriyor.

• .env ekrana yazıldı mı? Bir keresinde .env dosyasını sed ile maskeleyerek yazdırdık. Her satır KEY=value biçiminde olmadığı için maske bir satırı atladı ve o satırdaki anahtar maskelenmeden göründü. Artık bir anahtarın var olup olmadığını dosyaya değil, ortama soruyoruz; dosyanın içeriği maskeli de olsa yazdırılmıyor. Ajanın gizli dosyaları okumasını hangi aracın baştan engellediğini sandbox yazısında anlattık.
• Gösterilen yol, adres ya da paket gerçekten var mı? Ölçüm notlarımızdan biri, hiçbir branch’te olmayan bir klasörü kaynak gösteriyordu. Kısaltılmış dosya adlarını tamamlayan bir taslakta da tamamlanan adların çoğu yanlıştı. Artık kaynak satırındaki her yol, diskte var mı diye bir araçla kontrol ediliyor; bu blogu yazan araç da açılamayan bir kaynak yolunu reddediyor. Ajanın önerdiği paketleri neden ayrıca kontrol etmeniz gerektiğini inceleme yazısında anlattık.

Beşinin ortak noktası, “bitti” ile “bitmiş görünüyor” arasındaki fark. Claude Code’un rehberindeki öneri burada da geçerli: ajandan başarıyı söylemesini değil, kanıtını isteyin; çalıştırdığı komutu ve dönen çıktıyı.

Hangi işe hangi alışkanlık gerekir?

Her işe her alışkanlık gerekmiyor. Tek cümlelik bir düzeltmede planı atlayabilirsiniz; kullanıcı verisine dokunan kodda ise okumayı atlayamazsınız. Kabaca dört durum var:

Her durumun ayrıntısı ve birkaç özel durum daha:

• Yalnızca sizin kullandığınız bir araç ya da prototip. Willison’ın dediği gibi hatası yalnızca size dokunuyorsa vibe coding’in sakıncası yok. Yine de sık sık commit edin ki geri dönebilesiniz; anahtarları koda değil ortama koyun.
• Gerçek bir depoda küçük bir düzeltme. Planı atlayın ama kontrolü atlamayın; diff kısa olduğu için okuması da kısa sürer. Bir hatayı düzeltiyorsanız Claude Code’un rehberindeki sırayı izleyin: önce hatayı yeniden üreten ve başarısız olan bir test, sonra düzeltme.
• Çok dosyalı bir özellik ya da tanımadığınız kod. Önce plan, büyük işte spec; testleri koddan önce yazdırın ve değişikliği yeni bir bağlamda inceletin. Uzun ve belirsiz işlerde üst kademe modelin ve daha yüksek effort’un ne zaman fark yarattığını model seçimi ve effort yazılarında anlattık.
• Gözetimsiz koşu ve paralel ajanlar. Auto mode’da, bulut ajanında ya da zamanlanmış bir işte soracak kimse yok. Kontrolü bir hook’a ya da CI’a koyun, izinleri dar tutun, sandbox’ı açın, her ajana ayrı bir worktree verin ve sonunda iddia değil kanıt isteyin. İzinleri ve sandbox’ı auto mode ve sandbox yazısında anlattık.
• Kullanıcı verisi, giriş, ödeme ve sırlar. Güvenlik şartlarını prompt’a açıkça yazın; Andročec’in çalışmasında yalnızca bunu eklemek her uygulamada bulguları azalttı. Ama en ciddi bulguyu yine elle yapılan test yakaladı: bu kodu bir insan okusun.
• Vibe coding’le yazılmış bir uygulamayı herkese açmadan önce. Deng ve arkadaşlarının bulduğu açıklar en çok yetki kontrolünde ve kimlik doğrulamada. Bir kullanıcının başkasının verisini görüp göremediğini ve giriş yapmadan korunan bir sayfaya ulaşılıp ulaşılamadığını kendiniz deneyin.
• Tanımadığınız bir depo. Ajanla açmadan önce depoda kendiliğinden çalışabilecek dosyalara bakın; hangileri olduğunu workspace trust yazısında anlattık.