Zespół deweloperski: agenci AI recenzują pull requesty i sortują zgłoszenia GitHub

W zespole deweloperskim recenzja kodu i sortowanie zgłoszeń to dwa zadania, które wszyscy uważają za przydatne, a na które nikt nie znajduje czasu, by robić je dokładnie. Pull request czeka dwa dni, aż wolna osoba go przeczyta, a pierwsze komentarze dotyczą często tego, co zauważyłby szybki rzut oka: brakującego testu, zbyt szerokiej gałęzi, zapomnianego sekretu. Zgłoszenie przychodzi bez typu i priorytetu, czasem bez informacji potrzebnych do odtworzenia problemu, i czeka, aż człowiek je zakwalifikuje. To zadania metodyczne, z kryteriami, które zespół potrafi spisać, i pasują do agentów AI, o ile ich uprawnienia są ograniczone.

Inspiracja: pierwsze czytanie przed ludźmi

Punktem wyjścia jest zastosowanie opisywane przez użytkowników Hermes Agent, streszczone w karcie o zespole deweloperskim: recenzowanie otwartych pull requestów i sortowanie nowych zgłoszeń. Nie chodzi o zastąpienie recenzenta-człowieka, lecz o przekazanie mu pull requestów już przeczytanych, z punktami do sprawdzenia na górze listy, oraz zgłoszeń już zakwalifikowanych.

Zachowujemy dwie oddzielne role i zasadę ostrożności: agenci komentują i etykietują, niczego nie rozstrzygają. Atako stosuje ten pomysł z dwoma agentami, których dostęp do GitHuba jest celowo ograniczony do czytania, komentowania i etykietowania.

Co robią dwaj agenci

Scenariusz wdraża dwóch agentów, obu połączonych z Twoim repozytorium GitHub.

Recenzent PR czyta otwarte pull requesty. Dla każdego przegląda tytuł, opis, zmienione pliki i commity, otwiera istotne pliki i porównuje je z konwencjami, które podałeś: testy, nazewnictwo, rozmiar, komunikaty commitów, obszary wrażliwe. Szuka ryzyka błędów, brakujących testów, zmian dotykających uwierzytelniania, płatności lub sekretów oraz zmian, których nic nie wyjaśnia. Zostawia jeden komentarz pod pull requestem: jedno zdanie streszczające zmianę, to, co jest dobre, potem punkty do sprawdzenia w kolejności ważności, każdy powiązany z plikiem i, jeśli to możliwe, z linią, oraz oznaczony jako blokujący lub jako sugestia. Kończy tym, czego nie mógł zweryfikować, na przykład uruchomieniem testów. Pamięta ostatni przeczytany commit i komentuje ponownie tylko wtedy, gdy pojawią się nowe commity, krótkim uzupełnieniem.

Sortujący zgłoszenia zajmuje się nowymi zgłoszeniami. Sprawdza, czy istnieją etykiety typu (błąd, funkcja, pytanie, dokumentacja) i priorytetu (wysoki, średni, niski), i tworzy brakujące. Dla każdego zgłoszenia bez etykiety czyta tekst i komentarze, szuka podobnych zgłoszeń, ustala typ i priorytet według Twoich reguł, nadaje etykiety i dodaje komentarz: co zrozumiał, powód priorytetu, prawdopodobne duplikaty i czego brakuje do działania, na przykład kroków do odtworzenia lub dotkniętej wersji. Gdy typ lub waga są niejasne, mówi o tym, wybiera najniższy priorytet i zadaje pytanie.

Każdy przebieg kończy się podsumowaniem na czacie, które zaczyna się od tego, co szybko wymaga człowieka.

Czego agenci nie robią

Ograniczenia są częścią projektu. Żaden agent nie scala, nie zatwierdza, nie żąda formalnie zmian, nie zamyka pull requestu, nie wypycha kodu ani nie tworzy gałęzi. Nie mają tych narzędzi: to nie obietnica zapisana w instrukcji, lecz brakująca zdolność. Sortujący nie zamyka, nie otwiera ponownie, nie blokuje i nie usuwa żadnego zgłoszenia oraz nie zmienia ani tytułu, ani osoby przypisanej, ani kamienia milowego.

Agenci nie zgadują. Recenzent podaje plik i linię, wskazuje to, czego nie mógł zweryfikować, i nie wymyśla żadnej funkcji ani wyniku testu. Jeśli natrafi na zacommitowany sekret lub token, mówi, gdzie wydaje się znajdować, bez kopiowania go. Sortujący wskazuje jako duplikaty tylko zgłoszenia, które faktycznie znalazł wyszukiwaniem. A decyzja pozostaje ludzka na każdym kroku, co jest zasadą projektu z walidacją przez człowieka.

