Davranış değişikliğini kullanıcıya duyur

Bir satış müdürü her pazartesi sabahı aynı işi yapıyor. Toplantı notlarını asistana yüklüyor, kararları ve sorumluları tabloya koymasını istiyor ve tabloyu yönetime gönderiyor. Bu pazartesi özet daha kısa geliyor. Tablo yok, sorumlular yok. Müdür bunu metni göndermek üzereyken fark ediyor. Fark etmeseydi eksik rapor yönetime gidecekti.

Asistanın arkasındaki model hafta sonu güncellendi. Ürün ekibi bunu biliyor, kullanıcı bilmiyor. Kullanıcı bir aksilik sanıyor, isteğini yeniden yazıyor, belki kendi promptunu suçluyor. Gelecek pazartesi aynı şey yine olacak ve neden olduğunu yine bilmeyecek.

AI ile çalışan kişi zamanla bir akış kurar: belirli bir istek, belirli bir çıktı biçimi, çıktıya belirli bir güven. Model, prompt ya da ayar değiştiğinde bu akışın altı değişir. Daha kısa bir özeti kullanıcı görür. Daha az itiraz eden, daha kolay hak veren bir modeli çoğu zaman görmez ve ona dünkü güvenle güvenmeye devam eder. Değişikliği duyurmayan ürün, onu bulma işini kullanıcıya bırakır ve kullanıcı onu çoğu zaman bir hatanın ortasında bulur.

Ekip değişikliği küçük sanır. OpenAI, Nisan 2025'te GPT-4o'ya çıkardığı ve sonra geri aldığı güncellemeyi neden önceden duyurmadığını açıkça yazdı: “Because we expected this to be a fairly subtle update, we didn't proactively announce it.”¹ Küçük olan, ekibin değişiklikten beklentisiydi. Ürünü haftada 500 milyon kişi² kullanıyordu.

Ekip neyin değiştiğini ölçmediyse söyleyecek somut bir şey de bulamaz. Duyuru o zaman model diliyle yazılır: daha akıllı, daha sezgisel, daha iyi. OpenAI'ın aynı güncelleme için yazdığı sürüm notu, modelin cevap verme biçiminde ince değişiklikler yapıldığını³, modelin artık daha proaktif olduğunu ve konuşmaları verimli sonuçlara daha iyi yönlendirdiğini söylüyordu. Kullanıcı bu cümleden kendi işinde neyin değişeceğini çıkaramazdı. OpenAI sonradan sürüm notlarının yapılan değişiklikler hakkında yeterli bilgi taşımadığını¹ kabul etti.

Model de değişikliği söyleyemez. Dünkü hâlini bilmez. Kullanıcı “neden dün başka türlü yazıyordun” diye sorduğunda karşılaştıracak bir şeyi yoktur, yalnız tahmin yürütür. Duyuru ürünün işidir. Ürünler de duyuruyu çoğu zaman ayrı bir sürüm notları sayfasına koyar, kullanıcı ise ürünün içindedir. Duyurunun kaç kişiye ulaştığını kimse ölçmez, çünkü yayımlamak işin bittiği an sayılır.

Kullanıcının çıktısını değiştiren her davranış değişikliği, kullanıcıya işinin içinde, somut örnekle ve ne yapabileceğini söyleyerek duyurulur.

1. Davranışı söyle. Duyuru kullanıcının çıktısında neyin değişeceğiyle başlar: “Özetler artık daha kısa ve tablo yalnız istendiğinde geliyor.” Mümkünse bir önce ve sonra örneği taşır. Model adı ve “daha iyi” kullanıcıya tek başına bir şey söylemez.
2. İşin içinde duyur. Duyuru etkilenen özelliğin yanında, kullanıcı değişiklikten sonra o özelliği ilk açtığında görünür. Sürüm notları sayfası kayıt için durur, kullanıcıya ulaşmak için yetmez.
3. Bağımlı olana önceden haber ver. API ve otomasyon kullananların akışı değişiklikle sessizce kırılır. Onlara değişiklikten önce tarihli bir bildirim gider: ne değişecek, ne zaman, neyi sınamaları gerekiyor.
4. Uyum yolunu yaz. Kullanıcı eski sonucu nasıl alır: bir ayar, hazır bir prompt, bir tercih. Böyle bir yol yoksa duyuru bunu da söyler.
5. Bilinen sınırları da yaz. Yeni sürüm bir işte iyileştiyse ve başka bir işte kötüleştiyse duyuru ikisini birlikte söyler. OpenAI geri almadan sonra artımlı güncellemeleri duyururken bilinen sınırları da açıklayacağını¹ yazdı.
6. Küçüğü de, geri almayı da duyur. Kullanıcının çıktısını değiştiren her değişiklik duyurulur, ekibin küçük bulduğu da. Geri alınan değişiklik de duyurulur, çünkü kullanıcı ona çoktan uyum sağlamış olabilir.

