Organizasyon Tasarımı ve Değişim Yönetimi: Otonom Kodlayıcıları Güvenle Devreye Alma

Organizasyon Tasarımı ve Değişim Yönetimi: Otonom Kodlayıcıları Güvenle Devreye Alma

Giriş

Otonom kodlama ajanları, bir kod tabanını inceleyebilen, bir sorunu anlayabilen, bir değişiklik planlayabilen, dosyaları düzenleyebilen, testleri çalıştırabilen ve insan incelemesi için bir çekme isteği açabilen yazılım araçlarıdır. Bazıları ayrıca belirli bir programa göre çalışabilir, depo olaylarına yanıt verebilir, sorunları sınıflandırabilir, bağımlılıkları güncelleyebilir veya dokümantasyonu sürdürebilir.

Bu yetenek, geliştirici iş istasyonundan fazlasını değiştirir. Yazılım işini kimin yaptığını, işin nasıl atandığını, kodun nasıl gözden geçirildiğini, yöneticilerin neyi ölçtüğünü ve sorumluluğun nerede olduğunu değiştirir.

En güvenli organizasyonlar, “Ajanın üretim kodu yazmasına ne kadar çabuk izin verebiliriz?” diye sorarak başlamazlar. Şunu sorarlar:

• Hangi işi delege etmek güvenlidir?
• Bir ajanın hangi kanıtları sunması gerekir?
• Sonuçtan kim sorumludur?
• Ajanın hangi izinlere ihtiyacı var?
• Organizasyon eylemlerini nasıl durdurabilir veya geri alabilir?
• Geliştiriciler yeni iş akışını tehdit altında hissetmeden nasıl öğrenecekler?

Şu ana kadarki kanıtlar, dikkatli, bağlama bağlı bir yaklaşımı desteklemektedir. Model Değerlendirme ve Tehdit Araştırmaları organizasyonu tarafından 2025 yılında yapılan randomize bir çalışma, 16 deneyimli açık kaynak geliştiricinin, 2025 başlarındaki yapay zeka kodlama araçlarını tanıdık depolarda kullanırken daha az zaman yerine yüzde 19 daha uzun zaman harcadığını buldu. Diğer saha deneyleri farklı ortamlarda üretkenlik artışları bildirmiştir. Ders, kodlama ajanlarının etkisiz olduğu değildir. Ders, araç yeteneği, görev türü, geliştirici deneyimi, kod tabanı kalitesi ve organizasyonel iş akışının hepsinin önemli olduğudur. (metr.org)

2025 DevOps Araştırma ve Değerlendirme raporu da benzer bir organizasyonel sonuca ulaşmaktadır: yapay zeka bir amplifikatör görevi görür. Açık iş akışları, güvenilir platformlar, iyi testler ve güçlü geri bildirim döngülerine sahip organizasyonları güçlendirir. Aynı zamanda zayıf süreçleri, yetersiz dokümantasyonu, istikrarsız öncelikleri ve belirsiz sahipliği de büyütür. (dora.dev)

Bu makale, pilot ekipler, Mükemmeliyet Merkezi ve federatif yönetişim aracılığıyla kodlama ajanlarını güvenle benimsemek için pratik bir işletim modeli sunmaktadır.

Otonom Kodlama Ajanlarının Gerçekte Değiştirdiği Şeyler

Geleneksel kodlama asistanları, bir geliştirici kod yazarken öneriler sunar. Daha otonom ajanlar, bir dizi eylem gerçekleştirebilir:

1. Bir sorun veya görev açıklamasını okuma.
2. İlgili dosyaları ve dokümantasyonu inceleme.
3. Bir uygulama planı oluşturma.
4. Birden fazla dosyayı değiştirme.
5. Testleri, linters'ları ve güvenlik kontrollerini çalıştırma.
6. Değişiklikleri açıklama.
7. Bir çekme isteği açma veya güncelleme.
8. İnceleme yorumlarına yanıt verme.
9. İş tanımlı koşulları karşılayana kadar döngüyü tekrarlama.

Örneğin, GitHub Copilot bulut ajanı bir depoyu araştırabilir, kod değişiklikleri yapabilir ve inceleme için bir çekme isteği oluşturabilir. Otomasyonları belirli programlara göre veya sorunlara ve çekme isteklerine yanıt olarak çalışabilir. GitHub ayrıca araçları sınırlamak, ajan oturumlarını incelemek, otomasyonları devre dışı bırakmak ve birleştirmeden önce insan incelemesini gerektirmek için kontrolleri de belgeler. (docs.github.com)

Bu, dört organizasyonel değişim yaratır:

• Kod yazmaktan kod yönetmeye ve değerlendirmeye.
• Bireysel görevlerden ajanların sürekli işleyebileceği görev kuyruklarına.
• Periyodik bakımdan sürekli bakıma.
• Zımni geliştirici yargısından açık politikalara, testlere, talimatlara ve onay kurallarına.

