SIFIRDAN VIBE CODING - GÜN 13
Claude Code’un yaratıcısı Boris Cherny aynı anda 10-15 session açıyor. Hiçbirinde ilk iş kod yazmak değil. İlk iş her zaman plan yazmak. Kendi sözüyle: “İyi bir plan varsa, uygulama neredeyse her seferinde tek seferde doğru çıkıyor.”
Dün iyi prompt yazmayı konuştuk. Bugün o promptu ne zaman ve nasıl vereceğini konuşuyoruz. Çünkü doğru promptu yanlış anda vermek, yanlış prompt vermekten daha tehlikeli.
1. Tek dev prompt sorunu
“Kullanıcı giriş yapabilsin, profil düzenleyebilsin, ödeme alabilsin, dashboard görsün” diye tek seferde yazdığında Claude hepsini birden yapmaya çalışır. İlk 3-4 dosya iyi gider, sonra kararlar çelişmeye başlar. Auth yapısıyla ödeme akışı uyumsuz çıkar, dashboard’un beklediği veri modeli profil sayfasındakiyle tutmaz. Bir analize göre 7 dosyaya dokunan tasklarda tek prompt ile ilk denemede doğru sonuç alma oranı yaklaşık @. Plan mode ile bu oran w’ye çıkıyor. Sebebi basit: Claude kodu yazmaya başlamadan önce düşünme şansı buluyor.
2. Plan mode nedir, nasıl açılır
Shift Tab’a iki kez bas. Alttaki göstergede “plan mode on” yazısını gör. Bu kadar. Claude artık hiçbir dosyayı değiştiremez, hiçbir komut çalıştıramaz. Sadece okur, analiz eder, sana sorular sorar ve bir plan çıkarır. Planı beğenmezsen düzelt, beğenirsen onayla, o zaman yazmaya başlar. /plan komutuyla da aynı şeyi yapabilirsin. Terminal yerine VS Code kullanıyorsan mod seçiciyi tıklayıp Plan Mode’u seçmek de yeterli.
Ctrl G ile planı kendi editöründe açıp doğrudan düzenleyebilirsin. Claude’a “şunu değiştir” demek yerine dosyayı kendin editlemek çok daha hızlı.
3. Araştır, planla, uygula
Boris Cherny’nin ekibindeki standart akış şöyle çalışıyor: Plan mode’a gir, Claude’a konuyu araştırt. “Mevcut auth yapısını incele, hangi dosyalar etkilenecek, bağımlılıklar ne” gibi bir okuma talimatı ver. Claude codebase’i tarar ve bulgularını paylaşır. Sonra bu bulgular üzerinden plan oluştur, birkaç tur gidip gelerek olgunlaştır. Planı onayladıktan sonra auto-accept mode’a geç ve uygulat.
Uygulama sırasında senin rolün mimar olmaktan denetçiye dönüşüyor. Kısa, net düzeltmeler yeterli: “Bu fonksiyonu implement etmedin” veya “Bu sayfa ana app’te değil admin app’te olmalı.” Claude planın tüm bağlamını tutuyor, uzun açıklamaya gerek yok. Cherny’nin ekibinde bir kural daha var: Claude her hata yaptığında o hata CLAUDE.md’ye kural olarak ekleniyor. Aynı hatayı bir daha yapma olasılığı düşüyor, proje olgunlaştıkça Claude da olgunlaşıyor.
4. Constraint anchoring: sınırları önceden koy
Plan mode kullansa bile Claude’un sapabileceği noktalar var. Bunları promptu içine constraint olarak göm. Dosya sayısı, kullanılacak library, dokunulmaması gereken klasörler, test stratejisi. “Testleri en sona bırak” diyen planlar kötü sonuç veriyor çünkü Claude kendi çıktısını doğrulayamadan ilerliyor. Her aşamanın kendi testini içermesini iste. Somut bir örnek: “Bu refactor sadece /api klasörünü etkilesin, frontend’e dokunma, her endpoint için test yaz, toplam 5 dosyadan fazla değiştirme.”
5. Ne zaman plan mode, ne zaman direkt prompt
Pratik kural: 3 veya daha fazla dosyaya dokunan her iş için plan mode aç. Tek dosyada basit bir bug fix, hızlı bir stil değişikliği, bildiğin bir pattern’in uygulanması gibi işlerde direkt prompt yeterli. Bir de şu var: bir şeyler ters gittiğinde dur ve yeniden planla. Hata üstüne hata düzeltmek yerine geri adım at, plan mode’a geç, nerede sapıtıldığını bul.
Özet:
Plan mode’u aç, küçük bir feature için plan oluştur ama henüz uygulama. Planı Ctrl G ile editörde aç, elle düzenle.
Bir sonraki taskında araştır, planla, uygula döngüsünü dene.
Promptlarına dosya sınırı ve test beklentisi gibi constraint’ler ekle.
Basit işlerde direkt prompt, karmaşık işlerde plan mode. Farkı bir kez görünce geri dönmezsin.
Yarın context engineeringe giriyoruz. Claude’un projeyi gerçekten anlaması için context windowu nasıl yönetirsin, token nereye harcanır, dolunca ne olur.