Ajan tabanlı kodlamada inceleme darboğazını gidermek

Ajan tabanlı kodlama, darboğazı kod üretiminden incelemeye taşıyarak güvenilir inceleme iş akışlarını vazgeçilmez kılıyor.

Yönetici özeti

  • Ajan tabanlı kodlamayı benimseyen çoğu ekipte darboğaz üretimden incelemeye kayar; döngü düzeltilmezse net hız kazanımı sıfıra yakındır.

  • Büyük ölçekli CI ortamlarında (her gece milyonlarca test, yüzlerce mühendis) ajanın en değerli görevi kod üretmek değil, sorumluluğu doğru ekibe yönlendirmek ve önceliklendirmektir.

  • Yararlı ajan çıktısı ayrıntılı incelemeye dayanır ve yalnızca örüntü eşleşmelerini değil, nedenselliği de açıklar.

  • Kanıt toplama ve bağlam oluşturma katmanını tasarlamak, üretim katmanından daha önemlidir.

Ajan tabanlı kodlamaya ilişkin tartışmaların çoğu hâlâ basit bir vaatle başlıyor: daha kısa sürede daha fazla kod yazmak.

Bu vaat bazen ajanların işi planladığı, PR'ler açtığı ve asgari insan müdahalesiyle değişiklikleri kullanıma sunduğu daha iddialı bir vizyona dönüşüyor. Ancak çoğu mühendislik ekibi için yakın vadede en belirgin değer daha dar kapsamlıdır. Bu değer, yineleme maliyetini azaltmaktır.

Yazılım teslimatı yalnızca kod üretmekten ibaret değildir. Kod yazmak; inceleme, test, dağıtım ve işler ters gittiğinde araştırma aşamalarını da içeren uzun bir döngünün yalnızca bir parçasıdır. İnceleme döngüsünü yeniden tasarlamadan ajan tabanlı kodlamayı benimseyen çoğu ekip, darboğazı yalnızca sürecin sonraki aşamalarına taşır.

Yalnızca üretimi hızlandırmak, ekibi kendiliğinden daha hızlı hâle getirmez. Bu, inceleme, doğrulama ve güven tesisine daha fazla çaba harcanmasına yol açabilir.

Asıl darboğaz güvendir

Birçok mühendislik ortamında maliyetli olan ilk taslağı hazırlamak değil, güvene ulaşmaktır.

Değişiklik sorunu gerçekten çözdü veya sistemi iyileştirdi mi? Başka bir yerde gerilemeye yol açtı mı? Hata kodda mı, ortamda mı, testlerde mi yoksa bir bağımlılıkta mı? Önerilen düzeltme asıl nedeni mi ele alıyor, yoksa yalnızca görünür belirtiyi mi?

Ajanlar burada mühendislere destek olabilir. Bunun nedeni mühendislerin yerini almaları değil; dağınık kanıtları yapılandırılmış bir ilk incelemeden geçirebilmeleridir: günlükleri inceleyebilir, son değişiklikleri karşılaştırabilir, ilgili sinyalleri özetleyebilir, olası nedenlerin izini sürebilir, kontroller çalıştırabilir ve insanın sorgulayabileceği bir sonuç sunabilirler.

Birçok ekipte ajandan en yüksek faydayı sağlayan kullanım alanı, sıfırdan kod üretmek değildir. Asıl fayda, bir insan bu işi elle yapmak için saatler harcamadan önce sorunun arama alanını daraltmaktır.

İnceleme ağırlıklı iş akışları neden uygun?

Bu durum özellikle büyük ölçekli hata ayıklama iş akışlarında belirgindir. Yüzlerce mühendisin değişiklik yaptığı kod tabanlarında, her gece milyonlarca test çalıştıran bir CI sistemi düşünün (müşterilerimizden biri için bu, gerçeğin ta kendisi). Bir hata oluştuğunda sorumluluğu doğru ekibe yönlendirmek zordur. Sorun uygulama kodunda, bir bağımlılıkta, test düzeneğinde veya teknoloji yığınının başka bir yerinde olabilir. Günlüklerin boyutu gigabaytları bulabilir ve sorunu ilk gören ekip her zaman sorunun sorumlusu değildir.

