YZ’ye kıdemli bir mühendis gibi düşünmeyi öğretmek

• YZ kodlama araçlarında kod yazmadan önce önce plan yaptıran bir metodoloji ile hatalı uygulamaları önlemek ve geliştirme hızını artırmak mümkün
• 8 planlama stratejisi zorluk seviyesine göre uygulanıyor; her stratejide belirli ajanlar paralel araştırma yapıyor, ardından geliştirici değerlendirme ve karar alma sürecini yürütüyor
• Her strateji; hata yeniden üretme, en iyi pratikleri arama, mevcut kod tabanını analiz etme, git geçmişini inceleme gibi adımları içeriyor ve ajanın öğrendiği tercih ve kalıplar otomatik olarak birikiyor
• Açık kaynak olarak yayımlanan sistem Claude Code’a kurulabiliyor; ayrıca tek bir özellikle başlayıp geliştiricinin düşünme biçimini YZ’ye aşamalı olarak öğretecek şekilde ilerlemek de mümkün

---

YZ odaklı plan merkezli geliştirme yaklaşımı

• YZ kod yazmadan önce bir plan oluşturmasını sağlayan yaklaşım tanıtılıyor
  • Bu yaklaşım, yalnızca kod yazdırmaya kıyasla özellik geliştirme hızını artırıp hataları azaltıyor
• Örnek olarak, e-posta yönetim uygulaması Cora’nın “email bankruptcy” özelliğinin geliştirme süreci anlatılıyor
  • 53.000 e-postayı önemli iletileri kaybetmeden düzenleyen bu özellik uygulanırken, YZ araştırma ajanı ön analiz gerçekleştirdi
  • Gmail’in 2.000 öğe sınırı, sistem zaman aşımı ve kullanıcı bekleme süresi sorunları önceden tespit edilerek yanlış uygulama engellendi

8 planlama stratejisi

Strateji 1: Hatanın yeniden üretilmesi ve belgelenmesi

• Amaç: Düzeltmeden önce hatayı yeniden üretmek ve adım adım bir kılavuz oluşturmak
• Ne zaman kullanılır: Fidelity 1~2, özellikle hata düzeltmelerinde
• Email bankruptcy özelliği yayınlandıktan hemen sonra 19 kullanıcının işlemin başarısız olduğu bir durumda takılı kaldığı bir sorun yaşandı
  • AppSignal log’ları incelenerek yapılan teşhiste, Gmail hız sınırı hatasının production’da yok sayıldığı görüldü
  • Tek bir batch başarısız olduğunda tüm iş duruyor ama kullanıcıya bildirilmediği için kullanıcı yalnızca sonsuz yükleme göstergesi görüyordu
• Yeniden üretim sürecinde batch işleme ve işi kaldığı yerden sürdürme özelliğine ihtiyaç olduğu ortaya çıktı; yalnızca yeniden deneme yeterli değildi
• Bileşik etki: @kieran-rails-reviewer ajanının kontrol listesine “harici API çağıran arka plan işlerinde hız sınırı ele alınıyor mu, yeniden deneme var mı, kısmi durum sahipsiz bırakılıyor mu” maddeleri eklendi

Strateji 2: En iyi pratikleri araştırma

• Amaç: Benzer sorunların nasıl çözüldüğünü web’de aramak
• Ne zaman kullanılır: Tüm zorluk seviyelerinde, özellikle alışılmadık kalıplarda
• 2 sürüm geride kalmış bir gem yükseltilirken ajan şu aramaları yaptı: “X sürümünden Y sürümüne yükseltme yolu”, “sürümler arasındaki breaking change’ler”, “yaygın migration sorunları”
  • Resmî yükseltme kılavuzunun yanında aynı yükseltmeyi yapan mühendislerin 3 blog yazısı bulundu
  • 3 dakikalık araştırma, saatler sürebilecek deneme-yanılma hata ayıklamasını önledi