Kodlama ajanları, halihazırda şunlara sahip olan organizasyonlar için en kullanışlıdır:

• Versiyon kontrolünde kaynak kodu.
• İşleyen bir çekme isteği süreci.
• Otomatik testler.
• Hizmetlerin ve dosyaların net sahipliği.
• Tekrarlanabilir geliştirme ortamları.
• Coşkuya güvenmek yerine sonuçları ölçmeye istekli olma.

Güvenilir testleri olmayan, dokümante edilmemiş sistemleri olan, belirsiz sahiplikleri olan veya her yeni aracı bir görev olarak gören bir kültüre sahip organizasyonlar için ilk adım olarak daha az uygundur.

Temel Tasarım İlkesi: Sadece Modeli Değil, İş Akışını Yönetin

Bir kodlama ajanı, daha büyük bir sistemin sadece bir parçasıdır. Güvenli benimseme, şunlar etrafında kontroller gerektirir:

• Kimlik: Görevi hangi kişi veya hizmet hesabı başlattı?
• Yetki: Ajan neyi okuyabilir, değiştirebilir veya yürütebilir?
• Kanıt: Değişikliğe hangi testler, taramalar ve açıklamalar eşlik etmelidir?
• İnceleme: Kimin onaylaması gerekir?
• Dağıtım: Değişiklik kullanıcılara ne kadar kademeli ulaşabilir?
• Gözlemlenebilirlik: Yöneticiler ne olduğunu yeniden oluşturabilir mi?
• Kurtarma: Değişiklik, ajan veya özellik hızla durdurulabilir mi?

Ulusal Standartlar ve Teknoloji Enstitüsü, yapay zeka yaşam döngüsü boyunca, tasarım, geliştirme, dağıtım, kullanım, test etme ve değerlendirme dahil olmak üzere güvenilirliği göz önünde bulundurmayı önermektedir. Kodlama ajanları için bu, risk yönetiminin ilk olaydan sonraya ertelenemeyeceği anlamına gelir. (nist.gov)

Kullanışlı bir iç kural şudur:

Bir ajan bir değişikliği önerebilir, hazırlayabilir, test edebilir ve açıklayabilir. İnsan organizasyonu, üretime neyin gireceğine karar vermekten sorumlu olmaya devam eder.

Bu kural, daha yüksek olgunluk seviyelerinde daha esnek hale gelebilir, ancak yalnızca organizasyon güçlü kanıtlara, sınırlı izinlere, güvenilir geri alma yeteneğine ve net durdurma koşullarına sahip olduğunda.

İşe Yarayan Üç Organizasyonel Model

1. Pilot Ekipler

Bir pilot ekip, kodlama ajanlarını belirli bir süre boyunca gerçek işlerde kullanan küçük bir takımdır. Yapay görevler kullanan bir gösteri projesi değildir. Ekip, gerçek bir depo, gerçek sorunlar ve gerçek teslim kısıtlamaları üzerinde çalışmalıdır.

Güçlü bir pilot ekip şunları içerir:

• Farklı deneyim seviyelerine sahip dört ila sekiz geliştirici.
• Bir mühendislik yöneticisi.
• Bir ürün veya iş temsilcisi.
• Bir güvenlik veya kalite temsilcisi.
• Dağıtım ve operasyonlara aşina biri.
• Teknoloji hakkında şüpheci veya temkinli olan en az bir kişi.

GitHub, pilotların gerçek işleri, farklı beceri seviyelerini ve çeşitli ekipleri ve iş akışlarını içermesini önermektedir. Ayrıca başarı kriterlerini tanımlamayı, bir bütçe belirlemeyi ve anlamlı veri toplamak için yeterince uzun süre pilot çalıştırmayı tavsiye eder. Kullanıma dayalı ajan özellikleri için GitHub, genellikle dört ila altı hafta süren en az bir tam faturalandırma döngüsü planlamayı önermektedir. (docs.github.com)

En iyi kullanım senaryoları

Pilot ekipler özellikle şunlar için iyi çalışır:

• Birim ve entegrasyon testleri yazma.
• Dokümantasyon güncellemeleri.
• Küçük hata düzeltmeleri.
• Güçlü test kapsamına sahip yeniden düzenleme.
• Bağımlılık güncellemeleri.
• Log, izleme ve yapılandırma iyileştirmeleri.
• Çekme isteği açıklamaları taslağı hazırlama.
• Tekrarlayan sorun işini standart iş akışlarına dönüştürme.

Pilotun yapmaması gerekenler

Şunlarla başlamaktan kaçının:

• Kimlik doğrulama ve yetkilendirme değişiklikleri.
• Ödeme mantığı.
• Geri döndürülemez veritabanı geçişleri.
• Güvenlik açısından kritik yazılım.
• Büyük hizmetler arası yeniden tasarımlar.
• Kısıtlanmamış bir ajan için üretim erişimi.
• Bireysel çalışan verimlilik puanlaması.

Pilot çıkış kriterleri

