Kısıt Odaklı Vibe Coding

Kısıt Odaklı Vibe Coding

Yapay zekâ tarafından üretilen kodu yalnızca hız üzerinden değil, Laravel tabanlı bir içe aktarıcı testi üzerinden ölçmek.

Laravel Artisan · CSV içe aktarıcı · 930 satırlık test verisi · VCPRI puan kartı

Özet

Vibe Coding çoğu zaman hız üzerinden anlatılır: Yapay zekâ kısa bir isteği ne kadar hızlı çalışan koda dönüştürebiliyor? Bu önemli bir soru olabilir, ama tek başına yeterli değildir. Çünkü hızlı üretilen kod yine de hatalı, pahalı, kırılgan veya üretim ortamı için riskli olabilir.

Bu çalışma Vibe Coding’i bir gösteri gibi değil, mühendislik açısından test edilmesi gereken bir çıktı olarak ele alıyor. Örnek olarak Laravel ile yazılmış bir ürün CSV içe aktarıcısı kullanılıyor. Bu içe aktarıcı, gerçek Amazon ürün verilerinden türetilmiş sabit bir test verisi üzerinde çalıştırılıyor. Amaç, aynı özelliğin üç farklı yaklaşımla nasıl davrandığını ölçmek.

Temel İddia

Yapay zekâ tarafından üretilen kodun tehlikesi sadece kötü olabilmesi değildir. Kötü kod, yapay zekâdan önce de vardı. Yeni tehlike şu: Üretilen kod, gerçekten doğru olduğunu kanıtlamadan önce tamamlanmış gibi görünebilir.

Basit bir demo içe aktarıcı CSV dosyasını okuyabilir, ürünleri ekleyebilir ve ekrana güzel bir özet yazdırabilir. Ama üretim ortamı daha sert sorular sorar: Bozuk satırlar gerçekten reddedildi mi? Tüm veri belleğe yüklenmeden işlendi mi? Her satır gereksiz veritabanı sorgularına mı dönüştü? Bir hafta sonra tedarikçi verisindeki bir hatayı anlamak için yeterli kayıt var mı?

Yapay zekâ ile kodlama hakkında yapılan genel tartışmalar çoğu zaman fazla iddialı olur. Bir taraf yapay zekânın artık çoğu programcıdan daha iyi olduğunu söyler. Diğer taraf ise yapay zekâ kodunu kullanılamaz ve güvenilmez görür. Fakat bu görüşlerin çoğu kişisel deneyimlere, ekran görüntülerine, şaşırtıcı bir kod tamamlamaya veya bozuk bir fonksiyona dayanır. Bunlar tartışma başlatmak için faydalı olabilir, ama ölçüm sayılmaz.

Bu test daha dar ama daha faydalı bir soru soruyor: Bir yapay zekâ çıktısı, istek metninde üretim ortamında düşünülmesi gereken kısıtlar açıkça yazıldığında daha iyi davranır mı?

Önceki Bulgular ve Genel Tartışma

Karpathy’nin vibe coding kavramını yaygınlaştıran paylaşımı bilimsel bir kanıttan çok kültürel bir işaret olarak önemlidir. Çünkü birçok geliştiricinin zaten deneyimlediği bir çalışma biçimini adlandırdı: Ne istediğini tarif etmek, büyük yapay zekâ değişikliklerini kabul etmek ve sonucu konuşarak yönlendirmek. Bu, çalışma şeklini anlatır; fakat tek başına kod kalitesini kanıtlamaz.

İyimser tarafın elinde dikkate değer bulgular var. GitHub’ın Copilot araştırmasında, Copilot kullanan bir grup ile kullanmayan bir grup, JavaScript ile HTTP server geliştirme gibi sınırlı bir görevde karşılaştırıldı. Copilot kullanan grup görevi belirgin şekilde daha hızlı tamamladı. Bu sonuç ciddiye alınmalıdır, çünkü kontrollü bir deneyden geliyor. Ama sınırları da açıktır: Görev küçüktü, başarı ölçütü belliydi ve ölçüm o görevin tamamlanmasına odaklandı; uzun ömürlü bir üretim kodunun dayanıklılığına değil.

Diğer tarafta dikkatli olmayı gerektiren bulgular da var. METR’in 2025 çalışması, deneyimli açık kaynak geliştiricilerini zaten bildikleri gerçek depolardaki gerçek issue’lar üzerinde test etti. Bu bağlamda yapay zekâ kullanımına izin verildiğinde tamamlama süresinin arttığı görüldü. METR sayfası artık bu sonuçların tarihsel olduğunu ve 2026’da daha yeni sonuçların bulunduğunu belirtiyor. Bu yüzden burada çıkarılacak sonuç “yapay zekâ her zaman yavaşlatır” değildir. Asıl ders şudur: Gerçek işler, küçük demoların verdiği hissi tersine çevirebilir.

