Uzun işi arka plana al, bitince haber ver

Kullanıcı ajana uzun bir iş veriyor: iki yılın destek kayıtlarını taramak, bir pazarı araştırmak, bir kod tabanında hatayı bulup düzeltmek. Ekranda bir ilerleme sayacı beliriyor. Kullanıcının o sırada yapacağı başka işler var, ama sekmeyi kapatırsa ne olacağını bilmiyor. Ürün de söylemiyor.

Kullanıcı ya ekranın başında bekliyor ya da işi hiç başlatmıyor. Bekleyen kullanıcı dakikalarını ilerleme sayacına bakarak harcıyor. Bekleyemeyen kullanıcı sekmeyi kapatıyor, döndüğünde iş yok, yeniden başlatıyor ve aynı süreyi, aynı kullanım payını bir daha harcıyor. Bilgisayar uykuya geçtiğinde, tren tünele girdiğinde, tarayıcı güncellendiğinde de aynısı oluyor.

Ajan ne kadar uzun iş yapabiliyorsa bu kısıt o kadar pahalıya patlıyor. Dakikalar süren bir işi kullanıcının sekmesine bağlayan ürün, işin uzunluğunu kullanıcının sabrıyla sınırlıyor.

İlk sürümde en kısa yol işi isteğin içinde çalıştırmak. Sohbet arayüzü zaten bir istek ve bir akış üstüne kurulu: kullanıcı yazar, model cevabı akıtır, bağlantı kapanır. Birkaç saniyelik cevapta bu yeter. Aynı yapıya ajan döngüsü, araştırma ya da büyük dosya işleme eklenince istek dakikalarca açık kalıyor ve bağlantının kopması işin sonu oluyor. Arka plan için iş kuyruğu, kalıcı iş kaydı ve bildirim kanalı gerekiyor. Üçü de demoda görünmeyen altyapı.

İkinci neden beklemenin yanlış hesaplanması. Jakob Nielsen'in tepki süresi sınırlarına göre on saniye, kullanıcının dikkatini diyalogda tutmanın aşağı yukarı sınırı. Daha uzun gecikmede kullanıcı beklerken başka işler yapmak ister¹. Ekipler süreyi kendi demolarında ölçer ve uzun işi seyrek bir durum sayar. Araştırma ajanlarında bu süre dakikalarla ölçülüyor. OpenAI derin araştırma modellerinin işlerinin onlarca dakika sürebildiğini² yazıyor.

Üçüncü neden ölçümde. Ekipler başlatılan işlerin tamamlanma oranına bakar. Sekme kapandığı için ölen iş günlükte çoğu zaman kullanıcının iptali gibi görünür. Kullanıcının bekleyemeyeceğini bildiği için hiç başlatmadığı iş ise hiçbir panoya girmez.

Uzun iş kendi kaydına bağlı yaşar. Kullanıcı ayrılabilir, iş sürer, sonuç ve haber kullanıcıyı bulur.

1. İşi oturumdan ayır. Uzun sürecek iş başladığında ürün bir iş kaydı açar ve işi sunucuda çalıştırır. Sekmenin kapanması, bağlantının kopması ya da cihazın uyuması işi durdurmaz.
2. Süreyi ve serbestliği baştan söyle. İş başlarken ürün tahmini süreyi ve sekmenin kapatılabileceğini söyler. Kullanıcı ne kadar zamanı olduğunu bilir, beklemekle gitmek arasında seçer.
3. Durumu her yerden görünür tut. İşin durumu ve ara sonucu kalıcı olarak yazılır. Kullanıcı başka bir cihazdan ya da ertesi gün döndüğünde işi bir listede bulur.
4. Bitince ve takılınca haber ver. İş bittiğinde, başarısız olduğunda ve kullanıcıdan karar gerektiğinde bildirim gider. Bildirim sonucun özetini ve sonuca giden bağlantıyı taşır. Karar bekleyen iş, kullanıcı fark etmeden saatlerce beklemez.
5. Arka plandaki iş de durdurulabilir. Kullanıcı işi listeden durdurabilir. Ölen iş sessiz kalmaz, nedeniyle birlikte başarısız diye raporlanır.