Pilot başlamadan önce, yazılı bir “devam et”, “duraklat” ve “dur” kararı tanımlayın:

Devam et eğer:

• Kalite sabit kalır veya iyileşir.
• Güvenlik bulguları önemli ölçüde artmaz.
• İnceleyenler değişiklikleri anlayabilir.
• Geliştiriciler iş akışının faydalı olduğunu bildirir.
• Ajan maliyetleri onaylanan tavan içinde kalır.
• Ekip ajan aktivitesini durdurabilir veya geri alabilir.

Duraklat eğer:

• Çekme isteği inceleme süresi keskin bir şekilde artar.
• Ajan aynı hata sınıfını tekrar tekrar yapar.
• Bot tarafından oluşturulan iş, bakımcıları bunaltır.
• Geliştiriciler eğitim almadan aracı kullanmaya zorlandıklarını hissederler.
• Organizasyon ajanın neyi değiştirdiğini açıklayamaz.

Dur eğer:

• Ajan gerekli onayları atlar.
• Hassas veriler ifşa edilir.
• Kritik güvenlik açıkları ortaya çıkarılır.
• Ajan güvenilir bir şekilde kontrol altına alınamaz.
• İş gerekçesi, ölçülen sonuçlar yerine sadece iyimser görüşlere dayanır.

2. Mükemmeliyet Merkezi Modeli

Bir Mükemmeliyet Merkezi, paylaşılan standartlar, eğitim, araçlar, değerlendirme ve destek sağlar. Her deneyi onaylayan veya her ajan iş akışını yazan merkezi bir ekip haline gelmemelidir.

Microsoft'un mevcut ajan benimseme rehberliği, etkili bir Mükemmeliyet Merkezi'ni, etkinleştirme, standartlar, yönetişim ve ölçek sağlayan küçük, çapraz fonksiyonlu bir grup olarak tanımlar. Erken olgunlukta uygulamalı merkezi bir ekipten, yerel ekipler yetkin hale geldikçe daha hafif bir ekosistem ve topluluk rolüne doğru bir ilerleme önermektedir. (learn.microsoft.com)

Bir kodlama ajanı Mükemmeliyet Merkezi şunları içerebilir:

• Bir mühendislik verimliliği lideri.
• Bir güvenlik mühendisi.
• Bir platform veya geliştirici deneyimi mühendisi.
• Bir yazılım kalitesi temsilcisi.
• Bir değişim yönetimi veya öğrenme uzmanı.
• Bir ürün veya iş temsilcisi.
• Gerektiğinde bir hukuk, gizlilik veya uyumluluk danışmanı.

Mükemmeliyet Merkezi'nin sorumlulukları

Mükemmeliyet Merkezi şunları sahiplenmelidir:

• Onaylanmış kullanım senaryoları ve yasaklı kullanım senaryoları.
• Ajan görevleri için risk sınıflandırması.
• Standart depo talimatları.
• Çekme isteği ve dal koruma politikaları.
• Test ve tarama gereksinimleri.
• Ajan kimliği ve erişim modelleri.
• Eğitim materyalleri.
• Değerlendirme veri setleri ve test depoları.
• Maliyet kontrolleri.
• Denetim ve olay prosedürleri.
• Yeniden kullanılabilir komutlar, şablonlar ve iş akışları kütüphanesi.
• Bir uygulama topluluğu ve şampiyon ağı.

Her yerel uygulama kararını sahiplenmemelidir. Amacı, güvenli davranışları kolay, tekrarlanabilir ve görünür kılmaktır.

3. Federatif Yönetişim

Federatif yönetişim, merkezi bir temel ile yerel ekip sahipliğini birleştirir.

Merkezi organizasyon minimum gereksinimleri belirler:

• Korumalı dallara doğrudan birleştirme yok.
• Gerekli çekme istekleri.
• Gerekli testler ve güvenlik kontrolleri.
• Hassas alanlar için insan veya kod sahibi onayı.
• En az ayrıcalıklı erişim.
• Günlükleme ve ilişkilendirme.
• Tanımlanmış geri alma prosedürleri.
• Onaylanmış modeller, araçlar ve veri işleme kuralları.

Yerel ekipler şunlara karar verir:

• Hangi görevlerin otomatikleştirmeye değer olduğu.
• Depo talimatlarının nasıl yazılması gerektiği.
• Hangi alana özel testlerin gerekli olduğu.
• Hangi mühendislerin yerel şampiyon olarak hizmet edeceği.
• Aracın ekibin planlama ve inceleme sürecine nasıl uyduğu.

Microsoft, platform sorumlulukları ile iş yükü sorumlulukları arasında benzer bir ayrımı tanımlar: platform ekibi güvenli temeli ve yönetişimi sağlarken, iş yükü ekipleri alana özel değeri ve yaşam döngüsü kararlarını sahiplenir. (learn.microsoft.com)

Bu model, büyük bir organizasyon için genellikle en iyi uzun vadeli yapıdır çünkü iki yaygın hatadan kaçınır:

• Merkezi darboğaz: Her deney bir komiteyi bekler.
• Kontrolsüz yayılma: Her ekip kendi araçlarını, izinlerini, inceleme kurallarını ve veri uygulamalarını icat eder.

Önerilen ilerleme

Çoğu organizasyon için en güçlü sıra şöyledir:

1. Bir veya iki pilot ekiple başlayın.
2. Bu pilotlarda yer alan kişilerden küçük bir Mükemmeliyet Merkezi oluşturun.
3. Daha fazla ekip iş akışını benimsedikçe federatif yönetişime geçin.
4. Kimlik, güvenlik, değerlendirme ve üretim erişimi üzerinde merkezi kontrolü sürdürün.
5. Alan kullanım senaryoları ve günlük uygulamalar üzerinde yerel kontrolü sürdürün.

Değişim Yönetimi: Tepki Çekmeden Güven İnşa Etmek

Bir güven sözleşmesiyle başlayın

Geliştirici tepkisi genellikle teknolojiye karşı muhalefetten ziyade belirsizlikten kaynaklanır. İnsanlar, aracın kendilerine yardım etmek, onları izlemek, yerlerine geçmek veya onları yargılamak için mi kullanılacağını bilmek isterler.

Google'ın geliştirici güveni üzerine yaptığı araştırma, beş pratik strateji önermektedir:

1. Açık bir kabul edilebilir kullanım politikası yayımlayın.
2. Kod incelemesini ve otomatik testleri güçlendirin.
3. Geliştiricilere aşinalık kazanmaları için fırsatlar verin.
4. Kullanımı zorlamadan teşvik edin.
5. Geliştirici rollerinin tekrarlayan işlerin ötesinde nasıl gelişebileceğini açıklayın. (dora.dev)

Pratik bir güven sözleşmesi şunları belirtmelidir:

• Amaç: Teslimat kalitesini iyileştirmek, tekrarlayan işleri azaltmak veya öğrenme kapasitesini artırmak.
• İzin verilenler: Güvenli ve faydalı görevlere örnekler.
• Yasaklı olanlar: Hassas veri işleme, kısıtlanmamış üretim erişimi ve incelenmemiş birleştirmeler.
• Sorumlu kimdir: Değişiklikten sorumlu kişi ve ekip, bir ajan yazsa bile sorumlu kalır.
• Telemetri nasıl kullanılır: Benimseme verileri, basit bir çalışan sıralama sistemi haline gelmemeli, etkinleştirmeyi iyileştirmelidir.
• Neler olmayacak: Gizli dağıtım yok, otomatik yedekleme sözü yok ve ajan kullanımı için bireysel kota yok.
• İnsanlar nasıl itiraz edebilir: Sorunları bildirmek veya duraklama talep etmek için görünür bir kanal.

İnsanları sorumluluklarına göre eğitin

Eğitim, genel iki saatlik bir gösteri olmamalıdır. Rol tabanlı olmalıdır.

Kod yazmayanlar ve ürün ekipleri için

İnsanlara şunları öğretin:

• Net sorunlar nasıl yazılır.
• İstenen davranış sade dilde nasıl açıklanır.
• Kabul kriterleri nasıl tanımlanır.
• Hassas veya yüksek riskli gereksinimler nasıl belirlenir.
• Bir gösteri veya test sonucu nasıl incelenir.
• Her kod satırını okumaya gerek kalmadan bir ajandan bir değişikliği açıklamasını nasıl istenir.

Bu, kodlama ajanlarını iş sorununu anlayan ancak yazılım yazmayan kişiler için kullanışlı hale getirir.

Geliştiriciler için

Şunları öğretin:

• Bir ajana faydalı bağlam nasıl verilir.
• Uygulamadan önce bir plan nasıl istenir.
• Bir fark nasıl incelenir.
• Ajanın özetine güvenmek yerine testler nasıl doğrulanır.
• Bağımlılıklar, sırlar, izinler ve hata işleme nasıl kontrol edilir.
• Komut enjeksiyonu ve güvenilmeyen depo içeriği nasıl tanınır.
• Döngüye giren veya ilgisiz değişiklikler yapan bir ajan nasıl durdurulur.

Google'ın araştırması, geliştiricilerin araca maruz kaldıklarında, özellikle zaten anladıkları dillerde ve ortamlarda güvenin arttığını bulmuştur. (dora.dev)

İnceleyenler için

İnceleyenlere şunlara odaklanmayı öğretin:

• Değişikliğin belirtilen sorunu çözüp çözmediği.
• Testlerin önemli davranışı kapsayıp kapsamadığı.
• Değişikliğin güvenlik veya gizlilik riskleri oluşturup oluşturmadığı.
• Tasarımın mevcut mimariye uygun olup olmadığı.
• Ajanın gerekenden daha fazlasını değiştirip değiştirmediği.
• Çekme isteğinin güvenle incelenebilecek kadar küçük olup olmadığı.

