Başarısız bir test, daha önce görmediğiniz bir yardımcı fonksiyonu işaret ediyor. Nerede olduğunu ve hangi davranıştan sorumlu olduğunu henüz bilmiyorsunuz. İhtiyacınız netleşmeden mod seçerseniz yama beklerken açıklama alabilir, yalnızca açıklama isterken birkaç dosyaya yayılan değişikliklerle karşılaşabilirsiniz. Seçtiğiniz mod, Copilot'tan istediğiniz işin türünü belirler.
Mod, bir çalışma sözleşmesidir
Ask, Edit ve Agent üç farklı eylem düzeyidir. Bir modu seçerken Copilot'a ne kadar hareket alanı verdiğinizi de seçersiniz. Bu nedenle modu ve prompt'unuzu bir çalışma sözleşmesi olarak düşünün:
İhtiyacınızı karşılayacak en sınırlı eylem düzeyiyle başlayın. Davranışı henüz anlamıyorsanız Ask kullanın. Değişikliği tarif edip dosyaları adlandırabiliyorsanız Edit daha küçük bir diff verir. İş araştırma ve komut çalıştırma gerektiriyorsa Agent'a geçin ve durma koşulunu yazın. Mod, Copilot'un üstlenebileceği işi değiştirir. Sonucun sorumluluğu yine sizdedir.
Edit diff üretir, Agent görevi tamamlar
İstediğiniz davranışı netleştirdikten sonra işin ne kadar hareket alanı gerektirdiğine karar verin. Değişebilecek dosyaları adlandırabiliyor ve değişikliği açıkça tarif edebiliyorsanız Edit kullanın. Prompt'ta gerekli davranışı, korunacak noktaları, hata politikasını ve sonucu kanıtlayacak testleri belirtin. İyi bir Edit prompt'u, satır satır inceleyebileceğiniz küçük bir diff üretir.
Buradaki "sınırlı" ifadesi, Edit modunun teknik olarak uyguladığı bir kısıt değildir. İsteğinizde tanımladığınız kapsamı anlatır. Sınırı prompt'unuz koyar, incelemeniz ise bu sınıra uyulup uyulmadığını gösterir. Değişikliğin istediğiniz dosyalarda kaldığını varsaymayın. Gerçek dosya listesini ve diff'i mutlaka kontrol edin.
Tamamlanma için dosya inceleme, kod düzenleme, komut çalıştırma ve sonuca göre düzeltme gibi ardışık adımlar gerekiyorsa Agent kullanın. Başlamadan önce koruma sınırlarını yazın. Nihai sonucu, değişebilecek dosyaları, yasak eylemleri, doğrulama komutunu, başarı ölçütünü ve durma koşulunu belirtin. Son sınır yoksa küçük bir düzeltme, asıl görev gözden kaybolduktan sonra da genişlemeye devam edebilir.
IDE'nizdeki Agent modu ile GitHub'ın cloud coding agent özelliği aynı değildir. Cloud coding agent, GitHub Actions destekli bir ortamda çalışır ve incelemeniz için pull request açar. Yerel ortamda Agent seçmek görevi bu cloud workflow'a devretmez.
Bir öneri aslında nereden gelir?
Tuşa basmanızla önerinin ekranda görünmesi arasındaki yol, "Copilot böyle söyledi" ifadesinin neden kanıt olmadığını gösterir. Aşağıdaki sırayı düşünme modeli olarak kullanın:
Editör girdisi → bağlam seçimi ve prompt oluşturma → proxy filtreleme
→ model üretimi → son işleme → önerinin gösterilmesi
→ insan incelemesi ve doğrulaması
Girdi, süreci başlatan yorum, tamamlanmamış fonksiyon, seçili kod veya chat isteğidir. Girdi ne kadar açık olursa sonucu değerlendireceğiniz ölçüt de o kadar açık olur. Bağlam ise isteğin görebildiği sınırlı içerik paketidir. İmlecin yakınındaki kod, seçili bölüm, açıkça eklediğiniz bir dosya, geçerli talimatlar ve önceki mesajlar bu pakete girebilir. Bağlamın tüm repository'yi kapsadığını düşünmeyin. Eklemediğiniz bir dosyanın Copilot tarafından dikkate alındığını varsayamazsınız. Proxy filtreleme, model üretimi ve son işleme gerçek mimari aşamalardır. Ancak bu aşamaların iç kurallarını editörden göremezsiniz. Gözlemlediğiniz sonucu kaydedin, görünmeyen bir neden hakkında tahminde bulunmayın.
Proxy filtreleme ile içerik dışlamasını birbirinden ayırın. Proxy filtreleme bu düşünme modelindeki işleme aşamalarından biridir. İçerik dışlaması ise belirli dosyalar için yapılandırılan ayrı bir korumadır ve modülün ilerleyen bölümünde ele alınır. Bir alıştırmada çıktı alabilmek için hiçbir korumayı kapatmayın. Öneri görünmezse yalnızca "öneri görünmedi" gözlemini kaydedebilirsiniz. Bunun bir filtre tarafından engellendiğini kanıtlayamazsınız.
Son aşama sizin inceleme ve doğrulamanızdır. Model üretimi yalnızca bir adayın ortaya çıktığını gösterir. Adayın doğru olduğunu göstermez. Öneriyi kabul etmek editördeki kodu değiştirir, fakat davranış hakkında kanıt sunmaz. Önceki dersteki alışkanlık burada da geçerlidir. Açık bir sözleşme ve gerçekten çalıştırılmış kontroller olmadan gösterilen koda güvenmeyin.
Bağlamı kanıt gibi yönetin
Copilot kendisine verilen bağlamdan hareket eder. Bu yüzden hangi kanıtı paylaştığınızı bilin. Davranış tek dosyadaysa dosya yolunu yazın. Soru yerelse ilgili fonksiyonu seçin. Hata ayıklıyorsanız hata metnini ekleyin. İlgili kodun nerede olduğunu gerçekten bilmiyorsanız repository incelemesi isteyin.
Bağlamı kontrollü tutmak iki yanıtı karşılaştırırken de önemlidir. Prompt'u, seçili kodu, ekli dosyayı ve konuşma geçmişini aynı anda değiştirirseniz sonuçtaki farkın nedenini anlayamazsınız. Her denemede tek bir değişkeni değiştirin. Prompt'u, seçimi, imleç konumunu ve çıktı ölçütünü sabit tutup yalnızca ekli bağlamı değiştirmek anlamlı bir karşılaştırma sağlar. Dosya referansları için yarım hatırladığınız özel söz dizimlerine güvenmeyin. Editörünüz dosya veya seçim eklemek için görünür bir kontrol sunuyorsa onu kullanın. Böyle bir kontrol yoksa dosya yollarını, sembolleri, tanılamaları ve hata metnini prompt'ta açıkça yazın. Sağlam bir istek, sürümler arasında değişebilecek tek bir token yazımına bağlı kalmaz.
Moddan bağımsız olarak aynı inceleme döngüsünü uygulayın. İstediğiniz sonucu belirtin, gerekli kanıtı sağlayın, kapsamı ve kısıtları tanımlayın, yanıtı, diff'i veya araç eylemlerini inceleyin ve işe yarayacak en dar kontrolü çalıştırın. Sonra gördüğünüz belirli bir uyuşmazlığa göre isteği iyileştirin. "Tekrar dene" demek Copilot'a düzeltilebilir bir bilgi vermez. Bunun yerine "Yama public dönüş türünü değiştirdi" veya "Test üst indirim sınırını kapsamıyor" gibi somut bir sorun belirtin. Açık bir geri bildirim uygulanabilir bir talimata dönüşür. Bu prompt'ları test edilebilir şartnamelere dönüştürmek için Kod İçin Prompting dersine geçin.
