Dlaczego lepsze narzędzia popsuły recenzenta kodu w Copilocie

Instynkt jest prosty: daj agentowi lepsze narzędzia, a wykona lepszą pracę. Zespół Copilota w GitHubie sprawdził ten instynkt na własnej skórze i wyszło odwrotnie. Kiedy podmienił narzędzia, którymi jego agent do recenzji kodu przeszukuje repozytorium, na lepiej utrzymywany, wspólny zestaw z Copilot CLI, koszt recenzji w testach poszedł w górę, a agent wyłapywał mniej problemów.

Po otwarciu pull requesta Copilot code review czyta diff, patrzy więc tylko na to, co w kodzie się zmieniło, i sam dogląda okolicznego kodu, żeby złapać błędy, zanim trafią do głównej gałęzi. Dotąd robił to własnymi narzędziami. GitHub chciał posprzątać i oprzeć coraz więcej swoich agentowych produktów na jednym, wspólnym zestawie uniksowych narzędzi: grep do szukania tekstu, glob do znajdowania plików po wzorcu ścieżki i view do czytania konkretnego fragmentu. Na papierze wymiana wyglądała na prostą zamianę jednego na drugie. O tym, że wąskim gardłem przestaje być pisanie kodu, a staje się jego recenzja, pisałem miesiąc temu, więc tym bardziej liczy się, ile taka recenzja kosztuje.

Zamiana prosta nie była. Napalys Klicius, inżynier z GitHuba, prześledził w zapisach przebiegu każde wywołanie narzędzia agenta, to, ile danych wróciło i gdzie agent się pomylił, i zobaczył coś konkretnego: agent zachowywał się, jakby zwiedzał całe repozytorium, a nie badał jeden pull request. Szukał szeroko, zgadywał prawdopodobne ścieżki, czytał na zapas i całą tę nadmiarową zawartość ciągnął ze sobą dalej.