Jak korzystać z AI do programowania: procesy, które zmniejszają ryzyko

Zasady bezpiecznej pomocy AI przy kodzie

Najlepszy sposób na wykorzystanie AI w programowaniu to spowolnić ją dokładnie w tych momentach, w których zgadywanie jest niebezpieczne. AI potrafi wyjaśnić nieznany kod, zamienić błędy w hipotezy, naszkicować testy, przejrzeć diff i zaproponować refaktoryzację. Potrafi też wymyślić nieistniejące API, przeoczyć ukryte zależności, przeuczyć się na wklejonym fragmencie albo wyprodukować łatkę, która wygląda czysto, a zmienia zachowanie, które chciałeś zachować.

Stosuj taką zasadę: AI może proponować, ale decyduje twoje repozytorium. Źródłem prawdy są baza kodu, nieprzechodząca reprodukcja, zestaw testów, logi z działania, wymagania produktowe i przegląd wykonany przez człowieka. Dobry programistyczny partner AI powinien pomagać ci wnioskować z tych artefaktów, a nie je zastępować.

Zasada	Dlaczego to ważne	O co poprosić model
Najpierw reprodukcja	Zapobiega przypadkowym łatkom	"Powtórz opis błędnego zachowania i dowody, zanim zaproponujesz kod."
Mały zakres	Zmniejsza ryzyko regresji	"Zaproponuj najmniejszą bezpieczną zmianę i wymień zmieniane pliki."
Zachowaj zachowanie	Chroni użytkowników i kontrakty	"Nazwij niezmienniki, których ta zmiana nie może naruszyć."
Wymagaj testów	Czyni odpowiedź sprawdzalną	"Napisz testy, które nie przechodzą przed poprawką i przechodzą po niej."
Przegląd przed scaleniem	Wyłapuje pewne siebie pomyłki	"Przejrzyj ten diff pod kątem poprawności, bezpieczeństwa i pominiętych przypadków brzegowych."

Dotyczy to wszystkich modeli. OpenAI, Anthropic i inni dostawcy publikują dokumentację modeli, opisującą różne możliwości, okna kontekstu i wzorce korzystania z narzędzi. Te możliwości są przydatne, ale nie zastąpią zdyscyplinowanego procesu. W pracy inżynierskiej oceniaj modele tą samą miarą, jaką oceniłbyś współpracownika: czy dopytują o brakujący kontekst, zmniejszają niepewność, respektują ograniczenia i zostawiają ślad, który da się zweryfikować?

Proces debugowania

Niezawodny proces debugowania z AI ma pięć etapów: reprodukcja, izolacja, hipoteza, łatka i weryfikacja. Nie zaczynaj od "napraw to". Zacznij od dowodów. Podaj modelowi nieprzechodzące polecenie, dokładny błąd, oczekiwane zachowanie, zaobserwowane zachowanie, odpowiedni kod, szczegóły środowiska i każdą niedawną zmianę, która mogła wywołać problem.

Etap 1: uchwyć reprodukcję. Przy kodzie backendowym dołącz żądanie, odpowiedź, kod statusu, logi i nieprzechodzący test. Przy kodzie frontendowym dołącz trasę, akcję użytkownika, błąd z konsoli przeglądarki, odpowiedź sieciową, stan komponentu i opis zrzutu ekranu, jeśli ma znaczenie. Przy problemach z buildem dołącz polecenie, menedżer pakietów, wersję Node i pełny błąd wokół pierwszego niepowodzenia.

Etap 2: poproś o hipotezy przed kodem. Uważny model powinien uszeregować prawdopodobne przyczyny i powiedzieć, jakie dowody przemawiają za każdą z nich. Jeśli nie potrafi rozróżnić przyczyn, poproś o najmniejszy krok diagnostyczny. Może to być log, wąski test, sprawdzenie typów albo przeczytanie jeszcze jednego pliku.

Etap 3: poproś o najmniejszą łatkę. Powiedz modelowi, żeby nie zmieniał nazw zmiennych, nie przepisywał otaczającego kodu, nie wprowadzał zależności ani nie zmieniał publicznego zachowania, o ile nie potrafi tego uzasadnić. Poproś o zwrócenie przyczyny źródłowej, zarysu łatki, listy zmienianych plików, testów i ryzyka.

Etap 4: uruchom testy lokalnie. Wynik AI nie jest krokiem weryfikacji. Krokiem weryfikacji jest polecenie albo ścieżka użytkownika, która dowodzi zachowania. Jeśli nie ma testu automatycznego, poproś model, żeby najpierw stworzył test regresyjny, a dopiero potem wdrażaj poprawkę.

Prompt do debugowania:

Wciel się w uważnego partnera do debugowania. Jeszcze nie pisz kodu. Najpierw powtórz opis reprodukcji, oczekiwanego zachowania, zaobserwowanego zachowania i trzech najbardziej prawdopodobnych przyczyn źródłowych. Uszereguj każdą przyczynę według dowodów. Potem zaproponuj najmniejszy krok diagnostyczny. Błąd: [opisz]. Polecenie lub akcja użytkownika: [wklej]. Błąd/logi: [wklej]. Odpowiedni kod: [wklej]. Ograniczenia: [stos technologiczny, pliki, których nie ruszać, zachowanie do utrzymania].

Prompt do poprawki:

Na podstawie potwierdzonej przyczyny źródłowej zaproponuj najmniejszą bezpieczną poprawkę. Zwróć: przyczynę źródłową, pliki i funkcje do zmiany, zarys łatki, testy, które nie przechodzą przed i przechodzą po, przypadki brzegowe oraz ryzyko wycofania. Nie refaktoryzuj niepowiązanego kodu. Kontekst: [wklej].

Proces przeglądu kodu

AI często sprawdza się lepiej jako recenzent niż jako pierwszy autor. Gdy poprosisz ją o przegląd diffa, potrafi wypatrzyć pominięte przypadki brzegowe, problemy z bezpieczeństwem, nieaktualne założenia, luki w testach i zmiany zachowania. Klucz w tym, żeby przegląd był konkretny. Jeśli zapytasz "czy to wygląda dobrze?", dostaniesz uprzejmą akceptację. Jeśli zapytasz o ryzyko błędu, masz większą szansę na użyteczne zastrzeżenia.

Podaj modelowi diff, zamierzone zachowanie, powiązane testy i wszelkie ograniczenia. Poproś, żeby pomijał drobiazgi stylistyczne, o ile nie wpływają na łatwość utrzymania. Chcesz, żeby przegląd stawiał na pierwszym miejscu błędy, a nie efektowne czepialstwo.

Obszar przeglądu	Pytania, na które AI ma odpowiedzieć
Poprawność	Czy diff faktycznie spełnia wymaganie?
Ryzyko regresji	Jakie istniejące zachowanie może się przypadkiem zmienić?
Bezpieczeństwo	Czy zadbano o dane wejściowe, uwierzytelnianie, sekrety, uprawnienia i ryzyko wstrzyknięcia?
Obsługa błędów	Co się dzieje przy wartościach pustych, przekroczeniach czasu, ponowieniach, złych odpowiedziach lub stanie częściowym?
Testy	Które deklaracje o zachowaniu nie są pokryte?
Utrzymywalność	Czy to trzyma się lokalnych wzorców i zostawia zmianę zrozumiałą?

Prompt do przeglądu kodu:

Przejrzyj ten diff jak surowy, ale praktyczny opiekun projektu. Skup się na poprawności, ryzyku regresji, bezpieczeństwie, przypadkach brzegowych i brakujących testach. Pomiń drobiazgi stylistyczne, o ile nie tworzą realnego ryzyka utrzymaniowego. Zwróć tabelę z problemem, priorytetem, dowodem z diffa, sugerowaną poprawką i potrzebnym testem. Zamierzone zachowanie: [wklej]. Diff: [wklej]. Istniejące testy: [wklej].

Przy zmianach wysokiego ryzyka użyj w Whizi procesu porównywania poprawek z wielu modeli. Puść ten sam prompt przeglądowy przez dwa lub trzy modele. Jeśli jeden model znajdzie możliwy problem, nie przyjmuj tego na wiarę, tylko sprawdź, czy problem jest realny w bazie kodu. Celem nie jest zebranie większej liczby opinii. Celem jest poszerzenie pola przeglądu przed scaleniem.

Proces refaktoryzacji i testów

Refaktoryzacja z AI jest ryzykowna, bo wiele refaktoryzacji ocenia się po tym, co się nie zmieniło. Model może upiększyć kod, subtelnie zmieniając przy tym zachowanie, obsługę błędów, czasy albo publiczne kontrakty. Bezpieczniejszy proces refaktoryzacji zaczyna się od zdefiniowania niezmienników, zanim ruszysz implementację.

Krok 1: opisz cel refaktoryzacji. Przykłady: ograniczyć duplikację, rozbić duży komponent, wydzielić dostęp do danych, uprościć rozgałęzienia, przenieść opakowanie API albo poprawić testowalność. Potem określ, co musi zostać bez zmian: publiczne sygnatury funkcji, zachowanie tras, nazwy zdarzeń, kształty odpowiedzi, analityka, uprawnienia, dostępność i oczekiwania wobec wydajności.

Krok 2: poproś o plan etapowy. Użyteczny plan refaktoryzacji z AI powinien dać się cofnąć. Każdy etap powinien dotykać niewielkiego obszaru, zawierać testy i dawać działający stan pośredni. Unikaj przepisania wszystkiego za jednym razem, chyba że kod jest maleńki i dobrze pokryty testami.

