Toplu işten önce kuru koşu göster

Kullanıcı ajana toplu bir iş veriyor: müşteri tablosundaki telefon numaralarını tek biçime çevir, altı aydır açılmayan abonelikleri kapat, bütün ürün açıklamalarının sonuna yeni bir satır ekle. İstek tek cümle, iş yüzlerce kayıt. Ajan bir kural yazıyor ve tablonun hepsine uyguluyor. Kural çoğu kayıtta doğru çalışıyor. Numarası zaten yeni biçimde olan kayıtta ise öneki ikinci kez ekliyor.

Bu hata ilk birkaç örnekte görünür. Kullanıcı o örnekleri hiç görmüyor, çünkü ajan önce yapıyor, sonra raporluyor. Rapor da tek satır: kayıtlar güncellendi. Bozuk kayıtlar ancak bir müşteri aranamadığında ortaya çıkıyor. O zamana kadar başka işler o kayıtları okumuş, eski değerler çoğu zaman hiç saklanmamış oluyor.

Tek kayıtta yanlış, tek bir düzeltme ister. Toplu işte aynı yanlış kayıt sayısı kadar düzeltme ister. Hatayı görmenin bedeli ise ilk örnekte bir bakış.

Kuru koşu işi iki adıma böler ve ürün ekipleri ikinci adımı sürtünme sayar. Ajanın vaadi tek cümleyle işin bitmesi. Sayım, örnekler ve ikinci bir onay bu vaadi bozuyor gibi görünür. Demolar da küçük tablolarla yapılır. On satırlık bir tabloda kuru koşuya gerek yok, sonucun hepsi zaten ekranda.

Kuru koşu bir mühendislik işi de. Kubernetes gibi altyapı araçlarında bu mod çekirdeğe gömülü, istek aynı yoldan geçip yalnız kayıt adımında durabiliyor. Ajanın araçları ise çoğu zaman tek bir şey yapar: yazar. Kuru koşu için her aracın "hesapla ama yazma" diye çağrılabilmesi gerekir. Bunu desteklemeyen bir adım varsa kuru koşu onu sessizce atlar. Ansible bu tuzağı belgesine yazmış: check mode'u desteklemeyen modüller hiçbir şey raporlamaz ve hiçbir şey yapmaz¹. Raporda görünmeyen adım güvenli görünür.

Model de kendiliğinden kuru koşu yapmaz. "Numaraları düzelt" diyen kullanıcıya en kısa yol, kuralı yazıp çalıştırmaktır. "Önce öner, sonra yap" diye bir talimat verilse bile bu bir prompt satırıdır ve uzun bir işte kaybolabilir. Ölçüm de bu kaybı göstermez. Kuru koşunun yakaladığı hata hiçbir panoya olay olarak düşmez, panoda kalan iz iptal edilmiş bir iştir.

Toplu bir işte ajan önce hiçbir şeye dokunmadan ne yapacağını hesaplar ve gösterir: kaç kayıt, hangi değişiklik, gerçek örneklerle. Kullanıcı onaylayınca iş önce küçük bir partide çalışır, sonra kalanına geçer.

1. Kuru koşu gerçek yoldan geçsin. Ajan aynı kuralı, aynı araçları ve aynı sorguyu kullanır, yalnız yazma adımını atlar. Ayrı yazılmış bir tahmin gerçek işten zamanla ayrışır. Kubernetes'in dry run'ı isteği kayda kadar bütün aşamalardan geçirir² ve yalnız kaydı yapmaz.
2. Sayıyı ve örneği birlikte göster. Kaç kaydın değişeceği, kaçının atlanacağı, kaçında hata çıkacağı. Yanında gerçek kayıtlardan önce ve sonra örnekleri. Örnekleri değişiklik türüne göre seç ve sınırdaki kayıtları mutlaka koy: boş alan, zaten doğru olan, beklenmedik biçim. Hata genellikle oradadır.
3. Benzetemediğini söyle. Dış servise gidecek istek, gönderilecek ileti, değişikliğin tetikleyeceği başka bir otomasyon. Kuru koşunun kapsamadığı her adım ekranda adıyla durur.
4. Onaylananı uygula. Onaydan sonra ajan gösterdiği planı çalıştırır, her şeyi yeniden hesaplamaz. Arada veri değiştiyse farkı gösterir ve yeniden sorar. Terraform'un belgesi aradaki değişikliklerin sonucu önceki planın gösterdiğinden farklı kılabileceğini³ yazıyor.
5. Önce küçük parti. Onaydan sonraki ilk parti küçük olur, ajan sonucunu okur ve gösterir. Google'ın SRE ekibi değişikliği önce üretimin çok daha küçük bir kısmına⁴ uygulayıp değerlendirmeyi, yayına devam edip etmeme kararını bu değerlendirmeye bağlamayı anlatıyor.

