Kanıt öncelikli alışkanlıkları ekip ölçeğine taşıyın: önem derecesinden önce bulguları sınıflandıran kod incelemesi, sınırlarını koruyan agentic workflow'lar ve dürüst raporlayan kuruluş yönetimi. Ayrıca bilinçli model seçimi.
Bu derste neler öğreneceksiniz?
Kod incelemesi bulgularını önem derecesi vermeden önce sınıflandırın
Agentic workflow'u izin verilen tek çıktıyla sınırlandırın ve başarısızlıkları doğru role yönlendirin
Copilot yönetim metriklerini sonuç değil, hesaplama olarak okuyun
Görev özelliklerine göre model seçin ve konumlandırmayı değil, yapılandırmayı doğrulayın
Bir ekip aynı kod tabanına birçok agent yöneltebilir, yöneticiler de hangi yeteneklerin kullanılacağını belirler. Agent mode dersindeki temel disiplin burada da işe yarar. İşi sınırlandırın ve kanıtı saklayın. Değişen şey çıktı hacmi ve hataların yayılma biçimidir.
Büyüyen çıktı akışını tek bir yerel düzenleme kadar dikkatle incelemek zordur. Kendinden emin bir review yanlış olabilir, workflow kapsamdan çıkabilir, paneldeki sayı sonuç gibi yorumlanabilir. Bu ders kanıt öncelikli incelemeyi kod yorumlarına, agentic workflow'lara, kuruluş kontrollerine ve model seçimine uyguluyor.
Otomatik kod incelemesini ölçekte nasıl güvenilir kılarsınız?
Copilot code review, değişen kodda olası kusurları işaretleyebilir. Her yorumu insan incelemesi için bir başlangıç olarak görün. Otomatik algılama olası doğruluk, güvenlik, test veya sürdürülebilirlik sorununu bulur. Geliştirici ilgili sözleşmeyi kontrol eder ve sorunu yeniden üretmeye çalışır. Değişikliğin ürün, tasarım ve operasyon gereksinimlerini karşılayıp karşılamadığına yine insan karar verir. Otomatik review temizse yalnızca hiçbir şey bildirilmediğini bilirsiniz.
Bulguyu aciliyetinden önce sınıflandırın. Kod, test veya yeniden üretim sorunu gösteriyorsa doğrulanmış olur. Henüz belirlenmemiş bir sözleşmeye dayanıyorsa varsayıma bağlıdır. Kanıt bulguyla çelişiyor veya konu başka katmanın sorumluluğundaysa geçerli değildir. Adı belli bir kontrol bekliyorsa doğrulanmamıştır. Önem derecesi daha sonra gelir: Engelleyici, Önemli, Öneri veya kanıt tamamlanana kadar Atanmamış. Review "Negatif ara toplamlar reddedilmiyor. Engelleyici." diyorsa önce negatif değerlerin bu fonksiyona ulaşıp ulaşmadığını ve doğrulamanın nerede yapılması gerektiğini bulun.
Ekip genelinde .github/copilot-instructions.md içinde tek ve gözlemlenebilir bir review tabanı tutun. İncelenecek riskleri, eyleme dönük yorumun taşıması gereken kanıtı ve dışarıda bırakılacak düşük değerli geri bildirimleri yazın. Talimatı ayarlarken kodu sabit tutun, böylece değişen etkinin kaynağını görebilirsiniz. Review çıktısı çalıştırmalar arasında değişebilir. Yorum sayısını değil, istediğiniz doğrulama adımlarının izlenip izlenmediğini değerlendirin. GH-300 çalışma rehberi de Copilot çıktısını aynı nedenle doğrulamanızı ister.
Önem derecesi vermeden önce bulguyu sınıflandırın
Doğrulamadığınız bir iddiaya asla "Engelleyici" etiketi yapıştırmayın. Önce bulgunun doğrulanmış, varsayıma bağlı, geçerli değil ya da doğrulanmamış olduğuna karar verin. Engelleyici veya Önemli derecesini yalnızca repository kanıtı ya da yeniden üretim sorunu doğruladıktan sonra verin. Engelleyici diye etiketlenmiş bir varsayım, incelemenin diğer tüm yorumlarına güveni aşındırır.
Kanıt isteyen inceleme standartları belirleyin· github-copilot
Zayıf örnek
Bu kodu incele ve birleştirmeden önce önemli gördüğün sorunları işaretle.
İyi örnek
Değişen kodu eyleme dönük kusurlar için incele. Biçimlendirmeden önce doğruluk, güvenlik, veri bütünlüğü, testler ve uyumluluğa öncelik ver. Her bulgu için dosya ile sembolü belirle, varsayılan veya doğrulanan sözleşmeyi yaz, somut etkiyi açıkla, sorunu yeniden üreten test öner, bulguyu doğrulanmış, varsayıma bağlı veya doğrulanmamış olarak sınıflandır ve Engelleyici ya da Önemli derecesini yalnızca kanıt sorunu doğruladıktan sonra ver. Biçim tercihlerini veya spekülatif refactor'ları bildirme.
Bu prompt neden daha iyi? Her yorumun sözleşme, etki ve kontrol taşıdığı kıdemli mühendis düzeyinde bir inceleme elde edersiniz. Önem derecesi kanıtı bekler.
Harekete geçmeden önce tek bir inceleme bulgusunu doğrulayın· github-copilot
Zayıf örnek
Bu inceleme yorumunun geçerli olup olmadığını kontrol edip ne yapacağımızı söyle.
İyi örnek
Şu inceleme yorumu için: "[buraya yapıştırın]". Varsaydığı girdi veya davranış sözleşmesini yaz, bu sözleşmenin repository kanıtını belirle, sorunu yeniden üreten test öner, doğrulanmış, varsayıma bağlı ya da doğrulanmamış olarak sınıflandır, yalnızca kanıt sorunu doğrularsa önem derecesi ver ve en küçük makul eylemi sun. Biçimlendirme geri bildirimi veya spekülatif refactor ekleme.
Bu prompt neden daha iyi? Bulgu ya yeniden üretim ve önem derecesiyle doğrulanır ya da sözleşme kontrol edilene kadar açıkça varsayıma bağlı olarak bekler. Böylece tahmin, Engelleyici etiketiyle gerçekmiş gibi sunulmaz.
Agentic workflow'lar sınırlarını nasıl korur?
Agentic workflow, bir agent'a hedef ve bağlam veren, sınırlarını belirleyen ve üretmesi gereken çıktıyı tarif eden otomasyon sözleşmesidir. Sabit bir script'te adımlar önceden bellidir. Burada ise gerekli eylemlere agent karar verir. Bu esneklik, sınırı açık yazmayı zorunlu kılar. Markdown sözleşmesinde altı parça bulunur: tetikleyici, hedef, kullanılabilecek bağlam, aşılamayacak kısıtlamalar, çıktının nasıl doğrulanacağı ve incelemeye sunulacak teslim.
"Web sitesini güncelle" bir sözleşme sayılmaz. Şu talimatın sınırı ise bellidir: "Adı verilen bu üç kaynağı oku, yalnızca docs/updates/navigation.md dosyasını değiştir, her iddiayı bir kaynağa eşle, kaynakta belirtilmeyen tarihi ekleme ve doğrulamayı pull request'te bildir." Hem üretilecek çıktı hem de agent'ın nerede duracağı görünürdür.
Workflow'un kapsamdan kaymaması için iki alışkanlık gerekir. Önce izin verilen tek çıktının tam adını yazın. Aynı adı sınırda, teslim şemasında ve inceleme kontrol listesinde tekrarlayın. "Tek bir dokümantasyon dosyası" ifadesi yetmez, çünkü agent yanlış dosyada da bu koşulu karşılayabilir. Ardından pull request'i inceleme sınırı olarak kullanın. Tamamlanan çalıştırma veya açılan PR, insanın değerlendireceği bir öneridir. Otomatik kabul anlamına gelmez.
Planner, designer, builder, validator ve handoff gibi birkaç rolü birlikte çalıştırırken asıl tasarım işi roller arasındaki aktarımı kurmaktır. Her role adı belli bir girdi ve çıktı, tek bir sorumluluk alanı ve durma koşulu verin. Uygulamayı yalnızca builder değiştirsin. Validator bir kusur bulursa FAIL sonucunu builder'a iletsin. Örneğin veride bir riskli proje varken panel özeti sıfır gösteriyorsa builder yalnızca bu gereksinimi düzeltir. Ardından validator tam kontrol listesini yeniden çalıştırır. Hiçbir madde FAIL değilse handoff başlar. Validator kendi bulgusunu düzeltmez.
GitHub'ın gh aw uzantısı bu düzeni kur, yaz ve çalıştır akışıyla paketler, değişiklikleri de pull request üzerinden önerir. Kesin komutlar elinizde yoksa aynı sözleşmeyi ve inceleme adımlarını manuel olarak prova edebilirsiniz.
Pull request bir öneridir, onay değil
Tamamlanan bir workflow çalıştırması veya açılan pull request, insanın inceleyeceği bir çıktıdır. Otomatik kabul anlamına gelmez. Validator FAIL bildirdiğinde bulgu builder'a döner. Builder yalnızca o gereksinimi düzeltir, ardından validator bütün kontrol listesini yeniden çalıştırır. Hiçbir madde başarısız değilse handoff başlar.
Workflow'u izin verilen tek çıktıyla sınırlandırın· github-copilot
Zayıf örnek
Bu kaynakları kullanarak release notlarımızı güncelle.
İyi örnek
Yalnızca şu üç kaynaktan tek bir release güncellemesi taslağı oluştur: [kaynak A], [kaynak B], [kaynak C]. Tam olarak tek bir dosya oluştur veya değiştir: docs/updates/release-notes.md, başka hiçbir dosyaya dokunma. Her olgusal iddiayı adlandırılmış bir kaynağa eşle. Hiçbir kaynak release tarihi belirtmiyorsa tarihi çıkar ve "Date not provided in source material." notunu ekle. Önerilen dosyanın tamamını, iddiadan kaynağa matrisini ve başarılı/başarısız doğrulama raporunu döndür. Bu üçü incelemeye hazır olduğunda dur.
Bu prompt neden daha iyi? Kapsamı tek dosyayla kesin biçimde sınırlandırılmış ve iddiaları kaynaklarla eşlenmiş bir öneri elde edersiniz. Birleştirmeden önce hem kapsamı hem de kaynak dayanağını kontrol edebilirsiniz.
Bir kuruluş tüm bunları nasıl yönetir?
Enterprise yönetimi tek bir ayarla bitmez. Önce amaçlanan durumu tanımlarsınız. Ardından ilke, lisans ve entegrasyon kontrollerini uygular, etkinliği izler, gördüğünüz durumu hedefle karşılaştırır ve gerektiğinde düzeltir ya da geri alırsınız. Bu bir kontrol döngüsüdür.
Döngüyü anlamak için iki ayrımı koruyun. İlke yukarıdan aşağı işler. Enterprise tabanı belirler, kuruluş kendi ayarını yapar, kullanıcı da ortaya çıkan davranışı görür. Bu yüzden kullanıcının karşılaştığı sonucu tek bir ayar sayfasıyla açıklayamazsınız. Ayrıca seat ve ilke farklı kontrollerdir. Seat kimin lisanslı olduğunu, ilke ise hangi özelliklerin kullanılabildiğini belirler. Kuruluş ayarı beklediğiniz sonucu vermiyorsa nedeni enterprise kısıtlaması olabilir.
Metrikleri yorumlarken her ifadeyi kaynak değer, hesaplama veya yorum olarak etiketleyin. Panelden aldığınız sayı kaynak değerdir. Bu sayılardan ürettiğiniz oran hesaplamadır. Oranın ne anlattığına dair çıkarımınız ise yorumdur ve ek kanıt gerektirebilir. Otuz atanmış seat içindeki 18 aktif kullanıcı, ilgili kapsam ve dönem için 18 / 30 × 100 = %60 benimseme oranı verir. Bu hesaplama üretkenliği, kod kalitesini, tasarrufu veya kullanıcıların neden benimsediğini göstermez. Toplu metrik bir eğilimi işaret eder. Belirli bir olayı araştırmak için etkinlik raporuna veya audit kaydına bakarsınız. Eşleşen audit kaydı, yalnızca kayda geçen etkinliğin gerçekleştiğini kanıtlar.
Durum bilgisini de aynı açıklıkla raporlayın. Önerilmiş, yalnızca görüntülenmiş veya simüle edilmiş değişikliği uygulanmış gibi göstermeyin. Yapılandırılan içerik dışlama kuralının her yerde çalıştığını söylemeden önce her yüzeyi ayrı ayrı test edin. MCP tarafında registry, sunucu erişimi ve allowlist uygulaması üç ayrı kontroldür. Repository yapılandırması enterprise onayı sayılmaz. Her değişiklik için kanıtı ve geri alma koşulunu kaydedin. Canlı, simüle edilmiş ve doğrulanmamış durumları birbirinden ayırın.
Benimseme bir hesaplamadır, sonuç değil
"%60 benimseme", belirli bir kapsam ve dönemde 30 seat'in 18'inin aktif olduğunu söyler. Üretkenlik, kod kalitesi, tasarruf veya niyet hakkında kanıt sunmaz. Kaynak değerleri, hesaplamaları ve yorumları ayrı etiketleyin. Bir yüzdeyi destekleyemeyeceği sonuçların kanıtı gibi kullanmayın.
Bir metriği dürüstçe bildirin· github-copilot
Zayıf örnek
18 aktif kullanıcı ve 30 atanmış seat üzerinden benimsemeyi hesaplayıp ne anlama geldiğini özetle.
İyi örnek
Bu döneme ait Copilot kullanım verisinde 18 aktif kullanıcı ve 30 atanmış seat bulunuyor. Benimsemeyi hesapla ve her parçayı etiketle. 18 ile 30'u kaynak değerler, yüzdeyi hesaplama olarak işaretle. Kapsam ve dönemi belirt, sayının neyi göstermediğini listele. Üretkenlik, kalite, tasarruf veya kullanıcı niyeti çıkarımı yapma.
Bu prompt neden daha iyi? Kaynak değerleri, hesaplaması ve destekleyemeyeceği sonuçların açık listesiyle temiz bir 18 / 30 × 100 = %60 benimseme satırı.
Model seçimini de düşünmeniz gerekir mi?
Evet. Model seçimini, görevin özelliklerine göre verdiğiniz bir tasarım kararı olarak ele alın. GPT-5.6 ailesinde farklı kullanım profillerine sahip üç varyant bulunur. Sol, büyük ve yabancı kod tabanlarında en yüksek akıl yürütme kapasitesini hedefler. Terra, günlük etkileşimli ve agentic kodlama için dengeli varsayılandır. Luna ise küçük ve açık görevlerde hızlı, hafif seçenektir.
Bu konumlandırma yalnızca başlangıç noktasıdır. Her model yanılabilir. Görevi sınıflandırıp uygun başlangıç modelini seçin, ardından sonucu testler, repository kanıtı ve kapsam incelemesiyle değerlendirin. Profili göreve uyan en düşük karmaşıklıktaki katmandan başlayabilirsiniz. Daha fazla akıl yürütmeye ihtiyacınız olduğunu kanıt gösteriyorsa üst katmana geçin.
Auto, yönetici ilkesine uyarak her görev için otomatik yönlendirme yapar. Kayda "Auto" yazın, altta hangi modelin çalıştığını tahmin etmeyin. Tekrarlanabilir bir benchmark için adı belli sabit bir model seçerek yönlendirme farkını ortadan kaldırın.
BYOK, yani bring your own key, Copilot Business ve Enterprise'da Copilot'u kuruluşunuzun yönettiği bir anahtarla onaylı sağlayıcıya bağlar. OpenRouter, Microsoft Foundry, Google, Anthropic, OpenAI ve Ollama desteklenen sağlayıcılar arasındadır. Kurulumu, model seçicide görünen sağlayıcı ve model üzerinden doğrulayın. Modelin kendisini belirli bir sağlayıcıya aitmiş gibi tanıtması yönlendirme kanıtı değildir. Anahtar bir kimlik bilgisidir. Prompt'a, kaynak dosyaya veya commit edilmiş transkripte girmez.
Şimdi siz deneyin
Dört inceleme bulgusunu önem derecesinden önce sınıflandırın
Küçük bir pull request ve birkaç otomatik inceleme yorumuyla çalışın. Bulgulara önem derecesi vermeden önce gereken kontrolleri yaklaşık on dakikada uygulayın.
01
Copilot incelemesi bulunan gerçek veya deneme amaçlı bir PR açın. İsterseniz daha önce karşılaştığınız dört aday yorumu da kullanabilirsiniz.
02
Her yorumun varsaydığı girdi veya davranış sözleşmesini yazın.
03
Her yorumu sınıflandırın. Repository kodu, test veya yeniden üretim sorunu gösteriyorsa doğrulanmış olarak işaretleyin. Yorum belirtilmemiş bir sözleşmeye dayanıyorsa varsayıma bağlıdır. Kanıt yorumla çelişiyor veya başka bir katman sorunu ele alıyorsa geçerli değildir. Belirli bir kontrol bekliyorsa doğrulanmamıştır.
İpucu: "Negatif ara toplamlar reddedilmiyor" yorumu, negatif girdinin fonksiyona ulaşıp ulaşamadığını ve doğrulamadan hangi katmanın sorumlu olduğunu kontrol edene kadar varsayıma bağlı kalır.
04
Engelleyici veya Önemli derecesini yalnızca doğrulanmış bulgulara verin. Her dereceyi destekleyen yeniden üretim testini de kaydedin.
05
Geçerli olmayan bulguları reddedin ve neden geçersiz olduklarını gösteren kanıtı ekleyin.
Her önem derecesinin kanıtla desteklendiği ve varsayımların Engelleyici etiketi almadan önce açıkça gösterildiği bir bulgular tablosu elde edersiniz.
Aklınızda kalsın
Temiz bir otomatik inceleme, hiçbir sorun bildirilmediğini gösterir. Kodun doğru olduğunu kanıtlamaz.
Önem derecesi vermeden önce bulguyu doğrulanmış, varsayıma bağlı, geçerli değil ya da doğrulanmamış olarak sınıflandırın.
Agentic workflow'u izin verilen tek ve kesin çıktıyla sınırlandırın. Başarısız doğrulamayı builder'a geri yönlendirin.
Copilot benimseme metrikleri belirli bir kapsam ve dönem için yapılan hesaplamalardır. Üretkenlik veya kaliteyi kanıtlamaz.
Modeli görev kapsamına ve tekrarlanabilirlik ihtiyacına göre seçin. Kabul kararını testlere ve repository kanıtına dayandırın.
Kendinizi test edin
1. Copilot "Negatif ara toplamlar reddedilmiyor. Engelleyici." diye bildiriyor. Repository, negatiflerin fonksiyona ulaşıp ulaşamayacağını ya da doğrulamadan hangi katmanın sorumlu olduğunu göstermiyor. Nasıl ele almalısınız?
2. Planner → builder → validator → handoff workflow'unda validator, veriler bir projenin risk altında olduğunu gösterirken panelin sıfır dediğini buluyor. Sonra ne olur?
3. Bir kuruluş 18 aktif kullanıcı ve 30 atanmış seat bildiriyor. Hangisini doğru biçimde çıkarabilirsiniz?
4. Açık, geri alınabilir tek bir dosya dönüşümünde model davranışını karşılaştırıyorsunuz ve tekrarlanabilirlik gerekiyor. Auto ile mi, adı belirli sabit modelle mi başlamalısınız ve kabulü ne belirler?
5. Copilot code review, değişen bir dosya hakkında hiçbir yorum döndürmüyor. Bu neyi gösterir?
Sık sorulan sorular
Bu dersteki terimler
bulgu sınıflandırması
Herhangi bir önem derecesi vermeden önce inceleme iddiasını doğrulanmış, varsayıma bağlı, geçerli değil ya da doğrulanmamış olarak etiketleme.
önem derecesi
Doğrulanmış bulgunun önceliğini Engelleyici, Önemli veya Öneri olarak gösteren etiket. İddia varsayıma bağlı ya da doğrulanmamışsa Atanmamış kalır.
agentic workflow
Bir agent'a hedef, bağlam, kısıtlamalar, doğrulama kuralları ve inceleme için sınırları belli tek bir teslim veren otomasyon sözleşmesi.
ilke hiyerarşisi
Copilot ilkesinin kullanıcı için etkili özellik kullanılabilirliğini enterprise'dan kuruluşa, kuruluştan kullanıcıya çözdüğü sıra.
Auto (model yönlendirme)
Yönetici ilkesine uyarak göreve göre model seçen otomatik yönlendirme. Altta hangi modelin çalıştığı tahmin edilmeden "Auto" olarak kaydedilir.
