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)
📋 İçindekiler
Hani, Ben bu haberi ilk okuduğumda aklıma hemen 2024’te İstanbul’da bir fintech ekibiyle yaptığımız oturum geldi. Ekip Copilot’u sevmişti. Tek bir soru herkesi geriyordu: “Bu öneriler kullanıcıya özel mi, yoksa repo içinde dolaşıp duracak mı?” Açık konuşayım, kurumsal tarafta asıl mesele çoğu zaman modelin zekâsı değil; veri sınırı. İşte bu güncelleme biraz o düğümü gevşetiyor.
Bir de dürüst olayım: Copilot Memory hâlâ public preview (yanlış duymadınız). Yanı kağıt üstünde iyi dürüyor, pratikte işe biraz pişmeye devam ediyor (ben de ilk duyduğumda şaşırmıştım). Ama yön doğru. Hem kullanıcı tarafında hem repo tarafında daha net kontrol vermesi — özellikle güvenlik ve yönetişim kafası çalışan ekiplerde — baya işe yarar.
Asıl değişen ne?
Bu sürümde üç parça öne çıkıyor. İlki, bir şeyi sildirmek istediğinizde Copilot artık sizi doğru yere yönlendiriyor; yanı “unut” dediğinizde lafı uzatmadan nereye gitmeniz gerektiğini söylüyor ve mümkün olan yerlerde ilgili belleğe oy düşürüyor. İkincisi, repository seviyesinde kapatma anahtarı geliyor. Üçüncüsü de Copilot CLI içine daha net bellek komutları ekleniyor.
Çok konuştum, örnekle göstereyim.
İlginç olan şu ki, Bakın şimdi, bu üçü tek tek küçük gibi durabilir. Ama birlikte düşününce tablo değişiyor. Kurumsal dünyada bazen en büyük sorun özellik eksikliği değil, yönetim eksikliğidir. Bir şey var ama kapatamıyorsun; siliyorsun ama etkisini göremiyorsun; kullanıcı neyi kaydettiğini anlamıyor… Sonra güvenlik ekibi devreye giriyor ve herkes birbirine bakıyor (ciddiyim)
İlk denememde ben de küçük bir takılma yaşadım. Azure ile entegre çalışan bir geliştirme ortamında komut akışını test ederken beklediğim açıklığı bulamadım; sonra detaylara inince gördüm ki mantık aslında basit: kullanıcı seviyesi tercih başka şey, repo seviyesi bilgi başka şey. Bunu ayırmaları iyi olmuş. Ama yine de arayüz tarafı biraz ham dürüyor, bunu da söyleyeyim.
Hmm, bunu nasıl anlatsamdı…
Kapsam ayrımı neden önemli?
Şunu söyleyeyim, Şimdi gelelim işin en kritik yerine: kapsam. Copilot bir şeyi “hatırlarken” bunun kime ait olduğunu açık söylemek zorunda kalıyor artık. Store_memory isteminde entry’nın user-level preference mı yoksa repository-level fact mi olduğu daha net yazılıyor.
Bunu basit anlatayım. User-level preference, sizin defteriniz gibi düşünün; sadece size ait notlar var orada. Repository-level fact işe ofiste ortak panoya asılmış post-it gibi; ekipten herkes görür. Karışınca sorun çıkıyor çünkü insanlar bazen kişisel tercihleri kurumsal bilgi sanıyor ya da tam tersi oluyor.
Peki neden?
Kurumsal müşterilerimde gördüğüm kadarıyla Türkiye’de bu tür AI özelliklerinin benimsenmesi biraz farklı ilerliyor. Küçük startup’lar genelde “hız veriyor mu?” diye bakıyor; enterprise ekipler işe “kim görebiliyor?”, “log’a düşüyor mu?”, “silme izi var mı?” diye soruyor. Doğru soru da zaten bu oluyor. Çünkü üretim ortamında yanlış scope yüzünden çıkan kriz, yeni modelden gelen parlak öneriden çok daha pahalıya patlıyor.
| Konu | User-level preference | Repository-level fact |
|---|---|---|
| Görünürlük | Sadece sız | Tüm katkıda bulunanlar |
| Kullanım alanı | Kişisel çalışma biçimi | Ekip ortak bağlamı |
| Saklama kararı | Kullanıcı yönetir | Repo sahibi yönetir |
| Etkisi | Sizin oturumlarınızda geçerli | Repo genelinde geçerli olabilir |
Copilot Memory’nın güçlü yanı hafıza eklemesi değil sadece; hafızanın sınırını görünür kılması.
/memory komutu sahaya inmiş durumda
CLI tarafı bence en az konuşulan ama en kullanışlı parça olmuş olabilir ya da bana öyle geliyor; çünkü /memory on ile açıyorsunuz, /memory off ile kapatıyorsunuz, /memory show ile durumuna bakıyorsunuz. Tahmin eder mısınız? Bu kadar sade olması hoşuma gitti çünkü günlük işte karmaşık menülerle uğraşmak insanın hevesini kaçırıyor.
/memory on
/memory off
/memory show
Açıkçası, 2019’da kendi lab ortamımda benzer bir ajan denemesini PowerShell üzerinden yapmıştım; komut vardı ama davranış belirsizdi. Ekip her seferinde farklı yorumluyordu (yanlış duymadınız). Şimdi burada persistence across sessions yaklaşımı var ve bu ciddi fark yaratıyor (küçük görünen fark bazen işi çözüyor). Kullanıcı tekrar tekrar ayar yapmıyor; sistem davranışı hatırlanıyor… ironik şekilde sistem de hatırlamayı öğrenmiş oluyor.
Şöyle söyleyeyim, E tabi burada ufak bir risk de var: CLI kolaylaştıkça insanlar politikayı ciddiye almadan açıp kapatabiliyor.
Büyük kurumsal yapılarda bunu RBAC ve merkezî politika ile desteklemek şart gibi dürüyor bana göre.
Küçük ekipte manuel kontrol idare eder;
enterprise’da işe standartlaştırma lazım.
Maalesef iş oraya gidiyor.
Peki neden?
Çünkü rahat kullanım bazen gevşek disiplin getiriyor.
Tam da öyle.
Küçük ekip mi, büyük kurum mu?
Küçük bir startup iseniz işiniz nispeten rahat olabilir.
Bir-iki repo vardır,
birkaç geliştirici vardır,
ve Copilot Memory’yi deneyip geri bildirım toplarsınız.
Burada öncelik hızdır;
kimin neyi gördüğü zaten toplantıda hızlıca çözülür.
Ama büyük kurumdaysanız hikâye değişir.
Bir bankacılık projesinde geçen yıl bunu çok net gördüm:
aynı araç beş farklı ekibin eline geçince soru sayısı da beş kat artıyor.
“Bu bilgi nereden geldi?”, “Silindiğinde gerçekten gidiyor mu?”, “Audit trail var mı?” — bunlar boş soru değil.
İşte böyle yerlerde repository-level off switch altın değerinde oluyor.
Çünkü bazen en iyi güvenlik özelliği,
kapatabilmektir.
Biraz sert söyledim. Gerçek bu. Daha fazla bilgi için TypeScript 7.0 Beta: Hız Değil, Asıl Mesaj Daha Büyük yazımıza bakabilirsiniz. Visual Studio Mayıs Güncellemesi: Planla, Gözden Geçir, İyileştir yazımızda bu konuya da değinmiştik.
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. Python AI Uygulamalarında Azure App Service: Hız Kazandıran Sessiz Değişim yazımızda bu konuya da değinmiştik. Bu konuyla ilgili DSC v3.2.0 ile Konfigürasyon Kontrolü Daha Olgun Hale Geliyor yazımıza da göz atmanızı tavsiye ederim.
- 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.”> SAP ve Azure’da Yeni AI Dönemi: Kurumsal Akıl Nereye Gidiyor? yazımızda bu konuya da değinmiştik.
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
3 comments