Beklerken ne yaptığını söyle

Kullanıcı asistana üç tedarikçinin sözleşmesini veriyor ve ödeme ile fesih maddelerini karşılaştırmasını istiyor. Ekranda bir simge dönmeye başlıyor, yanında tek kelime var: düşünüyor. Kullanıcı bekliyor. Simge aynı hızla dönüyor, kelime aynı kalıyor. Bir süre sonra kullanıcı şunları bilmiyor: AI hangi sözleşmede, iş ilerliyor mu, bağlantı mı koptu, bir adımda mı takıldı.

Dönen simge bu dört durumun hepsinde aynı görünüyor. Çoğu üründe simge tarayıcının kendi animasyonu. İstek gönderildiği için dönmeye başlar ve cevap gelene kadar durmaz. Sunucu çökse de döner. Kullanıcıya söylediği tek şey bir isteğin gönderilmiş olduğu.

Kullanıcı bu boşluğu kendi tahminiyle dolduruyor. Kimi aynı isteği bir daha gönderiyor ve iş iki kez yapılıyor. Kimi sayfayı yeniliyor ve yarım işi kaybediyor. Kimi takıldı sanıp çıkıyor, oysa iş bitmek üzereydi. Kullanıcı adına iş yapan ajanda bekleme daha pahalı. Ajanın o an bir dosyayı mı okuduğunu, yoksa silmeye mi geçtiğini görmeyen kullanıcı araya girmesi gereken anı kaçırıyor.

Dönen simge yalnız isteğin gönderildiğini söyler. Kullanıcının bilmesi gereken her şey simgenin arkasında kalıyor.

Bekleme ekranı ekibin en az baktığı ekran. Geliştiricinin denediği küçük örnekte cevap birkaç saniyede gelir, simge görünüp kaybolur. Kullanıcının gerçek dosyasında aynı iş dakikalar sürer ve o dakikalarda ekranda yalnız simge vardır.

Gerçek durumu göstermek mimariyi değiştirir. Ürün çoğu zaman tek bir istek gönderir ve tek bir cevap bekler. Ajanın içinde onlarca araç çağrısı olur ama hiçbiri arayüze olay olarak çıkmaz. Durum satırı için araç katmanının her adımda “başladım” ve “bitirdim” demesi, bu olayların arayüze kadar taşınması gerekir. Simge bir satırlık kod, olay hattı bir proje.

Model de varsayılan olarak susar. Anthropic'in en yeni modellerinde düşünme metni varsayılan olarak gizli geliyor ve ancak açıkça istenince dönüyor¹. Ekip bir şey istemezse ajan araç çağırırken ya da düşünürken arayüze gösterecek bir metin vermiyor. Boşluğu doldurmak isteyen ekip de çoğu zaman kısa yolu seçiyor: zamanlayıcıyla dönen hazır cümleler. “Analiz ediliyor”, “Neredeyse bitti”. Bu cümleler hiçbir adıma bağlı olmadığı için iş takılsa da dönmeye devam ediyor.

Ölçüm de bu boşluğu göstermiyor. Ekipler toplam cevap süresine bakar. Bekleme sırasında aynı isteği yeniden gönderen, sayfayı yenileyen ya da “hâlâ orada mısın” diye yazan kullanıcı ayrı bir sayı olarak görünmez.

Bekleme ekranı AI'ın o an yaptığı gerçek adımı söyler. Kullanıcı çalışan işle takılan işi tek bakışta ayırır.

1. Adımı adıyla söyle. “Düşünüyor” yerine “Tedarikçi B sözleşmesi okunuyor”. Metin gerçek bir olaydan gelir: başlayan araç çağrısı, okunan dosya, aranan kaynak. Apple'ın kılavuzundaki örnek aynı yönde, “Processing…” yerine “Finding substitutions for ingredients”².
2. Biteni ve süreni ayır. Biten adımlar listede tikle durur, süren tek adım öne çıkar. Toplam iş biliniyorsa kaçta kaç olduğunu yaz. Bilinmiyorsa Nielsen'in eski önerisi hâlâ işe yarıyor: işlenen her birimin adını sırayla yazdır³.
3. Durgunluğu söyle. Bir adım beklenenden uzun sürerse ekran bunu söyler ve bildiği nedeni yazar: büyük dosya, yavaş kaynak, yeniden deneme. Bağlantı koparsa simge durur ve hata yazılır. İnsanlar duran göstergeyi takılmış bir süreçle⁴ eşleştirir, bu yüzden takılan işte dönmeye devam eden gösterge takılmayı gizler.
4. Hazır cümle döndürme. Zamanlayıcıyla değişen metin bir adıma bağlı olmadığı için takılan işte de “neredeyse bitti” demeye devam eder.
5. Geri dönüşü olmayan adımı fiiliyle yaz. Ajan silmeye, göndermeye ya da ödemeye geçtiğinde durum satırı bunu nesnesiyle söyler: “Eski e-postalar çöpe taşınıyor”. Kullanıcı araya girmesi gereken anı bu satırdan görür.