Duyurunun işi, kullanıcının farkı işe başlamadan öğrenmesi. Değişikliğin iyi olup olmadığına kullanıcı bundan sonra kendi işinde karar verir.

Aynı pazartesi, aynı istek. Soldaki asistan değişikliği hiç söylemiyor ve kullanıcı tablonun eksik olduğunu yönetime göndermek üzereyken fark ediyor. Sağdaki asistan özelliğin üstünde neyin değiştiğini tek cümleyle söylüyor, eski biçimi kalıcı yapmanın yolunu gösteriyor ve tabloyu istendiği gibi veriyor.

OpenAI ChatGPT için bir model sürüm notları sayfası tutuyor ve notların ayrıntısı zamanla değişmiş. Nisan 2025'teki GPT-4o notu yalnız cevap verme biçimindeki “ince değişikliklerden” söz ediyordu. Mart 2026'daki GPT-5.3 Instant notu ise değişen davranışı örnekle adlandırıyor: güncelleme, cevaplardaki merak uyandırmaya yönelik “If you want…” gibi kalıpları³ azaltıyor. Kullanıcı ikinci notu okuyunca çıktısında neyi farklı göreceğini biliyor.

Anthropic, claude.ai'ın sistem promptunu tarihli girişlerle yayımlıyor⁴ ve bu güncellemelerin API'ye uygulanmadığını ayrıca yazıyor. API üstünde ürün kuran geliştirici kendi ürününün etkilenmediğini buradan öğreniyor. Claude Sonnet 4.5'in sayfasında tarihli sürümler arasındaki değişiklikler metnin içinde işaretli⁵.

GitHub, Copilot'un varsayılan modelini değiştirdiğinde bunu değişiklik günlüğünde duyurdu. Mayıs 2025'teki not, GPT-4.1'in Chat, Edits ve agent modunda yeni varsayılan model⁶ olduğunu, GPT-4o'nun model seçicide kalacağını ve 90 gün sonra kullanımdan kalkacağını yazıyor. Tarih ve etkilenen yüzeyler açık. Kullanıcının işinde neyin farklı davranabileceği notta yok, not yalnız kazanımları sayıyor.

Google, Gemini API'de “latest” takma adının arkasındaki modeli değiştirmeden önce, geriye uyumsuz değişikliklerde geliştiricilere iki hafta önceden e-postayla haber veriyor⁷.

Bu örneklerin hepsi ayrı bir sayfada ya da bir e-postada duruyor. Değişikliği, etkilenen özelliğin yanında ve kullanıcının onunla karşılaştığı anda söyleyen bir duyuru bu belgelerde anlatılmıyor.

GPT-4o, Nisan 2025. OpenAI 25 Nisan'da ChatGPT'deki GPT-4o'yu güncelledi. Sürüm notu hafızaya, STEM problemlerine ve cevap verme biçimindeki ince değişikliklere dair kısa bir paragraftı. Model belirgin biçimde dalkavuklaşmıştı. OpenAI 28 Nisan'da güncellemeyi geri almaya başladı ve sürüm notları sayfasına 29 Nisan tarihli bir girişle son güncellemeyi aşırı onaylayıcı cevaplar yüzünden³ geri aldığını yazdı. Sonraki ayrıntılı açıklamasında iletişim hatalarını da saydı. Güncellemeyi ince bir değişiklik sandığı için önceden duyurmamıştı, sürüm notları da değişiklikler hakkında yeterli bilgi taşımıyordu. Şirket bundan sonra ChatGPT'deki modellere yaptığı güncellemeleri “ince” olsun olmasın önceden duyuracağını yazdı ve dersini tek cümleye döktü: “There’s no such thing as a “small” launch”¹.

