Geliştirme ekibi: yapay zekâ ajanları pull request'leri inceler, GitHub issue'larını ayıklar

Bir geliştirme ekibinde kod incelemesi ve issue ayıklama, herkesin yararlı bulduğu ama kimsenin derinlemesine yapmaya zaman bulamadığı iki iştir. Bir pull request, boşta bir kişinin okumasını iki gün bekler ve ilk yorumlar çoğu zaman hızlı bir bakışın göreceği şeyler hakkındadır: eksik bir test, fazla geniş bir dal, unutulmuş bir sır. Bir issue türsüz ve önceliksiz, bazen yeniden üretmek için gereken bilgiler olmadan gelir ve bir insanın onu nitelendirmesini bekler. Bunlar ekibin yazıya dökebileceği ölçütleri olan yöntem işleridir ve yetkileri sınırlandırıldığı sürece yapay zekâ ajanlarına uygundur.

İlham: insanlardan önce ilk okuma

Başlangıç noktası, Hermes Agent kullanıcılarının aktardığı ve geliştirme ekibine dair bir kartta özetlenen bir kullanımdır: açık pull request'leri incelemek ve yeni issue'ları ayıklamak. Amaç insan inceleyicinin yerini almak değil, ona zaten okunmuş pull request'leri, kontrol edilecek noktalar listenin başında olacak şekilde, ve zaten nitelendirilmiş issue'ları teslim etmektir.

İki ayrı rolü ve bir temkin ilkesini koruyoruz: ajanlar yorum yapar ve etiketler, hiçbir şeye karar vermezler. Atako bu fikri, GitHub erişimi bilerek okuma, yorum yapma ve etiketlemeyle sınırlandırılmış iki ajanla uygular.

İki ajan ne yapar

Senaryo, ikisi de GitHub deponuza bağlı iki ajanı dağıtır.

PR inceleyicisi açık pull request'leri okur. Her biri için başlığı, açıklamayı, değişen dosyaları ve commit'leri gözden geçirir, önemli dosyaları açar ve girdiğiniz kurallarla karşılaştırır: testler, adlandırma, boyut, commit mesajları, hassas alanlar. Hata risklerini, eksik testleri, kimlik doğrulamaya, ödemeye veya sırlara dokunan değişiklikleri ve hiçbir şeyin açıklamadığı değişiklikleri arar. Her pull request için tek bir yorum bırakır: değişikliği özetleyen bir satır, iyi olan şey, ardından önem sırasına göre kontrol edilecek noktalar; her biri bir dosyaya ve mümkünse bir satıra bağlıdır, engelleyici ya da öneri olarak işaretlenir. Doğrulayamadığı şeyle, örneğin testleri çalıştırmakla, bitirir. Okuduğu son commit'i hatırlar ve yalnızca yeni commit'ler geldiğinde, kısa bir takip yorumuyla yeniden yorum yapar.

Issue ayıklayıcısı yeni issue'larla ilgilenir. Tür etiketlerinin (hata, özellik, soru, dokümantasyon) ve öncelik etiketlerinin (yüksek, orta, düşük) var olduğunu denetler ve eksikleri oluşturur. Etiketsiz her issue için metni ve yorumları okur, benzer issue'ları arar, kurallarınıza göre bir tür ve öncelik belirler, etiketleri uygular ve bir yorum ekler: ne anladığı, önceliğin gerekçesi, olası kopyalar ve harekete geçmek için eksik olanlar; örneğin yeniden üretme adımları veya ilgili sürüm. Tür ya da ciddiyet belirsiz olduğunda bunu söyler, en düşük önceliği seçer ve soruyu sorar.

Her tur, hızla bir insan gerektiren şeyle başlayan bir sohbet özetiyle biter.

Ajanlar ne yapmaz

Sınırlar tasarımın parçasıdır. Hiçbiri merge etmez, onaylamaz, resmen değişiklik talep etmez, bir pull request'i kapatmaz, kod göndermez ya da dal oluşturmaz. Bu araçlar onlara verilmemiştir: bu, bir talimatta verilen bir söz değil, eksik bir yetenektir. Ayıklayıcı hiçbir issue'yu kapatmaz, yeniden açmaz, kilitlemez ya da silmez; başlığı, atananı veya kilometre taşını değiştirmez.

