Programowanie za pomocą promptów zmieniło to, kto może tworzyć aplikacje wyglądające na działające. Prompt może wygenerować ekrany, połączyć API i złożyć wiarygodny przepływ pracy, zanim tradycyjny zespół inżynieryjny zakończy pierwszy przegląd projektu.

Ta szybkość tworzy nowy problem związany z rekrutacją i dostarczaniem oprogramowania: demo nie jest już mocnym dowodem na to, że oprogramowanie jest dobre. Pracodawcy będą coraz częściej zadawać trudniejsze pytanie: czy ten system zbudowany przez AI zachowuje się prawidłowo, gdy dane wejściowe są nieuporządkowane, zależności zawodzą, użytkownicy powtarzają działania, a bazowy model się zmienia?

Odpowiedź przyniesie poprzeczka jakości, która będzie przypominać mniej dopracowanie wizualne, a bardziej zdyscyplinowaną weryfikację oprogramowania. Wyróżnią się nie osoby, które jedynie pokażą, co wygenerowało narzędzie AI do programowania. Pokażą one, jak to przetestowały, czego oprogramowanie nie potrafi bezpiecznie robić i skąd wiedzą, że zmiana nie zepsuła czegoś innego.

Benchmark jest dowodem, a nie wynikiem w rankingu

Benchmarki agentów programistycznych open source stanowią dobry punkt wyjścia, ale mierzą różne umiejętności. SWE-bench korzysta z rzeczywistych zgłoszeń GitHub i migawek repozytoriów, dzięki czemu jest istotny dla prac utrzymaniowych. Terminal-Bench sprawdza interakcję z wierszem poleceń. Inne wymienione benchmarki, w tym SlopCodeBench i ProgramBench, dotyczą innych aspektów generowanego kodu i zachowania agentów.

Benchmarki te mogą pomóc w porównywaniu narzędzi lub ustalaniu poziomu bazowego, ale pracodawcy powinni zachować ostrożność i nie traktować pojedynczego wyniku jako dowodu gotowości produkcyjnej. Model, który rozwiązuje problemy w repozytoriach, może nadal generować niebezpieczną logikę autoryzacji. Agent, który wykonuje zadania terminalowe, może nie zachować stanu podczas długiego przepływu pracy. Dopracowana aplikacja internetowa może przejść demonstrację poprawnej ścieżki, a jednocześnie nieprawidłowo obsługiwać ponowienia prób lub zduplikowane płatności.

Wiarygodne portfolio lub wewnętrzny przegląd powinny zatem obejmować zestaw ewaluacyjny dopasowany do zadania. Zestaw może zawierać reprezentatywne zgłoszenia błędów, typowe ścieżki użytkownika, nieprawidłowe dane wejściowe, granice uprawnień, awarie zależności oraz wcześniej naprawione regresje. Każdy przypadek powinien mieć jednoznacznie określony oczekiwany wynik, a nie tylko zrzut ekranu, który wygląda poprawnie.

Minimalny pakiet testów dla oprogramowania zbudowanego przez AI

W przypadku małej aplikacji przydatny pakiet jakości można przygotować bez rozbudowanego laboratorium badawczego:

  • Testy akceptacyjne: weryfikują zachowanie widoczne dla użytkownika w najważniejszych przepływach pracy, obejmujących zarówno pomyślne, jak i niepomyślne wyniki.
  • Testy jednostkowe i integracyjne: sprawdzają reguły biznesowe w izolacji oraz potwierdzają, że bazy danych, API, kolejki i uwierzytelnianie współdziałają zgodnie z założeniami.
  • Testy negatywne: wysyłają brakujące, nieprawidłowo sformatowane, zbyt duże, zduplikowane i nieautoryzowane dane wejściowe. Kod wygenerowany przez AI często wygląda najlepiej na ścieżce pokazanej w prompcie, dlatego znaczenie mają również ścieżki, o które nie poproszono.
  • Testy regresji: zamieniają każdy wykryty defekt w stały test. Zielone demo po naprawie nie wystarczy, jeśli ta sama awaria może powrócić przy kolejnej wygenerowanej zmianie.
  • Kontrole bezpieczeństwa: testują kontrolę dostępu, obsługę sekretów, ochronę przed wstrzyknięciami, podatności zależności oraz to, czy niezaufane treści mogą wpływać na wywołania narzędzi lub uprzywilejowane działania.
  • Kontrole operacyjne: weryfikują limity czasu, ponawianie prób, idempotencję, rejestrowanie zdarzeń, alerty oraz bezpieczne zachowanie w sytuacji niedostępności zależności.

