Vibe coding hizmeti: yapay zekâ hızında, mühendis denetiminde.

Bu rehberi, bir iç aracı, bir entegrasyonu, bir açılış sayfasını ya da ilk ürün sürümünü (MVP) yapay zekâ kod ajanlarıyla hızlı çıkarmak isteyen pazarlama, ürün ve KOBİ ekipleri için yazdık. Anlattığımız mekanizmalar Anthropic, OpenAI ve GitHub’ın kod ajanı belgelerine, güvenlik tarafında ise OWASP, NIST ve Google’ın İngilizce kaynaklarına dayanıyor; kaynaklar sayfanın altında numaralı olarak listeleniyor. Ürün adlarını ve varsayılan ayarları Eylül 2026 itibarıyla kaynaktan doğruladık. Kendi saha gözlemlerimizi “Uzman notu” başlığıyla ayrı işaretledik.

markention.com’un WordPress teması, yönetim paneli ve AI görünürlük analizi aracı da yapay zekâ kod ajanlarıyla, mühendis denetiminde geliştirildi. Bu yüzden aşağıda hızın nereden geldiğini anlattığımız kadar, nerede durması gerektiğini de anlatıyoruz: kapsam, ajan ile mühendis arasındaki döngü, güvenlik ve test, izinler, lisans ve bakım.

Vibe coding nedir, terim nereden geliyor?

Vibe coding, yazılımın doğal dille tarif edilip kodun büyük ölçüde yapay zekâya yazdırıldığı geliştirme biçimidir; terimi Andrej Karpathy Şubat 2025’te X’te paylaştığı bir gönderide kullandı.¹ Karpathy bu biçimi, kodun var olduğunu unuttuğu, hata mesajlarını yorumsuz modele yapıştırdığı ve kodun kendi kavrayışının ötesine büyümesine izin verdiği bir çalışma olarak anlattı; kendi değerlendirmesiyle bu yol, hafta sonu yapılıp bırakılacak projeler için fena değildi.¹

Terim kısa sürede yayıldı ve bugün yapay zekâyla hızlı yazılım geliştirmenin genel adı gibi kullanılıyor. Biz bu hizmette tanımın hız kısmını alıyoruz, “kodun var olduğunu unutmak” kısmını almıyoruz: kodu ajan yazar, bir mühendis okur, test eder ve yayına alır.

Kod ajanı ne yapar, sohbet asistanından farkı ne?

Kod ajanı, kod tabanınızı okuyup dosyaları düzenleyen, komut ve test çalıştıran, sonucu görüp bir sonraki adımına kendisi karar veren bir yapay zekâ aracıdır; yalnız metin öneren bir sohbet asistanından farkı araç kullanabilmesidir. Anthropic, Claude Code’un bir görevde iç içe geçen üç aşamadan geçtiğini yazıyor: bağlam toplama, eylem ve sonucu doğrulama.² Bir proje klasöründe başlatılan ajan o klasördeki dosyalara, terminalde çalıştırabileceğiniz komutlara ve git durumuna erişir; kullanıcı da döngünün parçasıdır ve ajanı istediği anda durdurup yönünü değiştirebilir.²

Kullandığımız ya da müşterinin ortamına göre seçtiğimiz üç ajanın varsayılanları şöyle:

Tablodaki yüzeyleri ve varsayılanları Anthropic,²⁴ OpenAI⁵ ve GitHub belgelerinden aldık;⁶ Codex’teki sandbox (kum havuzu), ajanın yazabileceği yeri ve ağa çıkıp çıkamayacağını sınırlayan yalıtımdır. Üç aracın ortak noktası, yetkiyi kullanıcının vermesidir. Anthropic bunu açıkça söylüyor: Claude Code yalnız sizin verdiğiniz izinlere sahiptir ve önerilen kodu ve komutları onaydan önce güvenlik açısından incelemek kullanıcının sorumluluğudur.⁴

Vibe coding hangi işlere uygun, hangilerine değil?

Vibe coding, gereksinimi net, etkisi sınırlı ve sonucu hızla doğrulanabilen işlerde uygundur; kişisel veri, ödeme ya da kritik iş süreci içeren kodda ajan yardımcı olur ama işi mühendislik disiplini taşır. Sınırı ajan üreticileri de yazıyor. GitHub, kendi ajanlarının uygulama kartında üretilen kodun geçerli görünüp anlamsal ya da sözdizimsel olarak doğru olmayabileceğini ve güvenlik açığı içerebileceğini belirtiyor.⁷