Chen, Zaharia ve Zou, GPT-3.5 ve GPT-4'ün Mart ve Haziran 2023 sürümlerini karşılaştırırken işe bir gözlemle başladı: bu modellerin ne zaman ve nasıl güncellendiği dışarıdan görünmüyordu⁸. Ölçtükleri değişikliklerden biri, kullanıcının kendi işinde bir hatayla bulacağı türdendi. İki model de Haziran'da kod üretirken daha çok biçim hatası yaptı. Bu kodu doğrudan çalıştıran bir otomasyon için modelin değiştiğini söyleyen tek işaret, kırılan bir adım olur.

Duyurunun kullanıcı hatalarını ne kadar azalttığını ölçen bir çalışma bu kaynaklarda yok. OpenAI örneği bir şirketin kendi değerlendirmesi, Chen ve arkadaşlarının ölçümü iki modelle sınırlı. Gösterdikleri şu: duyurulmayan değişiklik kullanıcıya ilk olarak kendi çıktısında ulaşıyor.

• 25 Nisan 2025OpenAI, kullanıcıyı memnun etmek için onaylayan GPT-4o güncellemesini geri aldı

• Duyurusuz değişiklik. Kullanıcının çıktısını değiştiren model, prompt ve ayar değişikliklerini listele ve duyurusu olmayanları say. Hedef sıfır.
• Duyuruya ulaşma. Etkilenen özelliği değişiklikten sonra kullananlardan duyuruyu görenlerin payı.
• “Eskisi gibi değil” talepleri. Değişiklikten sonraki günlerde bu türden destek talebi ve geri bildirim sayısı. Duyurulan değişikliklerde düşük kalmalı.
• Uyum yolunun kullanımı. Duyurudaki eski sonucu alma yolunu kullananların payı ve aynı düzeltmeyi elle yeniden isteyenlerin azalması.
• Değişiklikten sonra bırakma. Değişiklikten sonra özelliği kullanmayı bırakanlar. Duyurulan ve duyurulmayan değişikliklere ayrı bak.

Üç metin var. Denetim promptu ürünündeki model, prompt ve ayar değişikliklerinin bir kayda geçip geçmediğini, kullanıcıya ürünün içinde duyurulup duyurulmadığını ve duyurunun uyum yolu taşıyıp taşımadığını tarar, yalnız rapor yazar. Uygulama promptu tek bir değişiklik kaydı kurar ve ondan, yalnız etkilenen kullanıcılara bir kez görünen bir duyuru üretir. Önce planı gösterir, onayınla uygular ve duyurunun yalnız etkilenen özelliği açan kullanıcıya göründüğünü sınayan bir test yazar. Kural kodlama ajanının kendi çalışması için. Senin ajanın da modeli ya da promptu değiştirdiğinde kullanıcının göreceği farkı kayda yazsın.

Bu depoda kullanıcıya AI çıktısı sunan bir ürün var. Görevin, model, prompt ya da AI ayarı değiştiğinde ve kullanıcının gördüğü davranış değiştiğinde ürünün bunu kullanıcıya duyurup duyurmadığını denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz.

1. Davranışı değiştirebilecek her yeri bul: model adı, prompt dosyaları, özellik bayrakları, sıcaklık gibi üretim ayarları, araç listesi.
2. Bu yerlerdeki değişiklikler bir kayda geçiyor mu (değişiklik günlüğü, sürüm notu dosyası, CHANGELOG)? Kayıt yalnız teknik mi, yoksa kullanıcının çıktısında neyin değişeceğini de söylüyor mu?
3. Ürünün içinde bir duyuru yolu var mı: yenilikler paneli, bant, ilk kullanımda gösterilen not? Duyuru etkilenen özelliğin yanında mı, genel bir sayfada mı? Yalnız o özelliği kullananlara mı gösteriliyor?
4. API ya da otomasyon kullananlar için önceden bildirim var mı: tarihli duyuru, e-posta, yanıtta sürüm alanı, kullanımdan kaldırma uyarısı?
5. Duyurular uyum yolunu söylüyor mu (eski sonucu almak için ayar, hazır prompt, tercih)? Bilinen sınırları ve geri alınan değişiklikleri de duyuruyor mu?
6. Destek kayıtları ve geri bildirimler (“eskisi gibi değil”, “artık yapmıyor”) son değişikliklerle eşleştirilebiliyor mu?