Bildirim de bir kesinti. Birkaç saniyelik işte bildirime gerek yok. Uzun işte bildirimin kanalını kullanıcı seçer.

Aynı rapor işi, iki ayrı akışla. Solda iş sohbet penceresine bağlı ve ürün kullanıcıdan sayfada kalmasını istiyor. Sağda ajan süreyi söylüyor, işi arka planda çalıştırıyor ve rapor hazır olunca bildirim gönderiyor.

Google'ın yardım sayfasına göre Gemini'nin derin araştırma raporu genellikle 5-10 dakikada³ hazırlanıyor ve kullanıcı beklerken sohbetten ayrılabiliyor. Rapor hazır olunca Gemini web uygulamasında raporun bulunduğu sohbetin yanında, mobil uygulamada cihaz bildirimiyle haber veriyor.

Claude Code'un bulut oturumları Anthropic'in sunucularında çalışıyor. Belgeye göre oturum dizüstü bilgisayar kapandıktan sonra da sürüyor⁴ ve kullanıcı ona herhangi bir cihazdan bakıp yön verebiliyor. Claude bir soru sorduğunda oturum bekliyor, kullanıcı döndüğünde cevap verebiliyor. Uzaktan kontrol açıkken Claude uzun bir iş bittiğinde ya da kullanıcıdan bir karar beklediğinde⁵ telefona bildirim gönderebiliyor.

GitHub'ın Copilot bulut ajanı depoyu araştırıyor, değişikliği planlıyor ve arka planda uyguluyor⁶. İş bitince Copilot kullanıcıdan pull request incelemesi istiyor⁷. Bitti haberi, incelemeye çağrının kendisi.

Geliştirici tarafında da aynı yapı var. OpenAI'ın API belgesi derin araştırma isteklerini arka plan modunda çalıştırmayı ve iş bitince webhook ile haber almayı öneriyor. Arka plan modu uzun işleri zaman aşımı ve bağlantı sorunu kaygısı olmadan⁸ çalıştırmak için var. Apple'ın arayüz kılavuzu da üretken modellerin sonucu daha geç verdiğini yazıyor ve bir yükleme deneyimi tasarlamayı ya da kullanıcı uygulamanın başka bir yerini kullanırken arka planda üretmeyi⁹ öneriyor.

Bu desenin dayanağı ürün örnekleri. Araştırma, sohbet ve kodlama ajanı yapan şirketler aynı yapıya ayrı ayrı vardı: iş kaydı, kullanıcıdan bağımsız çalışma, bitince haber. Google raporun dakikalar sürdüğünü kendi yardım sayfasında kullanıcıya söylüyor. OpenAI aynı işlerin onlarca dakika sürebildiğini geliştiricilere yazıyor ve açık bekleyen bağlantı yerine arka plan modunu öneriyor. Anthropic bulut oturumunu kullanıcının bilgisayarından ayırıyor, uzaktan kontrol edilen oturumda iş bitince ya da karar gerekince telefona haber veriyor.

Beklemenin sınırı eski bir bulgu. Nielsen 1993'te yazdığı tepki süresi sınırlarında on saniyeyi dikkatin diyalogda kalabildiği sınır olarak koyuyor. Daha uzun gecikmede kullanıcıya işin ne zaman biteceğini söyleyen geri bildirim¹ verilmesini istiyor. AI ajanlarının işleri bu sınırın çok ötesinde. Dakikalar süren işte kullanıcıdan sayfada kalmasını beklemek, bu sınırı hiç hesaba katmamak oluyor.

Kullanıcı ayrıldığında AI işlerinin ne kadarının öldüğünü ölçen yayımlanmış bir çalışma bulamadık. Bu sayı her ürünün kendi günlüğünde duruyor ve çoğu ürün onu ayrıca saymıyor.