Bu sayfadaki karar çerçevesi de aynı mantıkla çalışır: kritiklik, kişisel ya da ödeme verisi ve entegrasyon karmaşıklığı arttıkça denetim büyür.

Kapsam, prototip ve kabul ölçütü neden koddan önce gelir?

Çünkü ajan ona tarif edilen işi hızla yapar; tarif yanlışsa yanlış işi de aynı hızla yapar. Anthropic, ajanın doğrudan kod yazmaya geçmesinin yanlış sorunu çözen kod üretebileceğini yazıyor ve işi keşif, plan, uygulama ve kayıt (commit) aşamalarına ayırmayı öneriyor.³ Aynı belgeye göre en yararlı iş tanımı kendi kendine yeten tanımdır: ilgili dosyaları ve arayüzleri adlandırır, kapsam dışını yazar ve özelliğin çalıştığını baştan sona kanıtlayan bir doğrulama adımıyla biter.³

Kodlamaya başlamadan önce her işte şu beş başlığı netleştiriyoruz:

1. Gereksinim: amaç, kullanıcılar, dokunulacak sistemler ve beklenen çıktı tek sayfada yazılır.
2. Kapsam dışı: bu sürümde yapılmayacak olanlar açıkça listelenir; ajanın “yardımcı olmak için” eklediği işler buradan ayıklanır.
3. Tıklanabilir prototip: ekranlar önce prototipte gösterilir; akış onaylanmadan üretim koduna geçilmez.
4. Kabul ölçütü: her gereksinim “şu girdide şu sonuç” biçiminde test edilebilir cümlelere bölünür ve bunlar otomatik teste çevrilir.
5. Risk sınıfı: kişisel veri, ödeme, yetki ve dış sistemlere yazma içeren parçalar işaretlenir.

Ajan ve mühendis döngüsü nasıl işler?

Döngüde ajan kodu yazar ve kendi kontrolünü çalıştırır; mühendis kontrolün doğru kurulduğunu, sonucun gerçekten işe yaradığını ve kodun okunabilir olduğunu denetler. Anthropic bunun nedenini açık yazıyor: ajan iş bitmiş göründüğünde durur ve çalıştırabileceği bir kontrol yoksa elindeki tek sinyal “bitmiş görünmesi”dir; bu yüzden ona test paketi, derleme sonucu ya da karşılaştırılacak bir ekran görüntüsü gibi geçti ya da kaldı diyen bir kontrol verilmelidir.³ Aynı belge, ajandan başarı iddiası yerine test çıktısı gibi kanıt istemeyi öneriyor.³

Belgenin “güven, sonra doğrula” boşluğu dediği hata tam da vibe coding’in riskidir: ajan akla yatkın görünen ama uç durumları karşılamayan bir uygulama üretir. Anthropic’in önerisi kısa: doğrulayamıyorsanız yayına almayın.³ İncelemeyi de yazan oturumdan ayırıyoruz; temiz bağlamla açılan bir inceleme oturumu, az önce yazdığı koda karşı önyargılı olmadığı için daha iyi inceleme yapar.³ Uzun oturumlarda bir sınır daha var: bağlam penceresi doldukça modelin performansı düşer ve ajan erken verilen talimatları unutmaya başlayabilir.³ Kalıcı kuralları bu yüzden projenin talimat dosyasına yazıyoruz; Claude Code, depoda başka ajanlar için yazılmış bir AGENTS.md dosyası varsa onu da okuyabiliyor.²

Yapay zekâ ile üretilen kod hangi riskleri taşır?

Başlıca riskler dört tanedir: doğru görünen ama yanlış çalışan kod, güvenlik açığı, olmayan ya da güvensiz bir kütüphaneye bağımlılık ve üretilen koda fazla güvenmek. GitHub, Copilot’un ürettiği kodun güvenlik açığı ya da başka sorunlar içerebileceğini ve her zaman dikkatle incelenip test edilmesi gerektiğini yazıyor.⁷ OWASP’ın büyük dil modeli uygulamaları için hazırladığı listede, modelin güvensiz ya da hiç var olmayan kod kütüphaneleri önerebileceği ve bunların yazılıma eklendiğinde açık yaratabileceği ayrıca anılıyor.¹⁰

