Copilot podpowiada mi kod kilkadziesiąt razy dziennie. Agent w Cursorze potrafi jednym zadaniem zmienić dziesięć plików. Oba strumienie weryfikuję przed merge, bo autorzy analizy 470 pull requestów z GitHuba (grudzień 2025) policzyli w kodzie współtworzonym z AI około 1,7 raza więcej poważnych problemów i o 75% więcej błędów konfiguracji niż w pisanym ręcznie. Poniżej opisuję, jak sprawdzić kod z Copilota i Cursora, zanim trafi na produkcję: dwa tryby review, checklista pięciu pytań, trzy metryki i testy jako ostatnia warstwa ochrony.
Czym różni się weryfikacja sugestii Copilota od diffa z Cursora?
Skalą i głębokością review. Sugestię inline z Copilota sprawdzam w locie: kilka linii w pliku, który mam otwarty, kontekst trzymam w głowie, decyzja zapada w kilkanaście sekund. Wieloplikowy diff od agenta Cursora czytam jak pull request od nowej osoby w zespole: w całości, plik po pliku, bez kredytu zaufania.
Przy sugestiach inline ryzykiem jest odruch. Po dwóch godzinach pracy tab i enter wchodzą w krew, więc łapię się na przyjmowaniu fragmentów, których rano bym nie przepuścił. Pomaga jedna reguła: akceptuję wyłącznie kod, który sam bym napisał, tylko wolniej. Przy diffie agenta ryzykiem jest zasięg, bo Cursor potrafi przy okazji „poprawić” plik, o który nikt nie prosił. Przegląd zaczynam więc od listy zmienionych plików i najpierw czytam te spoza zakresu zadania. Na review diffu agenta rezerwuję tyle czasu, ile na pull request tej wielkości od człowieka; przyspieszenie ma pochodzić z generowania, a nie z pobieżnego czytania. Jak taka sesja wygląda krok po kroku, opisałem w tekście o debugowaniu z Cursorem.
Jak wygląda checklista weryfikacji kodu z AI?
Pięć pytań zadawanych przy każdym diffie z asystenta. Przy odpowiedzi „nie” na dowolne z nich cofam kod do poprawki, niezależnie od tego, jak schludnie całość wygląda. Checklistę trzymam w szablonie opisu pull requesta, żeby autor odhaczał ją przed wysłaniem do review.
- Czy rozumiem każdą linię? Fragmentu, którego nie umiem wyjaśnić drugiej osobie z zespołu, nie scalam: przepisuję go albo proszę asystenta o prostszą wersję. Niezrozumiany kod wraca przy pierwszej awarii, wtedy już pod presją czasu.
- Czy każda zależność istnieje i jest utrzymywana? Modele podpowiadają czasem importy pakietów, których nie ma w rejestrze, a atakujący publikują pod takimi nazwami złośliwy kod. Sprawdzam datę publikacji, liczbę pobrań i opiekuna pakietu; mechanizm ataku omówiłem w tekście czy kod z AI jest bezpieczny.
- Czy błędy i edge case’y są obsłużone? Asystent domyślnie pisze happy path. Sprawdzam puste wejście, null, timeout zewnętrznego API i równoległe wywołania, bo tych gałęzi w wygenerowanym kodzie brakuje najczęściej.
- Czy kod trzyma się konwencji repozytorium? Model proponuje wzorce ze swoich danych treningowych, nie z naszego projektu. Szukam zdublowanych helperów, obcego stylu obsługi błędów i nazewnictwa niepasującego do reszty modułu.
- Czy jest test? Nowa logika bez testu nie przechodzi, także wtedy, gdy test wygenerował ten sam asystent. Wygenerowany test czytam pod jednym kątem: czy sprawdza zachowanie, czy tylko utrwala bieżącą implementację.
Jakie metryki mówią, czy AI pomaga, czy szkodzi?
Trzy: odsetek sugestii przyjętych bez poprawek, defect rate kodu z AI na tle pisanego ręcznie oraz churn po merge, czyli jak często scalony kod wraca do poprawki. Zbieram je przez co najmniej miesiąc, bo pojedynczy sprint daje za mało danych do decyzji.
Po odsetku sugestii przyjętych bez poprawek (precision) oceniam, jak dobrze asystent trafia w kontekst projektu; niska wartość to sygnał, żeby dopracować reguły i przykłady w repozytorium, a nie generować więcej. Defect rate porównuję po oznaczeniu pull requestów etykietą ai-assisted: błędy wracające z produkcji liczę osobno dla kodu z etykietą i bez niej. Churn mierzę jako odsetek linii zmienionych ponownie w ciągu trzech tygodni od merge. Jeśli kod z AI wraca do poprawki częściej niż pisany ręcznie, zespół scala rzeczy, których jeszcze nie rozumie, i wtedy dokręcam review zamiast ograniczać narzędzie. Na start wystarczą etykieta w repozytorium i prosty dashboard; raz w miesiącu pokazuję te liczby zespołowi, bo bez nich dyskusja o AI kończy się wymianą anegdot.
Jak testy chronią przed błędami z AI?
Testy krytycznych ścieżek pełnią rolę siatki bezpieczeństwa, w której błąd z wygenerowanego kodu zatrzymuje się w CI zamiast na produkcji. Kolejność ma u mnie jedną zasadę: pokrycie logowania, płatności i uprawnień powstaje, zanim zespół przyspieszy generowanie, bo review przepuszcza pojedyncze pomyłki nawet przy dobrej dyscyplinie.
Drugi element to bramka w CI. Merge blokuje automat, gdy testy nie przechodzą albo pokrycie krytycznego modułu spada, więc przeoczenie z review kończy się tanią poprawką na branchu. Ten sam błąd znaleziony na produkcji kosztuje debugowanie, hotfix i rozmowę z klientem. W zespołach, które dopiero budują pokrycie, zawężam bramkę do modułów krytycznych, żeby nie blokować całej pracy od pierwszego dnia. Zespół, który generuje kod szybciej, niż go testuje, odkłada tę różnicę w koszcie na pierwszy poważny incydent.
Jak pomagam w QA Sensei
Od 20 lat pracuję w IT, od siedmiu jako inżynier jakości, a proces z tego tekstu stosuję codziennie na własnym kodzie z Copilota i Cursora. W QA Sensei robię Bilans Jakości: przegląd projektu, po którym zespół wie, gdzie kod z AI omija weryfikację, które metryki zbierać od przyszłego sprintu i jakie testy postawić najpierw. Pracuję zdalnie w całej Polsce, a w okolicach Wrocławia także u klienta.