Sorun: Ajan her şeyi “bir kere daha” yapar
Bir projede kural yoksa, ajan her görevde yeni bir karar verir. Bir bileşeni bir klasöre koyar, sonrakini başka bir yere. Bir yerde API endpoint’i yazar, başka bir yerde aynı işi farklı bir yöntemle yapar. Tek tek bakınca hepsi çalışıyor. Toplayınca ortaya kimsenin anlayamadığı bir proje çıkıyor.
Syntax’ın 1007. bölümünde Scott Tolinski bunu ev düzenine benzetti: Her eşyanın bir yeri varsa, eve yardıma gelen biri de onu doğru yere koyar. Yer yoksa, her şey tezgâhta yığılır. Ajan da o yardımcı gibi.
Bölümün ana fikri şu: Hangi aracı seçtiğin çok önemli değil. Önemli olan, bir seçim yapman ve ona sadık kalman. Yapay zekâ ile bir yöntemden diğerine geçmek artık kolay. Ama sekiz farklı yöntemi tek bir yönteme toplamak çok zor.
Sekiz karar
1. Veri şeması. En pahalı hata burada. Scott, bir ajanın neredeyse aynı iki kullanıcı tablosu oluşturup bunları birbirine bağladığını anlattı. Öneri: Tabloları ve içlerinde ne olacağını önce elle, düz bir metin olarak yaz. Wes ise bunun için doğrudan TypeScript tipleri yazmayı tercih ediyor. Sonra ajana “neyi atladım?” diye sor, ama tasarımı tamamen ona bırakma.
2. Tipler. Verinin veritabanında, API cevabında ve arayüzde nasıl göründüğünü baştan belirle.
3. Doğrulama (validation). Veri kaydedilmeden önce, sunucuda ve tarayıcıda kontrol ediliyor. Zod, Valibot ya da ArkType gibi bir kütüphane seç. Seçtiğin kütüphanenin Standard Schema uyumlu olmasına dikkat et. Standard Schema, bu kütüphanelerin ortak bir arayüzü. Başka bir araç da doğrulama istediğinde, aynı şemayı iki kez yazmak zorunda kalmıyorsun.
4. Sayfa yapısı ve yetki. Hangi sayfalar herkese açık, hangileri giriş gerektiriyor, yönetici sayfaları olacak mı? Basit bir madde listesi yeter. Kullanıcı varsa, verilerin çoğu bir kullanıcıya ait olacak. Bu yüzden giriş ve yetki sistemini en başta kurmak, sonradan her tabloya sahiplik eklemekten çok daha kolay.
5. CSS yöntemi. Tailwind mi, klasik CSS mi? Ortak temel stiller nerede? Karar yoksa ajan her yerde farklı isimlendirme kullanır. Sonuç da “yapay zekâ yapmış” belli olan bir arayüz olur.
6. Arayüz bileşenleri. Tarih seçici gibi parçalar için shadcn, Base UI ya da Cloudflare’in Kumo’su gibi bir kütüphane seç ve hep onu kullan.
7. İstemci-sunucu iletişimi. Tarayıcı sunucuyla API endpoint’leriyle mi, RPC ile mi, React Server Components ile mi konuşacak? Wes’e göre, karar versen bile ajan bazen kendi bildiği yolu seçiyor. Projeye bir iki örnek koymak bu yüzden önemli.
8. Klasör düzeni. Bileşenler nerede duracak? Sayfaya göre mi, özelliğe göre mi gruplanacak? Emin değilsen benzer projelere bak ya da ajana öneri sor. Ama kararı yazıya dök.
Kararı ajana nasıl söylersin?
Kararları kafanda tutman yetmez. AGENTS.md gibi talimat dosyalarına, skill’lere ve örnek kodlara yaz. Daha da iyisi, bir linter’la denetle. Örneğin Stylelint, CSS kurallarına uymayan kodu yakalayabilir. Kuralı yazmanın ötesine geçip otomatik bir kontrole bağlamanın yollarını ajanı raylarda tutmak yazısında topladık.
Ve son bir not: Bu kararlar taşa yazılmış değil. İşe yaramıyorsa değiştir. Amaç, değişikliği tek bir düzenden diğerine yapabilmek.
Düşün
- Bugünkü projende bu sekiz karardan hangisi hiç verilmedi, sadece “kendiliğinden” oluştu?
- Projendeki bir kuralı yazıya dökmek yerine bir linter ya da teste çevirebilir misin?
Videoyu izle
Kaynaklar (2, İngilizce)
Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.