AI agentowa potrzebuje więcej testerów, a nie mniej

AI agentowa zmienia sposób, w jaki powstaje i jest wdrażane oprogramowanie. Asystenci przygotowują pull requesty, agenci otwierają migracje, a boty recenzujące zapewniają, że zmiana jest bezpieczna, zanim człowiek zdąży dopić kawę. Branża często przedstawia to jako drogę do zmniejszenia liczby osób zajmujących się jakością. To odwrócenie właściwej perspektywy. Gdy maszyny tworzą coraz większą część bazy kodu, rzadką umiejętnością nie jest generowanie. Jest nią niezależna weryfikacja.

W ankiecie Stack Overflow dla deweloperów z 2025 roku 84% respondentów zadeklarowało, że korzysta z narzędzi AI w procesie tworzenia oprogramowania lub planuje z nich korzystać, a 51% profesjonalnych deweloperów używa ich codziennie. Odsetek pozytywnych opinii spadł do 60%, a więcej deweloperów aktywnie nie ufa dokładności AI (46%), niż jej ufa (33%). Najczęściej wskazywaną frustracją, wymienioną przez 66% respondentów, były rozwiązania niemal poprawne, ale jednak nie do końca. Z badań DORA opublikowanych w 2025 roku przez Google Cloud wynika, że z AI korzystało 90% specjalistów zajmujących się tworzeniem oprogramowania, a ponad 80% twierdziło, że AI poprawiła ich produktywność. Tylko 24% deklarowało jednak duże lub bardzo duże zaufanie do AI. Przydatność bez zaufania to właśnie sytuacja, która poszerza zakres pracy testera, a nie go ogranicza.

Szybkość nie jest dowodem

Pracuję jako inżynier jakości oprogramowania i specjalizuję się w testowaniu systemów agentowych oraz bramkach CI dla kodu tworzonego przez AI. W naszym zespole wdrożyliśmy narzędzie do recenzowania pull requestów i generator przypadków testowych. Oba służą do przygotowywania wersji roboczych. Żadne nie ocenia własnej pracy. Ta zasada jest ważna, ponieważ agenci wypowiadają się z pewnością siebie. Pewność siebie nie oznacza poprawności.

Przekonaliśmy się o tym w kosztowny sposób. Podczas pilotażu narzędzia do recenzowania pull requestów stworzonego przez AI jedna zmiana przeszła CI w mniej niż 4 minuty. Dwa dni później na dalszym etapie pulpit nawigacyjny wyświetlił niemożliwe temperatury. Na jednej ze ścieżek kodu, której zestaw testów nigdy nie obejmował, doszło do odwrócenia przelicznika ze skali Celsjusza na Fahrenheita. Potok CI świecił na zielono. Produkt działał nieprawidłowo. Zielony status CI, który nie wynika z zadania trudnego pytania, to teatr.

Ten incydent wpisuje się w szerszy schemat. W raporcie CodeRabbit Porównanie generowania kodu przez AI i ludzi przeanalizowano 470 otwartych pull requestów w serwisie GitHub dotyczących oprogramowania open source (320 utworzonych wspólnie przez AI i ludzi, 150 wyłącznie przez ludzi). Zmiany tworzone przez AI wiązały się ogółem z około 1,7 raza większą liczbą problemów; błędy logiki i poprawności występowały o 75% częściej, a liczba ustaleń dotyczących bezpieczeństwa była nawet 2,74 raza większa. W raporcie Veracode z 2026 roku Bezpieczeństwo kodu generowanego przez GenAI przetestowano modele pod kątem zadań związanych z bezpieczeństwem. Średni odsetek pomyślnych wyników testów bezpieczeństwa wyniósł 56% — niewiele więcej niż 55% w poprzednim raporcie — a około 44% zadań polegających na generowaniu kodu przez AI prowadziło do wprowadzenia znanej podatności. Składnia jest niemal rozwiązanym problemem. Bezpieczne i poprawne działanie — nie. Testerzy nie pozwalają pomylić tych dwóch rzeczy.

Zmyślone zależności to problem wymagający testów

Generowanie kodu prowadzi też do wymyślania zależności. W badaniu USENIX Security 2025 Mamy dla ciebie pakiet! oceniono zmyślanie nazw pakietów przez 16 dużych modeli językowych generujących kod na podstawie 576 000 próbek. Modele komercyjne zmyślały pakiety średnio w co najmniej 5,2% przypadków, a średni wynik modeli open source wyniósł 21,7%; łącznie wygenerowały 205 474 unikalne zmyślone nazwy. Trwałe istnienie takich widmowych pakietów stwarza gotową okazję do ataku typu slopsquatting: atakujący rejestrują wymyśloną nazwę i czekają, aż deweloper lub agent zainstaluje pakiet.

