Vibe coding için kod bilmem gerekiyor mu?

Küçük, kişisel bir proje için hayır. Ama birkaç komut çalıştırabilmen, hata mesajını ajana aynen iletebilmen ve sonucu kendin denemen gerekiyor. Proje ne kadar önemliyse kodu okuyabilen birine o kadar ihtiyacın olur.

Vibe coding için en iyi araç hangisi?

Tek bir en iyisi yok. Claude Code, Codex ya da Gemini CLI gibi terminal ajanları bilgisayarında gerçek bir proje bırakır; Cursor gibi editör ajanları seni koda daha yakın tutar. Birini seç, alışkanlıklarını öğren, ikincisini ancak ikinci bir göze ihtiyaç duyduğunda ekle.

Yapay zekanın çalışan kodu bozmasını nasıl önlerim?

Küçük adımlarla ilerle, çalışan her adımdan sonra commit at ve önemli kısımlar için test iste. Bir değişiklik ters giderse ajandan kendi düzeltmesini üst üste üç kez düzeltmesini istemek yerine son commit’e dön.

Vibe coding ile yazılan yazılım canlıya alınabilir mi?

Ancak biri inceledikten sonra. Giriş, ödeme, kişisel veri, veritabanı migration’ları ve internete açık her şey, gerçek kullanıcılar dokunmadan önce kodun bir insan tarafından okunmasını, gerçek testleri ve temel bir güvenlik kontrolünü ister.

Vibe coding prompt’u ne kadar uzun olmalı?

Tek bir hedefi, kısıtları ve nasıl kontrol edeceğini söyleyecek kadar; genelde üç ile sekiz satır arası. Tüm uygulama için tek dev bir prompt, incelemesi zor bir kod yığını çıkarır.

Vibe coding nasıl yapılır? Güvenli bir iş akışı

Vibe coding yapmak için ne istediğini bir kodlama ajanına düz bir dille anlatırsın, kodu onun yazıp çalıştırmasına izin verirsin, sonucu kendin kontrol eder ve kısa mesajlarla yönlendirmeye devam edersin. Bunu güvenli yapmak ise bu döngünün etrafına biraz düzen koymak demek: kısa bir spec, küçük adımlar, testler, çalışan her adımdan sonra bir git commit’i ve yayına almadan önce bir inceleme.

Terim, Andrej Karpathy’nin Şubat 2025’te yapay zekaya kodu yazdırıp “kodun var olduğunu unutmak” üzerine attığı paylaşımdan geliyor; Collins Sözlüğü de sonra onu 2025’in yılın kelimesi seçti. Tanımı, geçmişi ve riskleri için vibe coding nedir sayfasına bakabilirsin. Bu yazı işin nasıl yapıldığıyla ilgili.

Bir bakışta iş akışı

Adım	Ne yaparsın	Ne elde edersin
1. Fikir	Tek paragraf yaz: kimin için, ne yapıyor	“Hayır” diyebileceğin bir kapsam
2. Spec	Ajandan bunu kısa bir plana çevirmesini iste	Sıralı, küçük görevler listesi
3. Küçük adımlar	Her prompt’ta tek görev	Kontrol edilebilecek kadar küçük değişiklikler
4. Testler	Önemli her şey için test iste	Hâlâ çalıştığını bilmenin bir yolu
5. Commit	Çalışan her adımdan sonra `git commit`	Geri dönebileceğin güvenli bir nokta
6. İnceleme	Diff’i oku ya da başka bir modele okut	Sonradan daha az sürpriz
7. Yayın	Önizleme build’i veren bir hosta gönder	Paylaşabileceğin canlı bir link

Yazınca adımlar çok basit görünüyor. Eğlenceli bir öğleden sonrayı “bir saat önce çalışıyordu” diye geçen bir hafta sonuna çeviren şey de tam olarak onları atlamak.

1. adım: Küçük bir fikirle başla

Herhangi bir aracı açmadan önce fikri birkaç cümleyle yaz. Kullanıcıyı, uygulamanın mutlaka yapması gereken tek şeyi ve ilk sürümde neyin olmayacağını belirt.

Koşu kulübümüzün haftalık mesafeleri kaydettiği bir sayfa. Üyeler e-postayla gelen bir linkle giriş yapar, koşu ekler ve ayın sıralamasını görür. İlk sürümde ödeme, mobil uygulama ve yönetim paneli yok.

En önemlisi son cümle. Ajanlar istemediğin özellikleri de seve seve yazar; net bir “ilk sürümde yok” listesi projeyi bitirilebilecek kadar küçük tutar.

2. adım: Kısa bir spec’e çevir

Henüz uygulamayı isteme. Plan iste:

Bu fikri oku. Bir teknoloji yığını, bir klasör yapısı ve ilk sürümü kurmak için 6–10 maddelik numaralı, küçük bir görev listesi öner. Her görev tek oturumda yapılabilir ve tek başına test edilebilir olsun. Henüz kod yazma.

