Vibe coding ile yapılan uygulama üretime hazır mı? 15 maddelik denetim

Vibe coding nedir?

Vibe coding, kodu satır satır yazmak yerine ne istediğinizi doğal dille anlatıp yapay zekanın ürettiği kodu çoğu zaman okumadan kabul etme biçimidir. Terimi 2 Şubat 2025'te Andrej Karpathy bir X gönderisiyle yaydı (Wikipedia); Collins Sözlüğü onu 2025 yılının sözcüğü seçti (Collins). Bu yazı terimin tanımına ya da araçlarına ayrılmadı. Tek bir soruya ayrıldı: ekranda çalışan bir prototip, gerçek kullanıcıya açılmaya hazır mı?

Vibe coding riskleri: prototip ile üretim arasındaki fark

Prototip bir fikri göstermek içindir; üretim ise gerçek insanların gerçek veriyle kullandığı ve hatanın gerçek bir bedeli olduğu ortamdır. Yapay zeka, fikirden çalışan bir ekrana giden yolu çok kısalttı; o ekranı üretime taşımak ise hâlâ mühendislik işi. Prototipten üretime geçerken neyin değiştiğini aşağıdaki tablo özetliyor.

Bu soru yeni değil. Google'ın SRE kitabındaki yayın öncesi kontrol listesi (Ek E) mimari, kapasite, yedek ve felaket kurtarma, izleme ve güvenlik gibi başlıkları tarar. Aşağıdaki liste aynı alanları, yapay zekayla üretilmiş küçük bir uygulamanın tipik zayıf noktalarına göre sıralıyor.

15 maddelik üretime hazırlık denetimi

Her madde aynı dört satırdan oluşur: neden önemli, nasıl kontrol edilir, geçti ölçütü ve düzeltme yükü. Düzeltme yükü göreli bir etikettir, süre ya da fiyat değildir: S tek bir ayar ya da küçük bir değişiklik; M birkaç dosya ya da ekranı etkiler ve test gerektirir; L yapıyı, örneğin veri modelini ya da yetki mantığını, yeniden düzenlemek demektir. Bir madde geçti ölçütünü karşılamıyorsa o madde kaldı (geçemedi) sayılır; yazının geri kalanında bu iki sözcük bu anlamda kullanılıyor.

