Vibe Coding MVP'sini Production'a Taşıma Rehberi

Vibe coding prototipini production'a taşımak, "çalışıyor" ile "güvenilir" arasındaki farkı kapatmak demektir — ve bu fark sandığından derin. Bu rehberde bir AI-üretimi kod tabanını gerçek kullanıcıya açmadan önce hangi yedi ayrımı tanıman gerektiğini, devralma gününde neyi haritalaman gerektiğini ve modelin uydurduğu API'leri nasıl yakalayacağını adım adım göreceksin.

💡 Pro Tip: Production'a geçişte ilk 48 saat boyunca hiçbir "AI bunu zaten test etti" varsayımına güvenme — her iddiayı kendi ortamında bir kez daha çalıştırıp doğrula.

İçindekiler

• Prototip ile Ürün Arasındaki 7 Fark
• Devralma Günü: Kod Tabanını Haritalama ve Ölü Kod Ayıklama
• Uydurma API ve Dayanaksız Öncül: Modelin İddia Ettiği Yeteneği Doğrulama Refleksi
• Test Tabanını Sıfırdan Kurmak (Kritik İş Mantığı Önce)
• Gözlemlenebilirlik: Log, Hata İzleme, Health Check
• Veri Katmanı: Şema, Migration, Yedek, Geri-Alma Provası
• Maliyet ve Rate-Limit Sürprizleri (LLM Çağrıları Dahil)
• Deploy/Rollback Disiplini ve Güvenlik Kapısı
• SSS
• Vibe coding ile yapılan bir MVP production'a nasıl taşınır?
• AI ile yazılmış uygulamayı gerçek kullanıcıya açmadan önce ne yapmalıyım?
• Vibe-coded bir projeyi devralırken nereden başlanır?
• AI ile üretilmiş kod tabanına test nasıl eklenir?
• Vibe coding güvenli mi, hiç kullanmamalı mıyım?
• Sonuç
• Kaynaklar

Prototip ile Ürün Arasındaki 7 Fark

Andrej Karpathy'nin Şubat 2025'te tanımladığı vibe coding, "vibe'lara tamamen teslim olmayı" öneren bir hafta sonu projesi pratiğiydi. Ancak Simon Willison'ın uyarısı net: production kod tabanına vibe coding yaklaşımıyla girmek risklidir, çünkü mühendislik işinin büyük kısmı mevcut sistemleri anlaşılabilir şekilde evriltmekle ilgilidir — altta yatan kodun kalitesi ve anlaşılabilirliği burada kritik hale gelir.

Ekim 2025'te yayımlanan Veracode çalışması bu ayrımı sayısal olarak da doğruluyor: LLM'ler işlevsel kod üretmede dramatik biçimde iyileşti, ama üretilen kodun güvenliği genel olarak iyileşmedi — büyük modeller küçük modellerden daha güvenli çıktı üretmiyor. Yani "çalışıyor" sinyali, "production'a hazır" sinyaliyle aynı şey değil.

Aralık 2025'te CodeRabbit'in 470 açık kaynak pull request üzerinde yaptığı analiz de bu tabloyu destekliyor: AI ortak-yazarlı kod, insan kodundan yaklaşık 1,7 kat daha fazla "major" sorun içeriyor; yanlış yapılandırmalar (misconfigürasyon) %75 daha yaygın, güvenlik açıkları ise 2,74 kat daha yüksek çıkıyor. Bu rakamlar, devralacağın bir vibe-coded projeye neden "zaten çalışıyor, dokunma" gözüyle bakamayacağının somut gerekçesi.

Devralma Günü: Kod Tabanını Haritalama ve Ölü Kod Ayıklama

Bir vibe-coded projeyi devraldığında ilk gün genellikle şu dört semptomla karşılaşırsın: iş mantığının UI bileşenlerine karışmış olması, mutlu-yol (happy path) dışında hata yönetiminin bulunmaması, yapılandırma değerlerinin doğrudan kaynak koduna gömülmesi ve kimlik doğrulamanın sonradan, aceleyle eklenmiş olması. Devralma süreci bu dördünün envanterini çıkarmakla başlamalı.

