Jak przeglądać kod wygenerowany przez AI

Aby przejrzeć kod wygenerowany przez AI, zacznij od tego, co się zmieniło — które pliki i dlaczego — a potem przetestuj działanie samodzielnie, zanim przeczytasz choćby jedną linię kodu. Następnie sprawdź obszary, w których kod AI najczęściej zawodzi: brakujące sprawdzenia uprawnień po stronie serwera, sekrety wystawione przeglądarce, niewalidowane dane wejściowe, pakiety lub funkcje, które nie istnieją, oraz edycje rzeczy, których nigdy nie prosiłeś o ruszanie.

AI pisze kod, który zwykle działa i często wygląda schludnie. To sprawia, że łatwo go zatwierdzić bez prawdziwego sprawdzenia. Ten przewodnik to procedura przeglądu, która działa, czy czytasz kod płynnie, czy wcale.

Dopasuj przegląd do ryzyka

Nie każda zmiana wymaga tej samej uwagi.

Krok 1: Zobacz, co się zmieniło

Zanim ocenisz kod, zdobądź listę zmian:

• Jeśli projekt jest w Git, spójrz na diff: pliki i linie zmienione od ostatniego commita. Zobacz jak używać Git w aplikacji zbudowanej przez AI.
• Albo zapytaj AI wprost:

Wypisz każdy plik, który zmieniłeś w ostatniej zmianie, i dla każdego wyjaśnij w jednym zdaniu, co się zmieniło i dlaczego.

Czerwone flagi na tym etapie: pliki niezwiązane z prośbą, usunięte pliki, zmiany w konfiguracji lub zależnościach, o które nie prosiłeś.

Krok 2: Najpierw przetestuj działanie

Czytanie kodu mówi, co ma robić; testowanie mówi, co faktycznie robi. Zanim zaczniesz czytać:

• Wypróbuj zmianę jako zwykły użytkownik, na komputerze i na ekranie wielkości telefonu.
• Wypróbuj ją z błędnymi danymi: puste pola, bardzo długi tekst, liczby ujemne, data z przeszłości.
• Wypróbuj ją wylogowany i jako inny użytkownik.
• Powtórz najważniejsze przepływy: rejestracja, logowanie, główna akcja, płatność.

Jeśli test się nie powiedzie, oszczędziłeś sobie czasu na czytanie — zgłoś to jasno i pozwól AI to naprawić. Zobacz jak napisać dobry raport o błędzie.

Krok 3: Sprawdź uprawnienia po stronie serwera

Najważniejsza rzecz do sprawdzenia. Narzędzia AI często ukrywają przycisk na stronie, ale zostawiają serwer gotowy wykonać akcję dla każdego, kto o to poprosi.

Dla każdej trasy lub funkcji, która odczytuje lub zmienia dane, zapytaj:

• Czy sprawdza, że użytkownik jest zalogowany?
• Czy sprawdza, że ten użytkownik ma prawo dostępu do tego rekordu?
• Czy to sprawdzenie działa na serwerze, a nie tylko na stronie?

Dla każdej trasy API, którą dodałeś lub zmieniłeś, powiedz, jakie sprawdzenie uprawnień wykonuje na serwerze, cytując linię. Oznacz każdą trasę bez takiego sprawdzenia.

Potem to przetestuj: zaloguj się jako użytkownik A, zapamiętaj ID rekordu, zaloguj się jako użytkownik B i spróbuj go pobrać. Pełny test znajdziesz w liście kontrolnej bezpieczeństwa dla aplikacji zbudowanych przez AI.

Krok 4: Szukaj wyciekłych sekretów

• Przeszukaj zmienione pliki pod kątem wszystkiego, co wygląda na klucz lub hasło.
• Sprawdź, czy sekretne klucze są odczytywane ze zmiennych środowiskowych i używane tylko w kodzie serwera.
• Uważaj na publiczne prefiksy, takie jak VITE_ lub NEXT_PUBLIC_, przy zmiennych sekretnych — trafiają one wprost do kodu przeglądarki.

Zobacz jak chronić klucze API.

Krok 5: Sprawdź dane wejściowe i błędy

