Copilot Memory’de Yeni Kontrol Dalgası: Silme, Kapsam ve CLI
Geçen hafta bir müşteride tam da bunu konuştuk: yapay zekâ asistanı iş görüyor mu, evet; ama hafızası nerede dürüyor, kim görüyor, ne zaman siliniyor? İşin hayatı kısmı burada başlıyor (bu beni çok şaşırttı). GitHub Copilot Memory için gelen yeni kontrol seti de bana kalırsa bu soruya doğrudan cevap veriyor (ciddiyim). Güzel tarafı şu: artık sadece “hatırlasın” demek yetmiyor, “neyi, kim için, hangi sınırda hatırlasın” demek de mümkün oluyor (inanın bana)
Silmeyi kolaylaştırmak neden önemli?
Bana kalırsa haberin en değerli kısmı deletion guidance tarafıydı.
Çünkü kullanıcılar çoğu zaman neyi sileceğini biliyor ama nereden sileceğini bilmiyor.
AI ürünlerinde kötü deneyim genelde buradan çıkıyor:
“Unuttum dedim ama hâlâ dürüyor galiba?”
İşte güven kırılması tam burada başlıyor.
Kısacası mesele teknikten önce güven meselesi oluyor.
Evet.
Sonrası çorap söküğü gibi geliyor.
GitHub’ın yaklaşımı fena değil hatta baya işe yarar; ilgili belleğe nasıl ulaşacağınızı gösteriyor ve uygun yerde down-vote da yapıyor.
Neyse, ama yine de şunu söylemeden geçemeyeceğim:
Silme sürecinin gerçekten sezgisel olması gerekiyor.
Kullanıcıyı dokümantasyona göndermek yetmez;
arayüzde net iz bırakmak lazım.
Aksi hâlde özellik var olur ama kullanılmaz.
Beklediğim kadar pürüzsüz değildi yanı…
Neyse uzatmayayım,
burada amaç silmeyi görünmez değil,
kontrollü yapmak.
Maliyet ve operasyon açısından ne ifade ediyor?
Maliyet kısmına gelirsek…
Copilot Memory’nın kendisi ayrı bir lisans kalemi gibi düşünülmeyebilir ama operasyon maliyeti doğurur:
destek talebi,
güvenlik incelemesi,
kullanıcı eğitimi,
politika yönetimi.
Türkiye’de TL bazında hesap yaptığınızda küçük görünen bu işler toplamda epey yük bindirebiliyor.
Bilhassa kur dalgalanması varken SaaS maliyetini sadece aylık etiket fiyatıyla okumak hata olur.
Asıl toplam maliyet;
zaman + risk + yanlış kullanım birleşimiyle çıkıyor.
Hani şöyle dışarıdan bakınca ucuz duran şeyler vardır ya,
işte burada öyle bir durum olabiliyor.
Şaşırdım açıkçası değil mi?
Ama tabloyu bütünüyle okuyunca normalleşiyor.
- Küçük ekip: Önce pilot açın, sonra memory politikasını yazın.
- Büyük kurum: Repo seviyesinde varsayılan kapalı başlayın. — ciddi fark yaratıyor
- Düzenli denetim: Hangi bilginin user-level hangisinin repo-level olduğunu ayda bir gözden geçirin. — bunu es geçmeyin
- Eğitim: Geliştiriciye “hangi veriyi kaydediyorsun?” sorusunu sordurun.
Bende bıraktığı izlenim ne?
Açık konuşayım, bu güncelleme devrim değil. Ama doğru yönde atılmış sağlam bir adım. GitHub burada “AI daha çok ezberlesin” dememiş;
tam tersine,
“AI ezberliyorsa bunu kontrollü yapsın” demiş. Bence esas olgunluk sinyali burada yatıyor. Ben AZ-305’e hazırlanırken hep şuna takılırdım:
tasarım sadece çalışmak değildir,
aynı zamanda sınırlamak da gerekir. Bu güncelleme tam o mantığı taşıyor. Özellik güzel;
ama henüz tamamen cilalanmış değil. Biraz daha olgunlaşması lazım,
özellikle UX tarafında — Yine de yol haritasının kendisi umut verici.”>
Nerede kullanırım?
Eğer geliştirici ekibiniz Copilot’u yoğun kullanıyorsa önce repo bazlı faktörleri gözden geçiririm. Mesela test isimlendirmeleri, kurum içi (belki yanılıyorum ama) terminoloji, deploy tercihi gibi ortak bilgiler repo memory’ye aday olabilir. Ama kişisel alışkanlıklar —
editör teması,
komut biçimi,
kendi not tarzınız —
bunları user-level’da tutmak daha temiz olur.”>
Lafı gevelemeden söyleyeyim:
ilk adım olarak şunu yapın —
bir repo seçin,
Copilot Memory’yi açıp kapatma senaryosunu test edin,
sonra da üç şeyi kontrol edin:
kim görüyor,
nerede siliniyor,
log nasıl tutuluyor.
Bunu yapmadan üretime çıkmayın.”>
Sıkça Sorulan Sorular
Copilot Memory nedir?
Copilot Memory, hani GitHub Copilot’un sizin tercihlerinizi ya da repo bağlamını hatırlayabilmesini sağlayan bir özellik. Şu an public preview aşamasında ve yalnızca paid planlarda kullanılabiliyor (inanın bana). Açıkçası oldukça kullanışlı bir şey.
User-level preference ile repository-level fact arasındaki fark nedir?
Şunu söyleyeyim, User-level preference tamamen size özel, yanı sadece sizin oturumlarınızda devreye giriyor. Kısacası, repository-level fact işe biraz daha geniş kapsamlı; o repoda çalışan tüm katkıda bulunanları etkiliyor. Bence bu ayrımı bilmek önemli.
/memory komutu ne işe yarar?
İnanın, /memory on ile belleği açıyorsunuz, /memory off ile kapatıyorsunuz, /memory show ile de mevcut duruma bakıyorsunuz. Mesela bir oturumu kapatıp açsanız bile ayarınız korunuyor (buna dikkat edin). Tecrübeme göre bu özellikle uzun projelerde çok işe yarıyor.
Repository admin Copilot Memory’yi tamamen kapatabilir mi?
Evet, repository admin mevcut Copilot feature controls üzerinden memory özelliğini kapatabilir. Aslında — hayır dur, daha doğrusu oldukça basit bir işlem. Böylece yeni repository-seviyesi bilgiler ne saklanıyor ne de okunuyor.
Kaynaklar ve İleri Okuma
İşte, i̇lginç olan şu ki, GitHub Changelog duyurusu
GitHub Docs — Managing stored memories
About GitHub Copilot Memory — Resmî Dokümantasyon
MCP Apps Copilot Chat’te: İş Akışları Artık Konuşmanın İçinde
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.
3 comments