Pilotaż agentów kodujących, który porównuje narzędzia na tej samej pracy

Dlaczego jeden zespół na narzędzie mówi niewiele

Najprostszy pilotaż daje narzędzie A zespołowi płatności, a narzędzie B zespołowi platformowemu i po miesiącu porównuje zmergowane pull requesty. Tylko że zespoły różnią się kodem, pokryciem testami, doświadczeniem, rodzajem zadań i surowością review, a każdy z tych czynników może zmienić liczby bardziej niż samo narzędzie.

GitHub mówi to samo o własnym dashboardzie wpływu Copilota: adoption multiplier porównuje różne grupy użytkowników, więc skład zespołu, złożoność projektu i doświadczenie mogą wpływać na niego tak samo jak korzystanie z narzędzia. Przydział narzędzi według zespołów dziedziczy ten problem.

Dwa projekty, w których praca pozostaje ta sama

Losowy przydział bieżących zadań

Każdy zespół tworzy pulę zadań, które i tak musi wykonać, a każde zadanie przed rozpoczęciem pracy trafia losowo do jednego z narzędzi, najlepiej osobno w każdym typie zadań. METR zastosował ten projekt w badaniu doświadczonych programistów open source z 2025 roku, losowo przypisując każde prawdziwe zgłoszenie do warunku z narzędziami AI albo bez nich, więc oba warunki obejmowały tych samych ludzi i ten sam rodzaj pracy.

Odtworzenie zmergowanych zmian

Równolegle z bieżącymi zadaniami odtwarzaj niedawno zmergowane zmiany. Każde uruchomienie działa w izolowanej kopii repozytorium, której historia kończy się na commicie sprzed zmiany, bez późniejszych commitów, zdalnych refów, cache'y i plików z wcześniejszych prób oraz bez dostępu sieciowego do zmergowanego pull requesta. Agent dostaje opis zadania i istniejący zestaw testów, a testy akceptacyjne dodane razem ze zmianą są wstrzymane i uruchamiane dopiero potem. Odtworzenie porównuje poprawność i koszt przy identycznych danych wejściowych, ale nic nie mówi o obciążeniu review przy nowej pracy.

Czynniki zakłócające do ustalenia przed pierwszym dniem

Poniższe źródła nieuczciwych porównań są przewidywalne. Zapisz, jak pilotaż radzi sobie z każdym z nich, zanim pojawią się wyniki.

• Dobór zadań: w kontynuacji badania METR z 2026 roku od 30 do 50 procent ankietowanych programistów przyznało, że wstrzymywało zadania, których nie chcieli robić bez AI. Zamknij pulę przed przydziałem i zapisuj każde wycofane zadanie z powodem.
• Nierówna konfiguracja: jeśli jedno narzędzie dostaje staranne instrukcje do repozytorium i działającą komendę testów, a drugie nie, porównujesz konfiguracje. Daj każdemu kandydatowi te same instrukcje, komendy i uprawnienia i zapisuj wersję narzędzia, model i ustawienia dla każdego uruchomienia.
• Samoocena tempa: uczestnicy badania METR z 2025 roku spodziewali się, że z AI będą o 24 procent szybsi, a potem uważali, że byli o 20 procent szybsi, podczas gdy pomiar wykazał 19 procent spowolnienia. METR uznaje dziś te wyniki za nieaktualne, ale rozjazd między odczuciem a pomiarem dotyczy każdego pilotażu.
• Równoległe sesje: inżynierowie, którzy uruchamiają kilku agentów naraz, sprawiają, że czas na zadanie przestaje być wiarygodny, o czym również pisze METR. W części na żywo główne miary efektywności to koszt zaakceptowanej zmiany i minuty review.

Przykładowy plan porównania dwóch narzędzi

Ten plan jest hipotetyczny: dwa zespoły produktowe przez sześć tygodni porównują dwóch agentów kodujących. Liczby to założenia planistyczne, a nie wyniki.

1. 1

   Zbuduj pule

   Każdy zespół wybiera z backlogu 24 zadania: osiem poprawek błędów, osiem zadań na pokrycie testami i osiem małych funkcji, każde z pisemnym opisem i sposobem weryfikacji.