Kontrole pochodzenia zależności powinny być traktowane na równi z testami funkcjonalnymi. Jeśli agent wymyśli pakiet NuGet lub npm, proces scalania powinien zakończyć się niepowodzeniem, zanim ktokolwiek zacznie dyskutować o tym, czy testy jednostkowe były wystarczająco dokładne. Weryfikacja pochodzenia to nie opcjonalna dobra praktyka. To bramka jakości dla zmian tworzonych przez AI.

Bramki, które skalują się wraz z liczbą agentów

Gdy przy użyciu automatyzacji wspomaganej przez AI przeprowadziliśmy w całej organizacji aktualizację z .NET 8 do .NET 10 w około dwa tygodnie, odpowiadałem za bramki jakości. Szybkość była realna. Równie realna była potrzeba stosowania kontroli, które nie ufają podsumowaniom agenta. Kontrole, które stosuję do zmienionego kodu, obejmują:

• Docelowy wynik testów mutacyjnych w przedziale od 60% do 70% dla zmienionej logiki, tak aby zestaw testów wykrywał rzeczywiste mutanty, a nie tylko obejmował linie kodu
• Testy oparte na właściwościach dla logiki wysokiego ryzyka, w przypadku której same przykłady nie określają zachowania w wystarczającym stopniu
• Kontrole pochodzenia zależności chroniące przed slopsquattingiem i zmyślonymi pakietami
• Sygnały duplikacji i nadmiernych zmian w kodzie, które pozwalają wykrywać chaotyczne kopiowanie i wklejanie przez agentów
• Niezależna weryfikacja twierdzeń agenta, takich jak „migracja zakończona”, ponieważ każde twierdzenie pozostaje hipotezą, dopóki nie pojawią się dowody

Wynik testów mutacyjnych nie jest wskaźnikiem na pokaz. Informuje, czy testy wykryją celowo wprowadzony błąd. Pokrycie kodu może wzrosnąć, a zestaw testów i tak może nie objąć ścieżki przeliczania temperatury w skali Celsjusza. Testy oparte na właściwościach sprawdzają, czy model systemu działa w całym zakresie wartości, a nie tylko w jednym idealnym scenariuszu. Weryfikacja pochodzenia zamyka furtkę dla podejrzanych pakietów. Kontrole nadmiernych zmian i duplikacji wychwytują nawyk agenta polegający na przepisywaniu tego samego pomysłu na trzy sposoby. Razem tworzą określone podejście: zakładamy, że agent się myli, dopóki zestaw testów nie dowiedzie czegoś innego. Tę zasadę przypominam podczas przeglądu kodu.

Żadne z tych rozwiązań nie zastępuje testowania API, testowania uwierzytelniania, testów dymnych ani automatyzacji testów interfejsu użytkownika. FlaUI i PowerShell nadal wychwytują problemy, których nie wykrywają testy API. Pakowanie za pomocą NuGet, MSI i MSM nadal wymaga weryfikacji instalacji oraz trybu cichego. Przepływy pracy z udziałem agentów zwiększają skalę działań. Nie sprawiają jednak, że te obszary przestają być potrzebne.

Więcej testerów, inna praca

Obawa polega na tym, że agenci będą pisać testy, a ludzie staną się zbędni. Agenci mogą przygotowywać przypadki testowe, ale nie powinni zatwierdzać własnych projektów. Respondenci Stack Overflow planujący przyszłe wykorzystanie AI do testowania wciąż wskazywali nieufność ludzi jako jeden z głównych czynników: najczęstszym powodem, dla którego zwróciliby się o pomoc do innej osoby, był brak zaufania do odpowiedzi AI. Ta intuicja jest atutem całej branży.

Ważne jest, by zatrudniać i wspierać osoby, które obrały nietradycyjne ścieżki kariery. Moja droga zawodowa do obszaru jakości wiodła przez pracę w operacjach HR i przy danych; w maju 2024 r. ukończyłem studia magisterskie z systemów informacyjnych na UMBC, a teraz na co dzień sprawiam, że bramki dla systemów agentowych stają się praktyczne. Agentowa AI nie będzie czekać na osoby o jednym, ściśle określonym profilu zawodowym. Potrzebuje więcej ludzi, którzy potrafią projektować metody gromadzenia dowodów, a nie mniej osób, które bezrefleksyjnie zatwierdzają kompilacje zakończone powodzeniem.

Pytanie dotyczące produktu jest proste. Jeśli agenci wdrażają zmiany szybciej, niż weryfikacja jest w stanie je ocenić, nie oznacza to wzrostu produktywności. Oznacza to odłożony w czasie incydent. Inwestuj w testerów, którzy podchodzą podejrzliwie do każdego twierdzenia agenta, uwzględniają testy mutacyjne i śledzenie pochodzenia w CI oraz zachowują niezależny osąd tam, gdzie model jest najbardziej elokwentny, a zarazem najmniej wiarygodny. Agentowa AI potrzebuje więcej testerów, a nie mniej.