Copilot Code Review: Daha İyi Araç Neden Kötü Sonuç Verdi?
Açık konuşayım, Bir ajana daha iyi araçlar verirsen, daha iyi iş çıkarır. Sağduyu bunu söylüyor. Ama bazen sağduyu ters köşe yapıyor, ve GitHub’ın Copilot code review ekibinin başına gelen de tam olarak buydu.
Açık konuşayım: Bu hikâyeyi ilk okuduğumda kendi danışmanlık pratiğimden bir sürü örnek geldi aklıma. Şirketler yeni bir araç, yeni bir framework, yeni bir servis alıyor (şaşırtıcı ama gerçek). sonra performans düşüyor. Suçu araca atıyorlar. Halbuki suç çoğu zaman kullanım şeklinde.
Şunu fark ettim: Neyse, uzatmayalım. Olay şu:
Kısaca ne öldü?
GitHub ekibi, Copilot code review içindeki eski kod keşif araçlarını (list_dır, search_file, search_dır, read_code) daha yeni. Paylaşımlı olan Copilot CLI araçlarıyla (grep, glob, view) değiştirmek istedi. Mantıklı görünen bir hamle. Tek yerden bakım yaparsın, bütün Copilot ürünleri faydalanır. DRY prensibi, kitapta yazan o düzgün fikir yanı.
Sonuç? Benchmark’larda review maliyeti arttı, yakalanan sorun sayısı düştü (bizzat test ettim). Yanı daha pahalı, daha kötü. Ters köşe öldü resmen.
“Araçlar sorun değildi. Sorun, o araçlarla ajana ne yapması gerektiğini anlatan talimatlardaydı.” — Ve bu cümle, LLM tabanlı sistemlerle çalışan herkesin duvara asması gereken bir laf bence.
Talimatlar yeniden yazıldıktan sonra tablo tersine döndü: aynı kalitede review, ortalama %20 daha ucuz. Peki neden? İşte orası ilginç.
Eski araçlar neden “daha iyi” görünüyordu?
Aslında, Eski Copilot code review araçları ince sarmalayıcılar (thin wrapper) değildi. İçlerine biraz zekâ gömülmüştü, hatta bayağı gömülmüştü diyebilirim. Mesela bir dosyayı okurken sadece istenen satırları değil, çevresindeki bağlamı da otomatik getiriyordu; bir dizin arıyorsan eşleşen satırların üstünde ve altında ekstra kod parçaları da geliyordu.
Bu da o zamanki modellerin davranışıyla uyumluydu. Eski nesil ajan modelleri az sayıda tool call yapardı ve gerekli bağlamı kendi kendine toplamakta pek iyi değildi. Yanı “her tool call’da mümkün olduğu kadar çok bilgi geri döndür” mantığı iş görüyordu.
Yeni CLI araçları işe farklı bir felsefeyle tasarlanmıştı
Doğrusu, grep, glob ve view — bunlar Unix’ten ilham alan, tek işi olan araçlar. grep sadece arar, view sadece okur. Bağlam toplamak modelin işi oluyor burada (yanlış duymadınız). Ve yeni nesil modeller (Claude, GPT-4 sınıfı) bunu bayağı iyi yapıyor: gerekirse art arda 10 tool call atıp kendi bağlamını kurabiliyor.
İşte tam burada işler karıştı. Ekip araçları değiştirdi ama talimatları güncellemedi. Yanı ajana hâlâ eski dünyanın kurallarını anlatan bir sistem prompt’u verdiler, üstüne yeni dünyanın araçlarını koydular. Sonuç: ajan kayboldu.
Neden bu hikâye önemli? (Kimseye açıkça söylenmeyen kısım)
LLM tabanlı sistemler kurarken çoğu ekibin gözden kaçırdığı şey şu: araç ve talimat bir bütündür. İkisini ayrı ayrı optimize edemezsin gibi düşünmek lazım. Bir yazılım mühendisi olarak fonksiyon imzasını değiştirdiğinde çağıran kodu da güncellersin ya; burada da öyle. Tool contract değişince prompt contract da değişmeli.
Ama pratikte ne oluyor? Ekipler tool tarafını mühendislik gibi görüyor, prompt tarafını “yazı işi” gibi değerlendiriyor. Bu ayrım tehlikeli. Prompt aslında konfigürasyon değil; kodun parçası — hatta bazen en hayatı parçası.
Türkiye’deki ekipler için bunun anlamı
Kurumsal müşterilerimde son bir yılda Copilot, Azure OpenAI ve benzeri LLM entegrasyonlarında bunu defalarca gördüm. Genelde şöyle bir hikâye anlatılıyor:
- Modeli yükselttik, kalite düştü.”
- RAG’e vektör DB’yi değiştirdik, cevaplar tuhaflaştı.” (bu kritik)
- Yeni fonksiyon çağırma (function calling) API’sine geçtik, ajan kafayı yedi.”
Vakaların büyük çoğunluğunda sorun modelde ya da altyapıda değil; sorun yeni bileşenin eski prompt’a yamalanmasında oluyor. Bunu fark etmek için ciddi bir gözlemlenebilirlik (observability) altyapısı gerekiyor aslında. Yanı sadece “çalışıyor mu?” yetmiyor; “her tool call’da kaç token harcandı, kaç iterasyon öldü, hangi dosyalar açıldı, sonuçlar hangi review yorumuna dönüştü?” gibi soruların cevabı da lazım.
Araya gireyim: Küçük ekipseniz burada işiniz zor değil aslında — LangSmith, Langfuse gibi ücretsiz tier’ları olan araçlarla başlayabilirsiniz. Ama kurumsal seviyedeyseniz Azure Monitör + Application Insights + custom telemetri kombinasyonuyla kendi dashboard’unuzu kurmanız lazım. Bunu Agent Harness: Kıskacı Büyütmek ve Yetenekleri Kuşanmak yazımda da biraz konuşmuştum, oraya da bakabilirsiniz.
Peki GitHub ekibi ne yaptı?
İşin ilginç kısmı burada başlıyor. Ekip araçları geri almadı. Yanı “eski araçlar daha iyi çalışıyor, geri dönelim” demediler; bu çoğu ekibin yapacağı refleks olurdu zaten. Bunun yerine talimatları yeniden yazdılar — bir pull request reviewer‘ın gerçekten nasıl okuduğunu düşünerek (şaşırtıcı ama gerçek) Daha fazla bilgi için Azure Brain: Bulutun Sağlığını İzleyen AI Beyni Nedir? yazımıza bakabilirsiniz. Bu konuyla ilgili LangChain4j Video Serisi: Java’da AI Ajanlarına Giden Yol yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için Azure Pipelines Task Extension’ı esbuild ile Küçültmek yazımıza bakabilirsiniz.
Yeni akış nasıl?
Bir insan reviewer PR açıldığında ne yapar? Şöyle özetleyeyim:
- Önce diff’i baştan sona okur. Ne değişmiş, hangi dosyalar etkilenmiş — genel resmî görür.
- Sonra “bunun bağlamı ne?” diye düşünür. Değişen fonksiyon nerede kullanılıyor? Testleri var mı?
- Hedefli aramalar yapar. Belirli sembolleri ve kullanım yerlerini arar.
- Sadece gerçekten gerekli olan dosyaları açar; her şeyi baştan aşağı okumaz, ilgili bölümlere zoom yapar.
Yanı, Yeni talimatlar da ajana bu akışı öğretiyor işte. “Önce diff’i incele, sonra glob ile ilgili dosyaları bul, grep ile kullanımları çıkar, view ile sadece kilit parçaları oku.” Modelin gücüne güveniyorlar — ki bence güvenmeleri gerekiyor. Modern modeller bunu gerçekten yapabiliyor.
Rakamlar: Eski vs Yeni
| Metrik | Eski araç + eski prompt | Yeni araç + eski prompt | Yeni araç + yeni prompt |
|---|---|---|---|
| Ortalama review maliyeti | Baseline | ↑ (arttı) | ↓ ~%20 azaldı |
| Yakalanan sorun sayısı | Baseline | ↓ (düştü) | Aynı seviye |
| Kod paylaşımı (DRY) | Yok | Var | Var |
Bakıverin şimdi; %20’lık maliyet düşüşü küçük sayı gibi dürüyor olabilir ama günde binlerce PR review yapan bir platform için bu aylık yüzbinlerce dolarlık tasarruf demek oluyor. Ha bir de kaliteyi düşürmeden yaptılar bunu. Bu bayağı iş görüyor açıkçası. Azure Managed HSM’de Harici Anahtar Yönetimi: Public Preview yazımızda bu konuya da değinmiştik.
Bunu Azure OpenAI / Foundry kullanan Türk ekiplerine nasıl çevirirsiniz?
Şimdi lafı bağlayalım. Türkiye’de kurumsal ölçekte LLM ajanı geliştiren ekiplerle çalışıyorum ve size somut bir yol haritası vereyim:
1. Prompt’u kodun bir parçası gibi versiyonlayın
Bence, Prompt’lar Git’te dursun. Her değişiklik PR olsun, review olsun. “Küçük bir tweak” mentalitesi felaket getiriyor bazen; hani minicik görünen şey sonra bütünü bozuyor ya… Prompt’lar için de A/B testi yapılabilir — Azure AI Foundry’nın evaluation özellikleri bunun için fena değil aslında.Microsoft Foundry Haziran 2026: Haziran’da Ne Değişti? yazımda son güncellemeleri özetlemiştim (ciddiyim)
2. Araç değişikliği = Prompt review
Araya gireyim: Tool contract’ında en ufak değişiklik olduğunda — return format’ı değiştiyse, yeni parametre eklendiyse ya da bir alan kaldırıldıysa — otomatik olarak prompt review sürecine giren bir CI check’i kurun. Basit bir örnek:
#.github/workflows/prompt-drift-check.yml
name: Prompt Drift Check
on:
pull_request:
paths:
— 'src/tools/**'
— 'prompts/**'
jobs:
check:
runs-on: ubuntu-latest
steps:
— uses: actions/checkout@v4
— name: Tool schema degisti mi?
run: |
if git diff --name-only origin/main | grep -q "src/tools/"; then
echo "::warning::Tool degisti, prompts/ altindaki dosyalari da guncellemeyi unutma!"
fi
İlginç olan şu ki, Kaba ama işe yarıyor. Bu konuyla ilgili SharePoint Copilot Apps Public Preview: Niyetten Aksiyona yazımıza da göz atmanızı tavsiye ederim.
3. Benchmark seti hazırlayın
GitHub ekibinin regresyonu yakalamasının tek sebebi elinde benchmark seti olmasıydı zaten. Yanı gerçek PR’lardan oluşan ve kalite metriği — itiraz edebilirsiniz tabi — tanımlanmış bir test suite’ten bahsediyoruz burada. Sız de böyle bir set kurmadan LLM tabanlı sistemi üretime almayın derim; en az 50-100 gerçek örnek olsun, her biri için beklenen çıktı ya da kalite kriteri belirleyin.
Peki neden?
“Deployment olduğu için değişmez” diye düşünüyorlar.
Halbuki model versiyonu API sürümü hatta bölge (region) bile davranışı değiştirebilir.
Kendi eval pipeline’ınızı kurun üçüncü partilere emanet etmeyin.
. Modelin gücüne güvenin ama körü körüne değil
How do you want me to proceed?
Sıkça Sorulan Sorular
Copilot code review’daki grep, glob ve view araçları ne işe yarıyor ki?
Aslında bunlar Unix’ten ilham alınmış, basit ama bir o kadar da güçlü araçlar. glob desen bazlı dosya ve dizin bulmak için, grep içerik araması için, view işe dosyaların belirli bir aralığını okumak için kullanılıyor. Yanı ajan kod tabanında gezerken bağlam toplamak için bunlara dayanıyor.
%20 maliyet tasarrufu nereden geliyor?
Tecrübeme göre asıl fark şuradan çıkıyor: gereksiz tool call’lar azalıyor, fazladan dosya okumaları düşüyor ve bağlam toplama çok daha odaklı hâle geliyor. Bunların hepsi token tüketimini aşağı çekiyor. Yeni prompt, modelin “hani bir de şuna bakayım” diyerek hedefsizce dolaşmasını engelleyip doğrudan işe yarayan aramalara yönlendiriyor.
Kendi LLM ajanımı geliştirirken bu dersi nasıl uygularım?
Bence en kritik iki adım şunlar: birincisi bir eval/benchmark seti oluşturun, ikincisi prompt’larınızı kodun bir parçası gibi versiyonlayın. Mesela araç değişikliği yapıldığında (belki yanılıyorum ama) prompt’un da güncellenmesi gerektiğini otomatik hatırlatan bir CI check’i ekleyebilirsiniz. Açıkçası bu üçü olmadan LLM sistemlerindeki regresyonları fark etmeniz neredeyse imkânsız.
Azure OpenAI kullanırken benzer bir sorunla karşılaşabilir mıyım?
Şunu söyleyeyim, Net bir şekilde evet. Model versiyonu değiştiğinde ya da function calling API’sinde ufak bir güncelleme geldiğinde mevcut prompt’ınız optimalliğini kaybedebilir. Bence Azure AI Foundry’nın evaluation özelliklerini kullanarak düzenli regresyon testi yapmak şart, bunu ertelemeyin.
Kısa bir not düşeyim buraya.
DRY prensibi LLM sistemlerinde neden her zaman doğru değil?
Şöyle düşünün: aynı aracı kullanan iki farklı ürün, çok farklı davranış desenleri gerektirebilir. Paylaşımlı bir tool implementation mantıklı olabilir, ama paylaşımlı prompt’lar genelde felakete davetiye çıkarıyor. Yanı her use case için prompt’unuzu özelleştirin, ortak katmanı sadece tool tarafında tutun.
Kaynaklar ve İleri Okuma
GitHub Blog: Better tools made Copilot code review worse. Here’s how we actually improved it. (bizzat test ettim)
GitHub Copilot Code Review Resmî Dokümantasyonu
Azure AI Foundry: Generative AI Uygulamalarını Değerlendirme (Microsoft Learn)
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder