Diff ma czterdzieści linii, testy przechodzą, kod wygląda znajomo. Akceptacja jest kusząca. Dopiero później okazuje się, że nowa funkcja zmienia typ daty, przechowuje token w logu i wykonuje dwa zapisy przy ponowieniu. Ładny kod może mieć brzydki skutek.
Odbiór powinien odpowiadać na pytania o zakres, zachowanie, dane, bezpieczeństwo i koszt utrzymania. Nie polega na szukaniu stylu AI. Kod trzeba ocenić tak samo rzetelnie jak pracę każdego innego autora.
Zacznij od briefu i zakresu zmiany
Przeczytaj, co agent miał zrobić i czego nie miał zmieniać. Porównaj listę plików i decyzji z tym zakresem. Dodatkowy refaktoring może być dobry, ale nie jest automatycznie częścią zadania.
Sprawdź, czy kod nie nadpisuje cudzych zmian. Duża różnica wspólnego pliku wymaga analizy kontekstu. Nie akceptuj zasady „agent znał lepiej”, jeśli proces wymagał zachowania istniejącej pracy.
Jeżeli nie ma briefu, zapisz go przed odbiorem na podstawie rzeczywistego celu. Bez niego recenzja skupia się na składni i traci pytanie o właściwy problem.
Przeczytaj krytyczne ścieżki
Zidentyfikuj wejścia, wyjścia, uprawnienia, dane, integracje i skutki uboczne. Nie musisz czytać każdej linii z jednakową uwagą. Zacznij od miejsc, gdzie błąd kosztuje najwięcej.
Sprawdź obsługę braków i nieoczekiwanych wartości. Model często zakłada poprawny format z przykładu. Dodaj puste pola, nieznane statusy, długie dane i konflikt wersji. Oczekiwane zachowanie powinno być jednoznaczne.
Przy błędach sprawdź, czy system pokazuje prawdę o stanie. Fałszywy sukces jest gorszy niż jasny błąd. Timeout nie może tworzyć automatycznego ponowienia bez reguły.
Testy muszą odpowiadać na ryzyko
Nie akceptuj samego faktu, że testy istnieją. Przeczytaj, co sprawdzają i jakich przypadków brakuje. Test napisany przez tego samego agenta może powtarzać jego błędne założenie.
Dodaj przypadki z briefu i niezależne kontrolne. Oceń wynik zewnętrzny, nie tylko wartość zwracaną. Przy formularzu sprawdź jeden rekord i jedno zdarzenie, nie tylko komunikat.
Przy integracji wykonaj timeout, ponowienie, konflikt wersji i brak uprawnień. Zasady opisuje przewodnik o ponowieniach integracji AI. Kod może przejść test jednostkowy i nadal duplikować skutki.
Bezpieczeństwo danych i sekretów
Sprawdź, czy klucze nie trafiają do kodu, logów, promptów i odpowiedzi błędów. Przeszukaj diff pod kątem sekretów i danych osobowych. Narzędzia secret scanning pomagają, ale nie zastępują analizy przepływu.
Ogranicz logowanie. Identyfikator operacji jest często wystarczający, pełny payload już nie. Sprawdź, czy dane zewnętrzne nie trafiają do analityki bez potrzeby.
Przy nowych źródłach i narzędziach oceń uprawnienia. Kod agenta nie powinien rozszerzać dostępu ponad brief. Test odmowy jest równie ważny jak test poprawnego działania.
Walidacja wejścia i wyjścia
Sprawdź typy, zakresy, długości, format i kodowanie. Walidacja frontendu nie wystarcza. Serwer powinien egzekwować reguły niezależnie od interfejsu.
Przy odpowiedzi modelu stosuj schemat i reguły biznesowe. Poprawny JSON nie zapewnia prawdziwej kwoty. Przewodnik o JSON Schema w AI opisuje tę granicę.
Nie zakładaj, że tekst z dokumentu jest bezpieczną instrukcją. Sprawdź obsługę prompt injection i ograniczenia narzędzi. Dane zewnętrzne nie powinny zmieniać uprawnień ani wywoływać kodu.
Zależności i licencje
Oceń każdą nową bibliotekę: potrzeba, wersja, licencja, utrzymanie, podatności, rozmiar i wpływ na build. Agent może wybrać popularny pakiet dla jednej funkcji, którą można napisać w kilku liniach.
Nie akceptuj aktualizacji wielu zależności przy okazji. To zwiększa zakres regresji. Jeżeli aktualizacja jest konieczna, opisz powód i testy zależne.
Uruchom skanowanie podatności i statyczne analizy zgodnie z projektem. GitHub zaleca automatyzację lint, bezpieczeństwa i pokrycia. Narzędzia wspierają odbiór, ale nie rozumieją twojej reguły biznesowej.
Wydajność i koszt procesu
Sprawdź nowe żądania, pętle, renderowanie, rozmiar danych i pracę w tle. Kod może działać poprawnie przy jednym przypadku i zwalniać przy rzeczywistym wolumenie. Zmierz zależny proces, nie całą aplikację bez potrzeby.
Przy AI oceń liczbę wywołań, kontekst i ponowienia. Model może być wywoływany kilka razy bez zmiany wyniku. To zwiększa koszt i opóźnienie.
Nie optymalizuj na podstawie zgadywania. Porównaj przed i po na tym samym zestawie. Zapisz warunki i wersję pomiaru. Drobna poprawka nie musi mieć pełnego benchmarku, ale krytyczna ścieżka wymaga danych.
Utrzymanie i czytelność decyzji
Zapytaj, czy nowa osoba zrozumie, dlaczego kod istnieje i jak go zmienić. Złożona abstrakcja dla jednego przypadku może kosztować więcej niż prostszy wariant. Nie chodzi o gust, tylko o koszt przyszłej pracy.
Sprawdź nazwy, odpowiedzialność, zależności i komentarze. Komentarz nie powinien powtarzać kodu ani opisywać nieprawdziwych założeń. Dokumentuj warunki i ograniczenia.
Jeżeli agent dodaje nowy wzorzec, porównaj z istniejącymi. Może projekt już ma sposób obsługi błędów lub danych. Jednolitość ułatwia odbiór i testy.
Test dostępności i rzeczywistego zachowania
Przy interfejsie wykonaj zadanie klawiaturą, na telefonie i z ograniczeniem ruchu. Sprawdź fokus, etykiety, komunikaty i brak overflow. Zrzut nie wystarcza.
Otwórz wdrożoną aplikację w docelowym kanale i z właściwymi uprawnieniami. Dla strony publicznej sprawdź także dostęp bez logowania. Gdy wynik zależy od pamięci podręcznej, sprawdź aktualną wersję oraz zachowanie z cache i bez niego. Wykonaj przypadek z briefu oraz jeden kontrolny. Deployment nie jest dowodem działania, a zielony build nie potwierdza skutku dla użytkownika.
Przy formularzach i publikacjach łączy się to z analizą formularza zgłoszeń. Odbiór obejmuje docelowy rekord, nie tylko interfejs.
Przykład: poprawka prostego eksportu
Agent dodaje eksport CSV i testuje jedną nazwę. Kod wygląda dobrze. Przy polskich znakach Excel otwiera błędne znaki, a przy ponowieniu tworzy dwa pliki. Testy nie obejmowały kodowania ani skutku.
Dodajesz przypadki kodowania, długiego opisu i ponowienia. Odbiór porównuje zawartość pliku, liczbę eksportów i nagłówki. Zmiana jest mała, ale ryzyko konkretne.
Po poprawce możesz zacząć od zależnych eksportów i kontrolnego formatu. Zakres dalszej regresji zależy od ryzyka, mapy zależności i rzeczywistego pokrycia. Mniejszy zestaw nie daje automatycznie takiej samej pewności jak pełny.
Kiedy odrzucić kod
Odrzuć przy niejasnym skutku, złym zakresie, nowych uprawnieniach bez decyzji, braku testów krytycznych i kodzie, którego zespół nie potrafi utrzymać. Nie akceptuj dla tempa.
Nie wymagaj automatycznej nowej wersji od agenta bez oceny przyczyny. Może brief jest zły albo źródło sprzeczne. Popraw proces przed kolejnym generowaniem.
Przy częściowo dobrej pracy możesz zachować ograniczony fragment, ale zapisz decyzję. Nie przepisuj całego projektu tylko dlatego, że agent już wygenerował kod.
Karta odbioru przed publikacją
Zapisz zakres, krytyczne decyzje, testy, skanowanie, ograniczenia i wersję. Dodaj właściciela i plan rollbacku. Nie przepisuj pełnego diffu; wskaż najważniejsze dowody.
Po wdrożeniu sprawdź logi i rzeczywisty wynik. Nowe błędy dodaj do testów. Odbiór kończy się po potwierdzeniu skutku, nie po kliknięciu merge.
Jak czytać testy wygenerowane przez agenta
Sprawdź, czy testy nie potwierdzają tylko implementacji zamiast wymagania. Test opisany jako „zwraca poprawny status” może powtarzać błędny status wybrany przez agenta. Porównaj z briefem i kontraktem zamiast ufać nazwie.
Dodaj niezależny przypadek z oczekiwanym wynikiem zapisanym przed kodem. Przy logice biznesowej poproś właściciela procesu o potwierdzenie. Testy powinny opisywać decyzję i skutek, a nie tylko uruchamiać funkcję.
Przy mutacji kodu możesz celowo zmienić jeden warunek w środowisku testowym i zobaczyć, czy test go wykrywa. To prosty sposób oceny wartości zestawu. Nie wykonuj takich zmian na produkcji ani nie uznawaj samego pokrycia za dowód jakości.
Odbiór zmiany infrastruktury i konfiguracji
Sprawdź nie tylko kod, ale także zmienne środowiskowe, uprawnienia, limity, DNS, migracje i ustawienia deploymentu. Agent może zmienić konfigurację bez dużego diffu kodu, a skutek będzie większy. Odbiór powinien objąć wszystkie zmienione zasoby.
Nie wypisuj wartości sekretów w raporcie. Zapisz nazwy zmienionych ustawień i właścicieli. Porównaj z wersją poprzednią bez ujawniania zawartości.
Przy zmianie środowiska wykonaj rzeczywisty test po wdrożeniu. Lokalny sukces nie potwierdza konfiguracji produkcji. Sprawdź także, czy rollback zachowuje wymagane sekrety i zależności.
Odbiór przez osobę mniej zaawansowaną
Nowa osoba powinna umieć wskazać, co kod robi i jak bezpiecznie go zmienić. Nie wymagaj od niej znajomości każdej biblioteki, ale kluczowych decyzji i ograniczeń. Jeżeli wyjaśnienie wymaga autora przy każdym kroku, dokumentacja lub kod jest zbyt zawiły.
Nie używaj tego jako oceny juniora. To test utrzymania systemu. Zapisz pytania i dodaj wyjaśnienia przy konkretnych decyzjach. Nie dokładaj komentarzy do każdej linii.
Przy przekazaniu właściciela wykonaj krótki przegląd zależny. To ogranicza wiedzę dostępną tylko w kontekście agenta i autora briefu.
Przy kolejnych zmianach zachowaj kartę odbioru jako mały rejestr decyzji. Wpisz, które ryzyka były zaakceptowane i dlaczego. Jeżeli nowy błąd dotyczy tego samego warunku, wróć do niego zamiast dodawać łatkę bez analizy.
Nie wymagaj pełnego audytu każdej drobnej poprawki. Dobierz głębokość do skutku i zakresu. Drobna literówka wymaga innego odbioru niż nowa integracja. Dokument powinien pokazywać tę proporcję, aby zespół nie omijał procesu dla prostych zadań.
Po publikacji oceń, czy testy wykryłyby wcześniejszy problem. Jeżeli nie, dodaj konkretny przypadek i powtórz zależny zestaw. Nie zwiększaj automatycznie całego pakietu testów dla każdej awarii; wybierz ryzyko, które rzeczywiście trzeba kontrolować.
Przy kolejnym odbiorze porównaj czas i zakres pracy z poprzednim. Jeżeli agent generuje coraz większe zmiany przy podobnych zadaniach, ogranicz brief i uprawnienia. Nie akceptuj wzrostu złożoności jako standardu.
Zachowaj listę odrzuconych rozwiązań i powodów. To ogranicza powtarzanie tych samych propozycji przy kolejnych promptach. Decyzje powinny być dostępne dla nowej osoby, a nie tylko w historii pull requestów.
Przy zakończeniu zadania usuń konta testowe i niepotrzebne tokeny. Sprawdź, czy dane testowe nie trafiły do analityki ani raportów sprzedaży. Odbiór obejmuje również porządek po pracy.
Przy kolejnej wersji agenta powtórz mały zestaw krytyczny zanim zwiększysz zakres. Nowy model może zmieniać decyzje i styl kodu. Nie przenoś akceptacji starej konfiguracji bez dowodu.
Zapisz, kto jest właścicielem procesu, jakie testy są wymagane i kto uruchamia je po zmianie. Automatyzacja odbioru bez właściciela tworzy zielone raporty, ale nie rozstrzyga wyjątków.
Aeneia Audit pomaga ograniczyć ryzyko procesu. Przy pracy z agentami pomocny jest przewodnik Aeneia Signal o odbiorze kodu.
Wybierz zmianę o największym skutku i poproś inną osobę o wyjaśnienie, jak działa oraz jak ją przetestować. Niejasność w odpowiedzi wskazuje miejsce do poprawy kodu lub dokumentacji.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