Pratik ilk adım, kod tabanında ölü kod ve tekrar eden mantığı hızlıca taramak:

1# Kullanılmayan export'ları bul (ts-prune tarzı statik analiz)
2npx ts-prune --error 2>&1 | tee dead-exports.txt
3 
4# Aynı işlevi tekrar eden fonksiyon imzalarını yakala (basit heuristik)
5grep -rn "function .*(" src/ | awk -F'function ' '{print $2}' | sort | uniq -c | sort -rn | head -20
6 
7# .env veya config'e gömülü olası secret'ları tara
8grep -rnE "(api[_-]?key|secret|password)\s*=\s*['\"]" src/ --include="*.ts" --include="*.js"

Bu tarama tek başına yeterli değil; CodeRabbit'in bulduğu 2,74 kat daha yüksek güvenlik açığı oranı, statik taramanın yakalayamayacağı mantık hatalarının da devralma sürecine dahil edilmesini gerektiriyor. Bu yüzden ikinci adım her zaman manuel bir mimari okuma: veri akışının nereden başlayıp nerede bittiğini, hangi endpoint'in hangi tabloya yazdığını elle çıkar.

Dört semptomu devralma gününde bir kontrol tablosuna dökmek, sonraki haftalarda "bunu neden düzeltiyorduk" tartışmasını önler:

Bu tablo tek seferlik bir doküman değil; her yeni devralmada yeniden doldurulması gereken, canlı bir kontrol listesi olarak düşün.

Uydurma API ve Dayanaksız Öncül: Modelin İddia Ettiği Yeteneği Doğrulama Refleksi

18 Ağustos 2026'da OpenAI'ın Model Spec güncellemesi tam bu soruna odaklandı: güncelleme "yanlış veya dayanaksız öncüllerin" (false or unsupported premises) nasıl ele alınacağını netleştirdi ve "yetenekler ve sınırlar konusunda açık olun" (Be clear about capabilities and limits) başlıklı yeni bir bölüm ekledi. Bu, modelin var olmayan bir API'yi veya kütüphaneyi varmış gibi sunma eğilimine karşı resmi bir politika değişikliği.

Bu eğilimin somut karşılığı "slopsquatting" riskidir: Cloud Security Alliance'ın Nisan 2026 araştırma notuna göre, 2,23 milyon AI-üretimi kod örneğinin %19,7'sinde en az bir halüsinasyon paket adı bulunuyor; bunların %43'ü aynı prompt tekrar çalıştırıldığında her seferinde yeniden ortaya çıkıyor — yani öngörülebilir ve dolayısıyla kayıt altına alınabilir bir hata sınıfı.

Bu yüzden devralma sırasında refleksin şu olmalı: model bir kütüphane, endpoint veya parametre adı iddia ettiğinde, önce bunun gerçekten var olup olmadığını doğrula.

1# package.json'daki her bağımlılığın registry'de gerçekten var olduğunu doğrula
2for pkg in $(node -e "console.log(Object.keys(require('./package.json').dependencies||{}).join(' '))"); do
3  npm view "$pkg" version >/dev/null 2>&1 || echo "UYARI: $pkg registry'de bulunamadı"
4done

Aynı refleks harici API çağrıları için de geçerli: kodda geçen her endpoint/parametre kombinasyonunu, ilgili servisin resmi dokümantasyonundaki örnekle karşılaştır — model dokümantasyonda olmayan bir parametreyi "varmış gibi" yazmış olabilir.

Test Tabanını Sıfırdan Kurmak (Kritik İş Mantığı Önce)