• Teknik olmayan kararlarda da kullanılabiliyor: “SaaS fiyatlandırma katmanı en iyi pratikleri”, “e-posta drip kampanyası dönüşüm metni”, “arka plan işi yeniden deneme stratejisi” gibi
• Bileşik etki: Yararlı kalıplar bulunduğunda bunlar otomatik olarak docs/*.md dosyalarına kaydediliyor; benzer bir soru geldiğinde sistem web aramasından önce önce bunlara bakıyor

Strateji 3: Kod tabanını araştırma

• Amaç: Mevcut kodda benzer kalıpları bulmak
• Ne zaman kullanılır: Mevcut işlevlerle çakışma ihtimali olan tüm işlerde
• Yeni bir özelliğe event tracking eklenmeden önce ajan kod tabanında şu sorularla arama yaptı: “Şu anda event tracking nasıl yapılıyor?”, “analytics çağrı kalıbı ne?”, “event’ler nereden gönderiliyor?”
  • Yardımcı metodlara kadar hazır olan mevcut bir tracking sistemi bulundu (yazarın unuttuğu bir sistemdi)
  • YZ kod tabanına bakmazsa bunu baştan yeniden kurmaya çalışıyor
• Yeni bir tracking sistemi oluşturmak yerine mevcut kalıp genişletildi ve uyumsuz ikinci bir sistemin kurulması önlendi
• Bileşik etki: “@event-tracking-expert” ajanı oluşturuldu; tracking gerektiren tüm özellik planlarında otomatik çalışıyor

Strateji 4: Kütüphane kaynak kodunu inceleme

• Amaç: Kurulu paketlerin ve gem’lerin kaynak kodunu doğrudan okumak
• Ne zaman kullanılır: Hızla değişen veya belgeleri yetersiz kalan kütüphanelerde
• RubyLLM gem’ine sürekli yeni model, parametre ve özellikler ekleniyor ama dokümantasyon geriden geliyor
  • Ajan RubyLLM kaynak kodunu analiz ederek şu sorulara baktı: “Kullanılabilir model seçenekleri neler?”, “hangi parametreler geçirilebilir?”, “son sürümde belgelenmemiş hangi özellikler var?”
  • “1.9 sürümünde streaming desteği eklendi ama belgelenmedi; test paketindeki parametre adları ve kullanım örnekleri bunlar” bilgisini sağladı
• Bileşik etki: Her bağımlılık güncellemesinde bilgi de otomatik güncelleniyor; böylece eski bilgilerle çalışılmıyor

Strateji 5: git geçmişini araştırma

• Amaç: Commit geçmişini analiz ederek geçmiş kararların niyetini anlamak
• Ne zaman kullanılır: Refactor, yarım kalan işe devam etme veya “neden”i anlamanın gerektiği durumlarda
• Eski bir EmailClassifier sürümünün kullanıldığı fark edilince, yükseltme denemesi öncesinde git geçmişinde şu sorular arandı: “Neden v1 kullanılıyor?”, “v2’ye yükseltme daha önce denendi mi?”
  • 3 ay önce başka bir ekip üyesinin açtığı bir PR bulundu: v2’ye yükseltilmiş ama inbox e-postaları archive’e, archive’deki e-postalar da inbox’a gidiyordu
  • PR tartışmasında, nedenleri ayrıntılı biçimde anlatılan bilinçli bir rollback kaydı vardı
• Bileşik etki: Kurumsal hafıza korunuyor ve aranabilir hale geliyor; yeni ekip üyeleri geçmiş kararların mantığını devralabiliyor

Strateji 6: Prototipleme ile gereksinimleri netleştirme

• Amaç: Ayrı bir ortamda hızlı prototipleme ile gereksinimleri netleştirmek
• Ne zaman kullanılır: Fidelity 3, UX belirsizliği veya keşif odaklı işlerde
• E-posta Brief arayüzü yeniden tasarlanırken Claude içinde 5 farklı yerleşim prototipi 5’er dakikada oluşturuldu
  • Bunlar bizzat tıklanarak sorunlu noktalar görüldü ve bazı kullanıcılara en iyi sürüm gösterildi
  • Bir kullanıcı geri bildirimi: “Yerleşim bunaltıcı ve e-postayı nasıl archive edeceğimi bilmiyorum”
• Bu içgörü daha sonra gerçek plandaki gereksinime dönüştü: “archive butonu sol üst köşede olmalı — kullanıcının kas hafızası Gmail’de bunu o konumda bekliyor”
• Bileşik etki: Prototipleme belirsizliği somut spesifikasyona dönüştürüyor ve kullanıcı tepkilerini belgeliyor

Strateji 7: Seçeneklerle birlikte sentezleme

• Amaç: Tüm araştırmayı, trade-off’ları da içeren tek bir planda birleştirmek
• Ne zaman kullanılır: Araştırma aşaması bittikten sonra, implementasyondan önce
• Strateji 1~6 uygulandıktan sonra ajan şu sentezi yapıyor: “Bu araştırmaya dayanarak sorunu çözmenin 3 yolunu öner. Her yaklaşım için uygulama karmaşıklığı, performans etkisi, bakım yükü ve eşleşen mevcut kalıpları belirt.”
• Gmail inbox senkronizasyonu örneği:
  • Seçenek A—mevcut senkronizasyon sistemini kullanmak: Hızlı implementasyon, ama kod tekrarına ve sorumlulukların zayıf ayrışmasına yol açıyor
  • Seçenek B—gerçek zamanlı senkronizasyon: Temiz bir mimari, ama yavaş olabilir ve güvenilirlik sorunları çıkarabilir
  • Seçenek C—ayna önbellekleme sistemi kurmak: Uzun vadede en iyi çözüm ve en temiz ayrım, ama başlangıçtaki iş yükü en yüksek
• Karşılaştırma görüldükten sonra 30 saniyede bilgiye dayalı bir seçim yapılabiliyor
• Bileşik etki: Yapılan seçim tercihleri ortaya koyuyor; örneğin “önce uyumluluk” tercihi işaretlenirse sistem bir sonraki benzer kararda uyumluluğa daha yüksek ağırlık veriyor

Strateji 8: Stil ajanı incelemesi

• Amaç: Tamamlanmış planı, geliştirici tercihlerini kontrol eden uzman bir review ajanına vermek
• Ne zaman kullanılır: Nihai plan aşamasında, implementasyondan önce
• Otomatik çalışan 3 review ajanı:
  • Basitleştirme ajanı: aşırı mühendislik uyarısı verir; “Bu özellik gerçekten 3 veritabanı tablosu mu gerektiriyor? type alanı olan tek bir tablo yetmez mi?”
  • Güvenlik ajanı: yaygın açıkları kontrol eder; “Bu plan kullanıcı girdisinin doğrudan veritabanı sorgusuna girmesine izin veriyor — input sanitization eklenmeli”
  • Kieran stil ajanı: kişisel tercihleri uygular; “Karmaşık join kullanılıyor, Kieran daha basit sorguları tercih ediyor, denormalization düşünülmeli”
• Bileşik etki: Ajan zamanla geliştiricinin zevk ve tercihlerini biriktiriyor; “bundan hoşlanmıyor” veya “iyi yakaladın” gibi işaretlemelerle sistem öğreniyor

Başlarken

Bugün hemen deneyebileceğiniz yöntem

• Every’nin Github Marketplace’i üzerinden planlama sistemi açık kaynak olarak yayımlandı
• Claude Code’a kurulduğunda /plan slash komutu ve araştırma ajanları hemen kullanılabiliyor
• Eklenti Claude Code veya Droid içinde kullanılabiliyor

Basit bir başlangıç yöntemi

• Bu hafta üzerinde çalıştığınız tek bir Fidelity 2 özelliği seçin: birden fazla dosyaya yayılan ve kapsamı net olan bir iş (yeni görünüm ekleme, geri bildirim sistemi uygulama, component refactor etme gibi)
• Claude Code ya da Cursor’dan geliştirme istemeden önce 15~20 dakikalık araştırma yaptırın:
  1. En iyi pratikler: Başkaları bunu nasıl çözüyor? Web’de blog yazıları, Stack Overflow ve dokümanları arayın
  2. Kendi kalıplarınız: Siz bunu nasıl çözüyorsunuz? Mevcut kod tabanında benzer işlevleri arayın
  3. Kütüphane yetenekleri: Kullandığınız araç gerçekte neyi destekliyor? YZ ile dokümanları veya kaynak kodu okutun
• YZ’nin bu araştırmayı şu maddeleri içeren bir planda sentezlemesini sağlayın:
  1. Çözülecek problem (tek ve net bir cümle)
  2. 2~3 çözüm yaklaşımı (her biri için dürüst artı ve eksiler)
  3. Eşleşmesi gereken mevcut kod kalıpları
  4. Edge case’ler veya güvenlik değerlendirmeleri
• Planı gözden geçirin ve tepkinizi izleyin: “fazla karmaşık” veya “zaten daha iyi bir yol var” diye düşünüyorsanız, yalnızca planı düzeltmeyin; neden böyle düşündüğünüzü yakalayıp kaydedin
• Planı temel alarak özelliği yayınlayın; son implementasyon ile ilk planı karşılaştırın. Nerede ayrıştı? Neden? Planı ne daha iyi yapabilirdi?
• 10 dakika ayırıp bir öğrenimi yazılı hale getirin: CLAUDE.md dosyasına ekleyin; “X türü işlerde Y kontrolünü unutma” ya da “C gerekçesiyle B yerine A yaklaşımı tercih edilir” gibi tek bir kural yazın
• Öğrenimler biriktikçe özelleşmiş araştırma ajanları veya komutlar oluşturun: “Event Tracking Expert” (sizin kalıplarınızı bilen), “Security Checker” (yaygın hataları işaretleyen)
• Gelecek hafta tekrarlayın, notlara bakın, ikinci planın ilkinden daha iyi olup olmadığını kontrol edin ve birkaç ay sonra geliştiricinin düşünme biçimini bilen bir sistem kurun