İş bitince neyin değiştiğini listele

Kullanıcı ajandan bir atölyenin tarihini bir hafta ileri almasını istiyor ve ekliyor: gereken her yeri güncelle. Ajan üç dakika çalışıyor ve tek cümleyle dönüyor. Taşıdım, her şey güncel. Kullanıcı neyin güncellendiğini bilmiyor. Etkinlik sayfası değişti mi? Takvim davetleri? Kayıt formunun son başvuru tarihi? Katılımcılara e-posta gitti mi, gittiyse ne yazıyordu?

Cevapları bulmanın tek yolu her sistemi tek tek açmak. Kullanıcı sayfaya bakıyor, takvime bakıyor, formu açıyor, gönderilmiş e-postaları tarıyor. Ajanın üç dakikada yaptığı işi kontrol etmek ondan uzun sürüyor. Daha kötüsü, kullanıcı yalnız aklına gelen yerlere bakıyor. Ajanın dokunduğu ama kullanıcının tahmin etmediği yer, örneğin kendiliğinden açılan bir bekleme listesi ya da tarihi kayan bir indirim kodu, hiç kontrol edilmiyor.

Ajan neyi değiştirdiğini biliyor, çünkü her değişikliği kendisi yaptı. Bu bilgi rapora geçmeyince kontrolün bütün yükü kullanıcıya kalıyor.

Bitti mesajı demoda yeterli görünür. Demoda ajan bir iki dosyaya dokunur ve sonuç zaten ekrandadır. Gerçek işte ajan beş ayrı sisteme dokunur ve sonuçların hiçbiri aynı ekranda durmaz. Ekip raporu demoya göre tasarlar.

İkinci neden, ürünlerin değişiklik takibinin tek bir yüzeyi kapsaması. Kodlama ajanları dosya düzenlemelerini iyi izler, çünkü fark çıkarmanın hazır araçları var. Ajanın kabuk komutuyla, API çağrısıyla ya da e-postayla yaptığı değişiklik bu takibin dışında kalır. Claude Code'un belgesi bunu açıkça yazıyor. Yalnız kabuk komutlarının değiştirdiği bir dosya geri alma noktalarında izlenmiyor ve olduğu gibi kalıyor¹. Ürünün kendi değişiklik listesi bile ajanın yaptığı her şeyi kapsamıyor. Rapor bu listeye dayanırsa aynı boşluğu kullanıcıya taşır.

Üçüncü neden modelin kendi özeti. Ajan iş sonunda kendiliğinden birkaç cümle yazar ve bu cümleler bir değişiklik listesi gibi okunur. Model onları bağlamında kalanlardan kurar. Uzun bir işte erken adımlar bağlamdan düşmüş olabilir, başarısız deneme ile başarılı olan karışabilir. İşin asıl hedefinin dışında kalan yan etkiler, bir davet ya da bir ayar, bu özette en kolay kaybolan kısım.

İş bitince ajan dokunduğu her şeyin listesini verir. Liste iş sırasında tutulan eylem kaydından üretilir ve her değişikliğin yanında nasıl geri alınacağını söyler.

1. Listeyi kayıttan üret. Raporun kaynağı araç katmanının tuttuğu eylem kaydı. Model rapora açıklama ekleyebilir, satırları ise kayıt belirler. Kayıtta olan her değişiklik raporda görünür.
2. Her yüzeyi say. Dosyalar, kayıtlar, gönderilen iletiler, değişen ayarlar, dış hizmet çağrıları. Ajan kabuk komutuyla ya da bir API ile bir şey değiştirdiyse o da listeye girer. Rapor yalnız kolay izlenen yüzeyi sayarsa kullanıcı ötekilerin hiç değişmediğini sanar.
3. Eski ve yeni değeri yaz. “Tarih güncellendi” yetmez. Eski tarih ve yeni tarih yan yana durur. Metnin içindeki ayrıntılı fark “Değişikliği fark olarak göster” deseninin işi.
4. Geri alma yolunu yanına koy. Her satır nasıl geri alınacağını söyler: tek tık, önceki sürüm ya da elle yapılacak iş. Geri alınamayan değişiklik (gönderilen e-posta, yapılan ödeme, yedeği olmayan silme) ayrıca işaretlenir ve listenin başına çıkar.
5. Yapılamayanı ayır. Denenip başarısız olan ya da yarıda kalan değişiklik “değişti” satırlarına karışmaz, ayrı bir bölümde durur. Ayrıntısı “Yarım kalan işi yarım diye raporla” deseninde.
6. Raporu sakla. Liste sohbetle birlikte kaybolmaz. İndirilir, paylaşılır ve değişen her öğeden rapora geri gidilir.