Jest to zbliżone do sposobu myślenia charakterystycznego dla inżynierii QA, opisanego w relacji Stack Overflow dotyczącej agentowego cyklu życia wytwarzania oprogramowania. Ważna zmiana ma charakter kulturowy: zapewnianie jakości nie jest końcową inspekcją przeprowadzaną po napisaniu kodu przez AI. To struktura, która sprawia, że szybkie generowanie jest wystarczająco bezpieczne, by z niego korzystać.

Testuj orkiestrację, a nie tylko wynik

Gdy oprogramowanie zawiera agenta AI, zwykłe testy aplikacji są konieczne, ale niewystarczające. System może zawieść, ponieważ model źle zrozumiał żądanie, ale może również zawieść dlatego, że otaczająca go orkiestracja utraciła kontekst, dwukrotnie wywołała narzędzie, zaakceptowała nieprawidłowo sformatowany ustrukturyzowany wynik albo nigdy się nie zakończyła.

Zalecane w podsumowaniu obszary regresji przed wdrożeniem tworzą praktyczną listę kontrolną: utrata kontekstu, idempotencja narzędzi, prompt injection, ustrukturyzowany wynik, brak zakończenia, ugruntowanie wyszukiwania oraz ponowne odtworzenie stanu. Są to testowalne właściwości inżynieryjne.

Na przykład test może wykonać to samo żądanie dwukrotnie i potwierdzić, że druga próba nie utworzy zduplikowanego zamówienia. Inny może przerwać działanie agenta w połowie przepływu pracy, uruchomić go ponownie i sprawdzić, czy wznowi pracę z prawidłowego stanu, zamiast powtarzać nieodwracalne działanie. Test wyszukiwania może wymagać, aby system cytował lub zwracał wyłącznie informacje z zatwierdzonego zbioru źródeł. Test ustrukturyzowanego wyniku może dostarczyć nieprawidłową odpowiedź i potwierdzić, że aplikacja bezpiecznie ją odrzuca, zamiast po cichu traktować ją jako prawidłowe dane.

Systemy długotrwałe i wieloagentowe wymagają szczególnie przejrzystych rejestrów awarii. Naukowcy pracują nad automatycznym przypisywaniem przyczyn awarii, ponieważ wskazanie, który agent spowodował awarię i w którym momencie długiego łańcucha interakcji do niej doszło, może być trudne. W praktyce zespoły powinny przechowywać wywołania narzędzi, dane wejściowe, wyniki, wersje modeli, znaczniki czasu, przejścia stanów i końcowe decyzje w rejestrze audytowym uwzględniającym ochronę prywatności. Bez tych dowodów czerwony test mówi, że coś zawiodło, ale nie wskazuje, od czego zacząć naprawę.

Odtwarzalność stanie się atutem zawodowym

Kod wygenerowany przez AI jest zmienny. Ponowne uruchomienie może wygenerować inną implementację; aktualizacja modelu może zmienić zachowanie; awaria dostawcy może wpłynąć na routing lub opóźnienia. Pracodawcy będą zatem cenić kandydatów, którzy potrafią zapewnić powtarzalność ewaluacji.

Oznacza to przypinanie migawek modeli, gdy jest to możliwe, rejestrowanie promptów i konfiguracji, kontrolowanie losowości, gdy platforma na to pozwala, oraz przeprowadzanie wielu prób dla zadań, których wyniki są zmienne. W podsumowaniu wskazano konkretnie przypięte migawki, niską temperaturę lub temperaturę równą zero, jeśli są dostępne, oraz bramki CI/CD oparte na przedziałach ufności jako przydatne zabezpieczenia.

Praktyczny raport powinien rozróżniać co najmniej trzy wyniki:

  1. Wskaźnik przejścia: ile przypadków zakończyło się powodzeniem.
  2. Spójność: jak często ten sam przypadek kończy się powodzeniem w kolejnych uruchomieniach.
  3. Dotkliwość: czy awarie są kosmetyczne, uciążliwe, powodują uszkodzenie danych, mają znaczenie dla bezpieczeństwa lub mogą doprowadzić do niebezpiecznego działania zewnętrznego.

System, który przechodzi 19 z 20 testów formatowania o niskim ryzyku, nie musi być lepszy od systemu, który przechodzi 18 z 20 przypadków, ale nigdy nie przekracza granicy autoryzacji. Poprzeczka jakości musi uwzględniać konsekwencje awarii.

