Vibe coding ile yaptığın uygulamanın gerçekten çalıştığını nereden biliyorsun?

O şeyi inşa ettin. İçinde tıklayarak dolaştın. Düğme çalıştı, kayıt kaydedildi, panel güncellendi. Kendini iyi hissediyorsun.

Ama o kodu sen yazmadın, ve dürüst olursan büyük olasılıkla onu okumadın da. Yani gerçekte bildiğin şey şu: bir kez, senin için, denediğin o tek şeyi yaparken çalıştı. “Çalışıyor” olup olmadığına dair her şey güvenden ibaret.

Happy path, çoğu insanın test ettiği tek yol

Vibe coding ile yapılmış bir uygulamayı test etmek genelde şöyle görünür: bir dosya yüklersin, işlenir. Bir formu gönderirsin, kayıt görünür. Bir düğmeye tıklarsın, iş akışı tetiklenir. Hepsi bu. Test bu.

Bu tembellik değil. Altta yatan mantığı yazmamış birinin yaptığı manuel testin doğal sınırı. Sadece yanlış gidebileceğini hayal edebildiğin şeyi test edebilirsin, ve kodu okuyamıyorsan demoyu test ediyorsun, sistemi değil. Happy path, yapay zekanın kesinlikle optimize ettiği tek yoldur, çünkü uygulamayı baştan doğuran senaryo, prompt’taki o senaryodur.

Sorun şu ki gerçek kullanım happy path’te kalmıyor. Gerçek kullanıcılar çift tıklar. İki sekme açarlar. Geri tuşuna basıp yeniden gönderirler. Sen, geliştirici, kendi uygulamanda bir kez, dikkatlice, beklediğin sırayla tıklayarak dolaşırken bunların hiçbiri ortaya çıkmaz.

Eşzamanlılık, işlerin gerçekten bozulduğu yer

En açık örnek eşzamanlılıktır, ve neye bakman gerektiğini tam olarak bilsen bile elle test etmek gerçekten zordur.

Kredi bazlı bir özelliği düşün: bir kullanıcı bir işlem başlatır, bu krediye mal olur, ve bakiye kontrolü krediler bittiğinde onu durdurmalıdır. Şimdi aynı kullanıcının beş sekme açıp ilk faturalama kontrolü bitmeden aynı saniye içinde beş işlem başlattığını düşün. ‘Kontrol et sonra düş’ mantığı bu çakışmayı ele alacak şekilde kurulmamışsa, beş işlemin hepsi hiçbiri bir düşüş kaydetmeden bakiye kontrolünden geçebilir. Sonuç, gücü yetmediği işlemleri çalıştıran bir kullanıcı, negatife düşen bir kredi bakiyesi ve kimsenin planlamadığı şekilde artık hatalı olan bir hesap durumudur.

Bunu bir düğmeye bir kez tıklayarak yakalayamazsın. Beş sekme açmayı düşünmen, tıklamaları aynı saniyenin küçük bir kesrine denk getirecek şekilde zamanlaman, ve ‘bakiyeyi kontrol et’ ile ‘bakiyeden düş’ün birbiriyle yarışabilecek iki ayrı adım olduğunu bilmen gerekirdi. Bu bir test hatası değil. Bu, tek tek yapılan manuel tıklamanın yapısal olarak bulamayacağı bir hata kategorisidir, çünkü hata sadece birden fazla şey aynı anda gerçekleştiğinde var olur, ve tek başına test eden bir kişi bu durumu bilerek kolayca yaratamaz, tekrarlaması ise daha da zordur.

Bu, yapay zeka tarafından üretilen uygulamalar üzerine yapılan araştırmaların kimsenin hesaba katmadığı hata modu olarak işaretlediği tam da bu tür uç durumdur: yapay zeka, kendisinden istenen belirli başarı senaryosu için yollar kurar, eşzamanlı düzenlemeler, çift tıklamalar veya adımlar arası zamanlama boşlukları için değil. Ve ortaya çıkan bozulma bir hata fırlatmadığı için, haftalar sonra bir rapor veya bir bakiye hatalı görünene kadar sessizce orada durur.

Neredeyse hiç kimsenin bunu yakalayacak testleri yazmamasının nedeni

Bu hata sınıfı için dürüst çözüm otomatik testtir: birim testleri, entegrasyon testleri, bir insanın hayal gücüne ve sabrına güvenmek yerine beş eşzamanlı isteği simüle edip sonucu mekanik olarak kontrol edebilecek bir şey. Otomatik testler yorulmaz, bir uç durumu unutmaz, ve pazartesi düzelttiğin bir şeyin salı günü bozulmadığından emin olmak için her değişiklikten sonra yeniden çalıştırılabilir.

