Przeglądaj kod wygenerowany przez AI

Przeczytaj wymaganie przed podsumowaniem

Zacznij od oczekiwanego zachowania i kryteriów akceptacji. Potem sprawdź rzeczywisty diff. Podsumowanie agenta pomaga się po nim poruszać, ale może pomijać zmiany lub niedokładnie opisywać kontrole.

Potwierdź branch i commit poddawane przeglądowi. Poza kodem aplikacji sprawdź zmiany konfiguracji, zależności, infrastruktury i testów. Mała widoczna funkcja może obejmować dużą zmianę uprawnień lub sposobu wdrażania.

Najpierw przejrzyj zachowanie o największych konsekwencjach. Formatowanie i nazewnictwo są ważne, ale nie powinny odwracać uwagi od brakującej granicy danych.

Prześledź tożsamość aż do zasobu

Rozważ ten niepełny, fikcyjny endpoint. Przykład pokazuje problem do wykrycia w przeglądzie; nie jest kodem produkcyjnym.

async function getInvoice(request) {
  const user = await requireSignedInUser(request);
  return database.invoice.findById(request.params.id);
}

Funkcja pobiera uwierzytelnionego użytkownika. Nie pokazuje decyzji o autoryzacji dostępu do faktury. Recenzent musi sprawdzić, czy egzekwuje ją inna warstwa. Nieużywana wartość użytkownika jest powodem do sprawdzenia, ale sama nie dowodzi podatności możliwej do wykorzystania.

Prześledź żądanie w rzeczywistym systemie. Wskaż zaufanego użytkownika i organizację. Sprawdź, jak zapytanie ogranicza dostęp do żądanego rekordu. Przejrzyj obsługę błędów i testy zabronionych żądań.

Nie zakładaj, że ukryty przycisk chroni API. Wywołujący może wysłać żądanie bez użycia interfejsu. Nie zakładaj też, że poprawny identyfikator rekordu daje dostęp.

Zapytaj, jakie dowody mogą odrzucić zmianę

Przechodzący test może korzystać z danych administratora albo zastępować autoryzację mockiem. Sprawdź, czy bada istotną granicę. W razie potrzeby dodaj przypadek z inną organizacją i rzeczywistą ścieżką autoryzacji.

Przy zmianie interfejsu sprawdź wyrenderowany wynik. Zbadaj obsługę klawiaturą, puste stany, ładowanie i błędy. Sprawdzenie typów nie dowodzi, że okno dialogowe da się obsłużyć klawiaturą.

Przy zmianie zależności sprawdź, dlaczego jest potrzebna. Przejrzyj wersję, licencję i ustalenia bezpieczeństwa. Nie akceptuj niezwiązanej aktualizacji tylko dlatego, że agent wygenerował ją podczas zadania.

Zachowaj niezależność przeglądu

Drugi model może wskazać przydatne problemy. Może też powtórzyć założenia implementacji. Przekaż recenzentowi wymaganie i diff. Nie sugeruj, że zmiana już jest poprawna.

Wymagaj wskazania konkretnego sposobu wystąpienia błędu i właściwego kodu. Traktuj niepoparte ostrzeżenia jako pytania do zbadania. Zdecydowaną akceptację traktuj jako kolejną opinię, dopóki ważne twierdzenia nie mają dowodów.

Przegląd przez człowieka pozostaje decyzją o odpowiedzialności. Recenzent powinien rozumieć zmianę na tyle, aby wyjaśnić jej zachowanie, ryzyko i weryfikację. Jeśli diff jest zbyt duży, ogranicz zakres lub podziel pracę na zmiany możliwe do przeglądu.

Zamknij przegląd na końcowej wersji

Po poprawce ponów kontrole, na które mogła wpłynąć. Sprawdź, czy nie powstał nowy problem. Upewnij się, że wymagany przegląd dotyczy końcowej wersji zgodnie z polityką repozytorium.

Zapisz decyzję o akceptacji przez zachowanie i dowody. Każde pozostałe ograniczenie zapisz wraz z osobą odpowiedzialną i kolejnym działaniem. Nie przedstawiaj nierozstrzygniętego problemu jako dowodu przejścia wszystkich kontroli.

Użyj ćwiczenia przeglądu kodu, aby przećwiczyć rozpoznawanie brakującej decyzji przed zbadaniem rzeczywistej zmiany.