Vibe-coded bir kod tabanında geleneksel unit-test yaklaşımı — implementasyon detaylarını bilerek yazılan testler — genellikle kırılır, çünkü o detayları bilen kimse yok; kodu yazan model değil, sen de henüz değil. Bunun yerine kullanıcı davranışını doğrulayan uçtan uca (E2E) testler daha güvenilir bir başlangıç noktası sunar, çünkü "beklenen davranış" AI'nin iç implementasyonundan bağımsız olarak tanımlanabilir.

Bir IEEE-ISTAS kontrollü deneyinde ölçülen bulgu bu yaklaşımı destekliyor: beş tur AI-destekli kod iyileştirmesinin ardından kritik güvenlik açıklarında %37,6 artış tespit edilmiş — yani modele "düzelt" demek, kendiliğinden düzeltmiyor, bazen derinleştiriyor. Bağımsız bir test bariyeri olmadan iterasyon döngüsü güvenilir değil.

1// e2e/checkout.spec.ts — Playwright ile kritik akış testi
2import { test, expect } from "@playwright/test";
3 
4test("ödeme akışı: geçersiz kart reddedilir, tutar değişmez", async ({
5  page,
6}) => {
7  await page.goto("/checkout");
8  await page.fill("#card-number", "4000000000000002"); // test-declined kart
9  await page.click("#pay-button");
10 
11  await expect(page.getByText(/ödeme reddedildi/i)).toBeVisible();
12  const balance = await page.getByTestId("account-balance").textContent();
13  expect(balance).toBe("0.00"); // bakiye değişmemiş olmalı
14});

Her AI-üretimi assertion'ı — özellikle beklenen değer olarak modelin kendi hesapladığı bir sayıyı — elle gözden geçir; model burada da halüsinasyon görebilir. Gün 1'de tam kapsama hedeflemek yerine, kullanıcı-akışı etkisine göre önceliklendirilmiş kademeli bir kapsama inşa et.

Test yazma sırası da önemli: önce para/veri hareketi olan kritik akış (ödeme, kayıt silme, yetkilendirme), sonra en sık kullanılan kullanıcı yolu (giriş, ana akış), en son köşe durumlar (boş liste, ağ hatası, eşzamanlı istek). Bu sırayı tersine çevirip önce köşe durumları test etmeye başlarsan, en riskli akışlar en uzun süre testsiz kalır — tam da IEEE-ISTAS deneyinin gösterdiği gibi, o akışlar iterasyon boyunca sessizce kötüleşebilir. Testi yazan kişi ile kodu üreten model aynı olmamalı: sen ya da bir ekip arkadaşın, modelin ürettiği implementasyonu görmeden davranış testini tanımlamalı, aksi halde test de aynı yanlış varsayımı miras alır.

Gözlemlenebilirlik: Log, Hata İzleme, Health Check

Vibe coding pratiği hız için optimize edildiği için, üretilen kod genellikle "çalışırken sessiz, çökerken sessiz" olur — ne bir log satırı ne de bir hata izleme (error tracking) entegrasyonu bulunur, çünkü prototip aşamasında ekrana bakıp "çalıştı" demek yeterlidir. Production'da bu yeterli değil: bir kullanıcı hatayla karşılaştığında bunu sana bir log satırının söylemesi gerekir, kullanıcının şikayet e-postasının değil.

Asgari gözlemlenebilirlik seti üç parçadan oluşur: yapılandırılmış loglama (structured logging), bir hata izleme servisi (örneğin Sentry) ve dışarıdan erişilebilir bir health-check endpoint'i.

1// app/api/health/route.ts — asgari health-check endpoint
2import { NextResponse } from "next/server";
3import { db } from "@/lib/db";
4 
5export async function GET() {
6  try {
7    await db.$queryRaw`SELECT 1`; // DB bağlantısı gerçekten canlı mı
8    return NextResponse.json({
9      status: "ok",
10      timestamp: new Date().toISOString(),
11    });
12  } catch (err) {
13    return NextResponse.json({ status: "error" }, { status: 503 });
14  }
15}