Jak to skonfigurować w Atako

Ze strony tego przypadku użycia wdrożenie wymaga czterech kroków.

1. Połącz GitHub. Utwórz token o szczegółowych uprawnieniach, ograniczony do repozytorium, z dostępem do odczytu kodu oraz odczytu i zapisu zgłoszeń i pull requestów. Połączenie jest sprawdzane, zanim cokolwiek powstanie.
2. Podaj swój kontekst. Wpisz repozytorium w postaci właściciel/nazwa, swoje konwencje recenzji, jeśli je masz, i to, co dla Ciebie czyni zgłoszenie pilnym. Bez nich agenci opierają się na ogólnych dobrych praktykach i wadze błędów.
3. Wdróż. Jedna akcja tworzy dwóch agentów i projekt „Zespół deweloperski”. Agenci są przygotowywani i sami otrzymują pierwsze instrukcje.
4. Pierwsze wyniki, potem regularny rytm. Recenzent komentuje pięć najnowszych pull requestów, sortujący etykietuje dziesięć ostatnich zgłoszeń bez etykiety, a każdy podsumowuje swój przebieg na czacie. Potem recenzent sam planuje swoje przebiegi na 9:00 i 14:00 w dni robocze, a sortujący swój na 9:30.

Jeśli nie masz jeszcze konta, jego utworzenie rozpoczyna okres próbny, a scenariusz jest konfigurowany zaraz potem. Jeśli administrator nie zezwolił Ci na tworzenie agentów, wdrożenie informuje o tym i na tym się kończy.

Gdzie zobaczyć wyniki

Komentarze recenzji czyta się na GitHubie, pod każdym pull requestem, a etykiety i komentarze sortowania pod każdym zgłoszeniem. Podsumowanie każdego przebiegu czyta się na czacie każdego agenta. W projekcie Atako „Zespół deweloperski” znajdziesz stronę opisującą działanie i śledzenie pracy, a na floorze Atako obaj agenci pojawiają się ze swoją bieżącą aktywnością.

Aby dostosować zachowanie, napisz do agenta na jego czacie, na przykład „dodaj do swoich konwencji, że każda migracja bazy danych musi wspominać plan wycofania”. Zachowa instrukcję w pamięci na kolejne przebiegi.

Zabezpieczenia

Dostęp jest celowo wąski. Połączenie z GitHubem jest przyznane agentom z ograniczoną listą dwunastu narzędzi: czytanie pull requestów, plików i commitów, czytanie i aktualizacja zgłoszeń, zarządzanie etykietami, dodawanie komentarzy. Agent widzący krótką listę narzędzi używa ich pewniej niż agent zagubiony w katalogu setek, a przede wszystkim to, co nie jest przyznane, nie może się wydarzyć, nawet jeśli tekst próbuje to wymusić. Agenci traktują tytuły, opisy, komentarze i kod jako dane do analizy, nigdy jako instrukcje.

Token, który tworzysz, to Twoje pierwsze zabezpieczenie: ograniczony do jednego repozytorium i precyzyjnych uprawnień, ogranicza możliwe szkody, cokolwiek się stanie. Jest przechowywany zaszyfrowany i w każdej chwili możesz go unieważnić po stronie GitHuba albo cofnąć agentom dostęp.

Walidacja przez człowieka znajduje się w punktach decyzyjnych. Ty czytasz komentarze recenzji, decydujesz, co poprawić, sam zatwierdzasz i scalasz oraz zamykasz, przypisujesz i planujesz zgłoszenia.

Czego się spodziewać

Spodziewaj się przydatnych komentarzy głównie przy pull requestach rozsądnej wielkości: przy bardzo dużej zmianie recenzent powie o tym i skupi się na najbardziej wrażliwych plikach, zamiast udawać, że przeczytał wszystko. Nie może uruchomić Twoich testów i mówi o tym w każdym komentarzu. Sortujący jest tak trafny, jak precyzyjne są Twoje reguły priorytetów; bez nich wybiera ostrożność i zadaje pytania. Wartość płynie z regularności: każdy pull request dostaje pierwsze czytanie w ciągu pół dnia, każde zgłoszenie przychodzi zakwalifikowane, a Twoi recenzenci-ludzie poświęcają czas na ocenę, a nie na wyszukiwanie.