GitHub Issue Triage’ı Copilot SDK ile Akıllandırmak: Ben Olsam Böyle Kurardım
Geçen ay, bir ekip toplantısında yine aynı sahne vardı: GitHub’da bildirım sayısı şişmiş, issue kuyruğu karışmış, herkes “hangisi acil, hangisi bekler?” diye birbirine bakıyor. Açık konuşayım, bu işin en yorucu tarafı kod yazmak değil; karar vermek. İşte tam burada Copilot SDK gibi araçlar devreye giriyor ve işi bayağı hafifletiyor.
Andrea Griffiths’in IssueCrush fikrinden ilham alan yaklaşım bana çok tanıdık geldi. Çünkü ben de yıllardır hem açık kaynak projelerde hem de kurumsal tarafta aynı problemi gördüm: issue triage ilk bakışta küçük bir operasyon gibi dürüyor. Büyüyünce insanın kafasını çorba ediyor. 2023’te bir finans müşterisinde bunu birebir yaşadık; sadece üç repoda haftalık 80’e yakın issue geliyordu ve manuel eleme neredeyse yarım gün yutuyordu.
Peki neden?
Neden issue triage bu kadar yoruyor?
Bakın şimdi, sorun sadece çok fazla issue olması değil. Asıl mesele bağlam değiştirme maliyeti. Bir satır başlığı okuyorsun, sonra açıklamaya dalıyorsun, etiketlere bakıyorsun, eski duplicate kayıtları kontrol ediyorsun… derken beyin RAM’i doluyor. Kısacası zorlayan şey sayı değil; sürekli aynı zihinsel geçişi tekrar etmek.
İlginç olan şu ki, 2019’da kendi laboratuvar ortamımda buna benzer bir akışı denemiştim. O zamanlar Copilot yoktu tabiî; basit kurallar ve birkaç webhook ile triage hızlandırmaya çalıştık. Çalıştı mı? Evet, ama kaba saba kaldı. Kural motoru iyi niyetliydi ama gri alanlarda tökezliyordu; “bu bug mı feature request mi?” sorusunda makine bazen duvara tosluyordu.
Bir de şu var: insan eliyle triage yaparken tutarlılık kaçıyor. Sabah enerjik olduğunuzda “hemen kapat” dediğiniz issue’ya öğleden sonra daha toleranslı bakabiliyorsunuz. AI burada yalnızca hız değil, biraz da standart sağlıyor. Tabiî kusursuz değil; yanlış sınıflandırma yaparsa olay büyür, önü da saklamayayım.
Evet.
İssueCrush fikri neyi çözüyor?
İssueCrush’ın güzel tarafı şu: konuyu dramatize etmiyor, doğrudan işe odaklanıyor. İssue’ları swipe kartlarına dönüştürmek kulağa oyun gibi geliyor ama aslında oldukça pratik bir fikir. Peki bunu neden söylüyorum? Sol kaydır — kapat ya da düşük öncelik ver; sağ kaydır — üzerinde durmaya değer bulduğun şeyi bırak ileride işlensin. Daha fazla bilgi için github ile ilgili önceki yazımız bakabilirsiniz. Bu konuyla ilgili Açık Kaynak Güvenlik Açıkları: 2025’te Neler Değişti, Ne Anlama Geliyor? yazımıza da göz atmanızı tavsiye ederim.
En hoşuma giden kısım “Get AI Summary” yaklaşımı öldü. Çünkü uzun issue açıklamalarını tek tek okumak yerine kısa özetle ne olduğunu anlayabiliyorsun. Hani markette kasanın önünde uzayan fişi tek tek incelemek yerine toplam tutara bakmak gibi… detay lazım olduğunda açarsın ama önce hızlı karar verirsin.
Copilot’un asıl değeri “her şeyi otomatik çözmek” değil; karar vermeyi hızlandırmakta yatıyor.
Benim Logosoft’ta yürüttüğüm bir Azure danışmanlık projesinde de benzer mantığı kullandık: kullanıcıya uzun log dökümleri yerine özetlenmiş aksiyon maddeleri gösterdikten sonra ekibin reaksiyon süresi ciddi biçimde düştü. Aynı prensip burada da geçerli; az laf, net yönlendirme. Daha fazla bilgi için GitHub Copilot for Jira: Preview’de Neler Sıkılaştı? yazımıza bakabilirsiniz. github ile ilgili önceki yazımız bu konuya da değinmiştik.
GitHub issue triage sürecinde asıl sorun “çok fazla issue”dan çok, bağlam değiştirme maliyeti ve tutarsız karar vermedir. Copilot SDK yaklaşımı işe özetleme ve ön sınıflandırma ile karar süresini kısaltmayı hedefler.
| Özellik | Manuel Triage | Copilot SDK ile Akıllandırma |
|---|---|---|
| Hız | Yavaş; başlık-açıklama-etiket döngüsü uzar | Daha hızlı; “Get AI Summary” ile önce kısa özet |
| Tutarlılık | Kişi enerjisine göre değişebilir | Daha standart karar desteği (öneri/ön sınıflama) |
| Gri alanlar | “Bug mı feature request mi?” yorucu olabilir | Etiket/bağlamdan öğrenerek sınıflandırma denemeleri |
| Risk | Yanlış karar genelde anında fark edilir | Yanlış sınıflandırma olursa öncelik/akış büyüyebilir |
| Odak | Detay okumaya zaman harcanır | Karar verme hızlanır; detay gerektiğinde açılır |
Not: Copilot’un değeri “her şeyi otomatik çözmek”ten çok, triage kararını hızlandırıp ekip yükünü azaltmaktır.
Mimariyi server-side kurmak neden mantıklı?
Burada kritik nokta şu: React Native uygulamanın içine Node.js paketini gömüp Copilot SDK’yı doğrudan client’ta çalıştırmak pek gerçekçi değil. Çünkü SDK’nın altında Node runtime var ve yerelde Copilot CLI süreci yönetiliyor; JSON-RPC üzerinden haberleşiyorlar. Yanı iş biraz mutfakta ocak gerektiriyor — salon dekoruyla olmuyor. Bu konuyla ilgili GitHub Copilot Verisi Değişiyor: Ne Toplanıyor, Ne Toplanmıyor? yazımıza da göz atmanızı tavsiye ederim.
Vallahi, Açık konuşayım, bu mimarı seçimi bence doğru hareket olmuş. Server-side yaklaşım sayesinde tek bir SDK instance paylaşabiliyorsunuz, auth karmaşası azalıyor ve mobil istemciler ayrı ayrı bağlantı açıp sistemi şişirmiyor oluyorlar vaziyette kalıyorlar demeyeyim ama sız anladınız işte. Bu ne anlama geliyor? Geçen sene Mart 2026 Azure SDK güncellemelerini incelerken de benzer bir desen gördüm; istemciyi sade tutup ağır işleri arkaya atınca sistem daha sakın davranıyor.
Hmm, bunu nasıl anlatsamdı…
Bence bu modelin artıları
- Daha güvenli: Kimlik bilgileri istemciye sızmaz. (bu kritik)
- Daha yönetilebilir: Tek noktadan logging ve monitöring yapılır.
- Daha esnek: AI servisinde kesinti olursa fallback koyabilirsiniz.
- Daha ölçeklenebilir: Çoklu mobil istemci tek havuzu tüketir. — bunu es geçmeyin
Peki eksisi ne?
E tabiî her güzel şeyin ufak bir faturası oluyor. Server tarafında ek bakım yükü çıkıyor; Node runtime, CLI kurulumu, process yaşam döngüsü derken operasyon biraz kabarıyor. Küçük startup için bu kabul edilebilir olabilir ama enterprise ortamda gözden kaçırılırsa gece nöbetinde can sıkabilir.
SenaryoTercihNeden
Hızlı kurulur maliyet düşük kalır
Bunu gerçek hayatta nasıl düşünürüm?
Burada, i̇lginç olan şu ki, Lafı gevelemeden söyleyeyim; ben böyle bir sistemi kurarken önce veri akışına bakarım, sonra yetkiye, en son arayüze geçerim.Çünkü UI parlak olsa bile arka plan kötü işe kullanıcı ilk hafta heveslenir, ikinci hafta söver.2018’de Ankara’daki bir kamu entegrasyon projesinde bunu görmüştüm; ekran şahane idi. Veri kalitesi zayıftı, sonuç hayal kırıklığı öldü.
Kendi pratiğimde AI destekli triage için üç katman öneriyorum:özetleme, etiket önerisi ve işlem tavsiyesi.Özetleme “bu konu ne？” sorusuna cevap verir.Etiket önerisi işe bug mu, enhancement mı, question mı ayrıştırır.İşlem tavsiyesi de “kapat / takip et / başka takıma aktar” gibi yön verir.
AZ-305 sınavına hazırlanırken öğrendiğim önemli şeylerden biri şuydu:iyi mimarı, tek parça sihir değildir; katmanların birbirini ezmemesidir.Burada da aynı mantık geçerli.Copilot her şeyi üstüne almamalı; yanlış olduğunda insan devreye girebilmeli. Mantıklı değil mi? Yoksa otomasyon diye başlayıp operatör bağımlılığına dönersiniz, işte o kötü (yanlış duymadınız)
Kod tarafında nasıl görünür?
// Basitleştirilmiş örnek akışconst summary = await copilot.summarize(issue.body);
const labelSuggestion = await copilot.classify(issue.title + "n" + issue.body);
if (!summary ||!labelSuggestion) {
return basicFallback(issue);
}
return {
summary,
labelSuggestion,
actionHint:
labelSuggestion === "duplicate"? "close":
labelSuggestion === "bug"? "prioritize":
"review"
};
Bunu prod’a aynen koymam tabiî ki doğru olmaz; hata yakalama, timeout yönetimi, rate limit kontrolü, gözlemleme… bunların hepsi şart. Geçen yıl İzmir’de bir SaaS müşterisinde AI çağrılarının yüzde on beşinin timeout yüzünden düştüğünü gördük; sebep basitti:fallback yoktu. O günden beri her AI entegrasyonunda önce B planını çiziyorum.
Kime uygun, kime biraz fazla gelir?
Küçük ekiplerde bu tarz çözüm bayağı işe yarar çünkü herkesin zamanı kıymetlidir. Beş kişilik startup’ta kimse iki saatini issue okumaya harcamak istemez. Peki bunu neden söylüyorum? Orada hızlı kazanımlar alınır: Ama enterprise tarafta hikâye değişir; güvenlik incelemesi, veri gizliliği, rol bazlı erişim, audit trail derken iş uzar.
Büyük organizasyonda en çok dikkat ettiğim şeylerden biri prompt/log politikası oluyor. Çünkü AI’a verdiğiniz metnin içinde hassas bilgi olabilir. Bir müşteri adı, ticket numarası, hatta bazen yanlışlıkla secret parçası düşebilir. Bu yüzden maskelenmiş veriyle çalışma alışkanlığı çok önemli.
Neyse uzatmayayım, benim görüşüm şu:IssueCrush gibi fikirler açık kaynak dünyasında gerçekten karşılık bulur. Ama asıl değer koddan çok operasyonel disiplinle ortaya çıkar: Copilot SDK size motoru veriyor; direksiyonu, frenleri emniyet kemerini işe sız takacaksınız.
Sıkça Sorulan Sorular
Copilot SDK’yı doğrudan React Native içinde kullanabilir mıyım?
Kısmen hayır diyebilirim; çünkü SDK Node.js runtime istiyor. Yerelde Copilot CLI ile konuşuyor.Bu yüzden genelde server-side entegrasyon daha doğru olur។ Mobil uygulama sadece API tüketir ağır iş arkada kalır.
İssue triage için AI kullanmak güvenli mi?
Eğer secrets sunucuda tutuluyor loglar maskeleniyor ve fallback mekanizması varsa evet, oldukça makul olur. İstemciye anahtar taşımamak temel kuraldır. Yine de hassas veri filtrelerini atlamamak lazım.
Küçük ekipler bu modeli rahat kullanabilir mi?
Evet, hatta en çok onlar fayda görür: Çünkü manuel triage yükü küçük ekipleri hızlı yorar. Basit bir backend ile başlanıp ihtiyaç oldukça geliştirmek mantıklı olur.
AI yanlış sınıflandırma yaparsa ne olur?
O yüzden insan onayı veya fallback akışı koymak gerekir. İlk sürümde AI’ı karar verici değil yardımcı olarak konumlamak daha sağlıklı olur. En çok da duplicate veya priority kararlarında dikkat şarttır.
Kaynaklar ve İleri Okuma
- Azure OpenAI Resmî Dokümantasyonu
- GitHub Copilot SDK GitHub Reposu
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