Mühendislik yöneticileri için

Yöneticilere şunları ölçmeyi öğretin:

• Teslimat kalitesi.
• İnceleme yükü.
• Yeniden çalışma.
• Teslim süresi.
• Geliştirici güveni.
• Olay oranları.
• Bakım birikimi.
• Müşteri sonuçları.

Birincil üretkenlik hedefi olarak kod satırı kullanmayın. GitHub, kod satırı metriklerini yönlendirici olarak tanımlar ve benimseme, kabul, çekme isteği yaşam döngüsü ölçütleri ve nitel geri bildirimlerin birlikte değerlendirilmesini önermektedir. (docs.github.com)

Güvenlik ve operasyon ekipleri için

Şunları öğretin:

• Ajan kimliği ve erişim kontrolü.
• Araç izin listeleri.
• Komut enjeksiyonu riskleri.
• Sır yönetimi.
• Denetim günlükleri.
• Kanarya dağıtımı.
• Kapatma anahtarları.
• Geri alma ve olay yanıtı.

Ücretsiz destek rolleri oluşturmadan şampiyonları kullanın

Bir şampiyon, aracı deneyen, pratik rehberlik paylaşan, meslektaşlarına yardım eden ve Mükemmeliyet Merkezi'ne geri bildirim getiren güvenilir bir ekip üyesidir.

Microsoft'un benimseme rehberliği, şampiyonlara eğitim, tanıma, uzmanlara erişim ve standartların şekillendirilmesinde söz hakkı verilmesini önermektedir. Şampiyonlar sadece ücretsiz bir yardım masası haline gelmemelidir. Zamanları ve sorumlulukları yöneticilerle kararlaştırılmalıdır. (learn.microsoft.com)

Faydalı bir şampiyon programı şunları içerir:

• Aylık topluluk toplantıları.
• Paylaşılan bir tartışma kanalı.
• Ofis saatleri.
• Gerçek iş kullanarak kısa gösterimler.
• Başarılı ve başarısız örneklerin bir kütüphanesi.
• Öğretme ve geri bildirim için tanınma.
• Güvenlik ve platform ekiplerine net bir eskalasyon yolu.

Aşamalı olarak iletişim kurun

Pratik bir iletişim sırası şöyledir:

Pilot öncesi

• Ele alınan sorunu açıklayın.
• Kapsam içinde ve dışında olanları belirtin.
• Güven sözleşmesini yayımlayın.
• Başarının nasıl ölçüleceğini açıklayın.
• Şüpheci sorulara davet edin.

Pilot sırasında

• Haftalık ilerlemeyi paylaşın.
• Kazanımların yanı sıra başarısızlıkları da yayımlayın.
• İnceleme yükü, kalite bulguları, maliyet ve geliştirici duyarlılığını raporlayın.
• Kanıtlara dayanarak iş akışını ayarlayın.

Pilot sonrası

• Kararı yayımlayın: genişlet, duraklat veya durdur.
• Süreçte neyin değiştiğini açıklayın.
• Yeniden kullanılabilir uygulamaları paylaşın.
• İnsan kontrolünde kalanları belirtin.
• Geliştiricilere katılmak için net bir sonraki fırsat verin.

Faydalı bir mesaj şudur:

Kodlama ajanları değişiklikleri taslak haline getirebilir ve test edebilir, ancak niyet, inceleme, risk ve üretim sonuçlarından insanlar sorumludur. Özerkliği yalnızca kalite, güvenlik ve geliştirici deneyiminin sağlıklı kaldığını kanıtlayan kanıtlar olduğunda genişleteceğiz.

Kodlama Ajanları için Pratik Bir Olgunluk Modeli

Olgunluk, satın alınan lisans sayısına değil, kanıt ve kontrol üzerine kurulmalıdır.

Aşama 5, varsayılan hedef değil, bir istisna olarak ele alınmalıdır. Google'ın Site Güvenilirliği Mühendisliği rehberliği, aşamalı özerkliği tanımlar: sistemler destekli analizden insan onaylı eyleme, ardından daha güçlü kanıt ve kontroller mevcut olduğunda yalnızca sınırlı otonom eyleme geçer. En az ayrıcalık, kesintiye uğratılabilirlik, kuru çalıştırma desteği, risk değerlendirmesi ve sürekli değerlendirmeyi vurgular. (goo.gle)

Aşamalar arası yükselme kriterleri

Bir ekip, ancak şunları gösterebildiğinde bir sonraki aşamaya geçmelidir:

• Kararlı veya iyileşen kusur oranları.
• Güvenlik bulgularında kabul edilemez bir artış olmaması.
• Yönetilebilir bir inceleme yükü.
• Net ajan ilişkilendirmesi.
• Güvenilir test ve dağıtım sinyalleri.
• Prova edilmiş bir geri alma.
• İş akışını anlayan ve güvenen geliştiriciler.
• Ajanın yapmaması gereken görevlerin belgelenmiş bir listesi.