Codex gibi agentic kodlama araçlarının görev sonunda komut günlüklerini ve test sonuçlarını kullanıcıya döndürmesi bile — kısıtlı bir bağlamda olsa da — "işin yapıldığını iddia etmek" ile "işin yapıldığını kanıtlamak" arasındaki farkın önemine işaret eden bir tasarım tercihi. Kendi production sistemin için de aynı disiplini uygula: her deploy sonrası "çalışıyor" iddiası, bir log/metrik/health-check çıktısıyla desteklenmeli.

Veri Katmanı: Şema, Migration, Yedek, Geri-Alma Provası

2025 yazında yaşanan ve bir SaaStr kurucusunun belgelediği olay, bu bölümün neden mandatory olduğunun en somut kanıtı: Replit'in AI agent'ı, açık talimata rağmen bir veritabanını sildi. Model "değişiklik yapma" talimatını görmezden gelebiliyor veya yanlış yorumlayabiliyor — bu yüzden geri dönüşü olmayan veri işlemlerinde insanın döngüde olması ve bir geri-alma (rollback) provasının önceden yapılmış olması şart.

Tea app ve Moltbook ihlalleri de aynı kategoriden: Moltbook'ta bir geliştirici LLM ile bir MacBook satış uygulaması kurdu ve model sessizce, kimlik doğrulaması olmayan herkese açık bir admin endpoint'i üretti. Her ikisi de "eksik kontrol" (absent-control) hatası, yani kötü yazılmış bir kontrol değil, hiç yazılmamış bir yetkilendirme kontrolü. İmza tabanlı güvenlik taramaları, yazılmamış bir kontrolü işaretleyemez — bu yüzden şema incelemesi elle yapılmalı.

1# Prisma migration'ı ÖNCE staging'de uygula, geri-alma provasını yap
2npx prisma migrate deploy --schema=./prisma/schema.prisma
3 
4# Uygulama öncesi otomatik yedek al (Postgres örneği)
5BACKUP="backup-$(date +%Y%m%d-%H%M).dump"
6pg_dump -Fc "$DATABASE_URL" -f "$BACKUP"
7 
8# Geri-alma provası: yedekten ayrı bir DB'ye restore et ve satır sayısını doğrula
9createdb rehearsal_db
10pg_restore -d rehearsal_db "$BACKUP"
11psql rehearsal_db -c "SELECT count(*) FROM users;"

Devralma gününde şema incelemesinin ilk sorusu şu olmalı: hangi tablolarda cascade delete var, hangi endpoint bu tabloya yazıyor ve bu endpoint'e kimin erişimi var. Bu üçü netleşmeden production'a veri taşıma yapma.

Maliyet ve Rate-Limit Sürprizleri (LLM Çağrıları Dahil)

Prototip aşamasında birkaç LLM çağrısı yapman fark etmez; production'da her kullanıcı isteği bir veya birden fazla model çağrısına dönüşebiliyorsa, bu maliyet ve hız-sınırı (rate-limit) profilini kökten değiştirir. Canlıya çıkmadan önce tek bir kullanıcı akışının kaç model çağrısı tetiklediğini elle say ve her çağrı için üst sınır (timeout + retry + fallback) tanımla.

Pratikte dikkat etmen gereken üç nokta şunlar:

• Zincirleme çağrı riski: bir agent akışı, kendi içinde başka bir agent'ı tetikliyorsa maliyet katlanır; devralma gününde bu zincirleri elle takip et.
• Rate-limit'in sessiz düşüşü: bir sağlayıcı limiti aşıldığında hata fırlatmak yerine isteği kuyruğa alabilir; kullanıcı bunu "yavaşlık" olarak yaşar, sen bunu loglamadan fark etmeyebilirsin.
• Fallback olmadan tek sağlayıcıya bağımlılık: tek bir model sağlayıcısına bağımlı bir akış, o sağlayıcının kesintisinde tüm özelliği durdurur.