Denetimin dayandığı ilke, mühendislik notlarımızda anlattığımız Eylem Değil Öneri yazısındakiyle aynı: yapay zekanın ürettiğine güvenmek yerine, kontrolü onun dışında, sistemde kurmak. Komutlar bir macOS ya da Linux terminalinde çalıştırılacak biçimde yazıldı (Windows'ta WSL ya da Git Bash kullanabilirsiniz); kendi uygulamanızın yapısına göre dosya adlarını uyarlayın.

1. Sırlar: API anahtarı, .env ve istemci paketine sızma

Neden önemli. Yapay zeka araçları örnek kodda anahtarı doğrudan dosyaya yazabilir; dosya depoya, oradan herkese açık bir pakete ya da tarayıcıya gider. Tarayıcıya giden her değeri herkes görebilir: Vite'ta VITE_ önekli değişkenler (belge), Next.js'te NEXT_PUBLIC_ önekli değişkenler (belge) derleme sırasında istemci paketine gömülür; Vite belgesi bu değişkenlerde API anahtarı tutulmamasını söylüyor.

Nasıl kontrol edilir. Depo geçmişinde: git log --all --oneline -S"sk_live_" ve git log --all --oneline -G"sk_(live|test)_[0-9A-Za-z]+" (anahtarın eklendiği ya da silindiği işlemleri listeler; çıkan işlemi git show ile açın). Çok büyük depolarda ya da başka anahtar türleri için gitleaks ya da trufflehog gibi bir sır tarayıcısı da kullanılabilir. Derlenmiş pakette: grep -rEn "sk_(live|test)_|AKIA[0-9A-Z]{16}|eyJ[A-Za-z0-9_-]{10,}\.eyJ" dist/ .next/static/. eyJ ile başlayan uzun diziler JWT'dir (Supabase anahtarları gibi); ortadaki bölümü base64 olarak çözün: "role":"service_role" yazıyorsa tam yetkili anahtar pakettedir, anon ise tarayıcıda bulunması beklenir ve güvenliği madde 3'e bağlıdır. Tarayıcıda Geliştirici Araçları'nın Ağ sekmesinde isteklere bakın.

Geçti ölçütü. Geçmişte ve pakette canlı anahtar yok. Bir kez bile açığa çıkmış her anahtar iptal edilip yenilendi: OWASP, açığa çıkan anahtarların hemen iptal edilmesini söyler (OWASP). Yalnızca dosyadan silmek yetmez; anahtar depo geçmişinde durmaya devam eder.

Düzeltme yükü. S (anahtarı değiştirmek).

2. Kimlik doğrulama ve oturum

Neden önemli. Yapay zeka çoğunlukla çalışan bir giriş ekranı üretir; ama çalışmak güvenli olmak demek değildir. Parola nasıl saklanıyor, oturum nasıl taşınıyor, parola sıfırlama bağlantısı ikinci kez kullanılabiliyor mu? OWASP Top 10:2025'te "Authentication Failures" ayrı bir kategori (A07).

Nasıl kontrol edilir. Mümkünse hazır bir kimlik servisi ya da olgun bir kütüphane kullanıldığını doğrulayın. Kendi yazılmışsa parolaların düz metin değil, yavaş bir özet algoritmasıyla (argon2, bcrypt gibi) saklandığına veritabanında bakın. Oturum belirtecinin nerede durduğuna bakın: Geliştirici Araçları > Uygulama bölümünde hem Çerezler'i hem Yerel Depolama'yı (localStorage) açın. Çerezdeyse HttpOnly, Secure, SameSite işaretlerine bakın. OWASP, oturum tanımlayıcılarının localStorage'da tutulmamasını söyler, çünkü o veriye JavaScript her zaman erişebilir; çerezler HttpOnly işaretiyle bu riski azaltır (OWASP). Bazı hazır kimlik servislerinin istemci kütüphaneleri oturumu tarayıcı depolamasına yazabilir (örneğin Supabase istemcisinde persistSession seçeneği açıkken oturum local storage'a kaydedilir, belge); belirteç oradaysa onu betik enjeksiyonundan korumak madde 4'ün işidir. Sıfırlama bağlantısını iki kez kullanmayı sınayın. Giriş ucuna art arda yanlış parola gönderin.

