Przegląd kodu przez AI wymaga wskazania przeczytanej wersji

„Przejrzałem zmianę. Dwie drobne uwagi, poza tym bez zastrzeżeń”. Taki raport mógłby zamknąć temat, gdyby nie niewygodne pytanie: którą zmianę? W czasie przeglądu autor dopisał jeszcze walidację, podmienił plik konfiguracyjny i poprawił jedną z uwag. Asystent skończył czytać, ale kod nie skończył się zmieniać.

To przykład hipotetyczny. Interesuje nas dowód zakresu przeglądu, a nie ocena konkretnego repozytorium. Przegląd kodu oznacza tu czytanie zmiany i jej kontekstu w poszukiwaniu problemów. Nie jest tym samym co uruchomienie testów ani zgodą na wdrożenie. Zdanie „nie znalazłem błędów” ma sens dopiero razem z informacją, gdzie i w jakiej wersji ich szukano.

Firma może zlecić w Aeneia Audit przegląd sposobu wykorzystywania AI oraz dowodów odbioru jego pracy. Specjalistyczna ocena poprawności lub bezpieczeństwa samego kodu wymaga odpowiednich kompetencji i odrębnego zakresu. Tutaj porządkujemy relację między materiałem, który otrzymał recenzent, a wnioskiem, który trafił do osoby podejmującej decyzję.

Jeden numer zgłoszenia może obejmować kilka różnych zmian

Załóżmy, że pracownia rozbudowuje portal rezerwacji sprzętu. Poprawka ma wykluczać wycofane urządzenia z nowych rezerwacji, zachowując ich obecność w historii. Zmienia pięć plików: wybór sprzętu, sprawdzenie dostępności, zapis rezerwacji, konfigurację i test. Historyczne rezerwacje mają nadal rozpoznawać urządzenia, których nie wolno już oferować nowym klientom. Ta różnica będzie celem lektury.

Pull request, czyli zgłoszenie propozycji zmiany kodu, może przez cały dzień mieć ten sam numer. W środku pojawiają się jednak kolejne zapisane wersje. Identyfikator zgłoszenia nie jest więc dokładnym oznaczeniem przeczytanych bajtów. W raporcie potrzebny jest punkt odniesienia: stan początkowy oraz stan propozycji poddany ocenie.

Delta to różnica między tymi stanami. Jeśli nie określono początku, „przejrzałem zmianę” może oznaczać ostatnią poprawkę, cały zestaw od rozpoczęcia prac albo lokalne pliki, których jeszcze nie dodano do zapisanej wersji. Każdy z tych zakresów może być uzasadniony. Żaden nie powinien zostać wybrany przypadkiem przez domyślne zachowanie narzędzia.

Dokumentacja git diff rozróżnia porównanie plików roboczych z obszarem przygotowanym do zapisu, porównanie tego obszaru z wersją oraz porównanie dwóch zapisanych stanów. Samo słowo „diff” nie określa więc pary ocenianych materiałów.

Dla przykładu z portalem ustalmy umownie stan A przed poprawką i stan B obejmujący pięć zmienionych plików. Recenzent powinien dostać właśnie różnicę A–B oraz potrzebny kontekst. Litery są oznaczeniami w tym tekście, nie prawdziwymi identyfikatorami wersji. W rzeczywistym raporcie zastąpią je dokładne dane pozwalające odnaleźć oceniany materiał.

Jeśli pracujemy na plikach lokalnych, zapisany identyfikator repozytorium może nie obejmować bieżących poprawek. Wtedy potrzebna jest zachowana kopia lub inny uzgodniony sposób utrwalenia ocenianego stanu. Dopisanie nowego identyfikatora po odczycie nie sprawi, że wcześniejsza lektura zacznie dotyczyć nowych plików.

Hash w raporcie AI, czyli skrót obliczony z danych, pomaga rozpoznać konkretny materiał. Sam nie dowodzi jego przeczytania ani prawdziwości wniosku. Do oznaczenia wersji trzeba dołączyć zakres rzeczywistego odczytu. Są to dwie różne części dowodu, które często mieszczą się w sąsiednich kolumnach raportu.

Zachowaj również początek porównania po aktualizacji gałęzi. Jeżeli zmieni się baza, ten sam końcowy plik może należeć do inaczej wyznaczonej różnicy. Raport powinien wyjaśnić, czy kolejna lektura dotyczy poprawki B–C, czy całej propozycji względem nowego początku. Bez tego odbiorca nie wie, dlaczego z listy nagle zniknęły dwa wcześniej widoczne pliki.