Eşiği geri dönüşe göre koy. Birkaç e-posta göndermek, yüzlerce etiketi değiştirmekten daha çok kuru koşu ister. Değiştirdiğin her kaydın eski değerini de sakla.

Aynı telefon düzeltmesi, iki ekran. Soldaki ajan kuralı bütün tabloya tek seferde uyguluyor ve kullanıcı hatayı iş bittikten sonra öğreniyor. Sağdaki ajan önce hiçbir kayda dokunmadan sayıyı ve her gruptan bir örneği gösteriyor, kullanıcı ikinci örnekte çift öneki görüyor.

Terraform'da plan ayrı bir komut. terraform plan altyapıda yapılacak değişiklikleri önizlemeyi sağlıyor³ ve tek başına hiçbir değişikliği uygulamıyor. Plan bir dosyaya kaydedilip sonra terraform apply ile aynen çalıştırılabiliyor. Belge planı, değişikliği uygulamadan önce beklentiyle karşılaştırmak ve ekiple incelemek için öneriyor.

Kubernetes, değişiklik yapan her API isteğine bir dry run parametresi tanıyor. Belgeye göre bu istekler depoya yazılmıyor ve başka bir yan etki doğurmuyor², cevap da gerçek bir isteğin cevabına olabildiğince yakın. Yani kuru koşu ile gerçek iş aynı denetimlerden geçiyor.

Ansible'ın check mode'u uzak sistemlerde hiçbir şeyi değiştirmeden, bu modu destekleyen modüllerin yapacakları değişiklikleri raporlamasını¹ sağlıyor. Diff mode önce ve sonra karşılaştırmasını ekliyor. İkisi birlikte neyin değişeceğini önce ve sonra hâliyle gösteriyor.

AI ürünlerinde bu adım henüz ince. Airtable'ın alan ajanı yapılandırma ekranında bir önizleme penceresi gösteriyor, ama önizleme ve kredi tahmini görünümdeki ilk kayda⁵ dayanıyor. Sınırdaki kaydı görmek kullanıcıya kalıyor. Aynı belge iki koruma daha tarif ediyor: otomatik çalışan bir alanın promptu değişince Airtable var olan kayıtların üzerine yazmadan önce soruyor ve insanın düzenlediği hücrelerin üzerine hiçbir zaman kendiliğinden yazmıyor.

OpenClaw, Şubat 2026. Summer Yue'nin istediği tam olarak bir kuru koşuydu: “suggest what you would archive or delete, don’t action until I tell you to”⁶. Yue'ye göre talimat bağlam sıkıştırmasında kayboldu. Ajan öneri listesi çıkaracağına, kendi itirafıyla, yüzlerce e-postayı onay almadan çöpe attı ve arşivledi⁷, planı önce göstermeden. Kuru koşu yalnız bir prompt satırıydı ve ürünün onu tutan bir modu yoktu.

Amazon S3, Şubat 2017. Olayda AI yok, mekanizma aynı. AWS'nin olay raporuna göre bir mühendis yerleşik bir çalışma kitabına uyarak az sayıda sunucuyu kaldıracak bir komut çalıştırdı. Girdilerden biri yanlış yazılmıştı ve amaçlanandan çok daha büyük bir sunucu kümesi kaldırıldı⁸. AWS'nin düzeltmesi bu desenin ikinci yarısına denk düşüyor: araç artık kapasiteyi daha yavaş kaldırıyor ve alt sınırın altına inmiyor⁸. AWS'ye göre bu değişiklik yanlış bir girdinin benzer bir olayı yeniden tetiklemesini önleyecek.

Altyapı tarafında kuru koşu yerleşik bir alışkanlık: Terraform'un planı, Kubernetes'in dry run'ı ve Ansible'ın check mode'u yukarıda anlatıldı. Google'ın SRE pratiği de değişikliği önce küçük bir kesimde deniyor. Bu desen kuru koşunun kaç hatayı önlediğini gösteren bir ölçüme dayanmıyor. Dayanağı, toplu değişikliği yıllardır yöneten araçların ortak tasarımı ve iki olay.

