AI potrafi napisać funkcję, poprawić błąd i zbudować cały ekran. Potrafi też z dużą pewnością oznajmić, że zadanie jest gotowe, mimo że sprawdziło tylko najwęższy fragment rozwiązania.

To tworzy trudną sytuację dla nieprogramisty. Widzisz działający przycisk, ale nie wiesz, co zmieniło się pod spodem. Nie przeczytasz tysięcy linii kodu. Nadal jednak odpowiadasz za produkt, dane i doświadczenie użytkownika.

Rozwiązaniem nie jest ślepe zaufanie ani próba zostania programistą w tydzień. Rozwiązaniem jest proces, który wymaga właściwych dowodów na kolejnych warstwach.

Zacznij od pytania: co dokładnie miało się zmienić?

Nie da się sprawdzić zadania opisanego jako „popraw aplikację” albo „dodaj lepszy panel”. Najpierw potrzebujesz małego kontraktu zmiany.

Zapisz:

  • jaki problem rozwiązujemy,
  • gdzie użytkownik zaczyna,
  • co robi,
  • jaki rezultat powinien zobaczyć,
  • czego ta zmiana nie obejmuje.

    • Jeżeli nie masz takiego opisu, wróć do prostego briefu aplikacji. Bez kryterium akceptacji nawet poprawny kod może rozwiązywać niewłaściwy problem.

    Warstwa 1: obejrzyj różnicę, nie tylko rezultat

    Pierwszym sygnałem ryzyka jest zakres zmiany. Prosiłeś o tekst na jednym ekranie, a AI zmieniło kilkanaście plików? Dodanie przycisku pociągnęło nową bibliotekę i przebudowę wspólnego komponentu? To nie musi być błąd, ale wymaga wyjaśnienia.

    Poproś AI o krótką odpowiedź:

    1. Które pliki zostały zmienione? 2. Dlaczego każdy z nich był potrzebny? 3. Co celowo pozostało bez zmian? 4. Jakie ryzyko może pojawić się obok?

    Mały, zrozumiały zakres jest łatwiejszy do sprawdzenia i wycofania.

    Warstwa 2: sprawdź pełny obieg użytkownika

    Nie testuj tylko ostatniego kliknięcia. Przejdź drogę od miejsca, w którym użytkownik naprawdę zaczyna.

    Jeżeli funkcja zapisuje notatkę, sprawdź:

  • pusty formularz,
  • poprawne dane,
  • błąd zapisu,
  • ponowne otwarcie zapisanej notatki,
  • widok na telefonie,
  • zachowanie po odświeżeniu strony.

    • To są proste testy produktowe. Nie wymagają znajomości kodu, a wykrywają wiele problemów niewidocznych w pojedynczym podglądzie.

    Warstwa 3: wymagaj automatycznych testów dopasowanych do ryzyka

    Test automatyczny nie daje gwarancji, ale tworzy powtarzalny dowód. Ważne, aby sprawdzał zachowanie, a nie tylko istnienie elementu.

    Dla zwykłej treści wystarczy lint, kontrola typów i build. Dla formularza potrzebne są przypadki poprawne i błędne. Dla uprawnień trzeba sprawdzić co najmniej osobę uprawnioną i nieuprawnioną. Dla płatności, danych klientów albo logowania nie wystarczy ręczne kliknięcie.

    Zapytaj nie tylko „czy testy przeszły?”, ale także „co dokładnie sprawdza każdy test?”. AI może uruchomić niewłaściwą komendę albo dopasować test do błędnego zachowania.

    Warstwa 4: sprawdź dane i uprawnienia

    Najgroźniejsze błędy często nie wyglądają źle. Ekran działa, ale osoba widzi cudze dane. Formularz zapisuje za dużo informacji. Log zawiera treść, która nie powinna go opuścić.

    Przy każdej funkcji korzystającej z danych zapytaj:

  • skąd pochodzą dane,
  • gdzie są zapisywane,
  • kto może je odczytać,
  • kto może je zmienić,
  • czy w logach lub komunikatach błędu pojawiają się informacje prywatne,
  • co stanie się po częściowym niepowodzeniu.

    • W obszarze logowania, płatności, danych klientów i prywatności potrzebny jest przegląd osoby technicznej lub specjalisty bezpieczeństwa. To nie jest miejsce na oszczędzanie przez pewność siebie AI.

    Warstwa 5: sprawdź telefon, klawiaturę i prawdziwy tekst

    Widok desktopowy potrafi ukryć problemy. Na telefonie nagłówek może rozbić słowo, przycisk może wyjść poza ekran, a klawiatura zasłonić pole formularza.

    Sprawdź co najmniej:

  • szeroki i wąski ekran,
  • najdłuższy realny tekst,
  • brak danych,
  • komunikat błędu,
  • obsługę klawiaturą,
  • czytelność kontrastu.

    • Podgląd makiety nie zastępuje przejścia działającej strony.

    Warstwa 6: oddziel „jest w kodzie” od „jest na produkcji”

    Zmiana może działać lokalnie i nadal nie być gotowa do publikacji. W dobrym procesie istnieją osobne etapy: zmiana, testy, przegląd, połączenie kodu, publikacja i sprawdzenie produkcji.

    Nie łącz ich jednym poleceniem „wrzuć”. Zawsze ustal, czy chodzi o zapisanie pracy, utworzenie prośby o przegląd, połączenie zmian czy publikację. Dzięki temu błąd wykryty po drodze nie trafia automatycznie do użytkowników.

    Kiedy możesz sprawdzić sam, a kiedy potrzebujesz programisty

    Samodzielnie możesz ocenić:

  • zgodność z problemem użytkownika,
  • pełny obieg działania,
  • treść i komunikaty,
  • zachowanie na telefonie,
  • stany puste i błędy widoczne w interfejsie,
  • czy zakres nie urósł bez powodu.

    • Poproś o przegląd techniczny, gdy zmiana dotyczy:

  • logowania i uprawnień,
  • płatności,
  • prywatnych danych,
  • migracji bazy,
  • integracji z zewnętrzną usługą,
  • usuwania danych,
  • procesów działających automatycznie bez człowieka.

    • Nie jest porażką nie rozumieć wszystkiego. Porażką byłoby nie rozpoznać miejsca, w którym brak wiedzy staje się ryzykiem dla innych.

    Checklista przed zaakceptowaniem zmiany AI

    1. Czy rezultat odpowiada na wcześniej opisany problem? 2. Czy zakres plików jest zrozumiały i proporcjonalny? 3. Czy przeszedłem cały obieg, nie tylko szczęśliwy wariant? 4. Czy sprawdziłem błąd, brak danych i telefon? 5. Czy testy odpowiadają rodzajowi ryzyka? 6. Czy wiem, kto może zobaczyć i zmienić dane? 7. Czy zmiana wysokiego ryzyka miała przegląd techniczny? 8. Czy publikacja jest osobną, świadomą decyzją?

    Nieprogramista nie musi udowadniać, że potrafi samodzielnie przeczytać cały kod. Powinien zbudować taki sposób pracy, w którym ważne założenia są jawne, wyniki możliwe do sprawdzenia, a ryzykowne obszary trafiają do właściwej osoby.

    AI może zwiększyć tempo. Proces kontroli sprawia, że tempo nie zamienia się w przypadek.