Wersja powinna pozostać stabilna na czas lektury albo dać się odtworzyć później. Jeśli autor nadal pracuje, recenzent może czytać zachowaną kopię B, podczas gdy bieżąca propozycja przechodzi już do C. To rozsądny sposób równoległej pracy, pod warunkiem że raport nie zostanie potem opisany jako przegląd C.

Lista pięciu nazw nie oznacza pięciu przeczytanych plików

W hipotetycznym raporcie asystent wskazuje pięć nazw z zestawienia zmian. Szczegółowe uwagi dotyczą jednak tylko wyboru sprzętu i dostępności. Czy pozostałe trzy pliki przeczytał, pominął jako nieistotne, czy ich treści w ogóle nie otrzymał? Lista nazw nie rozstrzyga tego pytania. Może pochodzić z indeksu, a nie z lektury zawartości.

Poproś o prosty opis zakresu przy każdym materiale. Na przykład: różnica odczytana wraz z funkcją wywołującą; cały plik odczytany; pominięty plik wygenerowany; treść niedostępna; fragment odpowiedzi narzędzia urwany. Te stany mają różne znaczenie. Nie wymagają twierdzenia, że recenzent przeczytał wszystko dookoła, żeby ocenić jedną poprawkę.

W naszym portalu plik konfiguracji określa, które kategorie sprzętu są widoczne. Jeśli asystent go nie otrzymał, nie powinien twierdzić, że sprawdził kompletne wykluczenie urządzeń. Może nadal zgłosić trafną uwagę do funkcji dostępności. Wniosek powinien być tak szeroki jak rzeczywiście zbadana zależność, a nie jak tytuł zadania.

GitHub pozwala oznaczyć plik jako Viewed i cofa to oznaczenie, gdy plik się zmieni. To mechanizm śledzenia postępu w interfejsie. Nie jest niezależnym dowodem głębokości analizy ani kompletności przeglądu modelu.

Jeśli narzędzie pokazuje tylko fragment dużego pliku, zachowaj tę informację w raporcie. Nie przepisuj „odczytano plik” z samego wywołania polecenia. Odczyt mógł się zakończyć na limicie odpowiedzi. W długim kontekście AI ważna jest również różnica między dostarczeniem treści a jej poprawnym wykorzystaniem. Przy przeglądzie najpierw potrzebujemy ustalić przynajmniej to pierwsze.

Kontekst spoza zmienionych linii też ma znaczenie, ale powinien być dobrany do pytania. Nowy warunek sprawdzania sprzętu może wymagać zajrzenia do miejsca, które uruchamia tę funkcję. Zmiana nazwy parametru wymaga sprawdzenia wywołań. Nie oznacza to obowiązkowego czytania całego repozytorium od pierwszego pliku licencji do ostatniej ikony.

W rejestrze można oddzielić kontekst pomocniczy od ocenianej zmiany. Jeśli recenzent otworzył instrukcję projektu, zapisz, którą wersję zasad uwzględnił. Jeśli nie sprawdzał kodu zależności zewnętrznej, nie dołączaj go do zakresu tylko dlatego, że funkcja jej używa. Czytelna granica pomaga następnej osobie skierować uwagę tam, gdzie nadal brakuje dowodu.

Szczególnie ostrożnie traktuj wygenerowane zestawienia i podglądy. Podgląd zmian zależności może nie pokazywać wszystkich zmian surowego pliku. Obraz lub plik binarny nie staje się ocenioną treścią dlatego, że narzędzie odnotowało jego nową wielkość. Raport może uczciwie wskazać taki materiał do innego rodzaju sprawdzenia.

Poprawka uwagi tworzy następny materiał do oceny

Asystent zauważa, że wycofane urządzenie nadal da się wybrać przez bezpośredni adres. Autor naprawia zapis rezerwacji. Przy okazji porządkuje parametr funkcji, zmienia test i dopisuje nową kategorię w konfiguracji. Powstaje stan C. Fakt usunięcia zgłoszonego problemu nie dowodzi jeszcze, że pozostałe zmiany są poprawne.

W ponownym odbiorze są więc dwa pytania. Czy usunięto konkretny problem z B? I co nowego pojawiło się pomiędzy B a C? Ograniczenie się do pierwszego może przeoczyć usterkę wprowadzoną podczas naprawy. Sam przegląd całej A–C bez rozpoznania poprzedniej uwagi może z kolei zgubić to, co należało potwierdzić szczególnie.

GitHub w opisie programowego tworzenia przeglądu pozwala wskazać identyfikator ocenianego commitu, czyli zapisanego stanu kodu. Dokumentacja ostrzega, że późniejsza zmiana wskazanej linii może uczynić komentarz nieaktualnym. Położenie uwagi wiąże się z wersją materiału.