• 23 Şubat 2026OpenClaw üç “dur” mesajına rağmen gelen kutusundaki e-postaları çöpe atmayı sürdürdü
• 28 Şubat 2017Amazon S3'te birkaç sunucuyu kaldıracak komut, yanlış bir girdiyle çok daha büyük bir kümeyi kaldırdı

• Kuru koşuda değişen işler. Kuru koşudan sonra kuralı düzeltilen ya da iptal edilen toplu işlerin payı. Sıfıra yakınsa kullanıcı kuru koşuyu okumadan onaylıyor olabilir, çok yüksekse ajan ilk kuralı özensiz kuruyor.
• Kuru koşu ile gerçek iş arasındaki fark. Kuru koşunun "değişecek" dediği kayıt sayısı ile gerçek işte değişen kayıt sayısı. Aynı olmalı. Fark varsa kuru koşu gerçek yoldan geçmiyor.
• İlk partide durdurulan işler. Küçük partide sorun çıkıp kalanına geçilmeyen işler. Desen çalışıyorsa hatalar tam koşuya kalmadan bu aşamada yakalanır.
• Sonradan düzeltilen kayıtlar. Toplu işin dokunduğu kayıtlardan sonradan elle düzeltilen ya da geri alınanların payı.
• Kuru koşunun bedeli. Ek süre, ek araç çağrısı ve önizleme ekranında geçen süre. Bu sayı, eşiğin nerede durması gerektiğini söyler.

Üç metin var. Denetim promptu ürünündeki toplu işleri bulur, hangilerinin kuru koşu ve önizleme gösterdiğini, kuru koşunun gerçek işle aynı yoldan geçip geçmediğini raporlar, hiçbir dosyayı değiştirmez. Uygulama promptu toplu araçlara bir kuru koşu modu ekler, planı saklatır, işi küçük bir partiyle başlatır. Önce planı gösterir, onayınla uygular ve kuralı bozan satırlarla bir test ekler. Kural kodlama ajanının kendi işi için. Senin deponda bir arama-değiştirme ya da toplu taşıma yapacağı zaman önce neyi değiştireceğini göstersin.

Bu depoda kullanıcı adına çok sayıda kaydı, dosyayı ya da iletiyi tek seferde değiştiren bir AI ajanı ya da otomasyon var. Görevin, bu toplu işlerin çalışmadan önce bir kuru koşu (dry run) ve önizleme gösterip göstermediğini denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz.

1. Toplu işleri bul: döngü içinde yazma, silme ya da gönderme yapan araçlar, toplu güncelleme sorguları (UPDATE ya da DELETE, WHERE koşulu geniş olanlar dahil), toplu e-posta ve bildirim gönderimi, dosya taşıma ve yeniden adlandırma, harici bir API'ye toplu istek.
2. Her toplu iş için bak: çalışmadan önce hiçbir şeyi değiştirmeden sonucu hesaplayan bir mod var mı (dry_run, preview, plan, check, simulate gibi bir bayrak ya da ayrı bir uç)? Yoksa iş doğrudan mı yazıyor?
3. Kuru koşu varsa gerçek işle aynı kod yolundan mı geçiyor, yoksa ayrı yazılmış bir tahmin mi? Aynı sorgu, aynı kural ve aynı araç mı kullanılıyor, yalnız yazma adımı mı atlanıyor?
4. Kullanıcıya ne gösteriliyor: değişecek, atlanacak ve hata verecek kayıtların sayısı, gerçek kayıtlardan önce ve sonra örnekleri, kuru koşunun benzetemediği adımlar (dış servise giden istek, gönderilecek ileti, tetiklenecek otomasyon)?
5. Onaydan sonra ne çalışıyor: kuru koşuda gösterilen plan mı, yoksa her şey yeniden mi hesaplanıyor? Arada veri değişirse fark algılanıyor mu?
6. Gerçek iş tek seferde mi bütün kayıtlara uygulanıyor, yoksa önce küçük bir partiyle başlayıp sonucu doğruladıktan sonra mı genişliyor? Değiştirilen kayıtların önceki değerleri saklanıyor mu?
7. Kuru koşu yalnız sistem promptunda bir talimat mı ("önce öner, sonra yap")? Kodda bir moda bağlı değilse modelin unutabileceği bir rica olarak işaretle.