Weryfikacja przez człowieka powinna koncentrować się na ryzyku, a nie na każdej linii

Celem lepszej automatyzacji nie jest zmuszanie człowieka do ponownego odczytywania każdego tokenu wygenerowanego przez AI. Chodzi o skierowanie ludzkiej uwagi na decyzje, których testy nie są w stanie w pełni rozstrzygnąć.

Weryfikujący powinni koncentrować się na uwierzytelnianiu i autoryzacji, przechowywaniu danych, działaniach finansowych lub umownych, prywatności, migracjach, odzyskiwaniu po błędach, uprawnieniach stron trzecich oraz zmianach wpływających na sam mechanizm oceny systemu. W przypadku agenta powinni również sprawdzić, jakie narzędzia może on wywoływać, do jakich danych każde z tych narzędzi ma dostęp oraz czy przed nieodwracalnym działaniem wymagane jest zatwierdzenie.

Widoczne różnice, procesy zatwierdzania, archiwizowane rozmowy i dzienniki audytowe — funkcje wyróżnione w opisie wspólnego programowania z AI w Slack Code — wskazują na szersze oczekiwanie: znaczenie będzie mieć historia powstawania oprogramowania. Weryfikujący powinien móc zrozumieć żądanie, przeanalizować wygenerowaną zmianę, zobaczyć dowody z testów i ustalić, kto zatwierdził wdrożenie.

Taki zapis nie jest biurokracją dla niej samej. Pozwala odróżnić efektowne demo od kontrolowanej zmiany, którą inna osoba może utrzymywać.

Co umieścić w portfolio lub omówić podczas rozmowy kwalifikacyjnej

W przypadku kandydatów najmocniejszą demonstracją jest niewielki system z celowo przejrzystą historią jakości. Należy dołączyć repozytorium, instrukcje konfiguracji, notatki dotyczące architektury, polecenia uruchamiające testy, reprezentatywne przypadki testowe, znane ograniczenia oraz krótki raport z awarii. Pokaż jeden lub dwa błędy, które wykryto i przekształcono w testy regresji. Wyjaśnij, jakiego modelu lub agenta programistycznego użyto, nie przedstawiając narzędzia jako autora decyzji inżynieryjnych.

Jeśli aplikacja korzysta z agenta, udokumentuj uprawnienia narzędzi, model stanu, zasady ponawiania prób, warunek zakończenia oraz punkty wymagające zatwierdzenia przez człowieka. Jeśli korzysta z wyszukiwania informacji, pokaż, jak wybierane są źródła i co się dzieje, gdy brakuje dowodów. Jeśli wywołuje usługi zewnętrzne, zademonstruj zachowanie w przypadku przekroczenia limitu czasu i zduplikowanych żądań.

Nie twierdź, że system jest niezawodny na podstawie jednego udanego nagrania. Weryfikowalne twierdzenie brzmi raczej: „W 30 zarejestrowanych uruchomieniach tych 12 scenariuszy system spełnił kryteria akceptacji w 28 przypadkach; dwie awarie dotyczyły niejednoznacznych danych wejściowych dotyczących daty i obie zostały udokumentowane”. Sama liczba jest mniej istotna niż metoda, granice oraz uczciwość w kwestii tego, co pozostaje nieprzetestowane.

Nowa definicja szybkości

AI obniża koszt stworzenia pierwszej wersji. Nie usuwa jednak kosztu ustalenia, czy ta wersja zasługuje na zaufanie. W rzeczywistości szybsze generowanie może sprawić, że ocena stanie się jeszcze ważniejsza, ponieważ między wdrożeniami może gromadzić się więcej niezweryfikowanych zmian.

Profesjonalista ery post-vibe-coding będzie oceniany na podstawie pętli: definiowanie zachowania, generowanie lub modyfikowanie kodu, testowanie realistycznych i przeciwstawnych przypadków, kontrolowanie decyzji wysokiego ryzyka, rejestrowanie awarii oraz ulepszanie systemu bez utraty dowodów. Benchmarki mogą pomóc w porównywaniu możliwości. Praktyki zapewniania jakości decydują o tym, czy te możliwości przełożą się na niezawodne oprogramowanie.

Poprzeczka jakości nie brzmi więc: „Czy potrafisz stworzyć aplikację za pomocą AI?”. Brzmi: „Czy potrafisz udowodnić, co robi aplikacja, wykryć, kiedy przestaje to robić, i zaprojektować ograniczenia, które nie pozwolą, by awaria przerodziła się w incydent?”.