Planı oku ve itiraz et. Bu yığını ücretsiz barındırabilir misin? Bir görev aslında üç görev mi? Son hâlini repoya SPEC.md (ya da PLAN.md) olarak kaydet ki sonraki her oturum okuyabilsin. Birden fazla ajan kullanıyorsan komutları ve kuralları içeren kısa bir CLAUDE.md ya da AGENTS.md de işe yarar; ajanla kodlama ajan her seferinde aynı bağlamı gördüğünde en iyi sonucu verir.

3. adım: Küçük adımlarla ilerle

Şimdi 1. görevi al, sadece onu:

SPEC.md’deki 1. görevi yap: projeyi kur ve “Merhaba” yazan bir ana sayfa ekle. Çalıştır ve bana adresi söyle.

Sonra aç, kontrol et, 2. göreve geç. İyi bir ritim şu: bir görev, bir kontrol, bir commit. Bir adım birkaç yüz satırdan fazla değişiklik çıkarıyorsa muhtemelen fazla büyüktü; bir dahaki sefere ajandan bölmesini iste.

Bir şey bozulduğunda hatayı tarif etme, aynen yapıştır. “Çalışmıyor” dersen ajan tahmin eder; tam hata çıktısını verirsen genelde etmez.

4. adım: Önemli kısımlar için test iste

Yan projede %100 kapsama gerekmez. Ama sessizce bozulduğunda canını yakacak kısımlar için test gerekir: sıralama hesabı, giriş akışı, paraya ya da veriye dokunan her şey.

Aylık sıralama için test ekle: eşitlik durumu, hiç koşusu olmayan üye, ayın son günündeki koşular. Testleri çalıştır ve çıktıyı göster.

Ajandan testleri sadece yazmasını değil, çalıştırıp çıktıyı göstermesini iste. Sonra bir şey değiştirdiğinde “testleri çalıştır” tek satırlık güvenlik kontrolün olur.

5. adım: Çalışan her adımdan sonra commit at

Git, vibe coding’in geri al tuşudur. Çalışan her adımdan sonra:

git add -A
git commit -m "Testleriyle aylık sıralama eklendi"

Ya da ajana “Bunu kısa bir mesajla commit’le” de yeter. Sonraki bir değişiklik ters giderse git diff neyin değiştiğini gösterir, git restore . (ya da son commit’e reset) seni geri götürür. Bu, ajandan kendi düzeltmesini dördüncü kez düzeltmesini istemekten çok daha iyi; o yol genelde yamanın üstüne yama demek.

6. adım: Yayına almadan önce incele

Vibe coding, inşa ederken her satırı okumadığın için işe yarar. Yayına almadan önce ise birinin okuması gerekir. En azından:

Son yayından bu yana olan her şeyin diff’ine göz at.
İkinci bir ajana ya da modele, ilk ajanın sohbet geçmişi olmadan, hata ve güvenlik sorunları için inceletme. Taze bir göz, yazanın kaçırdığını yakalar.
Uygulamayı telefonda ve bilgisayarda kendin bir tur gez.

Yapay zeka ile kod incelemesi yazısı neye bakılacağını ve nasıl kurulacağını daha ayrıntılı anlatıyor.

7. adım: Yayına al

Vibe coding ile yazılan web projelerinin çoğu için en kolay yol, GitHub reposundan build alan bir host: statik siteler ve Next.js ya da Astro gibi framework’ler için Vercel, Netlify veya Cloudflare Pages. Bir branch’e push’la, önizleme linkini al, kontrol et, sonra yayına almak için merge’le. Gizli anahtarları reponun içinde değil, hostun ortam değişkeni ayarlarında tut.

Araç seçimi

Tür	Örnekler	Ne için iyi
Terminal ajanları	Claude Code, Codex, Gemini CLI	Bilgisayarında tam projeler, komut çalıştırma, gerçek repolar
Editör ajanları	Cursor	Yapay zeka düzenlerken koda yakın kalmak
Tarayıcıdaki uygulama oluşturucular	Çeşitli barındırmalı servisler	Barındırması hazır, hızlı bir demo

Terminal ve editör ajanları sana ait normal bir kod reposu bırakır; barındırmalı oluşturucular daha hızlı başlar ama kodu kendi platformlarında tutar. Emin değilsen tek bir terminal ajanıyla, örneğin Claude Code ile başla ve başka araçlara geçmeden önce küçük bir projeyi baştan sona onunla bitir.

İşe yarayan prompt’lar

İyi vibe coding prompt’larının ortak bir kalıbı var: tek hedef, kısıtlar ve nasıl kontrol edileceği.