Güven anketleri de benzer bir tablo gösterir. 2025 Stack Overflow Developer Survey, geliştiriciler arasında yapay zekâ araçlarının doğruluğuna güvenmeyenlerin oranının güvenenlerden daha yüksek olduğunu gösterdi. Bu, geliştiricilerin yapay zekâyı reddettiği anlamına gelmez. Daha çok, doğrulamanın artık iş akışının doğal bir parçası olduğunu gösterir.

Bu makalenin yaklaşımına en yakın çerçeve DORA’nın 2025 yapay zekâ destekli yazılım geliştirme raporunda görülür. Oradaki ana fikir şudur: Yapay zekâ, sistemde zaten var olan güçlü ve zayıf tarafları büyütür. Net bir sözleşme, testler, kayıtlar ve iyi bir inceleme süreci varsa model bunları güçlendirebilir. İstek belirsizse model çoğunlukla sadece özelliğin dış görünüşünü üretir.

Güvenlik araştırmaları da aynı uyarıyı daha keskin hale getirir. Broken by Default adlı 2026 tarihli çalışma, yapay zekâ tarafından üretilen güvenlik açısından kritik kodları biçimsel doğrulama ile inceledi ve test edilen tüm modellerde güvenlik açıkları buldu. Bu içe aktarıcı testi bir güvenlik testi değildir; fakat aynı disiplini ödünç alır: Kod ikna edici görünüyor mu diye sormak yetmez. Hangi kurallara dayanabiliyor diye sormak gerekir.

Hız Neden Zayıf Bir Gösterge?

En hızlı çözüm, çoğu zaman gereğinden fazla değer verilen çözümdür. Terminalde bir komut çalışır, tabloya satırlar yazılır, sonunda da düzgün görünen bir özet çıkar. Uygulama hareket etmiş gibi görünür. Ama hareket, her zaman doğru ilerleme anlamına gelmez.

İçe aktarıcılarda bu his özellikle yanıltıcıdır. Kötü veri de sonuçta veridir. Zayıf bir içe aktarıcı geçersiz stok durumlarını kaydedebilir, bozuk miktarları sessizce sıfıra çevirebilir, hatalı JSON verisini kabul edebilir veya var olan bir ürünü yanlış kimlikle güncelleyebilir. Bu hatalar hemen bağırmaz. Daha sonra filtrelerde, stok sayılarında, destek taleplerinde veya katalogdaki açıklanamayan kaymalarda ortaya çıkar.

Bu yüzden bu test her stratejiye aynı kirli girdiyi ve aynı beklenen sonucu verir. Asıl soru komutun çalışıp çalışmadığı değildir. Asıl soru şudur: Veritabanı doğru durumda mı kaldı? Reddedilen satırlar açık ve dürüst şekilde raporlandı mı?

Testin Yapısı

Ham kaynak Amazon ürün verileridir. Bu veri gerçek ürün adları, fiyatlar, kategoriler ve dağınık varyant bilgileri içerir. Doğrudan test olarak kullanılmaz; çünkü tek başına gerçek veri, beklenen doğru sonucu vermez.

Bu ayrım önemlidir. Gerçek veri teste gerçeklik hissi verir: uzun ürün adları, tutarsız açıklamalar, boş tedarikçi alanları, metin olarak yazılmış fiyatlar ve rahatsız edici biçimlerde gelen varyant verileri. Kontrollü veri ise teste karar verme gücü verir: Komut çalışmadan önce kaç satırın ekleneceğini, kaç satırın güncelleneceğini ve kaç satırın reddedileceğini biliriz.

Bu nedenle test verisi, gerçek verinin dağınık yapısını korur; ama üzerine ölçülebilir bir sözleşme ekler: 930 giriş satırı, 600 beklenen ekleme, 250 beklenen güncelleme ve 80 beklenen reddetme.

Test akışı şöyledir:

• Amazon ürün verisi

• Kontrollü test verisinin hazırlanması

• Laravel Artisan komutlarının çalıştırılması

• Ölçülen sonuçların toplanması

• VCPRI puanının hesaplanması

