1. Önce çıktıyı değil, problemi tarif et
Bir kod asistanına “giriş ekranı yap” demek hızlı bir başlangıç sağlar; fakat neyin doğru olduğunu tanımlamaz. İstenen davranış belirsiz olduğunda model kendi varsayımlarını ekler. Bir oturumun ne kadar süreceği, başarısız girişte hangi mesajın gösterileceği veya erişim kontrolünün nerede yapılacağı bunlardan birkaçıdır. İşe ekranın görünüşüyle değil, kullanıcının tamamlayacağı işlemle başla.
Örneğin bir okuma listesinde kullanıcı bir makaleyi kaydedecekse şu sınırları yaz: liste kullanıcıya ait olacak, aynı makale ikinci kez eklenmeyecek, oturum kapalıysa istek reddedilecek. Kabul ölçütünü de görünür bir sonuca bağla: kaydet düğmesine basıldığında öğe listede görünür; sayfa yenilendiğinde kalır. Bu tarif, üretilen kodu incelemek için bir ölçü verir.
Tek istemle bütün uygulamayı istemek yerine bir davranışı uçtan uca ele al. Önce veri ve yetki kuralı, sonra sunucu işlemi, ardından arayüz. Bu küçük dilimlerin her biri bağımsız kontrol edilebildiğinde, hatalı bir varsayımın bütün projeye yayılması daha zordur.
2. Bağlamı ver, sırları çıkar
Asistanın dosya yapısını, kullanılan teknolojiyi ve ilgili sözleşmeyi bilmesi gerekir. Tüm depoyu rastgele paylaşmak yerine değişecek akışın girişini ve çıkışını göster. Hangi dosyaların değiştirilmemesi gerektiğini açıkça yaz. Özellikle var olan projelerde bir isimlendirme tercihi bile gereksiz yeniden yazıma dönüşebilir.
Gerçek API anahtarını, üretim veritabanı parolasını veya müşteriye ait kişisel kayıtları örneğe koyma. Test verisini sen üret; sahte olduğu belli olan adlar ve example.com adresleri kullan. Bir anahtar yanlışlıkla paylaşıldıysa mesajdan silmek tek başına yeterli kabul edilmez: ilgili hizmette iptal ve yeniden üretim gerekir. Paylaşacağın günlük kaydını da aynı gözle incele.
Görev: Kullanıcının okuma listesine makale ekle.
Mevcut yapı: PHP API + sunucuda oturum doğrulaması.
Kurallar: Yalnızca kendi listesine yazabilir. Tekrarlı kayıt oluşamaz.
Kabul: Oturumsuz istek 401; başka listeye erişim reddedilir.
Sınır: Giriş akışını ve mevcut URL'leri değiştirme.
Doğrulama: Başarılı ekleme ve iki olumsuz senaryoyu göster.3. Öneriyi küçük farklar halinde incele
Çalışan kod, doğru kodla aynı şey değildir. Önce değişen dosyaları ve satırları gözden geçir. Asistan yalnızca bir bileşen eklerken bağımlılıkları yükseltmiş, erişim kontrolünü kaldırmış veya hata mesajlarını gizlemiş olabilir. Bu yüzden inceleme sorusu “açılıyor mu?” ile bitmemeli.
Verinin istemciden sunucuya nasıl gittiğini takip et. Kullanıcı kimliği yalnızca arayüzden mi geliyor, yoksa sunucudaki doğrulanmış oturumdan mı alınıyor? Hata olursa kullanıcı tekrar deneyebilir mi? Bir işlemin iki kez gönderilmesi çifte kayıt yaratıyor mu? Üretilen kodu bu sorularla değerlendir; cevabı kodun içinden ve gerçek davranıştan çıkar.
4. Başarı yolunun yanına hata yollarını koy
Bir formun geçerli girişle kaydetmesi tek başına yeterli kanıt değildir. Boş değer, çok uzun metin, oturumun sona ermesi, ağın kesilmesi ve aynı isteğin yinelenmesi farklı hata sınıflarıdır. Bunların hepsini her küçük değişiklikte test etmek gerekmez; fakat değişikliğin etkilediği kuralların olumsuz örneklerini seçmek gerekir.
Bir metin düzenlemesinde geniş bir test takımı yerine mobil görünümü kontrol etmek anlamlı olabilir. Bir ödeme veya yetki değişikliğinde ise sunucu testleri gerekir. Testin değeri kaç satır olduğu değil, gerçek bir hata yakalayabilmesidir. Üretilen test yalnızca üretilen kodu tekrar anlatıyorsa bağımsız kanıt sağlamaz.
- İstenen davranışı bir cümlede tanımla.
- Değişen dosyaları incele; ilgisiz değişiklikleri ayır.
- Başarılı işlemle birlikte yetki ve hata yolunu dene.
- Yayından önce geri dönüş yolunu hazırla.
5. Yayına alma kararını kanıta bağla
Derlemenin tamamlanması, gerçek kullanıcı akışının çalıştığını göstermez. Yerelde doğrulanan değişikliğin doğru sunucuya ve doğru alan adına gittiğini ayrıca kontrol et. Yayın sonrasında ana akışı gerçek sayfada aç; kaynak dosyası veya sürüm kimliğiyle hangi sürümün çalıştığını doğrula.
Bu çalışma biçimi yapay zekâyı hızlı bir yardımcı haline getirirken sorumluluğu belirsiz bırakmaz. Model önerir; değişikliğin amacı, sınırı ve doğrulaması senin kontrolündedir. GitHub'ın sorumlu kullanım belgesi de çıktının hatalı veya eksik olabileceğini ve uygun insan gözetiminin önemini belirtir. Buradaki süreç, belirli bir ürünün performans testi değil, farklı kod asistanlarına uygulanabilecek editoryal bir çalışma önerisidir.
Kaynaklar ve kontrol notu
Bu rehber yapay zekâ desteğiyle hazırlanmış özgün bir editoryal içeriktir. Kaynak kontrolü: 30 Eylül 2026. Örnekleri kendi proje koşullarına uyarlayarak doğrula.
Bir hata fark ettiysen editörlüğe bildir; düzeltmeleri güncelleme tarihiyle işleriz.