Aynı OWASP belgesi aşırı güveni (overreliance) kullanıcıların modelin ürettiği içeriğe doğruluğunu denetlemeden fazla güvenmesi olarak tanımlıyor; önerisi, kritik işlerde insan denetimi ve doğrulama süreci kurmak ve inceleyenleri aşırı güvene karşı eğitmek.¹⁰ Web uygulamalarında nereye bakılacağını ise OWASP Top 10:2025 listesi gösteriyor. Liste bozuk erişim denetimiyle (Broken Access Control) başlıyor; güvenlik yanlış yapılandırması, yazılım tedarik zinciri hataları, enjeksiyon ve beklenmeyen durumların yanlış ele alınması (Mishandling of Exceptional Conditions) da on başlık arasında.⁹

Güvenlik ve test kontrol listesinde neler var?

Kontrol listemiz NIST’in Güvenli Yazılım Geliştirme Çerçevesi’ne (SSDF, SP 800-218) dayanır: kod okunur, çalışan kod test edilir, dış bileşenler doğrulanır ve koda erişim sınırlandırılır. SSDF uygulamaları dört grupta toplar: kuruluşu hazırlamak, yazılımı korumak, iyi korunmuş yazılım üretmek ve açıklara yanıt vermek.¹¹ Çerçeve, insanın koda doğrudan baktığı kod incelemesini ve araçlarla yapılan kod analizini ayrı ayrı tanımlar; çalışan kodun testini, üçüncü taraf bileşenlerin gereksinimlere uygunluğunun doğrulanmasını ve kodun en az yetki ilkesiyle saklanmasını da ayrı uygulamalar olarak sayar.¹¹

• Gizli anahtarlar: API anahtarı, parola ve belirteç (token) kodda, depoda ya da tarayıcıya giden dosyalarda bulunmaz.
• Erişim denetimi: her uç noktada yetki sunucu tarafında kontrol edilir; bir düğmenin arayüzde gizlenmesi yetki kontrolü sayılmaz.
• Girdi doğrulama: girdiler doğrulanır, sorgular parametreli yazılır, çıktılar kaçışlanır.
• Bağımlılıklar: eklenen paketlerin varlığı, bakımı, sürümü ve bilinen açıkları kontrol edilir.
• Hata yönetimi: beklenmeyen durumlar ele alınır; hata mesajları kullanıcıya iç sistem bilgisi göstermez.
• Kötüye kullanım sınırı: herkese açık form ve API uçlarına istek sınırı ve bot koruması, yayından önce konur.
• Testler: kabul ölçütleri, uç durumlar ve daha önce düzeltilen hatalar otomatik testte tutulur.
• Günlük kaydı: yetki ve dış servis hataları kayda geçer, uyarıya bağlanır.

Ajanın izinleri ve istem enjeksiyonu nasıl yönetilir?

Ajana işin gerektirdiği en dar yetkiyi veriyor, dışarıdan gelen metni talimat değil veri sayıyoruz. Prompt injection (istem enjeksiyonu), bir saldırganın araya kötü amaçlı metin ekleyerek yapay zekâ asistanının talimatlarını geçersiz kılmaya ya da yönlendirmeye çalıştığı tekniktir.⁴ Anthropic bu risk için önerilen komutları onaydan önce okumayı, güvenilmeyen içeriği ajana doğrudan aktarmamayı ve dış servislerle çalışırken sanal makine kullanmayı öneriyor; hiçbir sistemin bütün saldırılara karşı tamamen bağışık olmadığını da ekliyor.⁴

OpenAI, Codex için iki ayarı birbirinden ayırıyor: sandbox modu ajanın teknik olarak neyi yapabileceğini, örneğin nereye yazabileceğini ve ağa çıkıp çıkamayacağını belirler; onay politikası ise ajanın bir işlemden önce ne zaman size sormak zorunda olduğunu belirler.⁵ Aynı belge ağ erişimini ya da web aramasını açarken dikkatli olunmasını istiyor, çünkü istem enjeksiyonu ajanın güvenilmeyen talimatları getirip uygulamasına yol açabilir.⁵ GitHub da Copilot cloud agent’ın internet erişimini kısıtlıyor, girdideki gizli karakterleri süzüyor ve çekme isteğini açtıran kişinin onu onaylamasını engelliyor; depodaki iş akışları da varsayılan olarak, yazma yetkisi olan biri kodu inceleyip onaylayana kadar çalışmıyor.⁶