Çalıştırma düzeni üç ayrı parçadan oluşur: kontrollü içe aktarma girdisi, daha önce veritabanına eklenmiş ürünler ve yalnızca çalıştırmadan sonra kullanılan gerçek sonuç tablosu. İçe aktarıcı, giriş satırlarını ve önceden yüklü ürünleri görür. Beklenen cevabı çalışırken görmez; o cevap yalnızca puanlama için kullanılır.

İçe Aktarıcı Kuralları

Bu test Amazon’un tam ürün kataloğunu modellemeye çalışmaz. Bunun yerine, içe aktarıcının davranışını ölçmek için yeterli olan küçük ve açık bir ürün sözleşmesi tanımlar.

Ürün kimliği sabit bir sırayla belirlenir: önce Sku, sonra Asin, sonra Uniq Id. Bu üçünden hiçbiri kullanılabilir değilse satır reddedilir. Böylece kaynak verinin gerçekçi yapısı korunur, ama her uygulamaya aynı karar kuralı verilir.

Bu sözleşme bilinçli olarak sınırlı tutulmuştur. Görselleri, kargo ağırlığını, ürün boyutlarını veya pazar yerindeki tüm ayrıntıları modellemeye çalışmaz. Amaç, üretilen kod demo veriden çıkıp tedarikçi verisine geçtiğinde ilk kırılan davranışları izole etmektir.

Senaryo Protokolü

Her strateji aynı Laravel uygulamasında bir Artisan komutu olarak uygulanmıştır. Tüm komutlar aynı kontrollü içe aktarma verisini ve aynı önceden yüklenmiş ürün durumunu okur. Her biri eklenen, güncellenen, reddedilen ve başarısız olan satırları; çalışma süresini, en yüksek bellek kullanımını ve sorgu sayısını raporlar.

Bu protokol önemlidir; aksi halde karşılaştırma ölçüm olmaktan çıkar ve gösteriye dönüşür. Eğer raw sürüm sonuçları gördükten sonra düzeltilirse artık raw değildir. Eğer baseline sessizce optimize edilirse artık sıradan Laravel kodunu temsil etmez. Eğer kısıt odaklı sürüme farklı bir test verilirse, kısıtların etkisini ölçmüş olmayız.

Test üç stratejiyi karşılaştırır:

• Orta seviye Laravel baseline: Eloquent doğrulama kullanan, satır satır okuyan, basit reddetme kaydı tutan ve updateOrCreate kullanan pratik Laravel kodu.

• Raw vibe coding: Sadece küçük entegrasyon düzeltmeleri yapılan geniş ve genel bir yapay zekâ isteği. Bu sürüm özellikle kötüleştirilmemiştir; sadece yeterince tanımlanmamıştır.

• Constraint-driven vibe coding: Bellek, doğrulama, sorgu yükü, reddetme kayıtları ve test edilebilirlik gibi sınırların açıkça belirtildiği yapay zekâ üretimi.

Raw strateji sabote edilmiş değildir. Bilinçli olarak eksik tanımlanmıştır. Üretilen birçok özellik, istek kötü kod istediği için değil, kodun dayanması gereken baskıyı tarif etmediği için başarısız olur. Orta seviye Laravel baseline da zayıf bir örnek değildir; Eloquent doğrulama ve updateOrCreate kullanan bir Laravel komutu, ilk üretim sürümü olarak gayet tanıdık bir çözümdür. Kısıt odaklı sürümün daha bilinçli davranmasına izin verilir, çünkü prompt bellek, doğrulama, sorgu, kayıt ve test edilebilirlik sınırlarını açıkça söyler.

Kısıtlar Neyi Değiştiriyor?

Fark kod yazılmadan önce başlar. Raw prompt sadece özelliği tarif eder. Kısıt odaklı prompt ise hem özelliği tarif eder hem de o özelliğin ne zaman gerçekten tamamlanmış sayılacağını açıklar.

Raw prompt:

Build a Laravel CSV importer for products. It should read the CSV,
insert new products, update existing products, reject invalid rows,
and return a summary.

Kısıt odaklı prompt:

Build a Laravel product importer for the benchmark CSV. Do not load
the full dataset into memory. Use sku, then asin, then source_id as the
product-key fallback. Validate price, quantity, status, variants, and
description length. Reject duplicate product keys inside the import
input. Preload existing keys to reduce database queries. Log every
rejected row with row number and reason. Return measured counts,
runtime, memory, and query count.

Önemli olan ikinci promptun daha uzun olması değildir. Önemli olan, hatayı görünür hale getirmesidir. Bir satır sessizce atlanmaz; belirli bir nedenle reddedilir. Bu sınıflandırma, uygulamaları yalnızca “daha temiz görünüyor” hissiyle değil, gerçek davranışlarıyla karşılaştırmayı sağlar.