Tamamlanan iş sayısı desenin işe yarayıp yaramadığını söylemez. Bakılacak yer, kullanıcı ayrıldığında işe ve habere ne olduğu.

• Bağlantıyla ölen iş. Kullanıcının bağlantısı koptuğu için yarıda kalan işleri say. Desen yerindeyse bu sayı sıfır, çünkü iş bağlantıya bağlı değil.
• Bildirimden dönüş. Bitti bildirimlerinin ne kadarı açılıyor, kullanıcı sonuca ne kadar sürede dönüyor? Açılmayan bildirim yanlış kanalı ya da gereksiz bildirimi gösterir.
• Karar bekleme süresi. Ajan soru sorduğunda cevap gelene kadar geçen süre. Bildirim yoksa bu süre kullanıcının şans eseri geri dönmesine bağlı kalır.
• Aynı işin yeniden başlatılması. Kısa arayla aynı isteğin tekrar gönderilmesi, kullanıcının önceki işi bulamadığını gösterir.
• Sessiz başarısızlık. Arka planda başarısız olan işlerin kaçı kullanıcıya bildirildi? Hedef hepsi.

Üç metin var. Denetim promptu ürünündeki uzun AI işlerini bulur, her işin isteğe mi yoksa kendi kaydına mı bağlı olduğuna ve bitince kimin haber aldığına bakar, yalnız rapor yazar. Uygulama promptu uzun işi kuyruğa taşır, iş kaydını ve bildirimi ekler. Önce planı gösterir, onayınla uygular ve istemci bağlantısını bilerek koparan bir test ekler. Kural kodlama ajanının kendi çalışması için. Yeni bir uzun iş eklerken ajan onu isteğin ömrüne bağlamasın.

Bu depoda dakikalarca sürebilen bir AI işi var: ajan döngüsü, derin araştırma, büyük dosya işleme, toplu üretim ya da uzun bir kod görevi. Görevin, bu işlerin kullanıcının oturumuna bağlı olup olmadığını ve bitince kullanıcıya haber verilip verilmediğini denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz.

1. Uzun sürebilecek AI çağrılarını bul: akış (stream) uç noktaları, ajan döngüleri, araç çağrısı zincirleri, kuyruk işleri, zamanlanmış görevler. Her biri için tipik ve en uzun süreyi tahmin et, sunucusuz fonksiyonların süre sınırını ve istemci zaman aşımlarını not et.
2. İş HTTP isteğine, WebSocket bağlantısına ya da tarayıcı sekmesine mi bağlı? Sayfa kapanınca ya da bileşen kaldırılınca isteği iptal eden kod var mı (AbortController, unmount temizliği, beforeunload)? Bağlantı koparsa iş sunucuda sürüyor mu, ölüyor mu?
3. İşin kalıcı bir kaydı var mı (durum: kuyrukta, çalışıyor, bitti, başarısız, karar bekliyor)? Sonuç ve ara sonuç saklanıyor mu? Kullanıcı başka bir cihazdan ya da ertesi gün döndüğünde işi bulabiliyor mu?
4. İş bittiğinde, başarısız olduğunda ya da kullanıcıdan karar beklediğinde bildirim gidiyor mu (anlık bildirim, e-posta, uygulama içi, webhook)? Bildirim sonucun özetini ve sonuca giden bağlantıyı taşıyor mu? Kullanıcı kanalı seçebiliyor mu?
5. Arayüz metinlerini tara: tahmini süre söyleniyor mu? "Bu sayfadan ayrılmayın", "sekmeyi kapatmayın" gibi uyarılar var mı?
6. Arka plandaki iş durdurulabiliyor mu? Sunucu yeniden başlarsa ya da süre sınırı dolarsa iş ne oluyor, kullanıcıya söyleniyor mu?

Rapor biçimi: her uzun iş için dosya ve satır, işin neye bağlı olduğu (istek, sekme, kuyruk), bağlantı kopunca ne olduğu, bildirim durumu ve önerdiğin değişiklik. En uzun ve en pahalı işlerden başla.

