Ajanın her dokunuşu bir değişikliktir

Geçen yazıda kapının kanıtına baktım: dış onayın değişiklik başarısızlığını düşürdüğüne dair ölçüm yok, ajan üretimi birleştirme taleplerinin çoğunda kayıtlı inceleme bulunmuyor. Orada bir cümleyi açıkta bıraktım: standart değişiklik listen boşsa kapın her şeye bakıyor demektir. Bu yazı o listeyi nasıl dolduracağını anlatıyor.

Ne oldu

Standart değişiklik yeni bir fikir değil. AXELOS'un ITIL 4 Change Enablement uygulama rehberi tarif ediyor: düşük riskli, iyi anlaşılmış, tam belgelenmiş ve her seferinde ek onay gerektirmeden uygulanabilen, önceden yetkilendirilmiş değişiklik. Rehber 2020 tarihli, ajanlardan önce yazıldı.

Sorunun bugünkü boyutu ölçülmüş durumda. EASE 2026 için hazırlanan bir çalışma açık kaynak depolarında 33.596 AI üretimi birleştirme talebini inceledi; 20.621'inde, yani yüzde 61,38'inde kayıtlı hiçbir inceleme yok. Ajan tarafından açılan alt kümede oran daha da sert: yüzde 84'ü ya hiç incelenmemiş ya da yalnız başka ajanlarca incelenmiş. DORA'nın 2019'dan beri değişmeyen ve hâlâ yayında olan bulgusu da yerinde duruyor: değişiklikleri dış bir kurulun onayına bağlayan kuruluşlar düşük performans grubunda 2,6 kat daha sık çıkıyor, açık ve tanımlı bir değişiklik sürecine sahip olanlar ise elit grupta 1,8 kat daha sık. Farkı kapının varlığı değil, tanımı yaratıyor.

Gartner 26 Mayıs 2026 tarihli bültende aynı yere bakıyor: 2027'ye kadar kuruluşların yüzde 40'ı, üretimde olay yaşandıktan sonra fark edilen yönetişim boşlukları yüzünden özerk ajanları geri çekecek veya devre dışı bırakacak. Teşhis tekdüze yönetişim, yani her ajana aynı kural.

Neden önemli

Türkiye'de kurumsal BT tarafında tanıdık düzen şu: haftalık kurul, tek onay matrisi, her değişiklik aynı formda. Bu düzen kod yazmanın günler sürdüğü varsayımıyla kuruldu. Ajan bir öğleden sonra onlarca diff üretmeye başlayınca varsayım çöküyor ve iki şeyden biri oluyor. Ya kuyruk birikiyor ve ekip kapıyı aşmanın yolunu arıyor, ya da onay okunmadan veriliyor. İkisi de kapıyı kayıt adımına indiriyor.

Kuyruğun bir maliyeti daha var, faturası geç geliyor. Kapı her şeye baktığında kurul saatinin büyük kısmı düşük riskli kalemlerle doluyor ve gerçekten geri alınamaz olan değişiklik aynı yorgun dikkatle, sıranın sonunda görülüyor. Denetçi kapasitesinin bir sınırı var; her şeyi denetime göndermek denetimin kendisini zayıflatıyor.

Yanlış soru ajana güvenilip güvenilmediğidir. Doğru soru, değişikliğin geri alınabilir olup olmadığı ve kalıbının sabit olup olmadığıdır. Güven kişiye bakar, risk işe bakar. Değişiklik yönetimi ikincisini ölçmek için kurulmuştur.

Saha yorumum: dört ölçüt ve kendi depom

ITIL'in niteliklerini kendi depolarımda çalışan bir kontrol listesine çevirdim. Bu eşleme bana ait, rehberin kendi metni değil. Kural tek cümle: dördü de evetse değişiklik standart değişiklik sayılır ve önceden onaylı kapsama girer, bir tanesi hayırsa normal değişiklik olur ve kapıya gider.

Ölçütlerde evet ile hayırı ayıran şey şu:

Ölçüt	Evet	Hayır
Geri alınabilir mi	Tek commit ile geri alınıyor	Şema göçü, bağımlılık yükseltmesi, dış servis yapılandırması
Kalıbı sabit mi	Aynı iş daha önce en az beş kez aynı biçimde yapıldı	İlk kez yapılıyor
Kapsamı dar mı	Tek dizin veya tek veri dosyası değişiyor	Ortak bileşen, yapılandırma, yayın zinciri değişiyor
Kanıtı otomatik mi	Yeşil bir koşu veya makine kontrolü geçti	Kanıt yalnız insanın bakması

Beş kez eşiği ITIL'den gelmiyor, benim seçimim; kalıbın tekrar ettiğine ikna olduğum nokta orası.

Bu yazı da ölçütlerden geçti. Taslağı content/ altında ayrı bir dalda açtım, published: false ile işaretledim ve taslak birleştirme talebine bağladım. Taslak üretimi son üç ölçütü geçiyor: kalıbı sabit, kapsamı tek dosya, kanıtı önizleme derlemesi. Birinci ölçütü geçen ise taslağın kendisi, yayın değil. Yayını geri alınabilir saymıyorum: kaldırılan bir yazı besleme, arşiv ve paylaşım üzerinden dolaşmaya devam eder. Bu yüzden taslak önceden onaylı kapsamda, yayın kararı ayrı bir adım olarak kapıda duruyor.

Kamuya açık hs-site-team deposunda aynı ayrım görünür durumda: yayın zincirlerinin arşiv kayıtları doğrudan ana dala yazılır, içerik ve kural değişiklikleri talep üzerinden geçer. İki sınırı açık yazayım. Bu tek kişilik bir düzenek ve kendi talebimi onaylayan ikinci bir insan yok; EASE çalışmasının otuz üç bin talebiyle aynı terazide tartılmaz. Diğer depolarım kapalı, oradaki sayıyı doğrulayamazsın.

Ne yapmalı

Üç adım, üçü de bu hafta yapılabilir.

Listeyi yaz. Son elli değişikliğini aç ve dört ölçütü uygula. Dördü de evet olanlar standart değişiklik adayın. Liste boş çıkıyorsa kapının tanımına bak, ajana değil.

Kanıtı makineye ver. Önceden onaylı kapsamın bedeli belgelemedir. Geri alma yolu yazılı değilse o değişiklik standart olamaz.

Kapıyı ölç. Elle onay gerektiren değişikliklerin oranını ve açılıştan onaya geçen süreyi takip et. Oran düşmüyorsa liste kâğıt üstünde kalmış demektir.

Sunum değil, çalışan sistem.

Asıl soru şu: bu hafta ajanının ürettiği değişikliklerin kaçı dört ölçütü geçiyor? Sayamıyorsan kapın da sayamıyor.

Kaynaklar

• AXELOS, ITIL 4 Practice Guide: Change Enablement, 09.01.2020.
• DORA, Streamlining change approval, dora.dev, 10.09.2026 itibarıyla yayında.
• DORA, Accelerate State of DevOps Report 2019, s. 50 ve 52.
• Duma, Wróblewski, Bobińska, Winiarska, Przymus, "These Aren't the Reviews You're Looking For: How Humans Review AI-Generated Pull Requests", EASE 2026, arXiv 2605.02273, 04.05.2026.
• Gartner, "Applying uniform governance across AI agents will lead to enterprise AI agent failure", basın bülteni, 26.05.2026.
• hsendil/hs-site-team, github.com, 10.09.2026 itibarıyla.