Sürekli bakım botları özel dikkat gerektirir

Bakım işleri düşük riskli görünür, ancak büyük hacimli değişiklikler oluşturabilir. Örnekler şunları içerir:

• Bağımlılık yükseltmeleri.
• Dokümantasyon senkronizasyonu.
• Test onarımı.
• Statik analiz düzeltmesi.
• Yapılandırma güncellemeleri.
• Sorun etiketleme ve önceliklendirme.
• Eski kodun kaldırılması.

Dependabot gibi mevcut araçlar faydalı bir model gösterir: otomatik sistemler çekme istekleri oluşturur, ancak birleştirmeden önce testler ve kabul süreçleri yine de çalışmalıdır. Otomatik birleştirme, gerekli durum kontrolleri ile açıkça tanımlanmış, düşük riskli durumlara sınırlı olmalıdır. (docs.github.com)

Dil modeli tabanlı bakım botları için şunları ekleyin:

• Maksimum açık bot çekme isteği sayısı.
• Görev başına maksimum yeniden deneme sayısı.
• Maksimum günlük bütçe.
• Eski veya yinelenen işlerin otomatik olarak kapatılması.
• Gerekli bir insan sahibi.
• Botun kendi izinlerini veya iş akışı tanımlarını değiştirmemesi gerektiği kuralı.

Otonom Kodlama Benimseme Risk Kaydı

Bir risk kaydı, pilottan önce oluşturulmalı ve her genişleme kararında gözden geçirilmelidir.

GitHub'ın mevcut dokümantasyonu, doğrulanmamış kod, hassas bilgi erişimi, komut enjeksiyonu, idari görünürlük kaybı ve her görevi bir kişinin başlatmadığı otomasyonlar dahil olmak üzere bu risklerden birkaçını doğrudan belirtmektedir. Belgeli azaltmalar arasında dal kısıtlamaları, gerekli insan incelemesi, iş akışı onayı, oturum günlükleri ve sınırlı araçlar bulunmaktadır. (docs.github.com)

Open Worldwide Application Security Project'in ajan güvenliği ve yönetişimi hakkındaki 2026 rehberliği de, sadece metin üreten değil, hareket edebilen sistemler için özel olarak tasarlanmış tehdit modellemesi ve yönetişim ihtiyacını yansıtmaktadır. (genai.owasp.org)

Geri Alma Rehberleri

Bir geri alma rehberi, otonom bir ajanın üretime yönelik değişiklikler yapmasına izin verilmeden önce sade bir dille yazılmalı ve provası yapılmalıdır.

Rehber 1: Ajanı kontrol altına alma

Bu rehberi, ajan beklenmedik şekilde davrandığında, bilgi sızdırdığında, aşırı iş yarattığında veya görev sınırını ihlal ettiğinde kullanın.

1. Etkilenen ajanı, otomasyonu veya model politikasını devre dışı bırakın.
2. Planlanmış ve olay tetiklemeli çalıştırmaları durdurun.
3. Ajanın kimlik bilgilerini iptal edin veya askıya alın.
4. Yeni çekme isteklerinin oluşturulmasını engelleyin.
5. Oturum günlüklerini, komutları, farkları ve denetim kayıtlarını koruyun.
6. Ajanın dokunduğu tüm depoları ve dalları belirleyin.
7. Etkilenen bakımcıları ve güvenlik personelini bilgilendirin.
8. Bir olay incelemesi açın.
9. Hata modu ve kontrol açığı anlaşılana kadar ajanı yeniden etkinleştirmeyin.

GitHub, otomasyonları devre dışı bırakmak ve ajan oturumlarını incelemek için kontroller sağlar. Ayrıca, ajan tarafından oluşturulan commit'leri ve denetim olaylarını kaydeder, bu da bu tür bir kontrol sürecini destekler. (docs.github.com)

Rehber 2: Güvenli olmayan bir kod değişikliğini geri alma

Bu rehberi, ajanın kodu zaten birleştirildiğinde kullanın.

1. Olayı ilan edin ve bilinen son iyi sürümü belirleyin.
2. Daha fazla dağıtımı durdurun.
3. Çekme isteğini geri alın veya önceki bilinen iyi sürümü dağıtın.
4. Geri almanın kendisi riskliyse, bir kanarya veya sınırlı dağıtım kullanın.
5. Hizmet seviyesi göstergelerini, hata oranlarını, güvenlik sinyallerini ve müşteri etkisini doğrulayın.
6. Araştırma için orijinal değişikliği koruyun.
7. Sorunun ajandan, görev açıklamasından, eksik testlerden, inceleme başarısızlığından veya dağıtım sürecinden kaynaklanıp kaynaklanmadığını belirleyin.
8. Görevi yeniden açmadan önce bir regresyon testi veya koruyucu ekleyin.

