Zespoły, z którymi pracuję, piszą dziś sporą część kodu z Copilotem albo Cursorem. Presja jest zrozumiała: asystent generuje w minutę to, co człowiek pisałby godzinę. Pytanie od founderów i CTO wraca w podobnym brzmieniu, czy ten kod można spokojnie wypuścić na produkcję? Odpowiadam danymi i procesem, bo na tej decyzji wisi realny budżet: po jednej stronie tempo developmentu, po drugiej koszt incydentu.
Czy kod generowany przez AI ma więcej błędów?
Tak. Analiza 470 pull requestów z GitHuba opublikowana w grudniu 2025 pokazała, że kod współtworzony z AI zawiera około 1,7 raza więcej poważnych problemów niż kod pisany bez asystenta, w tym więcej podatności bezpieczeństwa, a błędów konfiguracji, o 75% więcej. Te liczby czytam jako rachunek za pominiętą weryfikację, a nie jako powód, żeby wyłączyć asystenty.
Mechanizm jest prozaiczny. Model generuje kod, który wygląda poprawnie: składnia i idiomy się zgadzają, więc czytający traci czujność. Do tego dochodzi autor, który tego kodu nie napisał ręcznie i zna go płycej, niż mu się wydaje. Podczas pracy z nowym zespołem robię prosty test: proszę autora, żeby wyjaśnił fragment wygenerowany tydzień wcześniej. Rzadko potrafi od ręki.
Czym jest slopsquatting?
Slopsquatting to atak, w którym ktoś rejestruje złośliwy pakiet pod nazwą biblioteki wymyśloną przez model AI. Modele podpowiadają czasem importy pakietów, które nie istnieją; te zmyślone nazwy powtarzają się między sesjami i między modelami, więc atakujący może je zebrać i opublikować pod nimi własny kod w npm czy PyPI. Deweloper, który instaluje podpowiedziany pakiet bez sprawdzenia, wpuszcza obcy kod do swojego łańcucha dostaw.
Obrona kosztuje niewiele. Każdą nową zależność sprawdzam przed instalacją: od kiedy pakiet istnieje, ile ma pobrań, kto go utrzymuje. W CI działa skan zależności (npm audit, osv-scanner albo odpowiednik dla danego ekosystemu), a wersje trzyma lockfile. Te trzy nawyki zamykają wektor, który w zespole kodującym „na słowo” asystenta stoi otworem.
Jakie guardraile ustawić dla kodu z AI?
Cztery, w tej kolejności: code review każdego diffa z AI, testy automatyczne krytycznych ścieżek, bramka jakościowa w CI blokująca merge przy regresji i skan zależności. Wdrożenie całości w małym zespole zajmuje tydzień, może dwa. Koszt jest jednorazowy, a ochrona działa przy każdym kolejnym pull requeście.
- Code review bez taryfy ulgowej. Diff z AI przeglądam jak pull request od nowej osoby w zespole, bez kredytu zaufania. Cursor i Copilot pokazują zmiany jako diff właśnie po to, żeby akceptacja była decyzją, a nie odruchem. Jak to wygląda u mnie w praktyce, opisałem w tekście o debugowaniu z Cursorem.
- Testy krytycznych ścieżek, zanim zespół przyspieszy. Siatka bezpieczeństwa musi wisieć, zanim akrobata wejdzie na linę. Logowanie, płatności, uprawnienia: te przepływy pokrywam testami w pierwszej kolejności, bo tam błąd z wygenerowanego kodu kosztuje najwięcej.
- Bramka jakościowa w CI. Merge blokuje automat, a nie dobra wola: testy muszą przejść, metryki nie mogą się pogorszyć. Jak zbudować taką bramkę, pokazuję na przykładzie testów wydajnościowych w tekście o k6 i Jenkinsie.
- Skan zależności przy każdym PR. Automatyczny, z blokadą na znane podatności i alertem przy nowym pakiecie. Zamyka slopsquatting i większość problemów łańcucha dostaw.
Czy da się bezpiecznie przyspieszać development z AI?
Tak, pod warunkiem że tempo weryfikacji rośnie razem z tempem generowania. Zespoły, które trzymają review, testy i bramkę CI, dostają przyspieszenie bez wzrostu liczby incydentów. Zespoły akceptujące sugestie hurtem oddają różnicę z nawiązką na produkcji, gdzie debugowanie kosztuje najwięcej.
U klientów zaczynam od pomiaru dwóch liczb: ile sugestii asystenta przechodzi review bez poprawek i ile błędów z wygenerowanego kodu wraca z produkcji. Te dwie wartości mówią, czy AI w zespole przyspiesza pracę, czy tylko przesuwa koszt na później. Dopiero na nich opieram decyzję, gdzie proces poluzować, a gdzie dokręcić.
Jak pomagam w QA Sensei
Od 20 lat pracuję w IT, od siedmiu jako inżynier jakości, a z asystentami AI koduję codziennie, więc widzę i tempo, i wpadki. W QA Sensei robię Bilans Jakości: przegląd projektu, który pokazuje, gdzie kod z AI wchodzi do repozytorium bez siatki i które guardraile ustawić najpierw, z planem wdrożenia, nie samą diagnozą. Pracuję zdalnie w całej Polsce, a w okolicach Wrocławia także u klienta.
Jak w praktyce ułożyć jakość i bezpieczeństwo takiego kodu na produkcji, opisuję na stronie QA dla kodu tworzonego z AI.