Rapor biçimi: her toplu iş için dosya ve satır, dokunduğu kayıt türü, kuru koşunun olup olmadığı, kullanıcının işten önce neyi gördüğü, olası zarar (örnek: kural hatası bütün tabloya yayılır, eski değerler kaybolur) ve önerdiğin düzeltme. Bulguları geri dönüşü olmayan işlerden (silme, gönderme) başlayarak sırala.

Bu depodaki AI ajanına "toplu işten önce kuru koşu göster" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. Belirli bir eşiğin üstünde kayda dokunan ya da geri dönüşü olmayan her toplu iş önce kuru koşuda çalışsın: aynı kural ve aynı araçlar, yazma adımı hariç. Eşiği bir ayar yap.
2. Kuru koşu sonunda kullanıcıya şunlar gösterilsin: değişecek, atlanacak ve hata verecek kayıtların sayısı, her değişiklik türünden en az bir gerçek önce ve sonra örneği, sınırdaki kayıtlar (boş alan, zaten doğru olan, beklenmedik biçim) ve kuru koşunun benzetemediği adımlar.
3. Kuru koşunun sonucu bir plan olarak saklansın. Onaydan sonra ajan bu planı uygulasın, yeniden hesaplamasın. Plan ile güncel veri arasında fark varsa farkı gösterip yeniden onay istesin.
4. Onaydan sonra iş önce küçük bir partide çalışsın, sonucu okunsun ve kullanıcıya gösterilsin. Kalan kayıtlara ancak ilk parti beklendiği gibi çıkarsa geçilsin.
5. Değiştirilen her kaydın önceki değeri iş kimliğiyle saklansın, böylece toplu iş geri alınabilsin.
6. Kuru koşu talimatla değil kodla zorunlu olsun: toplu yazma aracı, geçerli bir plan kimliği olmadan çalışmayı reddetsin.

Uygularken:
- Her toplu araca bir dry_run parametresi ekle. Araç dry_run modunda yazma yapmasın ama gerçek modda yapacağı her şeyi hesaplayıp döndürsün.
- Kuru koşuyu desteklemeyen bir adım varsa onu sessiz geçme, plana "benzetilemedi" diye yaz.
- Örnekleri rastgele değil değişiklik türüne göre seç, her gruptan en az bir tane.
- Bir test ekle: içinde kuralı bozan satırlar olan bir tabloyla toplu iş başlat, kuru koşunun hiçbir kaydı değiştirmediğini, bozan satırları örneklerde gösterdiğini ve plan kimliği olmadan yazma aracının çalışmadığını doğrula.

## Toplu işten önce kuru koşu göster
- Çok sayıda kaydı, dosyayı ya da iletiyi değiştirecek bir işi önce kuru koşuda çalıştır: aynı kural, aynı araçlar, yazma yok.
- Kuru koşudan sonra değişecek, atlanacak ve hata verecek kayıtların sayısını ve her türden gerçek bir önce ve sonra örneğini göster.
- Benzetemediğin adımı (dış servis, gönderilecek ileti, tetiklenecek otomasyon) ayrıca yaz, sessiz geçme.
- Onaydan sonra gösterdiğin planı uygula. Veri arada değiştiyse farkı söyle ve yeniden sor.
- İşe küçük bir partiyle başla, sonucu oku, ancak beklendiği gibiyse kalanına geç. Değiştirdiğin kayıtların eski değerlerini sakla.

Küçük ve geri alınabilir işte kuru koşu gerekmez. Tek bir kaydı değiştiren ya da sonucu zaten ekranda duran işte önizleme yalnız bir tık daha ekler. Her işe kuru koşu koyan ürün kullanıcıyı önizlemeyi okumadan onaylamaya alıştırır.

Kuru koşu eskir. Gösterildiği anla onaylandığı an arasında veri değişebilir. Plan saklanmıyorsa ve fark kontrol edilmiyorsa kullanıcı bir şeyi onaylar, ajan başka bir şeyi uygular.

Kuru koşu her şeyi benzetemez. Dış bir servisin cevabı, tetiklenen bir otomasyon, başka bir ajanın aynı anda yaptığı iş. Airtable'ın belgesi, bir alan ajanının çıktısını okuyan başka alanlar ve otomasyonlar varsa otomatik çalışmanın başka birçok değişikliği tetikleyebileceğini⁵ yazıyor. Kuru koşunun ekranı bu zinciri göstermiyorsa eksik bir resim verir.

Kuru koşu doğrulamanın yerini tutmaz. İş bittikten sonra sonucu ortamdan okumak ayrı bir adım. Kuru koşu ajanın ne yapacağını söyler, doğrulama ne yaptığını.