GPT-5.2’nin Veda Notu: Copilot Ekipleri Şimdi Ne Yapmalı?
Bakın, GitHub’ın 5 Haziran 2026 tarihli duyurusunu ilk okuduğumda aklıma gelen şey şu öldü: “Tamam, model değişiyor da asıl mesele bizim iş akışlarımız ne kadar kırılgan?” Çünkü açık konuşayım, yapay zekâ tarafında sürüm numarası bazen sadece sürüm numarası olmuyor; ekiplerin alışkanlığına, maliyete, hatta güvenlik politikasına kadar dokunuyor. GPT-5.2 ve GPT-5.2-Codex’in çoğu GitHub Copilot deneyiminde emekliye ayrılması tam da böyle bir konu (şaşırtıcı ama gerçek)
İkinci adım olarak Copilot Enterprise yöneticileri model policy ayarlarını gözden geçirmeli. Yeni modellerin açıldığını sanmakla gerçekten erişilebilir olması aynı şey değil. VS Code’da modeli seçicide görmüyorsanız çoğu zaman sebep budur. Ben bunu geçen yıl bir düşüneyim… Ankara’daki bir kamu kurumunda yaşadım; politika açık sanılıyordu ama bireysel kullanıcı izinleri kapalıydı. Sonuç? Herkes birbirine baktı kaldı…
Oops—buraya görsel koymadım çünkü istem dışı yer tutucu olurdu diye bıraktım gibi düşünmeyin; zaten görsel eklemiyorum.
Üçüncü adımda test setinizi hazırlayın:
- Aynı prompt ile eski-yeni çıktı karşılaştırması yapın. (bu kritik)
- Kod review örneklerinde ton ve açıklama uzunluğunu ölçün.
- Ajan modunda araç çağrılarının değişip değişmediğine bakın. — bunu es geçmeyin
- Tetiklenen güvenlik kontrollerinin aynı kalıp kalmadığını doğrulayın.
- Eğer bütçe kısıtlıysa önce sınırlı grupta deneyin.
- Eğer enterprise ölçekliyse governance ekibini baştan dahil edin.
- Kullanılan tüm Copilot senaryolarını çıkarın.
- Etkilenen kullanıcı gruplarını belirleyin.
- Yeni modeli sınırlı alanda açıp test edin.
- Error rate yerine çıktı kalitesini de değerlendirin. — bunu es geçmeyin
- Tamam diyene kadar production genişletmesi yapmayın.
Aklımdaki küçük hile şu: hangi modelin nerede kullanıldığını tek sayfalık basit bir envanterde tutun.
Excel olur mu?
Olur.
Mükemmel mi?
Hayır ama işe yarar… en azından başlangıçta.
Bak bir de şunu söyleyeyim: ilk migration sırasında çıkan hatalar sizi korkutmasın.
2023’te İzmir’de bir SaaS firmasında benzer şekilde “model bulunamadı” uyarısı almıştık çünkü selector’da ilgili policy aktif değildi;
Sorun aslında platformdan çok yetkilendirme katmanındaydı.
Çözümü bulunca herkes rahatladı ama o yarım günlük kayıp kimsenin hoşuna gitmedi.
Bence doğru olan operasyon planı ne?
Eğer benim AZ-305 sınavına hazırlanırken öğrendiğim bir şey varsa o da şu:
Teknik çözüm kadar işletim modeli de önemli.
Burada da aynı mantık var.
Yeni modele geçişi sadece teknik görev gibi ele almayın;
sahiplik atayın,
geri dönüş planını yazın,
ve ölçüt belirleyin.
“Daha iyi hissettirdi” ölçüt değildir.
Aşağıdaki sıra fena olmayan bir başlangıç verir:
Ha bu arada,
eğer sizin ekip henüz AI Governance konuşmuyorsa şimdi tam zamanı.
Model emekliliği ufak görünür;
ama policy,
uyumluluk,
kullanıcı eğitimi
ve maliyet kontrolü hepsi birbirine bağlıdır.
Bir arkadaşımız Temmuz 2024’te Londra’daki fintech ofisinde bunun tersini yaptı;
direkt topluca güncelledi,
sonra üç farklı takım aynı anda farklı davranış rapor etti.
İş biraz çorba öldü.
Düzeltildi mi?
Evet.
Kolay mıydı?
Hiç değildi.
Küçük ekipler ne yapsın?
Küçük ekipseniz fazla bürokrasi kurmayın ama körlemesine de ilerlemeyin.
Basit bir checklist yeter:
hangi repo,
hangi kullanıcı grubu,
hangi kullanım tipi etkileniyor?
Sonra iki saatlik kontrollü test yapıp devam edersiniz.
Bu yaklaşım idare eder;
fazlasına gerek olmayabilir.
Büyük kurumlar ne yapsın?
Büyük yapılarda işe olay biraz daha ağır yürümeli.
Change board’a not düşülmeli,
policy owner onayı alınmalı,
gerekirse ayrı subscription ya da tenant segmentasyonu düşünülmeli.
Ben özellikle Azure danışmanlığı yaptığım projelerde şunu görüyorum:
kurum büyüdükçe teknik kararların yanına belge zorunluluğu geliyor;
bu kötü değil,
aksine işi düzenli tutuyor.
Müşteri cephesinde gördüğüm küçük tuzaklar
Ve son olarak.
..
Bir proje boyunca en çok can sıkan şey genelde teknoloji olmuyor;
insan alışkanlığı oluyor.
Kullanıcı yeni modeli açınca çıktının stilini beğenmezse hemen “bozuldu” diyor.
Oysa belki sadece ton değişmiştir.
Geçen ay Nisan 2026’da Bursa’daki üretim firmasındaki geliştiricilerde bunu yaşadık:
ayný prompt eskisine göre daha açıklayıcı cevap verdi,
ama takım kısa yorum istiyordu;
biraz eğitimle düzeldi.
Yanı evet,
bu tür deprecation haberleri ilk bakışta sıradan görünebilir;
hatta biraz hayal kırıklığı yaratabilir;
ama doğru ele alınırsa fırsata dönüşüyor.
Sisteminizi sadeleştirmek için iyi bahane verir.
Kod bloğunuzu temizlersiniz,
policy’nızı gözden geçirirsiniz,
gereksiz bağımlılıkları kaldırırsınız.
{
"old_models": ["gpt-5_2", "gpt-5_2_codex"],
"recommended": ["gpt-5_5", "gpt-5_3_codex"],
"checks": [
"copilot chat",
"inline edits",
"ask mode",
"agent mode",
"code completions"
]
}
(yanlış duymadınız)
Sıkça Sorulan Sorular
GPT-5.2 tamamen kaldırıldı mı?
Şunu söyleyeyim,
Hayır, aslında Copilot code review içinde hâlâ kullanılabiliyor. Ama yanı diğer çoğu Copilot deneyiminden çekilmiş durumda, o yüzden workflow’unuzu bir gözden geçirmeniz iyi olur.
Copilot Enterprise yöneticisi olarak neyi kontrol etmeliyim?
Önce model policies kısmına bakın. Alternatif modeller açık mı, kullanıcıların kendi settings ekranlarında görünüyor mu — bunları doğrulayın. Bence bu adımı atlamak sonradan gereksiz baş ağrısı yaratıyor.
Ekipler hemen migrate etmeli mi?
Evet, özellikle üretimde kullanılan akışlar varsa geciktirmeyin. Tecrübeme göre küçük çaplı testten sonra aşamalı geçirmek en sağlıklısı.
Peki hangi alternatifi seçmeliyim?
Size bir şey söyleyeyim,
Genel kullanım için GPT-5.5, Codex ağırlıklı işler için GPT-5.3-Codex öneriliyor. Ama açıkçası kullanım senaryonuz refactor mı, review mu, agent task mı — ona göre karar verin. E peki, sonuç ne öldü? Herkese uyan tek bir cevap yok maalesef.
Microsoft Learn GitHub Copilot Belgeleri
GitHub Copilot Dokümantasyonu
GitHub Blog Changelog Ana Sayfa
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.
2 comments