Drożejące AI w pracy testera

Przez długi czas korzystanie z AI do pisania testów automatycznych wyglądało jak usługa z niemal nieograniczonym limitem. Subskrypcja za kilkanaście lub kilkadziesiąt dolarów miesięcznie, mocny model pod ręką i można generować kod bez patrzenia na koszt. Niestety, ten etap się skończył.

GitHub Copilot przesuwa rozliczenia w stronę realnego zużycia. Anthropic testował usunięcie Claude Code z najtańszych planów - wycofał się po reakcji użytkowników, ale próba coś ujawniła. To nie seria przypadków, tylko sygnał, że rynek przechodzi od budowania adopcji do porządkowania ekonomii produktu. Dostawcy najpierw chcieli, żebyśmy nauczyli się pracować z AI. Teraz zaczynają sprawdzać, jak wycenić intensywne użycie tak, żeby nie generowało im ciągłej straty.

Dla programistów to temat, który jest szeroko dyskutowany. Dla testerów i QA Engineerów - trochę mniej, a szkoda, bo zmiany dotyczą ich tak samo bezpośrednio. Generowanie testów, analiza kodu, praca agentowa, przeglądanie logów - to wszystko jest intensywnym użyciem AI, które przy nowym modelu rozliczeń zaczyna mieć wymierny koszt.

Dlaczego właśnie teraz warto zmienić nawyki

Zmiana cen jest nieunikniona, ale to nie jedyny powód, żeby zacząć myśleć o tym, jak faktycznie używasz AI. Ważniejszy jest nawyk, który łatwo wyrobić przy nieograniczonym dostępie: pytanie AI o wszystko, domyślnie, bez zastanowienia.

W trybie flat-rate - czyli przy stałej miesięcznej opłacie niezależnej od zużycia - nikt tego nie liczył. Zapytałeś o prostą asercję, poprosiłeś o zmianę selektora, wygenerowałeś boilerplate dla kolejnego page objecta. Każde z tych zadań osobno jest drobnostką, ale razem budują intensywne użycie. Przy rozliczaniu per token - czyli za każdy fragment tekstu wysłany do modelu i otrzymany w odpowiedzi - to zużycie zaczyna być widoczne w raportach.

Dobra wiadomość jest taka, że zmiana nawyków w tym miejscu nie wymaga rezygnacji z AI. Wymaga tylko bardziej świadomego podejścia do tego, kiedy i jak go używasz.

Nie każde zadanie testowe potrzebuje AI

To brzmi banalnie, ale w praktyce jest jedną z trudniejszych zmian. Kiedy AI jest pod ręką, pokusa jest prosta: wrzucam zadanie, dostaję kod, poprawiam jeśli trzeba. Problem w tym, że dla wielu zadań testowych ten proces jest wolniejszy niż napisanie kodu samodzielnie.

Jeśli znasz dobrze swój projekt, wiesz gdzie leżą selektory, rozumiesz strukturę Page Object Model - czyli wzorca organizacji kodu testowego, który grupuje elementy strony i operacje na nich w osobnych klasach - to dodanie prostej asercji zajmuje ci trzydzieści sekund. Zapytanie AI, poczekanie na odpowiedź, przejrzenie outputu i ewentualna korekta zajmuje znacznie więcej. AI dokłada krok do procesu zamiast go skracać.

Pytanie, które warto sobie zadać przed każdym zapytaniem, brzmi nie "czy AI to zrobi", ale "czy warto tu w ogóle pytać AI". W dobrze znanych komponentach, przy prostych poprawkach w sprawdzonym kodzie, przy zmianach które rozumiesz na wylot - odpowiedź często będzie negatywna. I to jest dobra odpowiedź, bo oznacza, że pracujesz efektywnie.

Dobieranie modelu do zadania - praktyczna strategia

Większość testerów używających AI w codziennej pracy ma jeden domyślny schemat: wybierają najmocniejszy dostępny model i wrzucają do niego wszystko. To jest wygodne, ale kosztowo coraz trudniejsze do obrony - i często po prostu niepotrzebne.

Różne zadania testowe mają różne wymagania co do jakości modelu. Planowanie strategii testów dla nowego modułu, analiza ryzyka przed wdrożeniem, rozgrzebywanie nieznanego fragmentu kodu, który zachowuje się niespodziewanie - to są zadania, gdzie mocniejszy model naprawdę się opłaca. Model rozumie złożony kontekst, łączy zależności, proponuje rozwiązania, których sam byś nie wziął pod uwagę.