Ajanlar tahmin yürütmez. İnceleyici dosyayı ve satırı belirtir, doğrulayamadığını işaretler ve hiçbir işlev ya da test sonucu uydurmaz. Commit edilmiş bir sır veya token'a rastlarsa, onu kopyalamadan nerede göründüğünü söyler. Ayıklayıcı yalnızca arama yoluyla gerçekten bulduğu issue'ları kopya olarak gösterir. Karar da her adımda insanda kalır; insan doğrulamalı bir tasarımın ilkesi budur.

Atako'da nasıl kurulur

Bu kullanım senaryosunun sayfasından dağıtım dört adımda yapılır.

1. GitHub'ı bağlayın. Depoyla sınırlı, kodda okuma, issue'larda ve pull request'lerde okuma ve yazma erişimi olan ince ayarlı bir token oluşturun. Bağlantı, herhangi bir şey oluşturulmadan önce doğrulanır.
2. Bağlamınızı girin. Depoyu sahip/ad biçiminde, varsa inceleme kurallarınızı ve bir issue'yu sizin için neyin acil kıldığını yazın. Bunlar olmadan ajanlar genel iyi uygulamalara ve hataların ciddiyetine dayanır.
3. Dağıtın. Tek bir eylem iki ajanı ve "Geliştirme ekibi" projesini oluşturur. Ajanlar hazırlanır ve ilk talimatlarını kendiliğinden alır.
4. İlk sonuçlar, ardından düzenli bir ritim. İnceleyici en son beş pull request'i yorumlar, ayıklayıcı etiketsiz son on issue'yu etiketler ve her biri turunu sohbette özetler. Sonra inceleyici turlarını hafta içi 9:00 ve 14:00'e, ayıklayıcı kendi turunu 9:30'a kendisi planlar.

Henüz hesabınız yoksa, hesap oluşturmak deneme sürenizi başlatır ve senaryo hemen ardından kurulur. Yöneticiniz ajan oluşturmanıza izin vermediyse, dağıtım bunu size söyler ve orada durur.

Sonuçları nerede görürsünüz

İnceleme yorumları GitHub'da her pull request üzerinde, ayıklama etiketleri ve yorumları her issue üzerinde okunur. Her turun özeti ilgili ajanın sohbetinde okunur. Atako'daki "Geliştirme ekibi" projesinde nasıl çalıştıklarını anlatan sayfayı ve işin takibini bulursunuz; Atako floor'unda iki ajan güncel etkinlikleriyle görünür.

Davranışı ayarlamak için ajana sohbetinde yazın, örneğin "kurallarına şunu ekle: her veritabanı migrasyonu geri alma planını belirtmeli". Talimatı sonraki turlar için belleğinde tutar.

Güvenceler

Erişim bilerek dardır. GitHub bağlantısı ajanlara on iki araçlık sınırlı bir listeyle verilir: pull request'leri, dosyaları ve commit'leri okumak, issue'ları okuyup güncellemek, etiketleri yönetmek, yorum eklemek. Kısa bir araç listesi gören ajan, yüzlerce araçlık bir katalogda kaybolan ajandan daha güvenilir çalışır ve en önemlisi, bir metin zorlamaya çalışsa bile verilmeyen şey gerçekleşemez. Ajanlar başlıkları, açıklamaları, yorumları ve kodu analiz edilecek veri olarak ele alır, asla talimat olarak değil.

Oluşturduğunuz token ilk güvencenizdir: tek bir depoyla ve kesin haklarla sınırlı olduğundan, ne olursa olsun olası zararı sınırlar. Şifreli saklanır ve onu GitHub tarafında iptal edebilir ya da ajanların erişimini istediğiniz zaman kaldırabilirsiniz.

İnsan doğrulaması karar noktalarındadır. İnceleme yorumlarını siz okur, neyin düzeltileceğine siz karar verir, siz onaylar ve merge eder; issue'ları siz kapatır, atar ve planlarsınız.

Beklentiniz ne olmalı

Yararlı yorumları esas olarak makul boyuttaki pull request'lerde bekleyin: çok büyük bir değişiklikte inceleyici bunu söyler ve her şeyi okumuş gibi davranmak yerine en hassas dosyalara odaklanır. Testlerinizi çalıştıramaz ve bunu her yorumda belirtir. Ayıklayıcı, öncelik kurallarınız kadar isabetlidir; kurallar yoksa temkini seçer ve soru sorar. Değer düzenlilikten gelir: her pull request yarım gün içinde ilk okumasını alır, her issue nitelendirilmiş gelir ve insan inceleyicileriniz zamanını hata avına değil, muhakemeye harcar.