<p>Son günlerde Claude Code todo listesine rastladım:</p>

<div class="highlight js-code-highlight">
    <pre class="highlight plaintext"><code>✓ Tüm ekran görüntülerini oku ve tanımla

<p>Dört adım. Temiz bir plan. Bir vibe kodlayıcısının ekran görüntüsü alıp <em>"AI şu an inanılmaz."</em> başlığı ile paylaşacağı türden bir şey.</p>

<p>Gerçekten de iyi bir plan. Çoğu projeden daha iyi. Ancak, aynı zamanda 30 güzel yazılmış belgenin birbirini sessizce çelişmesi ihtimaline bir adım daha yakın.</p>

<p>Bu stratejinin neden işe yaradığını, nerede bozulduğunu ve AI'nızın bir iş gereksinimini yazmadan önce ekleyeceğim bir adımı anlatayım.</p>

<h2><a name="the-strategy-decoded" href="#the-strategy-decoded">Strateji’nin İncelenmesi</a></h2>

<p>Herhangi bir şeyi eleştirmeden önce, bir yere kredi vermek gerekir. Bu iş akışı, çoğu vibe kodlama oturumunda olmayan üç şeye sahiptir.</p>

<p><strong>Ekran görüntülerini gerçek bilgiler olarak kullanıyor.</strong> Çoğu kişi vibe kodlamaya kafalarındaki belirsiz bir fikirle başlar — <em>"Bana ClickUp gibi ama daha ucuz bir proje yönetim uygulaması yap."</em> AI'nın somut bir şeyi referans alacak hiçbir şeyi olmadığından, ortalama bir CRUD uygulaması hayal eder ve sen de üç gününü bunu düzeltmekle harcarsın. Ekran görüntüleri bunu tersine çevirir. Onlar somuttur. Gerçek durumlar, veriler ve kenar durumları gösterir. Ekran görüntüsüne bakan bir AI, bir isteği dinleyene kadar çok fazla uzaklaşamaz.</p>

<p><strong>Belgelerden önce kategorize ediyor.</strong> "4 grup" adımı burada sık duyulmayan bir kahramandır. Gruplama olmadan, otuz ayrı belgesel gereksinim ile sonuçlanırsınız ve bunlar arasında kelime dağarcığı ortak olmaz. Gruplama, model tanıma zorlar — <em>bu sekiz ekran aynı varlığın CRUD'u, bu beş ekran raporlama, bu üç ekran ayarlama.</em> Bu kümelenme doğal olarak <strong>modüllere</strong> veya <strong>sınırlandırılmış bağlamlara</strong> haritalanır ve bu, belgeleri koda dönüştürmeye başladığınızda tam olarak istediğiniz şeydir.</p>

<p><strong>Atomik, gözden geçirilebilir belgeler üretiyor.</strong> Her ekran görüntüsü için bir BRD. Küçük, kendi içinde tutarlı, kolay karşılaştırılabilir, Claude Code'a <em>"bu spesifikasyon için Livewire bileşeni oluştur."</em> gibi bir yönerge vermek kolay. Bir BRD üzerinde iterasyon yapabilir, tüm projeyi yeniden yazmadan devam edebilirsiniz.</p>

<p>Bu gerçekten iyi bir temel. Burada okumayı bırakırsanız ve bunu uygulamaya geçerseniz, çoğu ekipten ileride olursunuz.</p>

<p>Ancak burada durmayacağız.</p>

<h2><a name="failure-mode-1-brds-without-a-shared-vocabulary" href="#failure-mode-1-brds-without-a-shared-vocabulary">Başarısızlık Modu #1: Paylaşılan Bir Kelime Dağarcığı Olmadan BRD'ler</a></h2>

<p>Kategorilemeden doğrudan BRD yazmaya geçerseniz ne olur? Ekran görüntüsü 03 bir müşteri listesini gösteriyor. AI şöyle yazar: <em>"Sistem,  Müşterileri  pagine edebilecek bir liste gösterecektir."</em></p>

<p>Ekran görüntüsü 11 bir müşteri detay sayfasını gösteriyor. AI şöyle yazar: <em>" Üye  profili şunları içerecektir..."</em></p>

<p>Ekran görüntüsü 19 aynı kişinin giriş yaptığını gösteriyor. AI şöyle yazar: <em>"Kimlik doğrulaması yapıldığında,  Kullanıcı  yönlendirilecektir..."</em></p>

<p>Ekran görüntüsü 24 bir B2B iletişim görünümünü gösteriyor. AI şöyle yazar: <em>"Her  Hesap  bir ana iletişim kişisine sahiptir..."</em></p>

<p>Müşteri. Üye. Kullanıcı. Hesap. Dört kelime. Aynı varlık. Farklı belge. Farklı yazar oturumu. Farklı vibe.</p>

<p>Şimdi bu 30 BRD'yi Claude Code'a besleyip göçler oluşturmasını söylediğinizi hayal edin. Ne olduğunu izleyin.</p>

<p><code>customers</code> tablosunu, <code>members</code> tablosunu, (muhtemelen Laravel'ın varsayılanından) <code>users</code> tablosunu ve bir <code>accounts</code> tablosunu alıyorsunuz. Hiçbiri birbirini referans almıyor. Eloquent ilişkileri tahmin. Eylemlerinizin yarısı <code>Customer $customer</code> alıyor, diğer yarısı <code>User $user</code> alıyor ve form talepleriniz her ikisini de yer değiştirerek kullanıyor.</p>

<p>Bu, ekran görüntüsü odaklı iş akışlarında gördüğüm en yaygın başarısızlıktır ve demo sırasında asla görünmez. Üçüncü haftada, kod tabanınızın yarısının birbirini görmezden geldiğini fark ettiğinizde açığa çıkar.</p>

<p><strong>Çözüm, bir kelime dağarcığı çıkarma adımıdır.</strong> Herhangi bir BRD yazılmadan önce, şu şekilde bir <code>glossary.md</code> üretirsiniz:</p>

<div class="highlight js-code-highlight">
    <pre class="highlight markdown"><code>| Terim     | Tanım                                   | Takma Adlar               |

|———–|—————————————-|————————–|
| Müşteri | Hizmet satın alan bir organizasyon | Hesap, Müşteri |
| Üye | Bir Müşteri içindeki bireysel kullanıcı | Kullanıcı, İletişim, Personel |
| Sipariş | Bir satın alma işlemi | Satış, Fatura (gayri resmi) |