Krok 3: napisz testy charakteryzujące. Zanim zmienisz kod, poproś AI o ustalenie obecnego zachowania i naszkicowanie testów, które zabezpieczą ważne przypadki. Te testy są szczególnie przydatne w starym kodzie, gdzie intencja jest niejasna. Powinny obejmować typowe dane wejściowe, wartości graniczne, ścieżki awarii i jeden przypadek regresyjny powiązany z powodem refaktoryzacji.

Krok 4: wdrażaj po jednym etapie. Po każdym etapie uruchom testy i poproś o wąski przegląd. Jeśli model proponuje szeroką abstrakcję, każ mu udowodnić, że usuwa ona realną duplikację albo realne ryzyko. W przeciwnym razie zostaw kod nudny i lokalny.

Prompt do planowania refaktoryzacji:

Stwórz etapowy plan refaktoryzacji. Cel: [cel]. Obecny kod: [wklej]. Ograniczenia: zachowaj publiczne zachowanie, ogranicz liczbę zmian, trzymaj się istniejących wzorców, unikaj nowych zależności, każdy etap ma być testowalny. Zwróć: niezmienniki, mapę zależności, etapy, zmieniane pliki, testy na etap, ryzyko wycofania i listę kontrolną przeglądu.

Prompt do testów jednostkowych:

Napisz testy przed zmianami w implementacji. Użyj istniejącego stylu testów pokazanego tutaj: [wklej]. Zachowanie do utrzymania: [wklej]. Testowany kod: [wklej]. Zwróć nazwy testów, przygotowanie, dane wejściowe, oczekiwany wynik i uzasadnienie, dlaczego każdy test ma znaczenie. Uwzględnij ścieżkę szczęśliwą, przypadek graniczny, przypadek błędu i przypadek regresyjny.

Szablony promptów

Dobre prompty programistyczne nie są długie dlatego, że są wymyślne. Są na tyle długie, żeby usunąć niejednoznaczność. Model potrzebuje roli, zadania, kontekstu, ograniczeń, formatu wyniku i kryteriów weryfikacji. Zapisuj prompty, które działają, żeby AI stała się powtarzalnym procesem inżynierskim, a nie jednorazową pogawędką.

Prompt do wyjaśniania kodu:

Wyjaśnij ten kod programiście dołączającemu do projektu. Omów cel, dane wejściowe, dane wyjściowe, przepływ danych, zależności, tryby awarii i testy, które podniosłyby pewność. Oddziel fakty widoczne w kodzie od założeń. Kod: [wklej].

Prompt do bezpieczeństwa kodu:

Przejrzyj ten kod pod kątem ryzyk bezpieczeństwa. Skup się na uwierzytelnianiu, uprawnieniach, wstrzyknięciach, sekretach, walidacji, niebezpiecznych przekierowaniach, obsłudze plików, ryzyku zależności i ujawnianiu danych wrażliwych. Zwróć wyłącznie problemy wraz z dowodem, skutkiem, sugerowaną poprawką oraz testem lub sprawdzeniem ręcznym. Kod/diff: [wklej].

Prompt do porównywania poprawek z wielu modeli:

Porównuję modele AI w zadaniu programistycznym. Korzystaj wyłącznie z podanego kontekstu. Zwróć przyczynę źródłową, najmniejszą bezpieczną poprawkę, testy, ryzyka, założenia i pytania. Oceń swoją pewność w skali od 1 do 5 i wypisz, jakie dowody zmieniłyby twoją odpowiedź. Zadanie: [wklej]. Kontekst: [wklej].

Lista kontrolna jakości, zanim przyjmiesz kod wygenerowany przez AI:

• Model poprawnie powtórzył opis zadania.
• Łatka jest mniejsza od problemu, a nie większa.
• Publiczne zachowanie i kontrakty są nazwane.
• Testy pokrywają wprost dany błąd albo cel refaktoryzacji.
• Przypadki brzegowe i ścieżki awarii są wypisane.
• Dane wejściowe wrażliwe z punktu widzenia bezpieczeństwa zostały sprawdzone.
• Diff trzyma się istniejących wzorców projektu.
• Uruchomiłeś odpowiedni test, lint, build albo ręczną reprodukcję.
• Człowiek przejrzał ostateczny diff.

Whizi przydaje się, gdy chcesz porównać poprawki bez zmiany zadania. Wklej ten sam prompt do debugowania albo przeglądu do kilku modeli, a potem oceń wyniki według dowodów, zakresu, testów i ryzyka. Zacznij od alternatyw dla ChatGPT do programowania, jeśli szukasz przewodnika po wyborze modelu, porównaj plany w cenniku albo załóż konto, żeby uruchomić ten proces na własnym kodzie.