GitHub'ın çekme isteği iş akışı, birleştirilmiş bir çekme isteğini tersine çeviren yeni bir çekme isteği oluşturabilir. Üretim sistemleri için kanarya dağıtımı tamamlayıcı bir kontroldür çünkü bir değişiklik daha fazla tanıtılmadan önce maruz kalan kullanıcı sayısını sınırlar. (docs.github.com)

Rehber 3: Riskli bir dağıtımı durdurma

Üretime yönelik değişiklikler için:

• Anında küresel bir sürüm yerine aşamalı dağıtım kullanın.
• Dağıtımdan önce otomatik durma koşulları tanımlayın.
• Hataları, gecikmeyi, kullanılabilirliği, güvenlik uyarılarını ve iş sonuçlarını izleyin.
• Bir acil durdurma mekanizması sürdürün.
• Eşikler aşıldığında önceden doğrulanmış bir sürüme geri dönün.

Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA), kanarya dağıtımlarını, kontrollü dağıtımı, genişleme sırasında izlemeyi ve acil durdurma mekanizmasını önermektedir. Google'ın Site Güvenilirliği Mühendisliği rehberliği de benzer şekilde, bir değişikliği doğrular iken trafiğin yalnızca küçük bir kısmını açığa çıkarmanın bir yolu olarak kanaryalamayı tavsiye eder. (cisa.gov)

Rehber 4: Benimseme aşamasını geri alma

Bazen kod güvenlidir, ancak işletim modeli hazır değildir. İnceleme yükü, geliştirici hayal kırıklığı veya bakım gürültüsü aşırı hale gelirse:

1. Genişlemeyi duraklatın.
2. Ekipleri önceki olgunluk aşamasına geri döndürün.
3. Önce en yüksek otonomili özellikleri devre dışı bırakın.
4. Düşük riskli destekli kodlamayı kullanışlı kalırsa kullanılabilir durumda tutun.
5. Dokümantasyonu, testleri, izinleri veya eğitimi düzeltin.
6. Pilotu daha dar görev sınırlarıyla yeniden çalıştırın.

Bir geri alma, programın bir başarısızlığı değildir. Organizasyonun benimsemeyi geri döndürülemez olarak ele almak yerine kontrollü deneme kullandığının bir işaretidir.

Doksan Günlük Bir Devreye Alma Planı

1. ila 10. Günler: Temeli oluşturma

Tek sayfalık bir charter oluşturun, şunları içermelidir:

• İş problemi.
• Pilot depo veya hizmet.
• Dahil edilen görevler.
• Hariç tutulan görevler.
• Ekip üyeleri.
• Ajan izinleri.
• Gerekli incelemeler.
• Gerekli testler ve taramalar.
• Maliyet tavanı.
• Başarı metrikleri.
• Durdurma koşulları.
• Geri alma sahibi.

Ajanı etkinleştirmeden önce temeli ölçün:

• Çekme isteği döngü süresi.
• İnceleme süresi.
• Yeniden çalışma.
• Kusur oranı.
• Güvenlik bulguları.
• Dağıtım sıklığı.
• Değişiklik başarısızlık oranı.
• Geliştirici güveni.
• Bakım birikimi.

11. ila 45. Günler: Pilotu çalıştırma

Gerçek işleri kullanın. Her hafta kısa bir inceleme toplantısı yapın, şunları kapsar:

• Ajanın ne yaptığını.
• İnsanların neyi düzeltmesi gerektiğini.
• Hangi görevlerin uygun olduğunu.
• Hangi görevlerin şaşırtıcı derecede zor olduğunu.
• İnceleme çabasının artıp artmadığını.
• Ekibin değişiklikleri anlayıp anlamadığını.
• Maliyetlerin beklentilerle eşleşip eşleşmediğini.

Ekip retrospektifine bir soru ekleyin:

Bu hafta kodlama ajanı nerede çabayı azalttı ve nerede daha fazla iş yarattı?

GitHub, tek bir benimseme sayısına güvenmek yerine kullanım verilerini anketler, retrospektifler, destek eğilimleri ve diğer nitel geri bildirimlerle birleştirmeyi önermektedir. (docs.github.com)

46. ila 75. Günler: İşletim modelini oluşturma

İlk Mükemmeliyet Merkezi'ni oluşturmak için pilot katılımcılarını kullanın.

Yayımlayın:

• Kabul edilebilir kullanım politikası.
• Risk sınıflandırma rehberi.
• Depo talimat şablonu.
• Çekme isteği kontrol listesi.
• Ajan erişim standardı.
• Güvenlik inceleme kontrol listesi.
• Eğitim yolu.
• Geri alma rehberi.
• Onaylanmış metrikler.
• Şampiyon programı.

76. ila 90. Günler: Dikkatlice genişletme

Ekipleri dalgalar halinde ekleyin, hepsi bir anda değil.

Her dalga için:

1. Deponun gerekli testlere ve sahipliğe sahip olduğunu doğrulayın.
2. Dal koruma ve kod sahibi kurallarını doğrulayın.
3. Ekibi eğitin.
4. Bir şampiyon atayın.
5. İzin verilen görev kategorilerini tanımlayın.
6. Bir bütçe ve inceleme kapasitesi belirleyin.
7. Kaliteyi ve geliştirici deneyimini ölçün.
8. Devam etmeye, duraklatmaya veya kapsamı daraltmaya karar verin.

İlk Sonraki Adım

En iyi ilk eylem daha fazla lisans satın almak değildir. Bir mühendislik ekibi, bir ürün temsilcisi, bir güvenlik veya kalite temsilcisi ve bir platform temsilcisi ile altmış dakikalık bir otonomi tasarım çalıştayı planlamaktır.

Çalıştay sırasında şunları seçin:

• Bir depo.
• Bir düşük riskli görev kategorisi.
• Bir insan onay kuralı.
• Bir ölçülebilir sonuç.
• Bir durdurma koşulu.
• Bir geri alma sahibi.

Uygun bir ilk görev şunlar olabilir:

“Her hafta bağımlılık uyarılarını inceleyin ve onaylanmış yama seviyesi güncellemeleri için bir çekme isteği açın. Uygulama mantığını, dağıtım yapılandırmasını, kimlik doğrulamayı veya iş akışı izinlerini değiştirmeyin. Tam test paketini ve güvenlik kontrollerini çalıştırın. Üç başarısız denemeden sonra veya beş açık bakım çekme isteği olduğunda durun.”

Bu küçük iş akışı, organizasyona kapsamı, izinleri, kanıtı, incelemeyi ve kurtarmayı nasıl tanımlayacağını öğretir. Bu dersler, gösterişli bir gösterimden daha değerlidir.

Sonuç

Otonom kodlama ajanlarının güvenli bir şekilde benimsenmesi öncelikle bir organizasyonel tasarım sorunudur.

En güçlü model genellikle şunlardır:

• Gerçek iş üzerinde öğrenmek için pilot ekipler.
• Ortak standartlar, eğitim, değerlendirmeler ve koruyucu önlemler sağlamak için bir Mükemmeliyet Merkezi.
• Yerel ekiplerin güvenli bir merkezi sınır içinde hızlı hareket etmesine izin vermek için federatif yönetişim.
• Destekli kodlamadan ajan tarafından oluşturulan çekme isteklerine ve ancak o zaman sürekli bakım botlarına ilerleyen bir olgunluk yolu.
• Otonomi genişlemeden önce yazılan bir risk kaydı ve geri alma rehberi.
• Güven, şeffaflık, gönüllü öğrenme, rol netliği ve ölçülebilir sonuçlar üzerine kurulu bir değişim yönetimi programı.

Amaç, insanları yazılım geliştirmeden çıkarmak değildir. Amaç, insan dikkatini mimari, ürün yargısı, güvenlik, güvenilirlik, kullanıcı deneyimi ve daha iyi sistemlerin tasarımı üzerine yönlendirmektir.

Özerklik kanıtlarla kazanılmalıdır. Bir organizasyon ajanlarının ne yapmasına izin verildiğini açıklayabildiğinde, işlerinin kontrol edildiğini kanıtlayabildiğinde ve onları dramasız durdurabildiğinde, kodlama ajanları bir kaos kaynağı olmaktan çok bir güç çarpanı haline gelir.

Seçili Kaynaklar

• Kaynak 1: DevOps Araştırma ve Değerlendirme, Yapay Zeka Destekli Yazılım Geliştirme Durumu 2025
• Kaynak 2: Model Değerlendirme ve Tehdit Araştırması, 2025 Başlangıcı Yapay Zekasının Deneyimli Açık Kaynak Geliştirici Üretkenliği Üzerindeki Etkisini Ölçme
• Kaynak 3: DevOps Araştırma ve Değerlendirme, Üretken Yapay Zekaya Geliştirici Güvenini Geliştirmek
• Kaynak 4: Microsoft Learn, Ajanlı Yapay Zeka Olgunluk Modeli: Organizasyon ve Kültür
• Kaynak 5: Microsoft Learn, Yapay Zeka Ajanları için Organizasyonel Hazırlık Planı
• Kaynak 6: GitHub Docs, Yeni Bir Copilot Özelliği veya Modelini Pilot Uygulama
• Kaynak 7: GitHub Docs, Bir GitHub Copilot Dağıtımında Kod Tabanı Standartlarını Sürdürme
• Kaynak 8: GitHub Docs, GitHub Copilot Bulut Ajanı için Riskler ve Azaltmalar
• Kaynak 9: Google Site Güvenilirliği Mühendisliği, Sürümleri Kanaryalama
• Kaynak 10: Siber Güvenlik ve Altyapı Güvenliği Ajansı, Güvenli Yazılım Dağıtımı
• Kaynak 11: Open Worldwide Application Security Project, Ajanlı Yapay Zeka Güvenliği ve Yönetişimi Durumu
• Kaynak 12: GitHub Docs, Copilot Bulut Ajanı ile Otomasyon Oluşturma