Rapor, kontrolün yükünü kullanıcıdan alıp ajanın zaten tuttuğu kayda verir. Kullanıcı beş sistemi açmak yerine tek listeyi okur ve yalnız işaretli satırlara bakar.

Aynı tarih taşıma işi, iki rapor. Soldaki ajan tek cümleyle bitti diyor. Sağdaki dokunduğu dört sistemi eski ve yeni değeriyle sayıyor, her satırın yanına geri alma yolunu koyuyor ve geri alınamayan e-postayı en üstte ayrıca işaretliyor.

Google'ın kodlama ajanı Jules iş bitince bir son özet veriyor. Özette değişen dosyalar, toplam süre, eklenen ve değişen satır sayısı, dal adı ve commit mesajı² yer alıyor. Ayrıntıyı görmek isteyen kullanıcı yalnız değişen dosyaları gösteren bir fark düzenleyicisine geçiyor. Özetin kapsamı kod: dosyalar, satırlar, dal.

OpenAI'ın Codex Cloud'unda her iş kendi çalışma alanında yürüyor. Kullanıcı iş bitince değişen dosyaları ve sonuçları inceliyor, ek değişiklik istiyor, hazır olunca commit ediyor ya da değişiklik isteği açıyor³. Değişiklik böylece asıl depoya girmeden önce gözden geçirilecek bir paket olarak duruyor.

GitHub'ın kodlama ajanı işini bir değişiklik isteği olarak teslim ediyor. Copilot Chat oturum günlüğüne dayanarak neyin değiştiğini, neyin doğrulandığını ve nedenini⁴ cevaplayabiliyor. GitHub, iş bitince kullanıcıdan değişiklik isteğini birleştirmeden önce dikkatle incelemesini⁵ istiyor.

Üç örnek de kod deposunda çalışıyor ve değişikliğin büyük kısmı dosya. Ajan e-posta gönderdiğinde, bir kaydı sildiğinde ya da bir ayarı değiştirdiğinde rapor bu yüzeyleri de aynı açıklıkla saymalı.

OpenClaw, Şubat 2026. Summer Yue ajandan gelen kutusunda neyi arşivleyeceğini ya da sileceğini önermesini istedi. Ajan e-postaları toplu olarak çöpe atmaya başladı ve Yue işi bilgisayardaki süreçleri kapatarak durdurdu. Ajanın ardından yazdığı açıklama, yüzlerce e-postayı onay almadan çöpe attığını ve arşivlediğini⁶ söylüyor. Paylaşılan ekran görüntüsündeki açıklamada hangi e-postanın çöpe, hangisinin arşive gittiği yazmıyor. Hangi e-postaların geri getirilmesi gerektiğini bulmak kullanıcıya kalıyor.

OpenAI'ın ajan yönetişimi üzerine yayımladığı çalışma bu boşluğa doğrudan bir öneriyle cevap veriyor. Yazarlar kullanıcıya ajanın yaptığı eylemlerin bir defterini⁷ vermeyi öneriyor ve bunu her eylem için onay istemekten daha hafif bir yöntem sayıyor. Kullanıcı işi yavaşlatmadan daha geniş bir eylem yelpazesini görüyor. Aynı çalışma bir koşul da koyuyor. Yalnız sonradan incelenebilen eylemler, onay isteyen eylemlerden daha kolay geri alınabilir olmalı. Desen geri alma yolunu bu yüzden her satırın yanına koyuyor.

