Vibe Coding ile Yaptığın Uygulama Sürekli Bozuluyorsa

Yapay zekayla ilk uygulamanı yaptın ve çalıştı. Belki müşterilerin kullanıyor, belki ekibin. Belki bir tanesinden para bile kazanıyorsun.

Sonra ikinci duvar geldi.

Bir yerini düzeltiyorsun, başka bir yeri bozuluyor. Kurallarını bir dosyaya yazdın ama uymuyor. Üç projen var, ikisi ayakta, biri bir türlü rayına oturmuyor. Ve en sinsi olanı: çalışıyor gibi görünüyor, ama doğru çalıştığından emin değilsin.

Bunları yaşıyorsan acemi olduğun için değil. Tam tersi: ancak gerçekten bir şey yapmış insanlar bu duvara çarpar. Hiç uygulama yazmamış birinin "kural dosyam okunmuyor" diye bir derdi olmaz.

Bu yazıda dört yaygın şikâyeti tek tek ele alacağız. Her birinin altında bugün deneyebileceğin bir ilk adım var. Sonunda da dördünün ortak sebebini konuşacağız — çünkü aynı kökten çıkıyorlar.

1. "Çalışıyordu, şimdi her hafta bir yeri bozuluyor"

En sık duyulan şikâyet bu. Uygulama ayakta, insanlar kullanıyor, ama her değişiklikten sonra başka bir yer patlıyor. Bir tuşu düzeltiyorsun, form bozuluyor. Formu düzeltiyorsun, kayıt kaybolmaya başlıyor.

Sebebi genellikle şu: yapay zeka her seferinde projeni sıfırdan tanıyor. Sen üç ay önce neyi neden öyle yaptığını biliyorsun; o bilmiyor. Her yeni oturumda kodun içine bakıp tahmin ediyor. Tahmin tuttuğu sürece iyi gidiyor, tutmadığı yerde bir şeyi kırıyor.

Bu yüzden en kritik dosya, kodun kendisi değil: projenin ne olduğunu, hangi kuralların asla bozulmaması gerektiğini anlatan bir proje dokümanı. Çoğu kişide bu dosya hiç yok.

2. "Kural dosyası yazdım ama okumuyor"

Dosyayı yazdın, kuralları koydun, yine de aynı hataları yapıyor. İki sebebi var ve ikisi de tahmin ettiğinden farklı.

Birincisi: dosya şişmiş. Her yeni kuralı alta ekleye ekleye dosya yüz kilobaytı geçiyor. O boyuttaki bir metin artık "kural" gibi değil, "arka plan gürültüsü" gibi davranıyor — içindeki kritik üç satır, iki yüz satırlık ayrıntının arasında kayboluyor.

İkincisi: kural değil, dilek yazılmış. "Kod temiz olsun" bir kural değil. "Veritabanı şemasını değiştirmeden önce bana sor" bir kural. Birincisi yorumlanır, ikincisi uygulanır.

Bir katılımcının yüz otuz kilobaytlık kural dosyası, parçalara bölündükten sonra dokuz kilobayta indi — ve o günden sonra kurallar tutmaya başladı. Kaybolan bir şey yoktu; sadece her kural, ilgili olduğu yerin yanına taşınmıştı.

3. "Üç projem var, biri bir türlü rayına oturmuyor"

Bu da çok yaygın: birkaç uygulama yapmışsın, çoğu iş görüyor, ama bir tanesi sürekli yarım. Her oturduğunda bir parçasını düzeltiyorsun, ertesi hafta başka bir parçası dökülüyor. Diğerlerine ayıracak vakit de kalmıyor.

Buradaki tuzak, o projenin "daha zor" olması değil. Genellikle diğerlerinden daha büyük başlamış olması. Küçük bir araç tek oturumda kurulur ve biter; büyük bir sistem aynı yöntemle kurulunca her hafta bir yerinden açılır.

Çözüm sezgiye aykırı: yazma kısmını değil, planlama kısmını uzatmak. Ne yapılacağı yeterince netleştiğinde yazma işi zaten hızlı bitiyor. Netleşmediğinde ise yazmak hiç bitmiyor.

4. "Testler geçiyor ama doğru çalıştığından emin değilim"

En sinsi olanı bu. Uygulama açılıyor, tıkladığın her şey çalışıyor, hatta testler bile geçiyor. Yine de içine sinmiyor — ve haklısın.

Bir derste tam olarak bunu gördük. Otuz dört testi geçen bir uygulamaya kod incelemesi yaptırdık: on bulgu çıktı, ikisi doğrudan veri kaybına yol açıyordu. Otuz dört test, o iki hatanın hiçbirini yakalamamıştı. Çünkü testler senin düşündüğün durumları kontrol eder; düşünmediğin durumları değil.

"Test geçti" ile "doğru çalışıyor" aynı şey değil. Aradaki farkı kapatmanın en hızlı yolu, kodu yazan araca kendi yazdığını denetletmek — ama bunu ayrı bir iş olarak, ayrı bir gözle istemek.

Dördünün ortak sebebi: kervanı yolda düzmek

Dört şikâyet farklı görünüyor ama aynı kökten çıkıyor: projeyi yürürken kurmak.

Bu, başlangıçta doğru olan bir yöntemdi. İlk uygulamanı yaparken ne istediğini de yaparak öğrendin; plan yapmaya kalksan hiç başlayamazdın. Ama aynı yöntem, gerçek kullanıcısı olan bir sistemde farklı sonuç veriyor. Yolda düzülen kervanın içinde ölü kodlar, unutulmuş kararlar ve kimsenin hatırlamadığı istisnalar birikiyor. Üç ay sonra o kodun neden öyle yazıldığını sen de bilmiyorsun.

İkinci duvarı aşmak yeni bir araç öğrenmek değil. Yöntemi değiştirmek: önce karar, sonra kod. Kuralları yazılı ve küçük tutmak. Yazdırdığını denetletmek. İşi tek seferde değil, parçalar hâlinde istemek.

Bunların hiçbiri zor değil. Zor olan, çalışan bir şeyin üstünde bunu tek başına yapmak — çünkü her değişiklik gerçek bir kullanıcıyı etkiliyor ve deneme yanılma lüksün kalmıyor.

Nereden başlamalı

Yukarıdaki dört ilk adımı bugün kendi projende deneyebilirsin; hiçbiri için bir şey satın alman gerekmiyor. Çoğu kişi ilkini uyguladığında farkı hemen görüyor.

Takıldığın yer daha derindeyse — elinde gerçekten kullanılan bir sistem var ve onu bozmadan düzeltmen gerekiyorsa — bunu birlikte yapmak daha hızlı oluyor. Kendi projen üzerinde, kendi verinle çalışıyoruz: önce neyin neden bozulduğunu buluyoruz, sonra yöntemi kuruyoruz.

Bireysel eğitim ve danışmanlık sayfasına göz at — başlangıç noktası otuz dakikalık ücretsiz bir tanışma görüşmesi. Uygun olmadığını düşünürsem bunu da söylüyorum.

Daha yeni başlıyorsan ve henüz ilk uygulamanı yapmadıysan, sıralama farklı: önce ilk projeni seçmek, sonra ne istediğini anlatmayı öğrenmek daha doğru. Bu yazıdaki sorunlar, o aşamayı geçtikten sonra başlıyor.