Bunun yerine	Bunu dene
“Bana alışkanlık takip uygulaması yap”	“SPEC.md’deki 3. görevi yap: alışkanlık ekleme formu. Adın boş olmadığını doğrula. Bitince testleri çalıştır.”
“Bozuldu, düzelt”	“Kaydet’e basınca şu hata çıkıyor: (yapıştır). Kodu değiştirmeden önce nedenini bul, sonra düzeltmeyi iki cümleyle açıkla.”
“Daha güzel yap”	“Bu ekran görüntüsündeki boşluklara ve yazı boyutlarına uy. Mobildeki düzeni değiştirme.”
“Giriş ekle”	“SPEC.md’deki kimlik doğrulama kütüphanesiyle e-posta linkli giriş ekle. Şifre saklama. Değiştirdiğin bütün dosyaları listele.”

Tekrar tekrar kullanmaya değer üç kalıp:

“Henüz kod yazma.” Planlar ve araştırmalar için.
“Çalıştır ve çıktıyı göster.” İddia değil, kanıt görmek için.
“Değiştirdiğin dosyaları listele.” Diff’te sürpriz olmasın diye.

Ne zaman durmalı?

Vibe coding prototipler, iç araçlar ve kişisel projeler için harika. Ama iş şunlara dokunuyorsa yavaşla ve kodu kendin oku ya da okuyabilen birini bul:

Giriş ve yetkiler. Atlanan tek bir kontrol herkesin verisini açığa çıkarır.
Ödemeler. Webhook’lar, iadeler ve uç durumlar gerçek test ister.
Kişisel veriler. KVKK, kodu kimin yazdığıyla ilgilenmez.
Veritabanı migration’ları. Canlıda bir DROP ya da WHERE’siz bir UPDATE kolay geri alınmaz.
Gerçek kullanıcısı olan, herkese açık her şey. Hız sınırları, girdi doğrulama, gizli anahtar yönetimi.

Bir sinyal daha: Ajandan aynı hatayı üç kez düzeltmesini istedin ve hata geri gelmeye devam ediyorsa dur. Son sağlam commit’e dön, sorunu sıfırdan anlat ya da kodun o kısmını kendin oku.

Bir şey yap

Bu rehberlerin her biri aynı iş akışını somut bir proje üzerinde izliyor:

AgentVera ile

Yukarıdakilerin hepsi tek bir terminal ve git ile yapılır. AgentVera, kodlama ajanlarını (Claude Code, Codex, Gemini CLI ve diğerleri, kendi hesaplarınla) gerçek terminallerde yan yana çalıştırır ve aynı döngünün etrafına birkaç güvenlik ağı ekler:

Tur bazında geri alma. Turlar ve oturum tekrarı, her turun başında çalışma klasörünün anlık görüntüsünü alır; panelin menüsünden tek bir turu geri alabilir, geri almayı da geri alabilirsin. Git reset’ten daha hızlı bir geri adım ama commit’lerin yerini tutmaz.
Otomatik inceleme. Proje ayarlarından otomatik kod incelemesini açtığında, tur bitince seçtiğin bir Claude modeli değişiklikleri okur ve bulguları önem derecesi ve dosya:satır linkleriyle raporlar; bunları ajana geri gönderebilirsin.
İstediğine göre kontrol. AgentVera Verify (Pro ve Team) mesajından kabul kriterlerini çıkarır; tur bitince ayrı bir doğrulayıcı testleri çalıştırır ve her kriteri kanıtıyla geçti ya da kaldı olarak işaretler.
Migration kontrolü. DB Guard, tur sonunda yeni migration’ları DROP ya da WHERE’siz UPDATE gibi riskli ifadeler için tarar.
Önizlemeler. Önizleme ortamları her branch’e kendi yerel adresini verir ve mobil, tablet ve masaüstü ekran görüntüleri alabilir.
Onay için tek yer. İnceleme kutusu tüm ajanların biten işlerini toplar; onaylayabilir ya da bir notla geri gönderebilirsin.

Kontrol listesi

Fikir bir paragrafa sığıyor ve bir “ilk sürümde yok” listesi var.
Repoda numaralı görevler içeren kısa bir SPEC.md var.
Her prompt’ta tek görev; her biri bir sonrakinden önce kontrol ediliyor.
Bozulursa canını yakacak kısımların testleri var.
Çalışan her adımdan sonra commit atılıyor.
Yayından önce diff incelendi; tercihen taze bir model ve bir insan tarafından.
Gizli anahtarlar repoda değil, ortam değişkenlerinde.
Giriş, ödeme, kişisel veri ve migration’lar dikkatle bir insan tarafından okundu.

Toparlarsak

Vibe coding artık yazılım yapmanın gerçek bir yolu, şakası değil. Saklayabileceğin bir prototiple çöpe atacağın bir prototip arasındaki fark nadiren modeldir; asıl fark küçük adımlarla ilerleyip ilerlemediğin, sık commit atıp atmadığın, önemli olanı test edip etmediğin ve yayından önce inceleyip incelemediğindir. Akışa bırakmayı inşa ederken yap, disiplini kenarlarda koru.