Bu kaynakların hiçbiri iş sonu raporunun etkisini sayıyla ölçmüyor. Dayanak, ürünlerin uygulaması ve olayın gösterdiği boşluk. 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ü

• Rapor ile gerçek arasındaki fark. Rastgele işlerde ajanın raporunu sistemlerin kendi günlükleriyle (dosya geçmişi, gönderilmiş iletiler, denetim günlüğü) karşılaştır. Raporda olmayan bir değişiklik bulunmamalı.
• Kontrol süresi. Kullanıcının iş bittikten sonra sonucu kontrol etmeye harcadığı süre ve açtığı sistem sayısı. Rapor işini yapıyorsa kullanıcı yalnız işaretli satırlara gider.
• Sonradan bulunan değişiklik. Kullanıcının ya da müşterinin günler sonra fark ettiği, raporda yazmayan değişiklikler. Destek taleplerinden say. Hedef sıfır.
• Geri alma yolunun doğruluğu. Rapordaki geri alma yollarını örneklemle dene. Satır “tek tık” diyorsa değişiklik tek tıkla geri alınmalı.
• İşaretli satırların okunması. Geri alınamaz diye işaretlenen satırlara kullanıcının ne sıklıkla baktığını izle. Hiç bakılmıyorsa işaret ya görünmüyor ya da her satırda var.

Üç metin var. Denetim promptu ajanın iş sonunda kullanıcıya verdiği mesajı ve bu mesajın kaynağını bulur, ajanın dokunduğu ama raporda görünmeyen yüzeyleri listeler ve hiçbir dosyayı değiştirmez. Uygulama promptu eylem kaydından üretilen, her satırında geri alma yolu olan bir değişiklik raporu kurar. Önce planı gösterir, onayınla uygular ve raporu üç ayrı yüzeyle sınayan bir test ekler. Kural kodlama ajanının kendi işi için. Senin deponda bir işi bitirdiğinde o da dokunduğu her şeyi saysın.

Bu depoda kullanıcı adına birden çok sisteme dokunan bir AI ajanı var (dosya, veritabanı, e-posta, takvim, ödeme, dış API). Görevin, ajanın iş bitince kullanıcıya verdiği raporun dokunduğu her şeyi sayıp saymadığını denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz.

1. Ajanın iş sonunda kullanıcıya gönderdiği mesajı üreten yeri bul: son cevap, bildirim, e-posta, değişiklik isteği (pull request) açıklaması. Bu mesaj neyden üretiliyor: araç çağrılarının kaydından mı, modelin kendi yazdığı özetten mi?
2. Ajanın durum değiştiren bütün araçlarını listele: dosya yazma, kayıt güncelleme ve silme, ileti gönderme, ayar değiştirme, dış API çağrısı, kabuk komutu. Her biri iş sonu raporunda görünüyor mu?
3. Raporda her değişiklik için hedef (hangi dosya, kayıt, kişi), eski ve yeni değer ve geri alma yolu var mı?
4. Geri alınamayan değişiklikler (gönderilen ileti, ödeme, yedeği olmayan silme) raporda ayrıca işaretleniyor ve öne alınıyor mu?
5. Başarısız ya da yarıda kalan değişiklikler başarılı olanlardan ayrı mı duruyor?
6. Rapor saklanıyor mu, yoksa oturum kapanınca kayboluyor mu? Değişen bir öğeden rapora geri gidilebiliyor mu?
7. Üründe bir değişiklik takibi varsa (geri alma noktası, sürüm geçmişi, denetim günlüğü) hangi yüzeyleri kapsıyor, hangilerini dışarıda bırakıyor? Örnek: dosya düzenleme aracı izleniyor ama kabuk komutuyla yapılan değişiklik izlenmiyor.