Böyle bir iş akışında çözümü tek bir ajanın yazması doğal bir beklenti değildir. Bu iş akışı, sorun alanını hızla daraltan bir sistem için uygundur.

Yararlı bir işlem hattı günlükleri alabilir, ilgili kanıtları seçebilir, önemli noktaları özetleyebilir, kodu korumalı bir alanda inceleyebilir ve güven puanı, izlenebilirlik ve önerilen sonraki adımlarla birlikte yapılandırılmış bir kök neden analizi sunabilir. Güven puanı oluşturmak için bir konu uzmanı, ajanın ilk çıktısını değerlendirir. Bu değerlendirme daha sonra hakem görevi gören bir LLM'ye aktarılır; böylece insan değerlendirmesiyle uyum korunurken sonraki puanlamalar otomatikleştirilir.

İnceleme ağırlıklı iş akışlarının neden uygun olduğunu gösteren diyagram.

Amaç mühendislik muhakemesini ortadan kaldırmak değil, inceleme yapanlara daha sağlam bir başlangıç noktası sunmaktır. Gerileme önceliklendirmesi, PR incelemesi, test onarımı, sürüm doğrulaması ve dağıtım sonrası araştırma aynı yapıya sahiptir. Bunların tümü kanıt ve inceleme ağırlıklıdır, ayrıca birçok belirsizlik barındırır. Ajandan mühendislik sürecinin yerini alması değil, yalnızca sürecin ilerlemesine yardımcı olması beklenir.

Çıktıya değil, iyileştirilmiş iş akışına odaklanın

Ekiplerin bu sistemleri nasıl değerlendirdikleri konusunda dikkatli olmaları da bu yüzden önemlidir.

Sorulması gereken, bir ajanın tek başına etkileyici bir şey üretip üretemediği değildir. Daha doğru soru, başka bir yerde yük oluşturmadan gerçek bir iş akışını iyileştirip iyileştirmediğidir.

Bunun için çıktının doğrulanabilecek kadar somut olup olmadığına, yalnızca örüntü eşleştirmek yerine nedenselliği açıklayıp açıklamadığına ve incelemeyi zorlaştırmak yerine kolaylaştırıp kolaylaştırmadığına bakmak gerekir. Makul görünen bir yanıt ile yararlı bir yanıt aynı şey değildir. Uygulamada ekipler, ayrıntılı incelemeye dayanan ve kontrol edilebilecek somut noktalar sunan ajan çıktılarına güvenir.

Çıktıya değil, iyileştirilmiş iş akışına odaklanmayı gösteren diyagram.

Zor olan, döngüyü tasarlamaktır

Buradan çıkarılacak daha derin ders, yararlı ajan tabanlı sistemlerin üretimden fazlasına bağlı olduğudur. Bu sistemlerin başarısı; kanıtların nasıl toplandığına, bağlamın nasıl oluşturulduğuna, çıktıların nasıl kontrol edildiğine ve belirsizliğin incelemeyi yapan kişiye nasıl gösterildiğine bağlıdır.

Ajan tabanlı mühendisliğin yakın geleceğinde tam özerkliğe tek bir büyük sıçrayış yapılması bu nedenle pek olası değildir. Daha olası olan, ajanların ekiplerin çalışmalarını incelemesine, gözden geçirmesine, doğrulamasına ve iyileştirmesine yardımcı olduğu; adımlar arasındaki boşa harcanan çabayı azaltan, titizlikle tasarlanmış bir dizi döngüdür.

Bu, genel özerklik anlatısından daha az çarpıcı olabilir; ancak yararlı sistemlerin gerçekte nasıl benimsendiğine çok daha yakındır.

Yazarlar

Atharva Tidke, George Montagu