Doğrulama farkı:

// Raw-style validation: enough for a demo, not enough for the contract.
if ($productKey === '' || trim($row['name']) === '' || $row['price'] <= 0) {
    reject($rowNumber);
}

// Constraint-driven validation: every controlled failure has a rule.
if ($productKey === '') return reject($rowNumber, 'missing_product_key');
if (trim($row['name']) === '') return reject($rowNumber, 'empty_name');
if (! is_numeric($row['price']) || $row['price'] <= 0) return reject($rowNumber, 'invalid_price');
if (! preg_match('/^-?\d+$/', $row['quantity']) || $row['quantity'] < 0) return reject($rowNumber, 'invalid_quantity');
if (! in_array($row['status'], $allowedStatuses, true)) return reject($rowNumber, 'invalid_status');
if ($row['variants'] !== '' && json_decode($row['variants']) === null && json_last_error() !== JSON_ERROR_NONE) {
    return reject($rowNumber, 'invalid_variants_json');
}

Değerlendirme Yöntemi

Çalışmada VCPRI, yani Vibe Coding Production Readiness Index kullanıldı. Bu puan; doğruluk, kaynak kullanımı, güvenlik, hata davranışı ve bakım kolaylığı gibi farklı yönleri tek bir ölçüde toplar.

VCPRI = 0.25C + 0.20M + 0.15R + 0.15Q + 0.10S + 0.10F + 0.05T

Burada C doğruluğu, M bellek verimliliğini, R çalışma süresini, Q sorgu verimliliğini, S güvenliği, F hata yönetimini, T ise test edilebilirlik ve bakım kolaylığını temsil eder.

Checklist Score = Passed Checks / Total Checks x 100
Memory Score = Lowest Peak Memory / Current Peak Memory x 100
Runtime Score = Fastest Runtime / Current Runtime x 100
Query Score = Lowest Query Count / Current Query Count x 100

Bu ağırlıklar bu içe aktarıcıya özeldir. Doğruluk en yüksek ağırlığı alır; çünkü yanlış veri bir performans sorunu değil, güven sorunudur. Bellek, çalışma süresi ve sorgu sayısı da güçlü ağırlık alır; çünkü içe aktarma işleri çoğu zaman küçük örnekte değil, veri büyüdüğünde kırılır.

Ölçülen Sonuçlar

Test, tekrarlanabilir yerel ölçüm için SQLite kullanılarak gerçek Laravel Artisan komutları üzerinden çalıştırıldı. Her strateji üç kez çalıştırıldı ve aşağıdaki değerler ortalama olarak verildi.

Özet VCPRI puanları şöyleydi:

• Raw vibe coding: 43.30 VCPRI

• Laravel baseline: 78.06 VCPRI

• Constraint-driven: 100.00 VCPRI

Sonuçları Okumak

Raw uygulama çalışmayı tamamladı, fakat içe aktarma kurallarına uymadı. 600 yerine 640 satır ekledi, 250 yerine 258 satır güncelledi ve 80 geçersiz satırın yalnızca 32’sini reddetti. Bu, içe aktarıcılarda en tehlikeli hata türüdür: Komut biter, veritabanı dolar ve hata kabul edilmiş verinin içinde saklanır.

Laravel baseline işlevsel olarak doğru sonucu verdi. Eklenmesi gerekenleri ekledi, güncellenmesi gerekenleri güncelledi ve reddedilmesi gerekenleri reddetti. Zayıflığı doğrulukta değil, uygulama biçimindeydi. Satır satır Eloquent kullanımı ve updateOrCreate, 1700 sayılmış veritabanı işlemine yol açtı ve doğru çalışan sürümler arasında en yavaş olanı oldu.

Kısıt odaklı sürüm tasarımı daha çalışmadan değiştirdi: Satırları akış halinde okudu, doğrulamayı açık yaptı, mevcut ürün anahtarlarını önceden yükledi, giriş dosyası içindeki tekrar eden anahtarları reddetti ve düzenli reddetme kayıtları yazdı. Aynı doğru sonuca 851 sorguyla ve çok daha düşük çalışma süresiyle ulaştı.

Bu, özellik isteği ile mühendislik isteği arasındaki pratik farktır. “Bir içe aktarıcı yap” ifadesi görünen sonucu tarif eder. “Girdiyi akış halinde okuyan, sabit kuralları doğrulayan, her satırda varlık kontrolü yapmayan, tekrar eden anahtarları reddeden ve her hata nedenini kaydeden bir içe aktarıcı yap” ifadesi ise sonucun ne zaman gerçekten tamamlanmış sayılacağını tarif eder.