2. 2

   Przydziel losowo

   W każdym zespole i typie zadań skrypt przydziela cztery zadania narzędziu A i cztery narzędziu B, a przydział trafia do repozytorium, zanim ktokolwiek zacznie pracę.

3. 3

   Wyrównaj konfigurację

   Oba narzędzia dostają te same komendy budowania i testów, konwencje review, uprawnienia i dostęp do sieci, każde w swoim formacie instrukcji.

4. 4

   Uruchom odtworzenie

   Trzydzieści zmian zmergowanych w ostatnim kwartale odtwarzasz po trzy razy dla każdego narzędzia, każde uruchomienie w świeżej, oczyszczonej kopii repozytorium, z testami dodanymi przez daną zmianę wstrzymanymi do oceny. Raportujesz dla każdego typu zadania odsetek zaliczeń na tych wstrzymanych testach i koszt zaliczonego zadania z odtworzenia, łącznie z nieudanymi próbami.

5. 5

   Review jak zwykle

   Pull requesty agentów przechodzą zwykłe review i wymagane checki. Recenzenci zapisują minuty review i poprawki oraz to, czy zmiana spełnia definicję akceptacji dla części na żywo.

Zapisz regułę decyzji przed pierwszym uruchomieniem

Poradnik GitHuba dotyczący pilotażu funkcji lub modelu Copilota zaleca, by przed startem określić, jak wygląda decyzja na tak, i prowadzić pilotaż przez co najmniej jeden pełny cykl rozliczeniowy, zwykle cztery do sześciu tygodni. Porównanie narzędzi wymaga tej samej dyscypliny.

• Dwie definicje sukcesu: zadanie z odtworzenia jest zaliczone, gdy przechodzą wstrzymane testy i istniejący zestaw, a diff mieści się w zakresie; zmiana na żywo jest zaakceptowana, gdy przechodzi wymagane checki i review i zostaje zmergowana bez poprawek w uzgodnionym oknie czasowym.
• Osobne miary: koszt zaliczonego zadania z odtworzenia oraz koszt zaakceptowanej zmiany na żywo, łącznie z minutami review i poprawkami. Nigdy nie sumuj tych dwóch.
• Próg praktyczny: najmniejsza różnica, która zmieniłaby twoją decyzję, na przykład dziesięć punktów procentowych odsetka zaliczeń, liczba hipotetyczna. Porównuj narzędzia przypadek po przypadku na tych samych zadaniach z odtworzenia, uruchamiaj każde kilka razy, a jeśli zmienność między przypadkami i próbami jest tak duża jak próg, zapisz wynik jako nierozstrzygnięty.

Wynik nierozstrzygnięty jest w pełni uprawniony, bo wyniki agenta różnią się między uruchomieniami; poradnik Anthropic o ewaluacji traktuje powtarzane próby jako normalny sposób mierzenia agenta. Remis poniżej twojego progu oznacza decyzję na innej podstawie, na przykład kosztu albo dopasowania do twoich mechanizmów kontroli.

Gdzie ten projekt ma swoje granice

Losowy przydział wymaga wystarczającej liczby porównywalnych zadań w każdym typie. Jeśli w trakcie pilotażu zbierze się ich za mało, porównanie na żywo jest nierozstrzygnięte i raport powinien to powiedzieć. Odtworzenie i część na żywo odpowiadają na różne pytania: odtworzenie dotyczy poprawności i kosztu na znanych zmianach, a część na żywo obciążenia review i dopasowania przy nowej pracy. Recenzenci mogą wiedzieć, które narzędzie napisało pull request, więc definicja akceptacji na żywo powinna być mechaniczna.

Gdy wymagania bezpieczeństwa, miejsce przechowywania danych albo twój host gita zostawiają tylko jedno sensowne narzędzie, pomiń porównanie i porównaj to narzędzie z dotychczasowymi wynikami zespołu. Pierwsza 30-minutowa rozmowa z jednym z naszych inżynierów o każdym z tych projektów nie wymaga dostępu do systemów ani danych produkcyjnych.

Jak czytać metryki pilotażu CopilotaEwaluacje na twoich repozytoriach