Durum metninin kaynağı araç katmanı. Her adımda bir olay yayar, arayüz satırı bu olaydan yazar. Modelin yazdığı ilerleme notu varsa satırın altında açıklama olarak durur.

Aynı karşılaştırma işi, iki bekleme ekranı. Soldaki ekranda aynı satır dakikalarca duruyor ve kullanıcı “hâlâ orada mısın” diye yazıyor. Sağdaki ekran her sözleşmeyi okununca işaretliyor, uzayan adımı nedeniyle söylüyor ve kullanıcıya beklemek dışında bir yol açıyor.

Apple'ın üretken AI kılavuzu bekleme anına ayrı bir madde ayırıyor. Gerçekte ne olduğunu anlatan mesajın belirsiz bir durum mesajından daha yararlı olabileceğini² yazıyor. Aynı şirketin ilerleme göstergesi kılavuzu da “loading” ya da “authenticating” gibi belirsiz kelimelerden kaçınmayı⁴ öneriyor.

Anthropic, Claude'un API'sinde bu ihtiyaç için ayrı bir ayar tutuyor. Bazı modeller araç çağrıları arasında kısa bir ilerleme notu yazıyor. Belge bu notu modelin az önce ne bulduğunu ve sırada ne yapacağını anlatan, ajanı izleyen kişi için yazılmış bir not¹ diye tarif ediyor. display: "updates" ayarını da akıl yürütmeyi gizleyip kullanıcıya her adımda bir durum satırı gösteren ajan arayüzleri için öneriyor. Ayar şimdilik beta.

OpenAI'ın gecikme rehberi aynı ilkeyi kısa yazıyor. Birden çok adım atılıyor ya da araç kullanılıyorsa bunu kullanıcıya göster, gösterebildiğin gerçek ilerleme ne kadar çoksa o kadar iyi⁵.

GitHub'ın kodlama ajanı aynı bilgiyi oturum günlüğüne koyuyor. Günlük Copilot'ın iç akıl yürütmesini ve kullandığı araçları⁶ gösteriyor, kullanıcı ajanın ilerlemesini oturum sürerken izleyebiliyor.

Bu desenin dayanağı ürünlerin ve platform kılavuzlarının ortak uygulaması. Bekleme üzerine yazılan kurallar ise AI'dan çok eski.

Jakob Nielsen 1993'te üç sınır yazdı. Bir saniyeye kadar kullanıcının düşünce akışı kesilmez. On saniye kullanıcının dikkatini işte tutmanın sınırıdır. Daha uzun bekleyişlerde kullanıcıya işin ne zaman biteceğini söyleyen geri bildirim³ gerekir. Nielsen ilerleme göstergesinin ilk yararını da yazıyor: kullanıcıya sistemin çökmediğini, işi üzerinde çalıştığını söylemek. Dakikalar süren bir ajan işi bu sınırların çok ötesinde.

Bekleyen kullanıcı sessizliği kendi yorumuyla dolduruyor. Tan ve arkadaşlarının 2026 tarihli ön baskısında katılımcılar ilk kelimenin gelmesini 2, 9 ya da 20 saniye bekledi. Katılımcılar gecikmeyi AI'ın düşünmesine bağladı, uzun beklemeler bu yorumu zaman zaman hayal kırıklığına ya da güvenilirlik kaygısına⁷ çevirdi. Aynı çalışmada 2 saniye bekleyenler çıktıyı daha az özenli ve yararlı buldu. Ekranda gerçek adım yoksa kullanıcının yorumu yalnız süreye dayanıyor.