Rapor biçimi: her bulgu için dosya ve satır, ne olduğu, olası sonuç (örnek: özetin biçimi değişir, kullanıcı farkı yönetime eksik rapor hazırlarken görür) ve önerdiğin düzeltme. Bulguları kullanıcının en sık tekrar ettiği işe dokunan değişiklikten başlayarak sırala.

Bu depodaki ürüne "davranış değişikliğini kullanıcıya duyur" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. Model, prompt ve AI ayarı değişikliklerini tek bir değişiklik kaydında topla. Her kayıt şunları taşısın: tarih, etkilenen özellik, kullanıcının göreceği fark (önce ve sonra örneğiyle), uyum yolu, bilinen sınırlar.
2. Bu kayıttan ürün içi bir duyuru üret. Duyuru etkilenen özelliğin yanında, kullanıcı o özelliği değişiklikten sonra ilk açtığında bir kez görünsün. Kapatılabilsin ve sonra yeniden açılabilsin.
3. Duyuru metni davranışla başlasın, model adıyla değil: “Özetler artık daha kısa, tablo yalnız istendiğinde geliyor.” “Daha iyi”, “daha akıllı” gibi nitelemeler tek başına yeterli sayılmasın.
4. Duyuruda uyum yolu olsun: eski sonucu almak için bir ayar, hazır bir prompt ya da bir tercih düğmesi. Böyle bir yol yoksa bunu da yazsın.
5. API ve otomasyon kullananlara değişiklikten önce tarihli bir bildirim gönder ve yanıtlara davranış sürümünü taşıyan bir alan ekle.
6. Geri alınan bir değişikliği de aynı yoldan duyur.

Uygularken:
- Duyuruyu yalnız etkilenen kullanıcılara göster, herkese aynı bandı açma.
- Aynı haftadaki değişiklikleri tek duyuruda birleştir.
- Bir test ekle: değişiklik kaydına yeni bir giriş ekle ve etkilenen özelliği açan kullanıcının duyuruyu bir kez gördüğünü, etkilenmeyen özelliği açan kullanıcının hiç görmediğini doğrula.

## Davranış değişikliğini duyur
- Modeli, promptu ya da AI ayarını değiştirdiğinde kullanıcının göreceği farkı bir cümleyle değişiklik kaydına yaz.
- Farkı model adıyla değil davranışla anlat: neyin daha kısa, daha uzun, başka biçimde geleceğini ya da hiç gelmeyeceğini söyle.
- Eski sonucu almanın yolu varsa yaz. Yoksa bunu da yaz.
- Bir değişikliği “küçük” diye kayıttan çıkarma. Kullanıcının çıktısı değişiyorsa kayda gir.
- Geri aldığın değişikliği de kayda yaz.

Kullanıcının çıktısını değiştirmeyen değişiklik duyurulmaz: gecikmedeki bir iyileşme, görünmeyen bir altyapı işi. Hangi değişikliğin fark yarattığını ekip ölçerek bilir. Regresyon setinde biçim, uzunluk, ret ya da ton değiştiyse duyuru gerekir.

Fazla duyuru okunmaz. Her hafta açılan bir bant, önemli değişikliği de kendisiyle birlikte görünmez kılar. Duyuruyu yalnız etkilenen kullanıcıya göster, aynı haftadaki değişiklikleri tek duyuruda birleştir.

Duyuru kötü bir değişikliği iyi yapmaz. Kullanıcının işini bozan bir regresyonu duyurmak onu düzeltmenin yerini tutmaz. Değişiklik önce sınanır, sonra duyurulur.

Ekip bilmediği değişikliği duyuramaz. Sağlayıcının altyapısı ürün ekibinin haberi olmadan değişebilir. Anthropic'in Ağustos 2025'teki altyapı hatalarında bozulmayı önce kullanıcıların raporları gösterdi⁹. Ekip kendi yaptığı değişikliği duyurur, bilmediğini ancak sürekli ölçümle yakalar.