• Walidacja po stronie serwera. Sprawdzenia w przeglądarce można pominąć. Wymagane pola, długości, formaty i dozwolone wartości powinien sprawdzać także serwer.
• Zapytania do bazy używają parametrów, a nie tekstu składanego z danych wejściowych użytkownika.
• Błędy nie są połykane. Blok try/catch, który nic nie robi, ukrywa awarie. Błędy powinny być logowane, a użytkownicy powinni widzieć prosty komunikat.
• Brak szczegółów wewnętrznych dla użytkowników — ślady stosu i błędy bazy danych należą do logów.

Krok 6: Sprawdź, czy to prawdziwe

Modele AI czasem tworzą kod, który wygląda poprawnie, ale odwołuje się do rzeczy, które nie istnieją.

• Pakiety: każda nowa zależność powinna być prawdziwym, utrzymywanym pakietem o dokładnie tej nazwie. Uważaj na nazwy wyglądające na literówki popularnych pakietów.
• Funkcje i opcje API: jeśli kod wywołuje funkcję biblioteki lub opcję zewnętrznego API, której nigdy nie widziałeś, sprawdź oficjalną dokumentację.
• Kod zastępczy: szukaj TODO, mock, fake, zakodowanych na sztywno danych przykładowych lub funkcji zwracających stałą wartość.

Czy dodałeś nowe pakiety? Dla każdego podaj dokładną nazwę, do czego służy i czy da się bez niego obejść.

Krok 7: Sprawdź, czy pasuje

Kod może działać i mimo to utrudniać późniejsze zmiany w aplikacji:

• Duplikacja. Ta sama logika skopiowana w kilku miejscach rozjedzie się.
• Spójność. Powinien trzymać się wzorców, których używa reszta aplikacji.
• Rozmiar. Prośba na 20 linii, która wygenerowała 600 linii, zasługuje na pytanie.
• Martwy kod. Stare wersje pozostawione obok nowych.

Czy po tej zmianie jest w projekcie kod, który jest już nieużywany, albo logika zduplikowana gdzie indziej? Niczego nie zmieniaj; po prostu wypisz.

Częste błędy

• Zatwierdzanie, bo wygląda czysto. Schludny kod nadal może pominąć sprawdzenie uprawnień.
• Czytanie zamiast testowania. Najpierw testuj; czytaj potem.
• Testowanie tylko szczęśliwej ścieżki. Wypróbuj złe dane, złego użytkownika i stan wylogowania.
• Ignorowanie niezwiązanych zmian w plikach. Pytaj, dlaczego zmieniły się wszystkie pliki.
• Ufanie samoocenie w 100%. Traktuj przegląd AI jako pierwsze podejście i potwierdzaj testami.
• Przeglądanie tygodnia zmian naraz. Przeglądaj małe zmiany na bieżąco.

Lista kontrolna

• Wiem, które pliki się zmieniły i dlaczego, i nic niezwiązanego się nie zmieniło.
• Zmiana działa na komputerze i na telefonie, przy złych danych, wylogowany i jako inny użytkownik.
• Każda trasa danych sprawdza logowanie i własność po stronie serwera.
• Brak sekretów w kodzie i w paczkach przeglądarki.
• Dane wejściowe są walidowane na serwerze; zapytania używają parametrów.
• Błędy są logowane, a nie połykane, i nie są szczegółowo pokazywane użytkownikom.
• Nowe pakiety są prawdziwe i potrzebne; nie zostały wymyślone funkcje ani kod zastępczy.
• Zmiany wysokiego ryzyka zostały uważnie przeczytane i, gdzie trzeba, przejrzane przez drugą osobę.

Przegląd kodu w Mythex

• Tryb Ask odpowiada na pytania o kod bez jego edycji — idealny do próśb w stylu „wyjaśnij każdą zmianę” i „które trasy nie mają sprawdzenia uprawnień”. Zobacz Czat.
• Widok kodu pokazuje drzewo plików, edytor i terminal w każdym planie (tylko do odczytu w Free, edytowalny w Pro), dzięki czemu sam możesz przeczytać, co się zmieniło. Zobacz Edytor kodu.
• /test każe agentowi przeklikać podgląd jako użytkownik i zgłosić zepsute przepływy.
• Checkpointy pozwalają cofnąć zmianę, która nie przechodzi przeglądu.

Jeśli przegląd robi za Ciebie programista, jak współpracować z programistą przy aplikacji zbudowanej przez AI opisuje przekazanie pracy; jeśli przegląd wykryje błąd, zobacz jak debugować aplikację zbudowaną przez AI.

Pytania