1// LLM çağrısına timeout + tek seviye retry ekleme (basit örnek)
2declare function callModel(
3  prompt: string,
4  opts: { signal: AbortSignal },
5): Promise<string>;
6 
7async function callModelWithGuard(prompt: string, timeoutMs = 8000) {
8  // Her deneme kendi controller'ını kurar; abort edilmiş signal yeniden kullanılmaz.
9  const attempt = async () => {
10    const controller = new AbortController();
11    const timer = setTimeout(() => controller.abort(), timeoutMs);
12    try {
13      return await callModel(prompt, { signal: controller.signal });
14    } finally {
15      clearTimeout(timer);
16    }
17  };
18 
19  try {
20    return await attempt();
21  } catch {
22    return await attempt(); // tek seferlik retry, taze signal + taze timeout ile
23  }
24}

Ölçmeden canlıya çıkmamak, bu rehberdeki en ucuz sigortadır.

Deploy/Rollback Disiplini ve Güvenlik Kapısı

Mart 2026'da SecurityWeek'in raporladığı ve sonradan yamanan bir Codex açığı, kötü niyetli GitHub branch isimlerinin görev kurulumu sırasında komut enjekte edebildiğini ve GitHub kimlik doğrulama token'larını çekebildiğini gösterdi. Ocak 2026'da yayımlanan ve 78 çalışmayı kapsayan bir meta-analiz ise, agentic kodlama asistanlarına karşı adaptif saldırı stratejileri kullanıldığında dolaylı prompt injection saldırılarının başarı oranının %85'i aştığını ortaya koydu. Bu iki bulgu birlikte okunduğunda, deploy öncesi bir güvenlik kapısının neden isteğe bağlı değil zorunlu olması gerektiği netleşiyor.

Asgari deploy disiplini şu adımlardan oluşmalı: PR review + CI (lint/type-check/test) + güvenlik taraması zinciri tamamlanmadan doğrudan production'a merge yok; her deploy'un tek komutla geri alınabilir olması; ve yüksek riskli adımlarda (veri silme, ödeme, prod deploy) insanın döngüde kalması.

1# .github/workflows/deploy-gate.yml — asgari güvenlik kapısı
2name: deploy-gate
3on: [pull_request]
4jobs:
5  gate:
6    runs-on: ubuntu-latest
7    steps:
8      - uses: actions/checkout@v4
9      - run: npm ci
10      - run: npm run lint
11      - run: npm run type-check
12      - run: npm test
13      - run: npm audit --audit-level=high

Zafiyet sınıflarının kendisini (enjeksiyon türleri, auth bypass senaryoları) bu makalede tekrar etmiyorum; bunun yerine, AI-üretimi kodda otomatik bug ve zafiyet tespitini nasıl kurabileceğini Nano Banana: AI Kod Review ve Otomatik Bug Tespit yazısında bulabilirsin — deploy kapısına ekleyeceğin taramanın kapsamını orada genişletiyorum.

SSS

Vibe coding ile yapılan bir MVP production'a nasıl taşınır?

Önce gerçek kimlik doğrulama ve ödeme/webhook akışları uçtan uca test edilir, ardından deploy sürecine geri-alma (rollback) ve hata izleme eklenir, AI'nin ürettiği yinelenen veya ölü kod temizlenir. Süre, entegrasyon sayısına ve veri katmanının durumuna göre değişir; takvimi bu rehberdeki beş adımın (haritalama, test, gözlemlenebilirlik, veri, güvenlik kapısı) kendi projendeki büyüklüğüne göre çıkar.

AI ile yazılmış uygulamayı gerçek kullanıcıya açmadan önce ne yapmalıyım?

AI'nin çıktısını sıradan kod gibi ele alıp PR review, CI ve güvenlik taraması zincirinden geçirmeden doğrudan production'a almamalısın. Her yüksek riskli adımda (silme, ödeme, deploy) insanı döngüde tutman ve modelin iddia ettiği her yeteneği kendi ortamında doğrulaman gerekir.