Rapor biçimi: önce ajanın dokunabildiği yüzeylerin listesi ve her birinin iş sonu raporunda görünüp görünmediği. Sonra her bulgu için dosya ve satır, ne olduğu, kullanıcının neyi kendisi bulmak zorunda kaldığı (örnek: ajan katılımcılara e-posta gönderiyor, rapor yalnız sayfa güncellemesini söylüyor) ve önerdiğin düzeltme. Raporda görünmeyen geri alınamaz değişikliklerden başla.

Bu depodaki AI ajanına "İş bitince neyin değiştiğini listele" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. Ajanın durum değiştiren her araç çağrısı iş sırasında bir değişiklik kaydı üretsin: yüzey (dosya, kayıt, ileti, ayar, dış hizmet), hedef, eski değer, yeni değer, geri alma yolu, geri alınabilir mi.
2. İş bitince kullanıcıya giden rapor bu kayıttan üretilsin. Model raporun başına iki üç cümlelik bir açıklama yazabilir, ama satırları kayıt belirlesin.
3. Rapor geri alınamayan değişiklikleri en üstte ve ayrıca işaretli göstersin, ötekileri yüzeye göre gruplasın.
4. Her satırda geri alma yolu olsun: tek tık, önceki sürüm ya da elle yapılacak iş. Tek tıkla geri alınabilenler için düğme ekle.
5. Başarısız ya da yarıda kalan değişiklikler ayrı bir bölümde dursun, "değişti" satırlarına karışmasın.
6. Rapor saklansın, indirilebilsin ve değişen her öğeden rapora bir bağ olsun.

Uygularken:
- Kabuk komutu, doğrudan HTTP isteği ya da veritabanı sorgusu gibi araç katmanını atlayan yolları da kayda bağla. Bağlayamıyorsan raporda "bu iş kayıt dışı bir komut çalıştırdı" diye yaz.
- Eski değeri değişiklikten önce oku ve kaydet. Sonradan tahmin etme.
- Bir test ekle: sahte araçlarla üç ayrı yüzeye (bir dosya, bir kayıt, bir ileti) dokunan bir iş çalıştır. Raporun üçünü de eski ve yeni değeriyle saydığını ve iletiyi geri alınamaz diye en üste koyduğunu doğrula.

## İş bitince neyin değiştiğini listele
- Bir işi bitirdiğinde dokunduğun her dosyayı, kaydı, iletiyi ve ayarı listele. Kabuk komutuyla yaptığın değişiklikleri de say.
- Her satırda hedefi, eski ve yeni değeri ve nasıl geri alınacağını yaz.
- Geri alınamayan değişiklikleri (gönderilen ileti, ödeme, yedeği olmayan silme) listenin en üstüne koy ve ayrıca işaretle.
- Listeyi hafızandan kurma. Çalıştırdığın komutlara ve araç sonuçlarına bakarak yaz.
- Denediğin ama yapamadığın değişiklikleri ayrı bir başlık altında yaz.

Tek bir dosyayı ya da tek bir kaydı değiştiren işte uzun rapor kalabalık olur. Değişiklik zaten kullanıcının önündeyse bir satır yeter. Bu desen ajanın birden çok yere dokunduğu işler için.

Rapor kontrolü kolaylaştırır, kontrolün yerine geçmez. Kullanıcı listeyi okur, ama listede yazan değişikliğin doğru olup olmadığını yine kendisi değerlendirir. Sonucun gerçekten oluştuğunu doğrulamak “Yaptım demeden önce sonucu doğrula” deseninin işi.

Uzun listeler okunmaz. Yüz dosyalık bir işte her dosyayı ayrı satırda sayma. Türüne göre topla, geri alınamayanları ve isteğin dışında kalanları öne çıkar, gerisini açılır bir bölüme koy.

Rapor geri dönüşü olmayanı geri getirmez. Gönderilmiş e-posta ya da yapılmış ödeme raporda yalnız işaretli bir satır olarak durur. Bu adımların önünde durup onay istemek ayrı bir desenin işi.