Raw sonucun faydalı olmasının nedeni, gerçekçi olmasıdır. Kod çökmedi. Boş tablo üretmedi. Hatta yüzeysel bir kontrolden geçebilecek sayılar üretti. Eğer kimse bu sayıları gerçek sonuç tablosuyla karşılaştırmasaydı hata fark edilmeyebilirdi. Yapay zekâ destekli kodlamada benchmark’ların önemi buradan gelir: “Tamamlanmış gibi görünüyor” hissini, gerçekte ne olduğuna dair dış bir ölçümle değiştirirler.

Bu Çalışma Yapay Zekâ ile Kodlama Hakkında Ne Gösteriyor?

Bu çalışma yapay zekânın geliştiriciden daha iyi olduğunu kanıtlamaz. Kısıt odaklı promptların her zaman kazanacağını da kanıtlamaz. Daha pratik bir şeyi gösterir: Yapay zekâ çıktısı, isteğin biçimine güçlü şekilde tepki verir. Prompt belirsizse çıktı çoğunlukla görünür tamamlanmayı hedefler. Prompt ölçülebilir baskılar içeriyorsa çıktı mühendislik davranışına yaklaşabilir.

Bu durum geliştiriciyi daha pasif değil, daha aktif hale getirmelidir. Mühendisin işi yalnızca her satırı elle yazmak değildir. Üretilen kodu ölçülebilir kılan sınırları tanımlamak da mühendisliğin parçasıdır: Ne reddedilmeli, ne kaydedilmeli, ne belleğe yüklenmemeli ve hangi sonuç doğru kabul edilmeli?

Sınırlar

Bu ölçülmüş bir vaka çalışmasıdır, evrensel bir yasa değildir. Test SQLite kullanır; bu yüzden MySQL veya PostgreSQL mutlak çalışma süresini değiştirebilir. İş yükü 930 satırdır. Bu sayı doğrulama ve sorgu yapısı farklarını göstermek için yeterlidir, ama 100.000 satırlık büyük içe aktarımlar hakkında kesin hüküm vermek için yeterli değildir.

Çalışma süresi tam Laravel Artisan komut süresi olarak ölçülmüştür. Buna framework başlatma maliyeti de dahildir: Composer autoload, service provider’lar, konfigürasyon, komut çözümleme ve veritabanı bağlantısı. Bu karşılaştırma için adildir, çünkü her strateji aynı Laravel uygulamasında ve aynı ortamda bu maliyeti öder. Mutlak süreleri etkileyebilir, fakat bu test içinde herhangi bir stratejiye özel avantaj vermez.

Yine de çalışma faydalıdır, çünkü görülen hata biçimleri oldukça sıradandır. Tedarikçi verisi dağınıktır. Ürün anahtarları eksik olabilir. JSON bozuk gelebilir. “Çalışıyor” görünen içe aktarıcılar aslında reddetmesi gereken satırları kabul edebilir. Yapay zekâ tarafından üretilen kodun alkıştan önce açık kısıtlara ihtiyaç duymasının nedeni tam olarak budur.

Bir sonraki sürüm aynı senaryoları daha büyük bir veri yüküyle, ağ üzerinden çalışan bir veritabanıyla ve reddetme nedenlerini daha sıkı test eden bir test takımıyla çalıştırmalıdır. Ayrıca Laravel’in soğuk başlatma maliyeti ile gerçek içe aktarma döngüsünün süresi ayrı ayrı ölçülmelidir.

Sonuç

Buradaki faydalı ders, yapay zekâ kodunun iyi ya da kötü olduğu değildir. Asıl ders şudur: Kısıtsız üretilen koda güvenmek fazla kolaydır. Raw vibe coding, içe aktarıcıya benzeyen bir sonuç üretti ama kuralları geçemedi. Baseline doğruydu ama ağırdı. Kısıt odaklı sürüm ise hem doğru hem daha ucuzdu; çünkü prompt, kodun dayanması gereken baskıyı açıkça tarif ediyordu.

Üretim işi için prompt “özelliği yap” noktasında bitmemelidir. Veri boyutu, doğrulama kuralları, sorgu bütçesi, bellek davranışı, hata kayıtları, güvenlik sınırları ve test edilebilir yapı tanımlanmalıdır. Bu noktada Vibe Coding hızlı bir kestirmeden çok, gerçek bir mühendislik pratiğine benzemeye başlar.

Daha ayrıntılı incelemek isteyenler için çalışmanın tüm detaylarını içeren PDF dosyasını burada ekledim.