Pratikte, vibe coder’ların bu neredeyse hiç yoktur. Bir test paketi yazmak kendi başına teknik bir beceridir, hatta muhtemelen uygulamanın kendisini yazmaktan daha zor bir beceridir, çünkü sadece özelliğin çalışması değil, hata modları üzerine akıl yürütme gerektirir. Bir yapay zeka aracısı istersen testler yazabilir, ama birinin bunu istemesi gerektiğini bilmesi, testlerin gerçekte neyi kontrol ettiğini anlaması, ve uygulama altlarında değişirken bunları güncel tutması gerekir. Salı öğleden sonra bir müşteri portalı çıkaran teknik olmayan bir geliştirici için bu gidilemeyecek kadar uzak bir köprüdür, ve hızlı vibe coding yapan teknik geliştiriciler bile bir sonraki prompt’la zaten değiştirecekleri kod için test kapsamı yazmak üzere nadiren dururlar.

Yani çoğu vibe coding uygulamasında testin gerçekçi durumu şudur: bir kez yapılan, ne ters gidebileceğini tahmin etmeye en az donanımlı kişi tarafından yapılan tek bir happy path tıklama turu. Bu, güven açığıdır. Uygulamanın çalıştığını doğrulamıyorsun. Denediğin o tek şeye dayanarak çalıştığını umuyorsun.

‘Görsel kesinlik’ gerçekte ne anlama geliyor

Ummanın gerçek bir alternatifi var, ve bu “test paketleri yazmayı öğren” değil. Riskli kısımları, mantığın baştan gizli olmadığı bir temel üzerine inşa etmek.

Görsel kesinlik, bir ayarlar panelini açıp hangi kullanıcı grubunun bir kaydı görebildiğini, bir bloğun bir veri kaynağına tam olarak hangi filtreyi uyguladığını, ve bir iş akışının adım adım, sırasıyla tam olarak ne yaptığını, üretilmiş kodun bir satırını okumadan görebilmen anlamına gelir. Davranışı test edip arkasındaki kuralı çıkarmıyorsun. Kuralı doğrudan okuyorsun.

Bu, güven açığının en maliyetli olduğu kategoriler için en önemlisidir: faturalama mantığı, izinler, ve eşzamanlı kullanıcı içeren her şey. Softr gibi bir platform, izinleri, veri kısıtlamalarını ve iş akışı adımlarını, güvenmek için satır satır denetlemen gereken yapay zeka tarafından üretilmiş kod olarak değil, görsel ve denetlenebilir yapılandırma olarak tutarak bunu ele alır. Bir müşterinin başka bir müşterinin kayıtlarını görüp görmediğini bilmek istiyorsan, veri kısıtlama kuralını açar ve okursun. Beş eşzamanlı girişi simüle edip yapay zekanın yarış durumunu doğru ele aldığını ummana gerek yoktur, çünkü kuralı uygulayan şey platformun kendi test edilmiş altyapısıdır, yapay zekanın senin belirli prompt’un için yazdığı özel bir kontrol değil.

Bu, her özel işlevin bir ayarlar paneline dönüşüp kaybolduğu anlamına gelmez. Gerçekten özel bir arayüz için, tek bir bileşene sınırlı ve platformun mevcut izin ve veri katmanı üzerinden bağlanan bir vibe coding bloğu, üretilmiş iş mantığının tümünü oluşturan bir uygulamadan çok farklı bir risktir, çünkü ‘yapay zeka bu bir kısmı yanlış yaptı’ hasarının kapsamı bir bloktur, faturalama sistemi değil.

Bunun seni gerçekte bıraktığı ayrım noktası

Uygulaman bir hafta sonu projesi veya kimsenin para vermediği bir prototipse, yayınla, happy path’te bir kez tıklayarak dolaş, ve devam et. Bahis tam olarak yaptığın manuel testin bahsidir.

Bir müşteri portalıysa, bir rezervasyon sistemiyse, kredi, bakiye veya rolleri olan bir şeyse, dürüst soru “bunu test ettim mi?” değildir. “Yanlış olsalar canımı yakacak kısımları gerçekten doğrulayabiliyor muyum, yoksa yapay zekanın sözüne mi güveniyorum?” sorusudur. Cevap güvense, bu daha önce İkinci Gün sorunu hakkında yazdığımız aynı ayrım noktasıdır, ve kim olduğuna bağlı olarak her iki dal da geçerlidir.

Kod okuyabiliyorsan, veya öğrenmeye istekliysen, bu açığı farklı bir araç değil, gerçek araçlarla kapat. Cursor gerçek bir kod tabanının içinde çalışır, burada eşzamanlılık testleri isteyip sonucu okuyabilirsin, ve Replit sana bir test paketini çalıştırmanın sonradan akla gelen bir şey değil, döngünün normal bir parçası olduğu bir bulut ortamı verir. Her iki durumda da açık, yapay zekanın yeteneği değildir, testi isteyip istemediğini bilip bilmemen ve onun iyi olup olmadığını anlayabilmendir.

Yapamıyorsan, ve yanlış bir iznin veya negatif bir bakiyenin gerçek bir sorun olduğu türden bir uygulama kuruyorsan, riskli kısımları kuralı tahmin etmek yerine okuduğun bir temele taşı. Eğer inşa ettiğin uygulama buysa, müşteri portalları sıralamamıza bak, çünkü yanlış bir tahminin en çok maliyete yol açtığı yer orasıdır.