Vibe Coding Yöntemi: 7 Pratik İpucu ve Prompt Yazma Sanatı

İlk vibe coding denemenizi yaptınız, kod çalıştı. Tebrikler. Şimdi asıl soru: aynı kod altı ay sonra hâlâ çalışıyor mu, yeni bir özellik eklediğinizde eskiyi bozuyor mu, başka bir geliştirici bu kodu okuyabiliyor mu? Bu yazıda "çalışıyor" hâlinden "sürdürülebilir çalışıyor" hâline geçmenin yedi somut yöntemini anlatıyorum. Bunlar kendi projelerimde ve öğrencilerimde uyguladığım, tekrar tekrar işe yarayan pratikler.

Yapay zekâyla yazılım geliştirmek "prompt yazmak" değil, karar vermeyi, küçük görevleri ve denetimi bilmektir. Aşağıdaki yedi yöntem de bunu hedefler.

1. Mimari kararı belgeleyin, sonra modele verin

Yapay zekânın en çok tökezlediği yer kendisine söylenmemiş kararlar. "Veri nereye yazılacak?", "kullanıcıya ne kadar güveneceğiz?", "hangi değer sunucudan gelecek?" — bunlar modele bırakıldığında her dosyada farklı cevap çıkabilir. Kod çalışır, ama tutarsız.

Çözüm: Karar belgesi (decision document). Projenin kökünde ARCHITECTURE.md veya DECISIONS.md adında tek bir dosya. İçinde:

• Güven sınırı. Hangi değerler istemciden gelir, hangileri sunucuda hesaplanır?
• Veri sahipliği. Hangi tabloda hangi alan, hangi serviste hangi mantık?
• Ürün kuralları. "Bir kullanıcı günde en fazla şu kadar...", "ödeme başarısızsa şu olur..."
• Teknoloji seçimleri. "PHP + MySQL, çünkü...", "Firebase yalnızca kimlik ve bildirim için."

Bu belge 50-100 satır uzunluğunda olabilir. Yazımı sizin, ama modele her verdiğiniz görevde "karar belgesine uygun yaz" diye hatırlatmanız yeterli. Çıkan kodun tutarlılığı fark edilir şekilde artıyor.

Somut örnek

LevelUpStudy projesinin karar belgesinde şu madde var:

Oyun ekonomisini belirleyen hiçbir değer istemciden gelmez. Süre = min(sunucu farkı, planlanan süre, istemcinin bildirdiği süre).

Bu tek madde, modelin "süre hesaplaması" ile ilgili her prompt'ta doğru cevabı vermesini sağladı. Aksi hâlde her dosyada farklı bir formül çıkabilirdi.

2. Küçük görev verin, büyük hedefi siz koruyun

"Uygulama yaz" prompt'u, modele bir hedef değil, bir hayal verir. Model o hayalin en kısa yoldan "çalışan" hâlini üretmeye çalışır; bu yol sizin istediğiniz yol değildir. "Tam uygulama" çıktısı genelde 500 satır, yarısı birbirine bağlı olmayan, yarısı tekrar eden koddur.

Onun yerine atomik görev verin. Örnek:

❌ "Bir e-ticaret uygulaması yaz"

✅ "Sepete ürün ekleme endpoint'ini yaz. Tek transaction. Aynı kullanıcı 100ms içinde aynı ürünü iki kez eklerse, yalnızca bir kez stok düşsün. Hata durumunda 422 dön."

Bu cümlede beş karar var: hangi endpoint, transaction kuralı, idempotency kuralı, davranış sınırı, hata cevabı. Model bu beş kararı uygulayacak kodu yazıyor. Siz de her bir kararı ayrı ayrı test edebiliyorsunuz.

Atomik görev, aynı zamanda hata ayıklamayı kolaylaştırır. "Sepete ekleme çalışmıyor" yerine "bu endpoint 422 dönüyor ama 500 olmalı" gibi spesifik şikayetler üretebilirsiniz.

3. Prompt'a "kontrol listesi" ekleyin

Modelin en sevdiğim özelliklerinden biri: ona ne kontrol etmesi gerektiğini söylerseniz, gerçekten kontrol ediyor. "Şu fonksiyonu yaz" yerine "şu fonksiyonu yaz, sonra şu 5 maddeyi kontrol et" deyin.

Örnek:

"Bu fonksiyonu yaz. Sonra şunları doğrula:

1. Edge case: input null ise ne dönüyor?
2. Aynı input iki kez verilirse aynı sonucu mu veriyor?
3. Hata durumunda exception fırlatıyor mu, sessizce yutuyor mu?
4. Yan etkisi var mı (veritabanı, dosya, network)?
5. Test edilebilir mi (saf fonksiyon mu, bağımlılıkları inject edilebiliyor mu)?"