Rutynowe generowanie przypadków testowych dla typowych scenariuszy, pisanie boilerplate'u pod nową klasę page objecta, uzupełnianie dokumentacji, drobne poprawki w istniejących testach - to zadania, gdzie tańszy lub darmowy model daje wystarczającą jakość. Claude Haiku to tańszy wariant modeli Anthropic, zoptymalizowany pod szybkie i proste zadania. Raptor Mini to szybki model Microsoftu, dostępny w GitHub Copilot, przygotowany głównie pod pracę z plikami konfiguracyjnymi, edycję dokumentacji i debugowanie mniejszych fragmentów kodu. Przy rutynowych zadaniach testowych oba dają wyniki, które spokojnie wystarczają - przy ułamku kosztu flagowych modeli.

Sam pracuję z kilkoma modelami równolegle. Mocniejszy model do myślenia i analizy, tańszy do implementacji. To wymaga chwili przełączenia i świadomości, czego od danego zadania oczekujesz, ale szybko staje się nawykiem.

Porządek w projekcie jako optymalizacja tokenów

Jest jeszcze jeden aspekt kosztów AI, który rzadko się pojawia w dyskusjach na ten temat: jakość środowiska testowego, do którego AI ma dostęp. Im gorzej poukładany projekt, tym więcej tokenów AI potrzebuje, żeby zrozumieć kontekst i wykonać zadanie poprawnie.

Kiedy wrzucasz do modelu fragment kodu z niespójnym nazewnictwem, bez jasnej struktury katalogów, z selektorami rozrzuconymi po plikach zamiast zebranych w page objectach - model potrzebuje więcej miejsca w oknie kontekstu, żeby wywnioskować co jest czym. Efekt to więcej iteracji, więcej poprawek i więcej tokenów na każde zadanie. Przy flat-rate to tylko frustracja. Przy rozliczaniu per token to wymierny koszt.

Dobrze zaprojektowany Page Object Model, sensowne konwencje nazewnicze, jasno podzielone pliki konfiguracyjne - to nie jest tylko kwestia czytelności dla ludzi. To też efektywność pracy z AI. Model, który dostaje dobrze poukładany kontekst, szybciej rozumie zadanie i rzadziej trafia obok. Jedna zmiana w dobrze zaprojektowanej strukturze to jeden plik do edycji i jedno krótkie zapytanie. Zmiana w chaotycznym projekcie to wyjaśnianie zależności od zera, kilka prób i mnóstwo poprawek.

Praca agentowa a koszty - co warto wiedzieć

Rozmowy o kosztach AI skupiają się zwykle na pojedynczych zapytaniach. Tymczasem największy wzrost zużycia tokenów pochodzi z czegoś innego: z pracy agentowej, gdzie model samodzielnie wykonuje dłuższe sekwencje zadań bez ciągłego nadzoru człowieka.

Praca agentowa - czyli tryb, w którym AI samodzielnie czyta pliki, modyfikuje kod, uruchamia testy i iteruje na wynikach - może w jednym zadaniu wygenerować tyle tokenów co setki zwykłych zapytań. Dla testów e2e z Playwright jest to szczególnie istotne, bo automatyczne generowanie całej suity testowej z analizą wyników i poprawkami to właśnie taki scenariusz.

To nie znaczy, że praca agentowa nie ma sensu - często jest wyjątkowo efektywna. Ale warto wiedzieć, co uruchamiasz. Jeśli zlecasz agentowi analizę dużego repozytorium albo generowanie rozbudowanej suity, to jest zadanie dla flagowego modelu i warto z tego skorzystać świadomie. Jeśli rutynowo uruchamiasz agenta do zadań, które mógłbyś wykonać w trzy minuty samodzielnie - to dobry moment na rewizję.

Co się zmienia dla QA Engineerów i testerów

Rosnące koszty AI prawdopodobnie zmienią sposób, w jaki firmy zarządzają narzędziami do testowania. Skoro użycie AI zaczyna mieć wymierny koszt, firmy zaczną patrzeć na nie podobnie jak na inne zasoby techniczne: infrastrukturę, chmurę, licencje. Pojawią się pytania o budżety, o to, które zespoły używają AI najwięcej, do jakich zadań i z jakim efektem.

To oznacza, że QA Engineer, który potrafi świadomie zarządzać kosztem AI w projekcie testowym - który wie, kiedy użyć mocnego modelu, kiedy sięgnąć po tańszą opcję i kiedy pracować bez AI - staje się cenniejszy niż ten, który po prostu "używa AI". Sama znajomość narzędzi przestaje wystarczać. Liczy się efektywność użycia.

Jest w tym też coś bardziej fundamentalnego. AI okazało się zbyt skutecznym narzędziem, żeby firmy z niego rezygnowały nawet przy wzroście cen. Zmieni się raczej sposób korzystania: mniej beztroskiego generowania, więcej kontroli i świadomego doboru narzędzia do zadania. I to jest zmiana, którą warto wyprzedzić, zanim wymusi ją budżet.

Polecane wpisy:

Sprawdź też moje social media:

Kontakt

kontakt@rwasik.pl

Znajdziesz mnie też tu

Newsletter