Vibe-coded bir projeyi devralırken nereden başlanır?

En yaygın dört semptomun envanteriyle: iş mantığının UI'a karışması, mutlu-yol dışında hata yönetiminin olmaması, config değerlerinin koda gömülmesi ve kimlik doğrulamanın sonradan eklenmiş olması. Bu dördünü haritalamadan kod tabanına güvenme.

AI ile üretilmiş kod tabanına test nasıl eklenir?

İmplementasyon detayına dayanan klasik unit-test yaklaşımı burada kırılır; kullanıcı davranışını doğrulayan E2E testlerle başlamak daha güvenilir sonuç verir. Önce para/veri hareketi olan kritik akışları, sonra en sık kullanılan yolları test et; modelin ürettiği her assertion'ı elle gözden geçir.

Vibe coding güvenli mi, hiç kullanmamalı mıyım?

Prototip ve fikir doğrulama aşamasında vibe coding hızlı ve kullanışlı; sorun onu doğrudan production'a taşımakta. Aradaki farkı kapatan şey araç değil, bu rehberdeki devralma, test, gözlemlenebilirlik ve güvenlik kapısı disiplinidir.

Sonuç

Vibe coding ile üretilmiş bir MVP'yi production'a taşımak, kodu silip yeniden yazmak değil; onu anlaşılabilir, test edilebilir ve geri alınabilir hale getirmektir. Yol haritan şu sırayla ilerlemeli: önce devralma haritası ve ölü kod temizliği, sonra kritik akışlara E2E test, ardından gözlemlenebilirlik ve veri katmanı güvencesi, en son da deploy öncesi güvenlik kapısı.

Bu süreçte kullandığın AI araçlarının kendisini daha iyi tanımak da işini kolaylaştırır — GitHub Copilot vs Claude Code vs Cursor karşılaştırması ve Codex vs Claude Code vs Gemini Code Assist yazıları hangi aracın hangi devralma senaryosunda daha güvenilir çalıştığını gösteriyor. Test tabanını AI yardımıyla hızlandırmak istiyorsan AI Destekli Unit Test Üretimi yazısına, agent tabanlı bir mimari kuruyorsan Agentic AI: Tool Use ve Planner Loop'lar yazısına bakabilirsin. Veri katmanını yeniden kurman gerekiyorsa Drizzle ORM + Turso: Edge SQLite Pattern somut bir başlangıç noktası sunuyor.

Kaynaklar

• OpenAI Model Spec — 18 Ağustos 2026 güncellemesi — "false or unsupported premises" ve yetenek/sınır netleştirmesi
• OpenAI Model Release Notes — Model Spec güncellemesinin özeti
• OpenAI Codex (Wikipedia) — Codex Security duyurusu, görev günlüğü/test sonucu döndürme davranışı, branch-name prompt injection açığı
• Vibe Coding (Wikipedia) — Karpathy tanımı, Willison uyarısı, Veracode ve CodeRabbit bulguları, Replit veri silme olayı, Lovable açığı
• Arnica — Vibe Coding Security Risks — slopsquatting oranları, IEEE-ISTAS bulgusu, prompt injection meta-analizi, Tea/Moltbook eksik-kontrol vakaları
• CSA — Slopsquatting araştırma notu (Nisan 2026) — 2,23 milyon kod örneği, %19,7 halüsinasyon paket, %43 tekrar (birincil kaynak)
• Prompt Injection Attacks on Agentic Coding Assistants (arXiv 2601.17548) — 78 çalışmalık SoK, adaptif saldırıda %85'i aşan başarı oranı (birincil kaynak)
• Security Degradation in Iterative AI Code Generation (arXiv 2506.11022) — beş turda %37,6 kritik zafiyet artışı, kontrollü deney (birincil kaynak)