Gerçek bir pipeline'da beş GitLab Duo ajanı: neleri düzelttiler, nerede durdular

Bir geliştirici, beş GitLab Duo ajanını — plan, review, fix, secure ve release — gerçek bir Python servisinin CI/CD pipeline'ına bağlama sürecini ilk elden anlattığı bir yazı yayımladı; sonuçlar, kod sonrası yapay zeka otomasyonunun neler yapıp neler yapamayacağına dair sağlam bir tablo sunuyor. dev.to'daki yazıya göre ajanlar yaklaşık iki dakikada bir özellik planı hazırladı, bir merge request'i üç tur incelemeden geçirdi, kimsenin bilerek yerleştirmediği bir dağıtım race condition'ını teşhis etti ve container taraması bulgularının 166'dan 1'e düşmesine yardımcı oldu. Hiçbir şey merge etmediler. Her merge insan kararıydı ve insan da bu işi yaparken bir hata yaptı.

Kurulum

Ro-cited-answers adlı test projesi, kamusal işlemlerle ilgili soruları Rumence yanıtlayan ve bir kaynak belge yanıtı desteklemiyorsa yanıtlamayı reddeden, MIT lisanslı bir demo. Yazar önce servisi inşa etti, ardından GitLab Transcend hackathon'unun Life After Code temasının kod sonrası iş olarak değerlendirdiği aşamaları kapsayan bir GitLab CI/CD pipeline'ı ekledi: verify, package, secure, release, configure, monitor ve govern.

Pipeline çevrimdışı testleri çalıştırıyor, bir container image'ını GitLab ve Google Artifact registry'lerine push ediyor, SAST, secret detection ve container scanning gerçekleştiriyor ve sürümleri Cloud Run üzerinde, terfi öncesinde kontrol edilen sıfır trafikli bir aday olarak sahneliyor; üretim kontrolleri başarısız olursa otomatik geri alma devreye giriyor. Bir drift işi canlı ayarları bir config dosyasıyla karşılaştırıyor, zamanlanmış bir iş ise üretimi altı saatte bir yeniden kontrol ediyor. Hiçbir yerde service account anahtarı yok: GitLab, Google Cloud'un Workload Identity Federation üzerinden güvendiği iş başına token'lar üretiyor.

Her ajan ne yaptı

Her ajan, depoda tanımlanmış, kendi service account'una sahip özel bir Duo flow'u ve hepsi bir AGENTS.md kurallar dosyasına bağlı: merge request açıp not yazabilirler ama merge edemez veya deploy edemezler.

Plan ajanı yeni oluşturulan issue'lara tepki verdi ve ilk issue için yaklaşık iki dakikada, soru metnini hariç tutan bir izin listesinde trace attribute'ların tutulması kararını da içeren eksiksiz bir uygulama planı üretti. O plan, sonunda yayımlanan özelliğe dönüştü. Review ajanı — bir değişikliğin sistemi yanıtlaması gereken bir şeyi yanıtlamasına yol açıp açamayacağı tek sorusunu soran — bir merge request'i üç turdan geçirdi; onaylamadan önce iki yüksek, ardından üç orta önemde sorun işaretledi ve daha sonra hangi revision'ın trafiğe hizmet verdiği konusundaki hatalı bir varsayımla ilgili gerçek bir hatayı yakaladı.

Fix ajanı pipeline hatalarında tetikleniyor. Bilerek yerleştirilmiş bir NameError'ı tek karakterlik bir düzeltmeyle onardı, çevrimdışı test paketlerini kendisi çalıştırdı ve pipeline'ı yeniden yeşile döndürdü. Daha çarpıcı olanı, yazarın yerleştirmediği bir hatayı sonradan teşhis etmesi: sekiz saniye arayla merge edilen iki değişiklik tek bir Cloud Run tag'ini paylaşıyordu, bu yüzden bir pipeline diğerinin revision'ını doğruladı ve yedi kontrolden altısını geçemedi. Ajan race'i tanımlayan bir issue açtı, üç çözüm önerdi, "insan kararı gerekiyor" yazdı ve hiçbir kod değiştirmedi.

Secure ajanına tarayıcı çıktısı verildi ve 173 bulguluk bir tablo üretti — 166 container, 7 SAST, sıfır secret. Hiçbirini görmezden gelmek yerine, base image'ı root olmayan bir kullanıcıyla Alpine'a çeviren bir merge request açtı; merge sonrası container bulguları zlib'deki tek bir Orta önemde issue'ya düştü. Release ajanı sürüm özetlerini issue olarak yazıyor. İlk çalışmasında üretimi kontrol etmesi Duo'nun sandbox proxy'si tarafından engellendi ve tahmin etmek yerine "doğrulanmadı" bildirdi — yazar bunu, bütün servisin destekleyemediği bir iddiada bulunmayı reddetmek üzerine kurulduğu göz önüne alındığında, projenin en tatmin edici sonucu olarak görüyor.

Nerede tıkandı

Başarılar kadar başarısızlıklar da öğretici. Race condition yazarın kendi tasarım hatasıydı; herhangi bir ajan tarafından önlenmek yerine pipeline'ın sürüm kontrolü tarafından yakalandı. Review verdict'i okuyup tek adımda merge eden bir komut, NOT READY durumundaki bir merge request'in geçmesine izin verdi; o verdict'in arkasındaki yüksek önemli bulgu doğru çıktı ve ajanın önerdiği çözüm yazarın kendi testinde başarısız oldu, bu yüzden yeni bir yaklaşım yalnızca READY verdict'inden sonra merge edildi. Yazarın koruduğu kural: verdict'i bir adımda oku, merge'ü ayrı bir adımda yap.

Yinelenen işler de oldu — fix ajanı tek bir YAML hatası için iki merge request açtı, plan ajanı başka bir ajana atanmış bir issue'da iki kez çalıştı. Duo'nun Rumence kişisel kimlik numaralarına benzeyen metinleri sansürlemesi, inceleyen kişinin bir testte örnek değer kullanılan yerde placeholder metin görmesine yol açtı ve bir Duo context dışlaması, inceleyen ajanı başta kendi yapılandırma dizinini okumaktan alıkoydu. Bir çözüm de üretimde hâlâ kanıtlanmış değil: sandbox'ın git'inin push sırasında bir lease flag'ini kabul etmesine bağlı ve yalnızca yerel olarak test edildi.

Neden önemli

Yapay zeka ajanları hakkındaki içeriklerin çoğu kod üretiminde duruyor. Bu dev.to yazısı ise cazibesiz yarımı — planlama, inceleme, triage, sürüm — gerçek bir pipeline üzerinde herkese açık sayılarla test ediyor ve ajanların teşhis, triage ve ilk taslaklarda gerçekten yararlı olduğunu, merge ve deploy'larda ise sert bir çizgi çektiğini görüyor. Tasarım dersi bu ayrımın kendisi: ajanlar önerir, inceler ve özetler; insanlar karar verir. Belirleyici olan şu: deneyin tamamındaki tek kötü merge, tam da bu çizginin bulanıklaştığı yerde yaşandı.