Yapay zeka kod inceleme ajanını pipeline'ınıza bağladınız ve işe yaradı. Eksik bir null kontrolünü işaretledi, kullanılmayan bir import'u yakaladı ve isimlendirmeyle ilgili üç düzgün yorum bıraktı. Merge ettiniz. İki gün sonra bir müşteri, ajanın doğrudan gözden kaçırdığı bir hataya takıldı: değişiklik kendi içinde temizdi ama yanlış olanı yapıyordu. İnceleme ajanı kodu doğruladı. Niyeti doğrulayamadı.
İşte bu boşluk, yapay zeka kod inceleme ajanlarının bütün hikayesi. Belirli ve kontrol edilebilir bir sorun sınıfında iyiler; bir diff'te tıpatıp aynı görünen başka bir sınıfa ise körler. Onların onayını kabul yerine koyarsanız, kör kaldıkları sınıfı canlıya verirsiniz. Sınırın nerede olduğunu bilirseniz, inceleyicilerinizi yalnızca insanların verebileceği kararlara serbest bırakan hızlı bir ilk geçiş elde edersiniz.
Bu makale o sınırı haritalıyor: bir yapay zeka kod inceleme ajanının neleri doğrulayabildiğini, neleri doğrulayamadığını ve ikisini birbirinden ayrı tutan işleyiş modelini. Sharkly, üzerinden geçeceğimiz katman: ajan incelemesi ile insan kabulünün aynı Görev üzerinde iki farklı durum olduğu, tek bir onay kaşesi olmadığı ortak çalışma alanı. Kodlama ajanlarınız zaten var; buradaki mesele, ikinci bir ajanın döngüyü kapattığını varsaymadan onların çıktısını incelemek.
Yapay zeka kod inceleme ajanı neleri doğrulayabilir
Yapay zeka kod inceleme ajanı, bir diff'i okuyan, üzerinde kontroller çalıştıran ve bulguları tıpkı bir insan inceleyicinin yorum bırakması gibi raporlayan bir programdır. Güvenilir olduğu alan, dikkatli bir inceleyicinin değişikliği ve hemen çevresindeki kodu okuyarak doğrulayabileceği her şeydir:
- Mekanik doğruluk: sözdizimi, tipler, bariz null ve sınır durumu yönetimi, işlenmemiş promise redleri, diff'te görülebilen kaynak sızıntıları.
- Yerel mantık: off-by-one hataları, ters çevrilmiş koşullar, ölü dallar, atanmadan önce okunan bir değişken.
- Konvansiyon: isimlendirme, biçimlendirme, import düzeni, yeni bir fonksiyonun yanında testinin olup olmadığı.
- Bilinen anti-pattern'ler: string birleştirmeyle oluşturulan SQL, düz metin olarak commit edilen gizli anahtarlar, girdi doğrulaması eksik bir public metot.
Bunların ortak bir özelliği var: kanıt diff'in içinde. Ajanın bunları yakalamak için işinizi bilmesine gerek yok ve akşam 6'da yorgun bir insandan daha hızlı, daha tutarlı yakalıyor. Bu gerçek bir değer ve ekiplerin bu araçlara yönelmesinin nedeni de bu. Google'ın kod inceleme rehberi bu mekanik geçişi olmazsa olmaz sayar ki insan dikkati tasarıma odaklanabilsin. Bir yapay zeka inceleyici, bu geçişi her seferinde tamamlamanın sabırlı bir yolu.
Neleri doğrulayamaz
Sınır şu, açıkça söyleyelim: yapay zeka kod inceleme ajanı, değişikliğin doğru değişiklik olduğunu doğrulayamaz. Aşağıdaki her şey, diff'te bulunmayan bir bağlama ihtiyaç duyar.
- Niyet ile spesifikasyon. Kod kusursuz olabilir ve yanlış problemi çözüyor olabilir. Bunu yalnızca ticket'ın kabul kriterleri belirler ve ajan bunları nadiren görür.
- İş doğruluğu. Bir indirim kuralının, vergi hesaplamasının veya yetki sınırının şirketin işleyişine uyup uymadığı bir muhakeme meselesidir, bir lint kuralı değil.
- Sistemler arası davranış. Bir dosyada sorunsuz görünen bir değişiklik, üç servis ötedeki bir çağırıcıyı bozabilir. OWASP'in Top Ten listesi, yalnızca tüm istek yolunu izlediğinizde ortaya çıkan, diff'te görünmeyen bozuk erişim kontrolü gibi hatalarla doludur.
- Testlerin dürüst olup olmadığı. Bir ajan bir testin var olduğunu ve geçtiğini doğrulayabilir. Ama testin önemli olan şeyi doğruladığını ya da kodu yazan ajanın geçmeye göre şekillendirilmiş bir test yazdığını söyleyemez.
Son madde, yapay zekanın yazdığı koda özgü tuzak. Değişikliği ve incelemeyi aynı sınıftan bir sistem ürettiğinde, temiz bir diff ve yeşil bir tik aynı anda doğru olabilir ve ikisi de asıl meseleyi ıskalayabilir. Bu yüzden bir inceleme ajanının onayı bir sinyaldir, karar değil. Ajan raporlar; kabul eden bir insandır.
Boşluğu kapatan işleyiş modeli
Çözüm, daha iyi bir inceleme ajanı değil. İnceleme ajanının işi ile insanın işinin farklı durumlar olduğu ve hiçbirinin atlanmadığı bir işleyiş modeli.
Sharkly bu durumları Görev durumu olarak açıkça ortaya koyar. Bir Görev Devam ediyor'dan İncelemeye hazır'a, oradan Tamamlandı'ya ilerler. Kural basit ve yapıyı taşıyan türden: işleri İncelemeye hazır'a ajanlar taşır; Tamamlandı'ya insanlar taşır. Kodu yazmış ya da incelemiş olsun, bir ajan kendi işini asla kabul edildi olarak işaretleyemez. Ajanlar araştırır, uygular, test eder ve raporlar. İnsanlar yön belirler, yetki verir ve sonucu kabul eder. Otomasyon, ekip muhakemesinin gerektiği yerde durur.
Her rolün tek bir işi var. Kodlama Ajanı değişikliği üretir. İnceleme Ajanı mekanik geçişi çalıştırır ve bulgularını ekler. İnsan inceleyici bu bulguları okur, değişikliği ticket'ın niyetiyle karşılaştırır ve karar verir. Her şey Görev'e döner: diff, İnceleme Ajanı'nın yorumları, test çıktısı ve insan kararı bir PR'a, bir sohbet kanalına ve birinin hafızasına dağılmak yerine tek bir zaman çizelgesinde yaşar.
Değişiklik mekanik ve kendi içinde kapalıysa — bir refactor, bir bağımlılık güncellemesi, kapsamı net bir hata düzeltmesi — inceleme ajanını ilk kapı olarak kullanın; gürültüyü temizlemesine izin verin ki insan geçişi hızlı olsun. Değişiklik parayla, auth ile, veri taşımalarıyla veya public sözleşmelerle ilgiliyse tek kapı olarak ona yaslanmayın; orada önce insan okur ve ajanın geçişi bir karar değil, bir kontrol listesidir.
Örnek bir akış: ticket'tan merge edilmiş PR'a
SH-312'yi ele alalım: "Ödeme sırasında süresi geçmiş kupon kodlarını reddet." Kabul kriterlerini bir insan yazar ve Görevi atar. Bir kodlama Ajanı görevi üstlenir, izole bir worktree'de çalışır ve Görev'e bir diff ile geçen bir test bırakır, Görevi İncelemeye hazır'a taşır.
Şimdi İnceleme Ajanı devreye girer. Tipleri doğrular, eksik bir null kontrolünü işaretler ve testin süresi geçmiş durumu kapsadığını belirtir. Temiz bir geçiş. Eski alışkanlıkla bu onay merge edilir.
Bunun yerine insan inceleyici Görevi açar ve niyete göre okur. Kod, tam yazıldığı gibi, süresi geçmiş kuponları reddediyor. Ama kabul kriterleri, daha önce kullanılmış kuponların da reddedilmesi gerektiğini ima ediyordu ve bunu ne kodlama Ajanı ne de İnceleme Ajanı biliyordu; çünkü bu bilgi diff'te değil, inceleyicinin kafasında ve ürün spesifikasyonunda yaşıyor. İnceleyici bir değişiklik talep eder. SH-312, belirli bir notla birlikte Devam ediyor'a geri döner, Ajan işi genişletir ve ancak ondan sonra bir insan Görevi Tamamlandı'ya taşıyıp pull request'i merge eder.
İnceleme ajanı işini iyi yaptı ve yine de bir boşluk canlıya çıkabilirdi. İşleyiş modeli bunu yakaladı, çünkü kabul, bağlama sahip bir insanın ayrı bir eylemiydi. Bu, yapay zekanın ürettiği kodu görev düzeyinde kanıtlarla incelemenin ardındaki disiplinin aynısı: incelemenin birimi, tek başına diff değil, Görev ve onun niyetidir.
İnceleme kapılarınızı nereye koymalı
Pratik soru, yapay zeka kod inceleme ajanlarını kullanıp kullanmayacağınız değil. Onların geçişinin nerede geçerli olduğu ve nerede önce bir insanın okuması gerektiği. İşte tutarlılığını koruyan birkaç kural:
- Her değişiklikte stil, biçimlendirme ve mekanik hatalar için kapıyı ajana bırakın. En iyi yaptığı geçiş bu ve insanların yorgunken en kötü yaptığı da.
- Auth, faturalama, veri taşımaları veya bir public API'ye dokunan her şeyde insan kapısı zorunlu olsun. Kör nokta orada yoğunlaşır.
- Kapılarınızı inceleme kapasitenize göre boyutlandırın. Ajanlar insanların kabul edebileceğinden hızlı üretir, o yüzden insan geçişini ajanın kör olduğu yerlerde harcayın.
- Kapıyı bir alışkanlık değil, bir durum haline getirin. Tamamlandı'yı engelleyen, belgelenmiş bir onay kapısı uygulanabilir; "birinin bakması lazım" şeklindeki bir norm uygulanabilir değildir. Döngüde bir insan tutmak, ancak döngü iş akışının gerektirdiği bir adım olduğunda işe yarar.
Yapay zeka kod inceleme ajanı, insan inceleyicinin yerini almaz. İnsan geçişini daha hızlı ve daha keskin yapan ilk geçiştir. Zaten birkaç kodlama ajanı çalıştırıyorsanız ve çıktılarının beş PR sekmesi yerine tek bir yerde incelenip kabul edilmesini istiyorsanız, Sharkly tam olarak bu problem için kuruldu: paylaşılan Görevler üzerinde ajan işini ata, takip et ve incele; İnceleme Ajanı'nın bulguları ve insan kararı aynı kayda döner. Halihazırda kullandığınız kodlama ajanlarını ve inceleme ajanını koruyun, sonra geçişlerinin ne zaman yeterli olduğuna karar veren katmanı ekleyin.