Geçti ölçütü. Parolalar özetlenmiş; oturum belirteci HttpOnly ve Secure bir çerezde (belirteç localStorage'daysa bunun gerekçesi yazılı ve madde 4 geçti); sıfırlama bağlantısı tek kullanımlık ve süreli; yanlış denemeler sınırlı.

Düzeltme yükü. S–M (hazır bir kimlik servisine geçmek M).

3. Yetkilendirme: nesne düzeyi

Neden önemli. Giriş yapmış olmak her kayda erişebilmek demek değildir. OWASP Top 10:2025'in ilk sırasında "Broken Access Control" var; API tarafında karşılığı "Broken Object Level Authorization" (API1:2023). Yapay zeka çoğunlukla "kullanıcı giriş yaptı mı" kontrolünü koyar, "bu kayıt bu kullanıcının mı" kontrolünü atlayabilir.

Nasıl kontrol edilir. İki hesapla sınayın: A hesabıyla bir kaydı açın, ağ isteğindeki kimliği (/api/orders/123) B hesabına ait bir kaydın kimliğiyle değiştirip isteği yeniden gönderin. Yönetim uçlarını normal kullanıcı oturumuyla çağırın. Tarayıcıdan doğrudan veritabanına konuşan servislerde (Supabase gibi) satır düzeyi güvenliğin (RLS) açık olup olmadığına bakın: select schemaname, tablename, rowsecurity from pg_tables where schemaname = 'public'; ve select * from pg_policies;. Supabase belgesine göre güvenliği kapalı bir tablo, yetkisi olan her rol tarafından okunup yazılabilir. Aynı belgeye göre tabloyu açan bir görünüm (view) de varsayılan olarak RLS'yi atlar; Postgres 15 ve üzerinde security_invoker = true ayarı görünümü alttaki tabloların ilkelerine uydurur (belge). Görünümleri select schemaname, viewname from pg_views where schemaname = 'public'; ile listeleyin.

Geçti ölçütü. B'nin verisi A'ya hiçbir yoldan dönmüyor (403 ya da 404); yönetim uçları rolü sunucuda, her istekte denetliyor (OWASP); her tabloda satır düzeyi güvenlik açık ve ilke tanımlı, tabloları açan görünüm yok ya da security_invoker ile tanımlı (Supabase).

Düzeltme yükü. M; veri modelinde "kaydın sahibi" yoksa L.

4. Girdi doğrulama ve enjeksiyon

Neden önemli. Formdan, adres çubuğundan ve dosya yüklemeden gelen her değer güvenilmezdir. OWASP Top 10:2025'te Injection A05. Üretilen kod sorguyu metin birleştirerek kurabilir ya da kullanıcı metnini sayfaya HTML olarak basabilir.

Nasıl kontrol edilir. Metin birleştirilen sorguları arayın: grep -rnE '(query|execute|raw)\(.*(\+|\$\{)' src/. HTML basılan yerleri arayın: grep -rnE "dangerouslySetInnerHTML|innerHTML" src/. Formlara ' ve <img src=x onerror=alert(1)> yazıp sonucu izleyin. Yüklenen dosyanın türünün, boyutunun ve nereye yazıldığının sunucuda denetlendiğini doğrulayın.

Geçti ölçütü. Tüm veritabanı erişimi parametreli ya da güvenilir bir ORM üzerinden; kullanıcı metni HTML olarak değil düz metin olarak gösteriliyor (kaçışlanıyor); yüklemelerde tür ve boyut sınırı sunucuda uygulanıyor.

Düzeltme yükü. S–M.

5. Veritabanı: şema, kısıt, indeks, geçiş

Neden önemli. Prototipte veri modeli ilk akla gelen biçimde kurulur: kısıt yok, indeks yok, şema konsoldan elle değiştirilmiş. Üretimde veri bozulduktan sonra düzeltmek, en pahalı düzeltmedir.

Nasıl kontrol edilir. Depoda geçiş (migrasyon) dosyaları var mı ve boş bir veritabanı yalnızca onlardan kurulabiliyor mu? Yeni, boş bir veritabanı açıp uygulayın. Önemli tablolarda ilişki (foreign key), benzersizlik ve NOT NULL kısıtlarına bakın (psql'de \d tablo_adi). Sık filtrelenen sütunlarda indeks var mı? Üretim şemasını depodakiyle karşılaştırın: konsolda elle yapılmış değişiklik var mı? Örnek veri ya da test kullanıcıları üretimde kalmış mı?

Geçti ölçütü. Boş veritabanı depodaki geçişlerle kurulup uygulama açılıyor; ilişkili kayıtlar kısıtlarla korunuyor; üretim şeması depoyla aynı.

Düzeltme yükü. M; veri modeli yanlışsa L.

6. Yedek ve geri yükleme testi

Neden önemli. Geri yüklenmemiş yedek bir varsayımdır. AWS Well-Architected rehberi, yedeğin var olduğunu ve çalıştığını varsaymayı yaygın hatalar arasında sayıyor ve yedekten düzenli aralıkla veri geri yüklemeyi öneriyor (REL09-BP04).

Nasıl kontrol edilir. Yedek nerede, ne sıklıkla alınıyor, kimin hesabında? Son yedeği yeni ve boş bir veritabanına geri yükleyin; bir tabloda satır sayısına ve en son kayda bakın; geri yükleme süresini not edin. Yüklenen dosyalar (görsel, belge) ayrı bir depoda ise onların da yedeği var mı? Barındırma planınızda otomatik yedek gerçekten dahil mi?

Geçti ölçütü. Son geri yükleme denemesinin tarihi ve süresi yazılı; geri yüklenen veri eksiksiz ve okunabilir; yedek uygulamanın çalıştığı hesaptan ayrı bir yerde.

Düzeltme yükü. S–M.

7. Ortamlar ve dağıtım

Neden önemli. Prototip çoğu zaman tek ortamdır: aracın düzenleyicisinde yaptığınız değişiklik doğrudan canlıya gider ve canlı veriye dokunur. Twelve-Factor ilkesine göre yapılandırma koddan ayrı tutulur; kod, hiçbir kimlik bilgisi sızdırmadan her an açık kaynak yapılabilecek durumda olmalıdır (12factor.net).

Nasıl kontrol edilir. Geliştirme ve üretim için ayrı veritabanı ve ayrı anahtarlar var mı? Önizleme sürümleri üretim verisine bağlı mı? Dağıtım tek komutla ya da otomatik mi, yoksa elle yükleme mi? Önceki sürüme tek adımda dönülebiliyor mu? Bir kez sınayın. Alan adı, DNS kayıtları ve TLS sertifikası kimin hesabında?

Geçti ölçütü. Test amaçlı bir değişiklik üretim verisine dokunamıyor; son sürüme geri dönüş sınandı ve çalıştı; yapılandırma ortam değişkenlerinde.

Düzeltme yükü. M.

8. Hata yönetimi, log ve izleme

Neden önemli. OWASP Top 10:2025'te iki ilgili kategori var: "Security Logging and Alerting Failures" (A09) ve "Mishandling of Exceptional Conditions" (A10). Prototipte hata ya konsola düşer ya da kullanıcıya yığın izi (stack trace) olarak gösterilir. İlki sizi kör eder, ikincisi saldırgana bilgi verir.

Nasıl kontrol edilir. Bilerek bir şeyi bozun: veritabanı bağlantısını kesin, geçersiz girdi gönderin. Kullanıcı ne görüyor, siz nasıl haberdar oluyorsunuz? Bir hata izleme servisi ve çalışma süresi (uptime) kontrolü var mı, bildirim bir insana ulaşıyor mu? Log'lara parola, erişim belirteci, anahtar, veritabanı bağlantı dizesi ve kart verisi yazılmamalı (OWASP).

Geçti ölçütü. Hata kullanıcıya anlaşılır bir mesajla, size ayrıntısıyla ulaşıyor; kritik hata bir kişiye bildirim olarak düşüyor; log'larda gizli bilgi yok.

Düzeltme yükü. S–M.

9. Bağımlılıklar: kullanılmayan, uydurma, açık, lisans

Neden önemli. Yapay zeka kodu çok sayıda paket çeker; bazıları kullanılmaz, bazıları eskidir, bazıları hiç var olmayan adlardır. Kod üreten dil modellerinde "paket halüsinasyonu"nun kalıcı ve sistematik bir olgu olduğunu gösteren bir araştırma var (Spracklen ve ark., USENIX Security 2025); OWASP Top 10:2025'te "Software Supply Chain Failures" üçüncü kategori (A03).

Nasıl kontrol edilir. npm audit --omit=dev üretim bağımlılıklarını bilinen açıklara karşı tarar; çıkış kodu --audit-level ayarına bağlıdır: --audit-level=high yalnızca yüksek ve kritik açıklarda sıfırdan farklı bir kod verir (belge). Komut JavaScript ve TypeScript (npm) projeleri içindir ve varsayılan olarak bir kilit dosyası ister; Python gibi başka ekosistemlerde pip-audit gibi karşılığı olan bir araç kullanılır. Her paketin gerçekten var olduğunu, yayıncısının ve yaşının makul göründüğünü doğrulayın: npm view <paket> name version time.created maintainers. Kullanılmayanları ayıklayın. Kilit dosyası (package-lock.json) depoda mı? Ticari kullanım için lisansları gözden geçirin.

Geçti ölçütü. Üretim bağımlılıklarında yüksek ya da kritik açık yok, ya da gerekçeli istisna yazılı; her paket doğrulandı; kilit dosyası depoda.

Düzeltme yükü. S–M.

10. Testler: kritik akışlar ve anlamlı testler

Neden önemli. Yapay zeka test de yazar; ama bazen uygulamanın ne yaptığını doğrulayan, ne yapması gerektiğini doğrulamayan testler çıkar. Bir testin işe yarayıp yaramadığını anlamanın yolu, onu kırmayı denemektir.

Nasıl kontrol edilir. Kritik akışları listeleyin: kayıt, giriş, ödeme, veri yazma. Her birinin testi var mı? Bir kuralı bilerek bozun (fiyat hesabını iki katına çıkarın, yetki kontrolünü yoruma alın): hiçbir test kırılmıyorsa test işe yaramıyor demektir. Testler her değişiklikte otomatik çalışıyor mu? Testi olmayan mevcut kod için önce davranışı olduğu gibi kaydeden "karakterizasyon testleri" yazılır (Feathers).

Geçti ölçütü. Kritik akışlar için, kural bozulduğunda kırılan testler var ve her değişiklikte otomatik çalışıyor.

Düzeltme yükü. M.

11. Performans ve ölçek

Neden önemli. Prototip on kayıtla denenir. Binlerce kayıtta, sayfalama olmayan bir liste ya da her satır için ayrı sorgu çalıştıran bir ekran (N+1) kilitlenir. Sık görülen ilk darboğaz veritabanıdır.

Nasıl kontrol edilir. Yüzlerce ve binlerce kayıtlık test verisiyle liste ve arama sayfalarını açıp ölçün (tarayıcının Ağ sekmesi yeterli). Bir istekte kaç sorgu çalıştığına bakın; veritabanı sağlayıcınızın yavaş sorgu ekranı varsa orayı da açın. Liste uçlarında sayfalama var mı? Görseller boyutlandırılmış mı? Dış servis çağrılarında zaman aşımı var mı?

Geçti ölçütü. Gerçekçi veri hacminde ana ekranlar, önceden yazdığınız hedef süre içinde açılıyor; listelerde sayfalama var; dış çağrılarda zaman aşımı tanımlı.

Düzeltme yükü. M.

12. Ödeme ve hassas akışlar

Neden önemli. Ödeme sağlayıcısından gelen bildirim (webhook) eşzamansız gelir; sahte olabilir, iki kez gelebilir, sırasız gelebilir. Stripe belgesi imzanın (Stripe-Signature) doğrulanmasını, ham istek gövdesinin değiştirilmemesini, işlenen olay kimliklerinin kaydedilip tekrarların işlenmemesini ve olay sırasının garanti edilmediğini söylüyor (webhooks). Başka sağlayıcılarda da ilkeler aynıdır; ayrıntı sağlayıcının belgesindedir.

Nasıl kontrol edilir. Webhook ucuna imzasız sahte bir istek gönderin: reddedilmeli. Aynı olayı iki kez gönderin: tek sipariş oluşmalı. İstek gövdesindeki tutarı Geliştirici Araçları'ndan değiştirin: sunucu tutarı kendi hesaplamalı. Siparişin "ödendi" durumu yönlendirme sayfasından değil, doğrulanmış bildirimden mi değişiyor? Yeniden denenen oluşturma isteklerinde idempotency anahtarı kullanılıyor mu (Stripe)?

Geçti ölçütü. Sahte, tekrarlanan ya da değiştirilmiş istek kayıt oluşturmuyor; tutar sunucuda hesaplanıyor; durum yalnızca doğrulanmış bildirimle değişiyor.

Düzeltme yükü. M; ödeme akışı baştan yanlış kurulmuşsa L.

13. Kişisel veri ve KVKK

Neden önemli. Yapay zekayla üretilen bir uygulama, farkında olmadan kişisel veri toplayıp üçüncü taraf servislere (analitik, e-posta, yapay zeka sağlayıcısı) gönderebilir. 6698 sayılı Kişisel Verilerin Korunması Kanunu'nun 12. maddesi, veri sorumlusunu verilerin hukuka aykırı işlenmesini ve erişilmesini önlemek ve muhafazasını sağlamak için gerekli teknik ve idari tedbirleri almakla yükümlü kılıyor; verilerin yasa dışı yoldan ele geçirilmesinde en kısa sürede ilgilisine ve Kurula bildirim şart (mevzuat.gov.tr). Yurt dışına aktarım 9. maddede ayrıca düzenlenmiş. KVKK, Kasım 2025'te üretken yapay zekaya ilişkin bir rehber de yayımladı (KVKK).

Nasıl kontrol edilir. Bir veri envanteri çıkarın: hangi kişisel veri (ad, e-posta, telefon, konum, ödeme bilgisi), nerede duruyor, kim okuyabiliyor, hangi üçüncü taraflara gidiyor, ne kadar saklanıyor, nasıl siliniyor? İstemlere (prompt) kullanıcı verisi giriyor mu? Bir test kullanıcısını silin; veritabanında, log'larda ve yedeklerde ne kaldığına bakın. Gizlilik metniniz gerçekte yaptığınızı anlatıyor mu?

Geçti ölçütü. Her kişisel veri için yeri, erişimi, üçüncü tarafı ve silme yolu yazılı; silme talebi karşılanabiliyor; yapay zeka sağlayıcısına giden veri biliniyor. Bu madde hukuki danışmanlık değildir; hukuki değerlendirme için bir avukata danışın.

Düzeltme yükü. M–L.

14. Maliyet ve kötüye kullanım

Neden önemli. Tarayıcıdan doğrudan yapay zekayı ya da başka bir ücretli API'yi çağıran bir uygulamada her ziyaretçi sizin faturanızı büyütebilir. OWASP'ın LLM uygulamaları listesinde bunun adı "Unbounded Consumption" (LLM10:2025); API listesinde "Unrestricted Resource Consumption" (API4:2023) ve iş akışlarının otomatik kötüye kullanımını kapsayan "Unrestricted Access to Sensitive Business Flows" (API6:2023) (liste).

Nasıl kontrol edilir. Ücretli servis anahtarlarının tarayıcıya gitmediğini doğrulayın (madde 1). Kendi uygulamanızın bir ucuna art arda yüz istek gönderin ve yanıt kodlarını sayın (adresi kendi adresinizle değiştirin): for i in $(seq 100); do curl -s -o /dev/null -w "%{http_code}\n" https://example.com/api/uc; done | sort | uniq -c. Bir noktadan sonra 429 görmelisiniz. Uç ücretli bir servisi (örneğin bir yapay zeka API'sini) çağırıyorsa önce seq 10 ile sınayın ya da bir test ortamında çalıştırın: yüz istek kendi faturanızı büyütebilir, IP adresinizin engellenmesine de yol açabilir. Sağlayıcı konsolunda aylık harcama üst sınırı ve bütçe uyarısı tanımlı mı? Kayıt formunda bot koruması var mı?

Geçti ölçütü. Art arda istek kısıtlanıyor; harcama üst sınırı ve uyarısı tanımlı; ücretli anahtarlar yalnızca sunucuda.

Düzeltme yükü. S–M.

15. Sahiplik ve sürdürülebilirlik

Neden önemli. Kod bir yapay zeka platformunun içinde, hesaplar bir tanıdığın e-postasında, alan adı kişisel bir hesapta duruyorsa, bir gün erişimi kaybetmek ürünü durdurabilir. Kodu kimse okuyamıyorsa ilk ciddi hata ürünü kilitler.

Nasıl kontrol edilir. Şu listeyi doldurun: kod deposu, barındırma, alan adı ve DNS, veritabanı, e-posta ve SMS, ödeme hesabı, mağaza hesapları, yapay zeka sağlayıcı hesabı. Her birinin sahibi kim, yönetici hesabı kimde, kurumsal bir e-postaya bağlı mı? Kodu platformdan bir depoya dışa aktarabiliyor musunuz? Depoda "nasıl kurulur ve çalıştırılır" yazan bir README var mı ve temiz bir bilgisayarda izlenince çalışıyor mu?

Geçti ölçütü. Tüm hesaplar şirketin ya da ürün sahibinin adına; kod dışa aktarılmış ve bir depoda; bir mühendis, yapay zeka aracı olmadan, ilk gün projeyi çalıştırabiliyor.

Düzeltme yükü. S–L.

Mühendis değilseniz: kendiniz tarayabileceğiniz altı madde

Altı madde yanıt ya da kanıt istemeyi gerektirir, kod okumayı gerektirmez. Her soruya "evet, işte kanıtı" diyemiyorsanız o madde kalmıştır.

Karar: kırmızı, sarı, yeşil

Aşağıdaki eşikler bu yazının önerisidir, bir standart değildir. Uygulamanızda ilgili özellik yoksa (ödeme gibi) o madde "uygulanmaz" sayılır.

Kendiniz düzeltmek ve mühendis çağırmak

Bazı maddeler eğitimle ve birkaç ayarla kapanır: anahtarları değiştirmek, yedeği açıp geri yüklemeyi denemek, harcama üst sınırı koymak, hesapları kendi adınıza taşımak, kullanılmayan paketleri ayıklamak.

Bazı maddeler ise yapıya dokunur ve bir mühendisin işidir: yetki modeli, ödeme akışı, veri modeli ve geçişler, anlamlı testler, kişisel veri akışları. Kişisel veri maddesinde mühendisin yanında bir hukuk danışmanı da gerekebilir.

"Baştan mı yazalım, düzeltelim mi?" sorusunun dürüst yanıtı, hangi katmanın kaldığına bağlıdır. Kimlik, yetki ya da veri modeli yanlış kurulmuşsa o katmanı yeniden kurmak gerekir. Ekranlar, akış ve ilk kullanıcılardan aldığınız geri bildirim ise çoğu zaman prototipin gerçekten değerli kısmıdır. Eski kodu tümden atmak da, tümden korumak da bir kural değildir; yaygın iki uç görüş için bkz. Joel Spolsky ve Martin Fowler. Karar, gerekçesiyle birlikte yazılı olmalı.

Sonraki adım

Elinizde bir prototip varsa, MVP geliştirme sayfasında nereden başladığımızı anlattık: elinizdekine birlikte bakar, üzerine kurmanın mı yoksa yeniden başlamanın mı doğru olduğuna gerekçesini yazarak karar veririz. Uygulamanız size özgü iş kuralları gerektiriyorsa özel yazılım geliştirme, yapay zeka özelliği ekliyorsanız yapay zeka entegrasyonu sayfası yol gösterir; uygulama bir telefon uygulamasıysa mobil uygulama yaptırma sayfasına bakın. Hazırsanız projenizi anlatın.

Sık sorulan sorular

Vibe coding güvenli mi?

Araç tek başına güvenli ya da güvensiz değildir; güvenli olan, çıktının denetlenmesidir. Vibe coding riskleri de buradan gelir: yapay zeka çalışan bir uygulama üretebilir, ama yetki, yedek, ödeme ve kişisel veri gibi konularda sizin sormadığınız soruyu kendiliğinden sormaz. Bu yazıdaki 15 madde bu soruları sıraya koyar.

Kod yapay zekadan geldiyse sorumluluk kimde?

Bu hukuki bir sorudur; yanıt sözleşmelere (aracın kullanım koşulları, varsa geliştiriciyle yapılan sözleşme) ve olayın koşullarına bağlı olabilir. Kişisel veride, 6698 sayılı Kanun'un 12. maddesine göre gerekli tedbirleri almak veri sorumlusunun yükümlülüğüdür. Somut bir olay için bir avukata danışın.

Lovable, Bolt ya da Cursor ile yapılan uygulama canlıya alınır mı?

Alınabilir. Bu araçlar çıktı üretir; çıktının üretime hazır olup olmadığı ayrı bir sorudur ve bu yazıdaki denetim araçtan bağımsızdır. Aracın sunduğu barındırmayı kullanıyorsanız, kodu ve veriyi dışa aktarıp aktaramayacağınızı (madde 15) önceden öğrenin.

Üretime hazırlık ne kadar sürer?

Kapsama bağlıdır, bu yüzden süre vermiyoruz. Süreyi en çok hangi maddelerin kaldığı belirler: bir anahtarı değiştirmek ile yetki modelini yeniden kurmak aynı büyüklükte iş değildir. Önce denetimi yapıp maddeleri S, M ve L olarak sınıflandırmak, gerçekçi bir takvimin ilk adımıdır.

Baştan yazmak mı, düzeltmek mi?

Kaldığı katmana bağlıdır. Ekranlar ve akış genellikle korunabilir; kimlik, yetki ve veri modeli yanlış kurulmuşsa bu katmanlar yeniden kurulur. Hangisinin doğru olduğu denetimden sonra, gerekçesiyle birlikte karara bağlanmalıdır.

Kaynaklar

Aşağıdaki sayfalar 24 Ekim 2026'da açılıp okundu. Ücret, eşik ve sürüm bilgisi taşıyan sayfalar zamanla değişebilir.

• Vibe coding, Wikipedia · Collins Word of the Year 2025
• OWASP Top 10:2025 · OWASP API Security Top 10 2023 · OWASP Top 10 for LLM Applications 2025
• OWASP Cheat Sheet Serisi: Secrets Management, Authorization, HTML5 Security, Logging
• Vite: ortam değişkenleri · Next.js: ortam değişkenleri · Twelve-Factor App: Config
• Supabase: Row Level Security · Supabase: JavaScript istemcisi · Stripe: webhooks · Stripe: idempotent requests
• npm audit · Spracklen ve ark., paket halüsinasyonu (arXiv) · Feathers, karakterizasyon testi
• AWS Well-Architected REL09-BP04 · Google SRE kitabı, Ek E
• 6698 sayılı KVKK, mevzuat.gov.tr · KVKK, Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi
• Joel Spolsky, Things You Should Never Do, Part I · Martin Fowler, Strangler Fig

Bu yazı genel bilgi içindir; hukuki ya da güvenlik denetimi yerine geçmez.