Programista prosi asystenta o funkcję sprawdzającą, czy użytkownik może pobrać raport. Kod się kompiluje. Test happy-path przechodzi pomyślnie. Żądanie ściągnięcia wygląda na uporządkowane. Dwa tygodnie później współpracownik zauważa, że funkcja sprawdza, czy użytkownik jest zalogowany, ale nigdy nie sprawdza, czy raport należy do niego.
To przykładowy scenariusz, a nie udokumentowany incydent. Opisuje on lukę, którą musi wypełnić szkolenie z zakresu przeglądu kodu generowanego przez sztuczną inteligencję: wygenerowany kod, który pomyślnie przejdzie podstawowe sprawdzenie, może nadal zawierać błąd autoryzacji lub współbieżności, a osoba dokonująca przeglądu musi go znaleźć i wyjaśnić, dlaczego jest to istotne.
Ten przewodnik jest przeznaczony dla liderów ds. wdrażania rozwiązań inżynieryjnych i menedżerów ds. inżynierii. Obejmuje on opisywanie problemów z wydajnością, diagnozowanie luk, przygotowanie i praktykę projektową, analizę przypadku oraz ocenę, czy umiejętności przekładają się na rzeczywiste testy. Dotyczy on projektowania szkoleń. Każda reguła dotycząca defektów, testów i przeglądów w programie powinna zostać zatwierdzona przez doświadczonych inżynierów i zespół ds. bezpieczeństwa.
Na czym polega szkolenie z zakresu przeglądu kodu generowanego przez sztuczną inteligencję?
Szkolenie z zakresu przeglądu kodu generowanego przez sztuczną inteligencję uczy programistów jasnego podpowiadania asystentowi, a następnie oceniania i audytowania wyników: czy są poprawne, bezpieczne, czy zachowują się pod obciążeniem współbieżnym, czy są wystarczająco wydajne. To nie jest kurs poświęcony konkretnemu narzędziu. Kształtuje nawyk przeglądu, który pozostaje niezmieniony po zmianie narzędzia.
Szybkie fakty
| Question | Krótka odpowiedź |
|---|---|
| Jakie jest zadanie? | Przeprowadź audyt wygenerowanego kodu i potwierdź każde ryzyko za pomocą testu. |
| Jaki jest Twój wynik? | Weryfikacja jakości i stwierdzenie, czy wykryto istotne wady. |
| Czy quiz dotyczący zasad bezpiecznego kodowania wystarczy? | Nie. Potwierdza ona spełnienie wymagań wstępnych, ale nie to, czy programista jest w stanie dostrzec w kodzie lukę, która wydaje się prawdopodobna. |
| Kto weryfikuje treść? | Kierownik ds. inżynierii i zespół ds. bezpieczeństwa. |
| Czego nie naprawi szkolenie? | Przeanalizuj czas, narzędzia, niejasną własność i presję na szybkie połączenie. |
| Skąd wiesz, że zadziałało? | Nowe, niepublikowane wcześniej ćwiczenie z kodem, oceniane według ustalonych kryteriów, z późniejszymi sprawdzeniami w rzeczywistych recenzjach. |
1. Opisz problem z wydajnością
Zacznij od zadania: audyt wygenerowanego kodu i uzasadnij ryzyko testami. Audyt to czytanie z podejrzliwością. Uzasadnianie to przekształcanie podejrzeń w dowód, zazwyczaj w test, który się nie powiedzie, lub w reprodukcję, która pokazuje błąd.
Badania sugerują, dlaczego wymaga to świadomego ćwiczenia. W badaniu GitHub Copilot, Pearce i współpracownicy stworzyli 1,689 programów w 89 scenariuszach wybranych dla znanych typów słabości i stwierdzili, że około 40% z nich było podatnych na ataki (Pearce i współpracownicy, 2021). Było to wczesne narzędzie i konkretny zestaw scenariuszy, więc nie należy traktować tej liczby jako wskaźnika dla dzisiejszych asystentów. W oddzielnym badaniu użytkowników poproszono uczestników o napisanie kodu z asystentem AI i bez niego. Osoby korzystające z asystenta pisały znacznie mniej bezpieczny kod i częściej uważały, że ich kod jest bezpieczny (Perry i współpracownicy, 2023). W tym samym badaniu odkryto, że uczestnicy, którzy mniej ufali asystentowi i bardziej angażowali się w polecenia, rzadziej wykazywali się podatnością.
Z projektowania szkoleń płyną dwie lekcje. Wiarygodne wyniki wymagają aktywnego recenzenta. A pewność siebie to nie dowód, dlatego ćwiczenie musi wymagać testu, a nie opinii.
Napisz oświadczenie o wydajności w jednym zdaniu i zleć jego sprawdzenie kierownikowi ds. inżynierii: „Po wygenerowaniu zmiany programista wymienia dostrzegane przez siebie zagrożenia dla bezpieczeństwa, współbieżności i wydajności i dla każdego z nich opisuje lub pisze test, który je wykaże”.
2. Zdiagnozuj luki w nauce i kontekście
Zanim cokolwiek stworzysz, porównaj zadanie z tym, co ćwiczy i ocenia Twój obecny program. Trzy pytania zazwyczaj odróżniają lukę w szkoleniu od czegoś innego:
- Czy obecna praktyka wykorzystuje rzeczywiste zadanie? Jeśli szkolenie obejmuje pisanie podpowiedzi, ale nigdy nie wymaga od programistów weryfikacji wyników, to nikt nie praktykował audytu. Jeśli ocena jest testem wielokrotnego wyboru dotyczącym bezpiecznych reguł kodowania, mierzy ona przypomnienie.
- Jakie jest zapotrzebowanie poznawcze? W zrewidowanej taksonomii Blooma, ocena bezpieczeństwa kodu i wybór testu, który to potwierdza, znajdują się na poziomie analizy i oceny, a zaprojektowanie lepszego komunikatu lub poprawki osiąga poziom tworzenia. Dopasowanie aktywności do tych poziomów jest omówione w naszym przewodniku. dopasowywanie działań edukacyjnych do taksonomii Blooma.
- Czy coś innego niż umiejętności stoi na przeszkodzie? Sprawdź czas przeglądu, narzędzia i odpowiedzialność. Jeśli recenzenci mają pięć minut na każde żądanie ściągnięcia, brak szkolenia nie zaowocuje audytem. Jeśli w procesie nie ma analizy statycznej ani zestawu narzędzi testowych, programista może znaleźć ryzyko, ale nie będzie mógł go uzasadnić. Zgłaszaj przyczyny niezwiązane ze szkoleniem osobom, które mogą je naprawić.
3. Przygotowanie i praktyka projektowania
Gdy już wiesz, które luki można wypełnić szkoleniem, przypisz każdemu etapowi odrębne zadanie.
Przygotowanie. Sprawdź wymagania wstępne za pomocą krótkiej diagnostyki: typowe kategorie słabości, z którymi boryka się Twój stos, struktura testów, lista kontrolna przeglądu używana przez Twój zespół. Nauka we własnym tempie jest odpowiednia na tym etapie. Kontrola pamięci potwierdza jedynie wymagania wstępne.
Ćwiczyć. Stosuj ćwiczenia audytowe zbudowane z realistycznie wygenerowanego kodu. Każde z nich powinno zawierać niewielką liczbę defektów różnego rodzaju, takich jak brak kontroli własności, wyścig między dwoma żądaniami i nieefektywna pętla, a także fragment poprawnego kodu. Programista dokonuje przeglądu, nazywa każde ryzyko, określa jego wagę i proponuje test, który je wykaże. Proś o uzasadnienie, a nie o listę numerów wierszy.
Informacje zwrotne. Powiąż to z decyzjami, a nie z wynikiem całkowitym. „Oznaczyłeś pętlę, ale nie wyścig na wspólnym liczniku, a Twój test by tego nie wykrył, ponieważ uruchamia żądania pojedynczo” jest bardziej przydatne niż „Znaleziono 2 z 3”.
Dane wejściowe na żywo czy przegląd asynchroniczny? Wkład pracy na żywo przynosi największą wartość, gdy ryzyko jest niejednoznaczne, a programiści uczą się, słuchając starszego inżyniera, który wyjaśnia, dlaczego zablokowaliby scalenie. Asynchroniczna analiza wystarcza do porównania ustaleń programisty z opatrzoną komentarzami analizą ekspercką. Wiele zespołów korzysta z obu metod: najpierw z przygotowania we własnym tempie, a następnie z sesji moderowanej nad trudnymi przypadkami.
4. Omów realistyczny przykład
Ilustrujące. Kierownik ds. inżynierii powinien zweryfikować przypadek i kryteria odpowiedzi przed ich użyciem.
Walizka. Wygenerowany punkt końcowy zwraca fakturę klienta według jej identyfikatora. Sprawdza, czy wywołujący ma prawidłową sesję, używa sparametryzowanego zapytania i przechodzi podstawowy test. Ta sama funkcja zwiększa współdzielony licznik pobrań bez blokady.
Zadanie. Deweloper wymienia każde zagrożenie, jakie widzi, klasyfikuje je i opisuje test, który potwierdza każde z nich.
Pierwsza próba. „Wygląda dobrze. Zapytanie jest sparametryzowane, a test przechodzi”. Deweloper potraktował zaliczenie testu jako dowód i nie zapytał, czego test nie obejmuje.
Prześlij opinię i spróbuj ponownie. Recenzent prosi programistę o wskazanie, co weryfikacja sesji udowadnia, a czego nie. Ponowna próba wymaga uwzględnienia dwóch różnych klientów i dwóch równoczesnych żądań.
Silniejsza próba. „Sprawdzenie sesji dowodzi, kto dzwoni, a nie, że faktura należy do niego. Napisałbym test, w którym klient A prosi o identyfikator faktury klienta B i oczekuje odmowy. Licznik jest zwiększany bez synchronizacji, więc dwa żądania naraz mogłyby spowodować utratę aktualizacji. Uruchomiłbym test współbieżny i porównałbym licznik. Samo zapytanie jest sparametryzowane, więc nie traciłbym na to czasu”. Zauważ, że ta odpowiedź klasyfikuje ryzyka i wiąże każde z nich z testem.
Dlaczego każda odpowiedź jest możliwa do obrony lub niekompletna. Oceniaj każdą z nich według zatwierdzonych kryteriów, a nie preferencji recenzenta. Pierwsza próba opiera się na nawyku, ale pomija dowody. Silniejsza próba jest konkretna, priorytetowa i możliwa do sprawdzenia.
5. Ocena zdolności i zaplanowanie przeniesienia
Dowodem umiejętności jest wykonanie nowego ćwiczenia, którego uczeń nie widział. Weryfikacja jakości wyników i identyfikacja istotnych błędów. Prosta rubryka wykorzystuje skalę od 0 do 2 dla każdego kryterium:
| Kryterium | Obserwowalne dowody |
|---|---|
| Wykonanie zadania | Audytuje wygenerowany kod i rejestruje dowody potwierdzające każde ustalenie. |
| Rozumowanie | Wyjaśnia ograniczenia, alternatywy i to, co pozostaje niepewne, a także klasyfikuje ryzyka. |
| Granice | Postępuje zgodnie z zasadami przeglądu obowiązującymi w zespole i eskaluje sprawę do specjalisty ds. bezpieczeństwa, gdy ryzyko przekracza jego kompetencje. |
Kotwice: 0 oznacza brak lub brak obsługi, 1 oznacza częściowe pominięcie istotnych elementów, a 2 oznacza kompletne i uzasadnione zgodnie z ustalonymi kryteriami. Zdefiniuj błędy krytyczne osobno, takie jak zatwierdzenie kodu z niezabezpieczoną ścieżką dostępu, aby ogólny wynik nie mógł ich ukryć. Ta rubryka jest propozycją, a nie sprawdzonym standardem gotowości: dostosuj ją z kierownikiem ds. inżynierii i przeprowadź pilotaż. Nasz przewodnik po projektowanie interaktywnej praktyki z użyteczną informacją zwrotną pokazuje, jak napisać opinię, która odnosi się do decyzji.
Zaplanuj transfer z rozwagą. Po ćwiczeniu, sparuj każdego programistę z prawdziwym pull requestem zawierającym wygenerowany kod i wspólnie przejrzyjcie ich wnioski lub przeprowadź krótką retrospektywę na podstawie niedawnego przeglądu, w którym coś pominięto.
Gdzie interaktywna dostawa pomaga
Formaty interaktywne pomagają w podjęciu decyzji przez każdego przed spotkaniem z grupą. Podczas sesji na żywo prowadzący może pokazać wygenerowany fragment kodu, poprosić każdego programistę o wpisanie ryzyka, które widzi, oraz testu, który napisałby, a następnie ujawnić rozkład przed dyskusją. To samo ćwiczenie można przeprowadzić we własnym tempie, aby się przygotować. AhaSlides wspiera interaktywną naukę i przełączanie się między trybem na żywo a trybem we własnym tempie. Jest to narzędzie do prezentacji i nauki, a nie miejsce do uruchamiania kodu, dlatego uruchamiaj ćwiczenia z kodowania we własnym środowisku. Sprawdź wszystkie konkretne funkcje tworzenia, przekazywania opinii lub raportowania, na których planujesz polegać w swoim własnym procesie pracy. Wskazówki dotyczące wyboru formatów znajdziesz w naszym artykule na temat kiedy stosować naukę adaptacyjną, interaktywną i na żywo.
Zmierz, co się zmieniło
Zdecyduj z wyprzedzeniem, co będzie świadczyć o tym, że programiści potrafią wykonać zadanie. Porównaj jakość weryfikacji i identyfikację defektów w nieobejrzanym ćwiczeniu z punktem odniesienia. Określ, kto jest uwzględniany, jaki jest mianownik i jaki jest czas. Jeśli wyniki się poprawią, sprawdź, co jeszcze zmieniło się w tym samym okresie, na przykład nową regułę analizy statycznej, zaktualizowaną listę kontrolną przeglądu lub zmianę asystenta, przed zaliczeniem szkolenia.
Ograniczenia, które mogą pozostać
- Czas na recenzję. Audyt trwa dłużej niż pobieżne przejrzenie, a terminy są tym większe, im bardziej pobieżne jest przejrzenie całości.
- Obróbka. Bez testów i skanowania w toku, trudno jest uzasadnić jakiekolwiek ryzyko.
- Zmiana narzędzi. Asystenci zmieniają się szybko, dlatego ćwicz nawyk recenzowania, a nie tylko jednego produktu.
- Relacja ze sprawy. Jedno z ćwiczeń pokazuje kilka typów błędów. Wynik nie opisuje ogólnej oceny programisty.
- Transfer. Wyniki uzyskane w warsztacie nie są takie same jak wyniki uzyskane w trakcie długiej kolejki recenzji.
Zgłosić je sponsorom na wczesnym etapie i zaplanować osobne poprawki. Szkolenie poprawia to, co programista może znaleźć i udowodnić. Nie tworzy czasu ani narzędzi.
PYTANIA I ODPOWIEDZI
Na czym polega szkolenie z zakresu przeglądu kodu generowanego przez sztuczną inteligencję?
Uczy programistów, jak podpowiadać, oceniać i audytować kod generowany przez asystenta AI, wyszukiwać problemy związane z bezpieczeństwem, współbieżnością i wydajnością, a następnie potwierdzać każdy z nich testem.
Czy kod generowany jest mniej bezpieczny niż kod tworzony przez człowieka?
Badania wskazują na ryzyko, ale wyniki zależą od narzędzia, zadania i projektu badawczego. Jedno z badań użytkowników wykazało, że uczestnicy korzystający z pomocy asystenta pisali mniej bezpieczny kod i czuli się z nim pewniej, co jest powodem do wyrobienia w sobie nawyku przeglądania kodu.
Jak ocenić, czy programiści mogą audytować generowany kod?
Przeprowadź nowe ćwiczenie z kodowania i oceń jakość weryfikacji oraz identyfikację defektów według uzgodnionych kryteriów. Quiz z zasad bezpiecznego kodowania potwierdza jedynie spełnienie wymagań wstępnych.
Czy potrzebujesz piaskownicy kodu do szkolenia?
Potrzebujesz miejsca do wykonywania ćwiczeń, którym zazwyczaj jest Twoje własne środowisko. Sprawdź, czy narzędzie, którego używasz, obsługuje to, czego potrzebujesz, zanim zaczniesz na nim polegać.
Gdzie zacząć
Wybierz jeden powtarzający się rodzaj generowanej zmiany w bazie kodu. Napisz oświadczenie o wydajności, poproś kierownika ds. inżynierii o sprawdzenie zgłoszonych defektów i testów, które je wykryją, a następnie opracuj trzy kryterialną rubrykę z skalą od 0 do 2 i listą błędów krytycznych. Przeprowadź pilotaż z małą grupą przed wdrożeniem.
Aby zobaczyć, jak ćwiczenie audytowe można przeprowadzić na żywo z udziałem własnego zespołu, a następnie wykorzystać je ponownie w indywidualnym tempie, zapoznaj się z AhaSlides.