Dlatego nie traktuj przesuniętego numeru linii jako rozstrzygnięcia problemu. Komentarz może zestarzeć się w interfejsie, choć błąd nadal istnieje w innym miejscu. Może też pozostać widoczny, choć autor poprawił zależną funkcję. Osoba odbierająca powinna odnieść się do treści uwagi i aktualnego zachowania, nie tylko do wyglądu wątku.

Wynik ponownej lektury może brzmieć: „Sprawdzono różnicę B–C w trzech plikach oraz ponownie odczytano wywołanie funkcji dostępności. Pozostałe dwa pliki są zgodne z kopią B”. To przykład formy raportu. Wolno go użyć dopiero po rzeczywistym porównaniu, a nie po zapewnieniu autora, że „tam już nic nie ruszał”.

Niezmienność nie usuwa jednak wcześniejszego braku. Jeżeli konfiguracja w B nie została przeczytana, informacja „bez zmian względem B” nadal nie potwierdza jej przeglądu. Trzeba uzupełnić ten zakres albo zachować go jako otwarte ograniczenie. W naszym przykładzie dopisanie kategorii do konfiguracji wymaga również rozpoznania jej wcześniejszych reguł, zamiast przeczytania wyłącznie nowego wiersza bez zależności.

Instrukcja Copilot code review wskazuje, że nowy push nie uruchamia automatycznej ponownej oceny bez odpowiedniej konfiguracji. Można poprosić o nią ręcznie albo włączyć przegląd nowych zmian. Samo pojawienie się kolejnego commitu nie oznacza nowego przeglądu.

Przy automatyzacji zachowaj wersję, której dotyczy zakończone uruchomienie. Proces może wystartować dla B, skończyć po opublikowaniu C i nadal poprawnie raportować wynik B. Problem powstaje wtedy, gdy podsumowanie przypina tę ocenę do bieżącej wersji tylko dlatego, że oba zdarzenia wydarzyły się w jednym zgłoszeniu.

Jeżeli przegląd działa w procesie CI dla pull requestu, osobno określ, z jakich instrukcji i treści korzysta. CI to automatyczny przebieg uruchamiany przez zmianę w repozytorium. Dowód zakresu lektury nie rozstrzyga, czy środowisko miało właściwe granice dostępu. Zakres lektury oraz dostęp środowiska wymagają osobnych odpowiedzi, nawet jeśli narzędzie pokazuje jeden wynik.

Po zmianie nazw plików zachowaj związek z wcześniejszym zakresem. Zniknięcie starej ścieżki nie musi oznaczać usunięcia zachowania; kod mógł zostać przeniesiony. Recenzent powinien odnaleźć miejsce, do którego trafiła poprawka, i sprawdzić potrzebne wywołania. Raport opisujący dawną nazwę jako „nie występuje, problem zamknięty” mógłby przeoczyć tę samą usterkę w nowym module.

Co można przyjąć po takim raporcie

Raport może uczciwie stwierdzić brak znalezionych problemów w opisanym zakresie. Nie dowodzi nieistnienia błędów. Nie potwierdza też automatycznie wykonania prób. Dowód uruchomienia testów z AI obejmuje polecenie, warunki i wynik; lektura kodu jest inną czynnością. Przy końcowej decyzji oba materiały mogą się uzupełniać, ale nie powinny udawać siebie nawzajem.

Zamiast zbierać wszystkie informacje w słowie „sprawdzone”, zostaw krótki wynik z odrębnymi granicami:

• Wersja oraz porównanie, którego dotyczył przegląd.
• Rzeczywiście odczytane pliki i potrzebny kontekst.
• Znalezione problemy oraz sposób ich późniejszego rozstrzygnięcia.
• Materiały pominięte lub niedostępne i wpływ tej granicy na wniosek.
• Osobne dowody wykonanych testów, jeśli były częścią zlecenia.

Taki zapis przydaje się także w odbiorze kodu i dokumentacji od wykonawcy. Pozwala powiązać ocenę z materiałem, który firma faktycznie otrzymuje. Nazwa gałęzi, data spotkania i liczba komentarzy mogą ułatwiać orientację, lecz nie zastępują tego związku.

Przed decyzją porównaj bieżącą propozycję z ostatnim przyjętym zakresem. Jeśli doszła konfiguracja kategorii sprzętu, skieruj ją do lektury i zachowaj wcześniejszy raport jako ocenę B. Jeśli kolejna wersja dotyczy wyłącznie uzgodnionej naprawy, opisz sprawdzenie tej naprawy i jej zależności. Nie trzeba urządzać nowego wielkiego przeglądu niezmienionych plików. Trzeba przestać udawać, że stary raport przeczytał przyszłość.