Wieloagentowy przegląd kodu w LinkedIn: programiści przyjęli 63,9 % sugestii z próby

Problem

Przegląd kodu jest wąskim gardłem dostarczania oprogramowania. LinkedIn ma ponad 10 000 aktywnych repozytoriów kodu i co tydzień dziesiątki tysięcy pull requestów (proponowanych zmian w kodzie). Narzędzia do kodowania z AI dodawały więcej kodu na programistę, a czas oczekiwania na pierwszy przegląd przez człowieka rósł. Ogólne narzędzia AI do przeglądu kodu dawały komentarze nietrafiające w konwencje poszczególnych zespołów, a hałaśliwe komentarze uczą programistów ignorowania narzędzia.

Co zbudowano

Wieloagentowego recenzenta. Orkiestrator wysyła każdy pull request jednocześnie do kilku podagentów przeglądu. Każdy podagent to inna para: model AI i otaczające go narzędzia. Orkiestrator zbiera ich ustalenia, usuwa duplikaty, weryfikuje je i publikuje jeden przegląd. LinkedIn porównał to z hostowanymi produktami do przeglądu kodu od dostawców modeli i postanowił zbudować własny. Podał trzy ograniczenia: każdy produkt niesie martwe punkty swojego modelu, jeden plik reguł nie wyrazi jednocześnie standardów całej firmy i poszczególnych repozytoriów, a kupionego produktu nie można najpierw przetestować na kilku repozytoriach ani monitorować w całej flocie.

Jak to zrobiono

Ustalenia, które niezależnie zgłasza kilku podagentów, są traktowane jako wysoce pewne. Ustalenie zgłoszone tylko przez jednego jest sprawdzane przed publikacją. Trzypoziomowe ramy reguł pozwalają firmie, grupom zespołów i pojedynczym repozytoriom dodawać wskazówki do przeglądu, a system łączy je dla każdej zmiany. System działa na zdarzeniach GitHub i puli maszyn roboczych w Kubernetes. Każda maszyna robocza obsługuje do 12 pull requestów równolegle. LinkedIn prowadzi go z dyżurami na wezwanie, monitoringiem szybkości i wskaźnika przyjęcia, etapowym wdrażaniem i rozwiązaniem zastępczym na wypadek pogorszenia działania dostawcy modelu.

Jakość jest sprawdzana na dwa sposoby. Zanim jakakolwiek zmiana promptu lub modelu trafi do użytku, musi pokonać lub zrównać się z bieżącą wersją w ślepym porównaniu bezpośrednim ocenianym przez sędziego AI. Po wdrożeniu automatyczna kontrola porównuje każdą sugestię z kodem ostatecznie scalonym, aby sprawdzić, czy programiści ją uwzględnili.

Wyniki

LinkedIn podaje łączny wskaźnik przyjęcia 63,9 % w próbie 1 727 pull requestów i 5 230 komentarzy z siedmiu dni. Według kategorii błędy logiczne osiągnęły 80 %, a poprawki błędów 58,1 %, podczas gdy refaktoryzacja (43,5 %) i bezpieczeństwo (40,6 %) wypadły niżej. LinkedIn odczytuje niższe wyniki jako oznakę, że te obszary są bardziej subiektywne. Podaje, że w typowym tygodniu system kończy ponad 79 000 przeglądów w ponad 40 000 pull requestach w ponad 7 500 repozytoriach, przy odsetku ukończonych zadań 99,1 %. Podaje też, że większość przeglądów kończy się w mniej niż 10 minut, a przegląd AI zwykle pojawia się, zanim recenzent-człowiek otworzy zmianę. Wskaźnik przyjęcia wahał się od 0 % do 100 % w poszczególnych repozytoriach. LinkedIn mówi, że wielu inżynierów czeka teraz na przegląd AI, zanim zwróci się do współpracowników, a przegląd przez człowieka pozostaje wymagany przy każdej zmianie.