OpenClaw, Şubat 2026. Summer Yue'nin paylaştığı ekran görüntülerinde ajanın her komutu sohbete ayrı bir satır olarak düşüyor. Yue önce ajana ne yaptığını soruyor. Gelen satırlardan biri şu: “Nuclear option: trash EVERYTHING in inbox older than Feb 15”⁸. Yue bir dakika içinde “Do not do that” yazıyor. Satır tehlikeyi zamanında gösterdi. Ajan yine de durmadı, o ayrı bir sorun.

Bu çalışmaların hiçbiri AI ürünlerinde durum satırının etkisini doğrudan ölçmüyor. Etkiyi kendi ürününde aşağıdaki sinyallerle ölç.

• 23 Şubat 2026OpenClaw üç “dur” mesajına rağmen gelen kutusundaki e-postaları çöpe atmayı sürdürdü

• Bekleme sırasında yeniden gönderme. Cevap gelmeden aynı isteğin ikinci kez gönderildiği ya da sayfanın yenilendiği oturumların payı. Desen işliyorsa düşer.
• Bekleme sırasında vazgeçme. İş bitmeden kapatılan sekmeler ve iptaller. Hangi adımda vazgeçildiğine bak, kullanıcıyı yoran adım orada görünür.
• Durum metninin doğruluğu. Rastgele seçtiğin oturumlarda ekranda gösterilen adımı sunucu günlüğüyle karşılaştır. Günlükle eşleşmeyen satır olmamalı.
• Uzama uyarısının isabeti. “Bu adım uzadı” uyarılarının ne kadarı gerçek bir sorunla bitiyor, gerçek takılmaların ne kadarı uyarı veriyor? İki oran da yüksek olmalı.
• “Ne yapıyorsun” mesajları. Kullanıcının bekleme sırasında “hâlâ orada mısın”, “ne oldu” gibi yazdığı mesajlar. Durum satırı işini yapıyorsa azalır.

Üç metin var. Denetim promptu bekleme ekranını çizen bileşenleri ve ajanın araç çağrılarını bulur, ekrandaki metnin gerçek bir adıma bağlı olup olmadığını raporlar, hiçbir dosyayı değiştirmez. Uygulama promptu araç katmanına başladı ve bitti olayları ekler, durum satırını bu olaylardan çizer. Önce planı gösterir, onayınla uygular ve takılan bir adımı taklit eden bir test ekler. Kural kodlama ajanının kendi işi için. Sana uzun süren bir AI özelliği yazdığında bekleme ekranını dönen simgeye bırakmasın.

Bu depoda kullanıcıya açılan bir AI özelliği var (sohbet, yan panel ya da kullanıcı adına iş yapan bir ajan). Görevin, AI çalışırken kullanıcının ekranda ne gördüğünü denetlemek: bekleme ekranı AI'ın o an ne yaptığını söylüyor mu, çalışan işle takılan işi ayırıyor mu? Hiçbir dosyayı değiştirme, yalnız rapor yaz.

1. Bekleme hâlini çizen bileşenleri bul: yükleniyor durumları, dönen simge (spinner), iskelet ekranlar, "düşünüyor" ya da "yazıyor" metinleri, ilerleme çubukları.
2. Bu bileşenler neye bağlı: yalnız isteğin gönderilmiş olmasına mı (istemcideki bir isLoading bayrağı gibi), yoksa sunucudan gelen olaylara mı (akış olayları, araç çağrısı başladı ve bitti olayları, iş durumu sorgusu)?
3. Ajan döngüsünü ve araç çağrılarını bul. Her araç çağrısı başladığında ve bittiğinde arayüze bir olay gidiyor mu? Gidiyorsa olayda insanın okuyacağı bir ad var mı (hangi dosya, hangi kaynak, hangi işlem)?
4. Ekranda zamanlayıcıyla değişen hazır cümleler var mı ("Analiz ediliyor", "Neredeyse bitti" gibi)? Bunlar gerçek bir adıma bağlı mı?
5. Bir adım beklenenden uzun sürdüğünde ne oluyor: zaman aşımı, yeniden deneme, kullanıcıya bildirim? Ağ koptuğunda ya da sunucu hata verdiğinde dönen simge duruyor mu, dönmeye devam mı ediyor?
6. Model çağrısında düşünme özeti ya da ilerleme notu (reasoning summary, progress update, thinking) açık mı? Açıksa arayüzde gösteriliyor mu, yoksa atılıyor mu?
7. Geri dönüşü olmayan adımlar (silme, gönderme, ödeme) bekleme ekranında öteki adımlardan ayırt ediliyor mu?