Model bu kontrol listesini çıktıya ekliyor; siz de tek tek gözden geçiriyorsunuz. Bulduğu sorun varsa, "şu maddeyi düzelt" diye ikinci bir tur atıyorsunuz. İki-üç turda çok sağlam kod çıkıyor.

4. Testleri senkron tutun, koruma kalkanı yapın

Vibe coding'in en büyük güvenlik ağı testlerdir. Süre, puan, kimlik, yetki gibi kritik değerleri saf fonksiyonlara ayırıp testle korumak, modelin ileride aynı yeri bozmasını engelliyor.

Saf fonksiyon: dış dünyaya bağlı olmayan, aynı input için aynı output veren, yan etkisi olmayan fonksiyon. calculateScore(time, level) -> number saf bir fonksiyondur. updateUserInDatabase(userId, score) saf değildir çünkü veritabanına dokunur.

Kural: Kritik iş kuralı barındıran mantığı saf fonksiyona çekin. Para, puan, süre, yetki, sıralama — hepsi saf fonksiyon olabilir. Bu fonksiyonlara yazılan testler, modelin gelecekte aynı yeri değiştirip bozmasını engelliyor.

Pratiğim:

1. Yeni bir özellik eklerken önce iş kuralını saf fonksiyon olarak yazıyorum.
2. Saf fonksiyona test yazıyorum.
3. Modelden "bu saf fonksiyonu kullanarak endpoint'i yaz" diyorum.
4. Endpoint'i yazdıktan sonra "test hâlâ geçiyor mu" diye soruyorum.

Bu dört adım, "çalışıyor ama yanlış hesaplıyor" hatalarını büyük ölçüde engelliyor.

5. Denetim sorularını rutine çevirin

Her faz bittiğinde, modele üç denetim sorusu sormak alışkanlık hâline gelsin:

1. "Bu dosyada erişilemeyen kod var mı?"
   Model, ulaşılmayan fonksiyonları, dead code'u, eski parametrelerini sayar. Siz de silersiniz.
2. "Tekrar eden fonksiyon var mı?"
   Model, benzer iş yapan ama farklı isimde fonksiyonları listeler. Birleştirme kararı verirsiniz.
3. "Sihirli string (magic string) var mı?"
   Model, doğrudan yazılmış string'leri (ör. "Kalem", "TR", "YKS") sabitlere taşımayı önerir.

Bu üç soruyu her sprint sonunda sormak, "çalışan ama spagetti olan" kodu önler. Model ürettiği kodun kalitesini kendisi denetlemez; sormayı unutursanız, sormadığınız için kötü kod üretmeye devam eder.

6. Refactor'ü ayrı bir faz olarak görün

Vibe coding'de yaygın hata: model yeni özellik yazarken, "bu arada şu kısmı da düzelteyim" demesine izin vermek. Sonuç: bir commit'te yeni özellik + refactor + bug fix karışır, geri almak zorlaşır.

Bunun yerine:

• Yeni özellik fazı: sadece yeni iş.
• Refactor fazı: sadece düzenleme.
• Test fazı: sadece test.

Her faz sonunda "bu fazda ne yaptık, ne öğrendik, sırada ne var?" sorusu. Bu ayrım kaliteyi artırdığı gibi, bir şey bozulduğunda tek bir commit'i geri almanızı da mümkün kılıyor.

7. Prompt logunu tutun, tekrar eden kalıpları çıkarın

Vibe coding yaparken fark etmeden aynı prompt'u farklı yerlerde yazıyorsunuz. "Şu dosyayı anla, X kuralına uyarak Y fonksiyonunu yaz" gibi kalıplar. Bunları bir yere not edin.

Pratikte nasıl:

• Bir not dosyasında (PROMPT_PATTERNS.md) en iyi çalışan prompt kalıplarını tutuyorum.
• Her kalıbın yanında ne zaman işe yaradığını, ne zaman yaramadığını yazıyorum.
• Yeni bir proje açtığımda bu kalıplardan uygun olanı seçip düzenliyorum.

Bu alışkanlık, "her seferinde sıfırdan prompt yazma" yükünü azaltıyor. Aynı zamanda prompt yazma kasınız güçleniyor.

Bonus: prompt'un kendisini bozan beş şey

Yukarıdaki yedi yöntem yerinde olsa bile prompt'un yazılışı sonucu bozabilir. En sık gördüğüm beşi:

1. Kabul kriterini yazmamak.
   "Login endpoint'i yaz" ile "login endpoint'i yaz; yanlış şifrede 401, beş başarısız denemeden sonra 429 dönsün" arasındaki fark bir turdur. Kriteri yazmadığınızda o turu sonra ödüyorsunuz.
2. Bağlamı yapıştırmak yerine anlatmak.
   "Bizim bir User modelimiz var" demeyin, modelin tanımını yapıştırın. Model alan isimlerini tahmin ettiğinde kod derlenir ama veri tutmaz.
3. Gerekçe istememek.
   "Yaz" yerine "yaz ve neden böyle yazdığını açıkla" deyin. Yanlış varsayımı, kodu incelemeye başlamadan önce yakalarsınız.
4. Modele seçim yaptırmak.
   "Sence hangi kütüphane?" kötü bir sorudur; "şu üç kütüphaneden hangisi bu kısıtlara uyar?" iyi bir sorudur. Seçenekleri siz koyun, gerekçeyi model yazsın.
5. Tek turda mükemmel prompt beklemek.
   İyi prompt iteratif çıkar. İlk cevabı okuyun, modelin nerede yanlış anladığını bulun, yalnızca o cümleyi daraltın. Baştan yeniden yazmak neredeyse her zaman daha yavaştır.

Vibe coding gerçekten sürdürülebilir mi?

Yukarıdaki yedi yöntemi uygularsanız, evet. Yoksa: çalışan ama bakımı yapılamayan bir kod tabanı, her yeni özellikte artan borç, altı ay sonra "bu kodu kim yazdıysa silsin" noktası.

Sürdürülebilirlik için gereken şey ritim:

1. Karar ver.
2. Küçük görev ver.
3. Testi senkron tut.
4. Denetimini yap.
5. Refactor'ü ayrı tut.
6. Prompt logu tut.

Bu ritim, modelin üretkenliğini geliştiricinin disipliniyle birleştiriyor. Vibe coding böyle çalıştığında, bir yandan hız kazanıyorsunuz, öte yandan kodu aylar sonra bile açıp anlayabiliyorsunuz.

Son söz

Vibe coding bir araç değil, bir yöntem. Araçlar değişir (yarın belki başka bir model öne çıkar) ama yöntem kalır: karar ver, küçük görev ver, testi senkron tut, denetle.

Daha derli toplu bir başlangıç için Vibe Coding rehber sayfasına bakabilirsiniz. Kullanılan araçları somut senaryolarla karşılaştırmak isterseniz Vibe Coding araçları karşılaştırması yazısı işinizi görür.

Vibe coding ile gerçek bir uygulamanın nasıl çıkarıldığını görmek isterseniz: Vibe Coding ile App Store'a Uygulama Çıkarmak — LevelUpStudy'nin hikâyesi.

Sık Sorulan Sorular

Vibe coding prompt'u nasıl yazılır?

Prompt'un üç parçası olsun: amaç (ne yapılacak), kısıt (hangi kurallara uyulacak), kabul kriteri (ne zaman "bitti" denir). Örnek: "Sepete ürün ekleme endpoint'i yaz. Tek transaction, idempotent. Hata durumunda 422 dön."

Vibe coding ile yazılan kodun kalitesi nasıl korunur?

Kritik iş kurallarını saf fonksiyonlara ayırıp testle koruyun. Her faz sonunda erişilemeyen kod, tekrar eden fonksiyon, sihirli string denetimi yapın. Refactor'ü ayrı faz olarak görün, yeni özellikle karıştırmayın.

Vibe coding'de en önemli ipucu nedir?

Kararları yazıya dökmek. Mimari karar belgesi olmadan modele verilen her prompt eksik. Bu tek alışkanlık, çıktı kalitesini fark edilir şekilde artırıyor.

Vibe coding ile hata nasıl ayıklanır?

Hatayı olduğu gibi yapıştırın, prompt'a "bu hatayı veren kodu bul, neden olduğunu açıkla, düzeltilmiş hâlini yaz" deyin. Modelin verdiği açıklamayı okumadan commit atmayın; bazen "düzeltme" aslında hatayı gizler.

Vibe coding öğrenmek için Türkçe kaynak var mı?

Türkçe içerik hâlâ sınırlı; bu yazı ve Vibe Coding rehberi Türkçe başlangıç noktası. İngilizce kaynaklar (Claude ve OpenAI blogları, Cursor docs) daha zengin. Modelleri Türkçe konuşturabilirsiniz ama teknik terimleri İngilizce yazmak tutarlı sonuç veriyor.