Bu üründe "uzun işi arka plana al, bitince haber ver" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. Belirli bir süreyi (ör. 30 saniye) aşması beklenen AI işini isteğin içinde çalıştırma. İş başlarken kalıcı bir iş kaydı oluştur, kimliğini hemen döndür ve işi kuyrukta ya da arka plan çalıştırıcısında yürüt.
2. İşin durumunu ve ara sonucunu kayda yaz. Arayüz durumu kayıttan okusun. Kullanıcı sekmeyi kapatıp başka bir cihazdan döndüğünde işi bir listede bulsun ve kaldığı yerden izlesin.
3. İş başlarken kullanıcıya tahmini süreyi ve sekmeyi kapatabileceğini söyle. "Bu sayfadan ayrılmayın" türü metinleri kaldır.
4. İş bittiğinde, başarısız olduğunda ve kullanıcıdan karar beklediğinde bildirim gönder. Bildirimde sonucun tek cümlelik özeti ve sonuca giden bağlantı olsun. Kanalı (uygulama içi, anlık bildirim, e-posta) kullanıcı seçsin.
5. Arka plandaki işe bir durdurma yolu koy. Süre sınırı ya da sunucu hatası yüzünden ölen işi "başarısız" diye işaretle ve kullanıcıya bildir.

Uygularken:
- Depoda var olan kuyruk ve bildirim altyapısını kullan, yenisini kurmadan önce sor.
- İş kaydını tekrar denemeye dayanıklı yaz: aynı iş iki kez çalışırsa sonuç iki kez yazılmasın, bildirim iki kez gitmesin.
- Kısa işleri (birkaç saniyelik cevaplar) olduğu gibi bırak, onları kuyruğa taşıma.
- Bir test ekle: uzun bir iş başlat, istemci bağlantısını bilerek kopar, işin sunucuda tamamlandığını, sonucun kayıtta durduğunu ve bitti bildiriminin oluştuğunu doğrula.

## Uzun işi arka plana al, bitince haber ver
- Yarım dakikadan uzun sürebilecek bir AI işini isteğin ya da sekmenin ömrüne bağlama. İş kaydı oluştur, kimliği hemen döndür, işi arka planda çalıştır.
- İşin durumunu ve sonucunu kalıcı olarak yaz. Kullanıcı başka bir cihazdan döndüğünde işi bulabilsin.
- İş bittiğinde, başarısız olduğunda ve kullanıcıdan karar gerektiğinde bildirim gönder. Bildirimde özet ve bağlantı olsun.
- Sayfa kapanınca uzun işi iptal eden kod ve "bu sayfadan ayrılmayın" metni ekleme.
- Arka plandaki işe de durdurma yolu koy, başarısızlığı sessiz bırakma.

Kısa işte arka plan gerekmez. Birkaç saniyede biten bir cevabı kuyruğa almak, iş listesi ve bildirim eklemek arayüzü kalabalıklaştırır. Orada akış hâlinde gelen cevap yeter. Desen kullanıcının bekleyemeyeceği işler için.

Arka planda çalışmak, onay gerektiren adımda onayı atlamak anlamına gelmez. Kullanıcı ortada değilken ajan silme, gönderme ya da ödeme gibi geri dönüşü olmayan bir adıma gelirse durmalı ve haber vermeli.

Arka plan da kaybolabilir. Claude Code'un belgesi, hareketsiz kalan bulut oturumunun sanal makinesi geri alındığında hâlâ çalışan arka plan işlerinin geri gelmediğini⁴ yazıyor. İşin hangi koşulda öldüğünü kullanıcı baştan bilmeli. Süre sınırı varsa ürün bunu iş başlarken söylesin.

Her işe bildirim göndermek bildirimi gürültüye çevirir. Bildirimi kullanıcının ayrıldığı işlere ve karar gerektiren anlara sakla, kanalı kullanıcı seçsin.