Rapor biçimi: bekleme ekranının bugünkü hâlinin kısa tarifi, sonra her bulgu için dosya ve satır, ne olduğu, kullanıcının o an neyi göremediği ve önerdiğin değişiklik. En sonda sunucudan arayüze bugün hangi durum olaylarının gittiğini ve hangilerinin eksik olduğunu listele.

Bu depodaki AI özelliğine "beklerken ne yaptığını söyle" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. AI çalışırken ekranda tek bir durum satırı dursun ve o an yapılan gerçek adımı söylesin: "Tedarikçi B sözleşmesi okunuyor", "3 kaynak tarandı, 4. taranıyor". Metin sunucudan gelen olaydan üretilsin, istemcide uydurulmasın.
2. Biten adımlar tikle listelensin, süren adım öne çıksın. Toplam adım sayısı biliniyorsa kaçta kaç olduğu yazsın. Bilinmiyorsa işlenen her birimin adı görünsün.
3. Bir adım belirlediğin süreyi aşarsa (örnek: 20 saniye) durum satırı bunu söylesin ve bildiği nedeni yazsın (büyük dosya, yavaş kaynak, yeniden deneme). Bağlantı koparsa ya da sunucu hata verirse dönen simge dursun, yerine hata metni gelsin.
4. Geri dönüşü olmayan bir adıma (silme, gönderme, ödeme) geçerken durum satırı bunu fiiliyle ve nesnesiyle yazsın: "Eski e-postalar çöpe taşınıyor".
5. Ayrıntıyı ayrı tut: durum satırı tek cümle, tam araç çağrısı günlüğü açılır bir bölümde.

Uygularken:
- Araç katmanına "başladı" ve "bitti" olayları ekle (araç adı, hedef, süre, sonuç) ve bunları arayüze akıt. Arayüz durum metnini bu olaylardan üretsin.
- Model ilerleme notu ya da düşünme özeti üretebiliyorsa onu satırın altında açıklama olarak kullanabilirsin, ama adımın kendisini araç olayından al.
- Zamanlayıcıyla dönen hazır cümleleri kaldır.
- Bir test ekle: sahte bir aracı 30 saniye bekleterek çalıştır ve arayüzün önce adımın adını, sonra uzama uyarısını gösterdiğini doğrula. Sunucu hatasını taklit eden ikinci bir test, dönen simgenin durup hata metni gösterdiğini doğrulasın.

## Beklerken ne yaptığını söyle
- Uzun sürebilecek bir AI işi yazarken bekleme ekranını da yaz: o an yapılan adımı tek cümleyle söyleyen bir durum satırı.
- Durum metnini gerçek bir olaydan üret (araç çağrısı, okunan dosya, aranan kaynak). Zamanlayıcıyla dönen hazır cümle yazma.
- Biten adımla süren adımı ayır. Toplam biliniyorsa kaçta kaç olduğunu yaz.
- Bir adım uzarsa ya da hata verirse dönen simgeyi durdur ve nedenini yaz.
- Silme, gönderme ve ödeme adımlarını durum satırında fiiliyle ve nesnesiyle yaz.

Kısa işte durum satırı göz kırpar. Nielsen 2 ile 10 saniye arasındaki işlerde gerçek bir yüzde göstergesinin fazla gelebileceğini³ yazıyor, ekran çok hızlı değişince kullanıcı takip edemiyor. Birkaç saniyelik işte sakin bir gösterge yeter.

Ayrıntı boğar. Ham araç çağrıları okunmuyor. Durum satırı tek cümle olsun, tam günlük açılan bir bölümde dursun. Claude Code bunu iki düzeyde çözüyor: ekranda kısa satırlar, bir tuşla açılan dökümde ayrıntılı araç kullanımı⁹.

Durum satırı gerekçe sayılmaz. Modelin yazdığı ilerleme notu ya da düşünme özeti, Anthropic'in belgesinin dediği gibi akıl yürütmenin bir özeti¹. Kullanıcı ikna edici bir durum satırını işin doğru gittiğinin kanıtı sanabilir. Satır ne yapıldığını söyler, doğru yapılıp yapılmadığını söylemez.

Durum satırı işi görünür kılar, işin yönünü değiştirmez. Yanlış yöne giden işi durdurmak, uzun işi arka plana alıp bitince haber vermek ayrı desenler.