Lisans, sahiplik ve bakım nasıl ele alınır?

Lisans tarafında üretilen kodun kamuya açık kodla eşleşip eşleşmediğine, sahiplikte depo ve hesapların kimin adına olduğuna, bakımda ise yayından sonra neyin izlendiğine bakıyoruz. GitHub’ın kod referansı özelliği, Copilot önerisini çevresindeki yaklaşık 150 karakterlik kodla birlikte GitHub.com’daki bütün herkese açık depoların dizinine karşı karşılaştırır; eşleşmeler genellikle önerilerin yüzde birinden azında görülür ve kayıt, eşleşen dosyaların adreslerini ve bulunduysa geçerli lisansın adını gösterir.⁸ GitHub ayrıca cloud agent’ın, “kamuya açık kodla eşleşen öneriler” politikası engellemeye ayarlı olsa bile herkese açık koda birebir ya da çok yakın kod üretebileceğini yazıyor.⁷

Teslimden önce hazır görünen uzun kod bloklarının kaynağını kontrol ediyor, üçüncü taraf kodun lisansını listeliyoruz. Depo, barındırma ve servis hesapları sizin adınıza açılır; yapay zekâ çıktısının hukuki niteliği ise hukuk danışmanınızın alanıdır.

Yayından sonrası için Google’ın SRE (site güvenilirliği mühendisliği) kitabındaki dört altın sinyali kullanıyoruz: gecikme, trafik, hata ve doluluk.¹² Kitap hatayı yalnız başarısız istekler olarak tanımlamıyor; başarılı yanıt kodu dönen ama yanlış içerik taşıyan istekleri de hata sayıyor.¹² Bir entegrasyonda istek başarılı görünüp CRM’e eksik kayıt düşebilir; bu yüzden içeriği de denetliyoruz. Açılış sayfalarında hızı da yayından sonra saha verisiyle izliyoruz; bu tarafı web sitesi hızlandırma sayfamızda anlatıyoruz.

İlk 30 gün ve doğru ortağı seçmek

İlk 30 günün işi, denetlenmiş ilk sürümü yayına almak ve bakımın nasıl süreceğini netleştirmektir. Küçük bir panel eklentisinde bu adımlar daha kısa sürer:

1. 1. hafta · Kapsam: gereksinim, kapsam dışı, kabul ölçütleri ve risk sınıfı yazılır; ekranlar tıklanabilir prototiple onaylanır.
2. 2. hafta · Geliştirme: kod ajanla, ayrı dallarda ve sınırlı izinlerle yazılır; her değişiklik teste bağlanır, ilerleme size çalışan sürümle gösterilir.
3. 3. hafta · Denetim: mühendis incelemesi, güvenlik kontrol listesi, kabul testleri ve bağımlılık kontrolü tamamlanır.
4. 4. hafta · Yayın ve devir: sürüm sizin altyapınızda yayına alınır; izleme uyarıları, sürüm notu, kurulum belgesi ve ajan talimat dosyaları teslim edilir.

Yapay zekâ ile geliştirme yapan bir ortakla görüşürken şu soruların somut yanıtını almak işe yarar: kodu kim okuyor, hangi testler otomatik çalışıyor, ajan hangi izinlerle çalışıyor ve canlı sisteme erişimi var mı, gizli anahtarlar nerede duruyor, depo ve hesaplar kimin adına, yayından sonra ne izleniyor. Bu yöntemle geliştirdiğimiz bir aracı denemek isterseniz ücretsiz AI görünürlük analizimize bakabilirsiniz.

Aklınızdaki işi birlikte kapsamlamak isterseniz aşağıdan size uygun bir görüşme günü seçebilirsiniz; ilk görüşmede işin hızlı bir prototip mi, denetimli bir sürüm mü olacağını birlikte netleştiriyoruz.