Zyski:
- Umiejętność rozróżnienia, gdzie sztuczna inteligencja zapewnia prawdziwą prędkość w cyklu życia oprogramowania, a gdzie decyzja i odpowiedzialność spoczywa na inżynierze
- Umiejętność stosowania trójwarstwowej dyscypliny inżynierskiej, która weryfikuje każdy kod i projekt stworzony poprzez kompilację, testowanie i przegląd.
- Nabierz nawyku czyszczenia kontekstu, aby wykorzystać sztuczną inteligencję bez udostępniania poufnego kodu źródłowego, danych uwierzytelniających i danych klientów
Kiedy patrzysz na dzień inżyniera informatyka, obraz większości zespołów jest podobny: zrozumienie żądania biznesowego, projektowanie, pisanie kodu, czytanie kodu innej osoby, debugowanie (proces ustalania, dlaczego program działa niepoprawnie i naprawiania go), pisanie testów, przygotowywanie dokumentacji, przeglądanie kodu i uczestnictwo w spotkaniach. Innymi słowy, czas poświęcony na prawdziwą „ocenę inżynierską”, czyli czy rozwiązanie jest prawidłowe, bezpieczne i trwałe, zostaje zmiażdżony przez powtarzalną pracę. Tutaj z pomocą przychodzi sztuczna inteligencja (w skrócie AI; oprogramowanie działające na tekście i kodzie z dużym modelem językowym). AI nie podejmuje decyzji za Ciebie; Przygotowuje cię do decyzji, tworzy szkielet kodu, zawęża zakres błędów i przedstawia przed tobą przepracowaną wersję roboczą. W tym module będziemy pozycjonować sztuczną inteligencję nie jako „automatycznego programistę”, ale jako zdyscyplinowanego partnera w programowaniu w parach, którego wyniki są za każdym razem kompilowane, testowane i przeglądane.
W tej pierwszej części wyjaśniamy trzy rzeczy: na jakich etapach cyklu życia oprogramowania (etapy, przez które przechodzi oprogramowanie od pomysłu do produkcji: analiza, projektowanie, kodowanie, testowanie, wdrażanie, konserwacja) sztuczna inteligencja dodaje rzeczywistą wartość; jakie decyzje powinny ściśle należeć do inżyniera; oraz jakiej dyscypliny w zakresie weryfikacji i poufności należy przestrzegać, wykonując tę czynność. Bez prawidłowego zamontowania tego dachu techniki stosowane w kolejnych jednostkach mogą stać się niebezpieczne; Ponieważ błąd w oprogramowaniu dociera jednocześnie do milionów użytkowników i może stać się luką w zabezpieczeniach.
Pojęcia: Halucynacja: przekonujące wymyślenie przez sztuczną inteligencję metody, biblioteki, interfejsu API lub zachowania, które w rzeczywistości nie istnieje. Kontekst: Dane wejściowe, które podajesz AI (kod, komunikat o błędzie, wymagania, ograniczenia). Weryfikacja: Sprawdzanie wyników w niezależny sposób (kompilacja, testowanie, dokumentacja). Te trzy koncepcje stanowią podstawę całego modułu.
W jakich firmach można zastosować akcelerator AI, a w jakich jest to ryzykowne?
Zadania związane z oprogramowaniem mają dwojakie spektrum pod względem wyników. Z jednej strony są odwracalne prace przygotowawcze o niskim ryzyku; Z drugiej strony istnieją zadania trudne do zwrócenia, które trafiają do środowiska produkcyjnego i mogą powodować utratę danych, luki w zabezpieczeniach lub przerwy. Wartość AI różni się w zależności od tego, gdzie stoisz w tym spektrum.
rodzaj działalności
Wkład AI
Rola inżyniera
Szkielet kodu / szablon
Szybkie generowanie powtarzalnej struktury
Kontrola stanu logiki i krawędzi
debugowanie
Hipoteza i lista możliwych przyczyn
Powielanie i potwierdzenie przyczyny źródłowej
pisanie testów
Tworzenie wersji testowej i scenariuszy
Znaczące sprawdzanie asercji i zakresu
refaktoryzacja
Propozycja refaktoryzacji
Utrzymywanie zachowania poprzez testowanie
Dokumentacja
Pierwszy projekt i struktura
Kontrola poprawności z kodem
Decyzja architektoniczna/bezpieczeństwa
Lista opcji oraz zalet i wad
Ostateczna decyzja i odpowiedzialność
Zasada jest prosta: ryzyko, że wynik AI będzie równy szkodzie, jaką poniesie, jeśli wynik ten popełni błąd. Błędne sugerowanie nazwy zmiennej jest nieszkodliwe; Niewłaściwe uwierzytelnienie (sprawdzenie, czy użytkownik jest naprawdę tym, za kogo się podaje) naraża cały system na ataki. Zatem pierwszym pytaniem, które należy zadać przed użyciem wyników, jest: „Co się stanie, jeśli coś będzie nie tak i kto i kiedy to zauważy?”
Uwaga: sztuczna inteligencja tworzy płynny i pewny kod. Płynność nie gwarantuje dokładności. Model językowy może wiarygodnie wygenerować nazwę funkcji, która w rzeczywistości nie istnieje, nieprawidłową sekwencję parametrów lub nawet niebezpieczny wzorzec. W oprogramowaniu nie pozostaje to na papierze; Kompiluje się, uruchamia i eksploduje w środowisku produkcyjnym.
Decyzje, które należy pozostawić inżynierowi
Niektóre decyzje nigdy nie powinny być w pełni zautomatyzowane; niesie ze sobą ryzyko techniczne, prawne i etyczne:
- Dopuszczenie do produkcji: Dopuszczenie kodu do produkcji i odpowiedzialność za to.
- Bezpieczeństwo i architektura: drogie decyzje, takie jak uwierzytelnianie, autoryzacja, szyfrowanie i model danych.
- Licencja i prawa autorskie: Użyteczność wytworzonego kodu w produkcie komercyjnym i zgodność z licencją.
- Praca z poufnymi danymi: Transakcje z danymi klientów, tajemnicami kodu źródłowego i informacjami o tożsamości.
Ostrzeżenie: Nawet jeśli sztuczna inteligencja powie „ten kod jest bezpieczny i gotowy do produkcji”, zaakceptowanie tego bez testów bezpieczeństwa, przeglądu i walidacji kodu pod rzeczywistym obciążeniem jest niedopuszczalne. W pracach mających kluczowe znaczenie dla bezpieczeństwa wyniki sztucznej inteligencji nigdy nie zastępują zatwierdzenia przez kompetentnego inżyniera; Wszelkie dane wyjściowe prowadzące do podjęcia decyzji muszą zostać niezależnie zweryfikowane i zatwierdzone przez upoważnionego inżyniera przed wdrożeniem.
Dyscyplina weryfikacji: kontrola trójwarstwowa
Zastosuj trzy warstwy kontroli, aby korzystać z wyników AI jak starszy recenzent, a nie na ślepo. Jest to podstawowy odruch, który będziemy powtarzać w całym module.
- Kompilacja i sprawdzanie statyczne: czy kod faktycznie się kompiluje/uruchamia? Czy występują błędy typu, nieużywane zmienne, nieistniejące interfejsy API? Co mówi narzędzie do analizy statycznej (narzędzie, które bada kod bez jego uruchamiania)?
- Niezależna reprodukcja (testowanie): Uruchom kod z małymi, znanymi danymi wejściowymi i sprawdź, czy otrzymasz oczekiwany wynik. Wypróbuj przypadki Edge (null, zero, minus, ogromny).
- Weryfikacja źródła: Każde API, wersja biblioteki i funkcja językowa używana przez sztuczną inteligencję powinna zostać zweryfikowana na podstawie oficjalnej dokumentacji.
Monit o weryfikację (ułatwia sprawdzenie wyników): „Wymień WSZYSTKIE zewnętrzne biblioteki, metody i funkcje językowe, których używasz w swoim kodzie. Dla każdej z nich wskaż, w której wersji jest ona dostępna i oznacz ją jako „musi zostać zweryfikowana na podstawie dokumentacji”. Nie twórz żadnych interfejsów API, co do których nie jesteś pewien; jeśli nie jesteś pewien, wyraźnie napisz „nie jestem pewien”. Wymień także wszystkie przypadki Edge, których nie poruszyłeś jako osobną listę.
Krytykuj własną zachętę do kodu: „Przyjrzyj się krytycznie kodowi, który właśnie napisałeś, jak starszy inżynier, który cię zatrudnił. Podaj konkretne elementy w ramach trzech nagłówków: (1) błędy logiczne/przypadki brzegowe, (2) zagrożenia bezpieczeństwa, (3) problemy z wydajnością lub czytelnością. Dla każdego elementu napisz „dlaczego jest problem” i „sugerowane rozwiązanie”. Jeśli nie ma problemu, powiedz „nie mogłem znaleźć problemu”; nie próbuj go upiększać.
Słaba podpowiedź/silna podpowiedź
SŁABY: „Napisz mi funkcję uwierzytelniania użytkownika.” (Rezultat: niejasny, który język, jaka reguła, jakie zachowanie; kod ogólny, często niepewny lub wyrwany z kontekstu.) SILNY: „Napisz funkcję sprawdzania poprawności poczty e-mail dla Pythona 3.11. Dane wejściowe: ciąg znaków. Dane wyjściowe: prawda, jeśli jest poprawna, w przeciwnym razie fałsz. Reguły: pusty ciąg znaków Fałsz; zgodność z RFC nie jest wymagana, wystarczy podstawowy format. NIE KORZYSTAJ z biblioteki zewnętrznej. Poniżej funkcji dołącz test z 5 próbami blok: ważny, pusty, bez „@”, podwójny „@”, zawierający tylko spacje.”
Różnica tkwi w kontekście. Potężny monit; Obejmuje język, wersję, umowę wejścia-wyjścia, ograniczenia i oczekiwania dotyczące testu. Ta pojedyncza dyscyplina znacznie zmniejsza ryzyko halucynacji i niebezpiecznego kodu.
Mini etui
Przypadek 1 — Metoda wymyślona. Programista dowiaduje się od sztucznej inteligencji, że w bibliotece dat istnieje metoda o nazwie date.addBusinessDays(5) i została ona wyjaśniona w pewny sposób. Przeglądając dokumentację widzi, że nie ma takiej metody, właściwym sposobem jest pętla ręczna. Halucynacja zostaje uchwycona przed wprowadzeniem do produkcji w ramach 10-minutowej weryfikacji.
Przypadek 2 — Utrata stanu brzegowego. AI tworzy funkcję „oblicz średnią”; Działa, gdy jest testowany na 1000 wierszach danych. Jednakże, gdy lista jest pusta, daje dzielenie przez zero błędów. Ponieważ inżynier dodał test pustego wejścia, widzi i naprawia błąd, zanim zostanie on uruchomiony. Test stanu pojedynczej krawędzi zapobiega alarmowi produkcyjnemu o 3:00.
Przypadek 3 – Ryzyko prywatności. Ekspert ma zamiar wkleić plik z rzeczywistym ciągiem połączenia z bazą danych i kluczem API do narzędzia publicznego. pamięta o polityce instytucji; Zastępuje sekrety <ZMIENIONO>, redukuje kod do reprezentatywnego przykładu i prosi o to. W ten sposób otrzymuje pomoc w ciągu 5 minut, ale informacje o jego tożsamości nie wychodzą na jaw.
Zasada pracy z tajnym kodem i informacjami dotyczącymi tożsamości
Najbardziej wrażliwa część oprogramowania; tajemnice kodu źródłowego, informacje o tożsamości (klucz API, hasło, token) oraz dane klienta/osobiste. Podstawowa zasada: posprzątaj przed udostępnieniem, zapytaj tylko o istotę problemu na reprezentatywnym przykładzie, jeśli to możliwe.
Zanonimizowany wzór podpowiedzi: „Wystąpił błąd w następującej funkcji. Rzeczywistą logikę biznesową i ukryte stałe zastąpiłem reprezentatywnymi wartościami (klucz API, nazwy tabel, ogólne nazwy pól). Problem: pojawia się błąd Y na wejściu X. Po prostu znajdź błąd logiczny w tym reprezentatywnym kodzie i wyjaśnij poprawioną wersję. [kod reprezentatywny]”
Wskazówka: jeśli masz wątpliwości, wykonaj ten test: „Czy moja organizacja miałaby kłopoty, gdybym napisał to publicznie na forum?” Nawet jeśli odpowiedź jest niejasna, najpierw ją wyjaśnij. Resetowanie jest zawsze tańsze niż późniejsze szukanie wycieku.
Typowe błędy
- Korzystanie z danych wyjściowych bez kompilacji/testowania. „AI napisała” nie jest usprawiedliwieniem; Każdy fragment kodu jest weryfikowany poprzez jego uruchomienie.
- Składanie próśb bez kontekstu. Jeśli nie zostanie podany język, wersja, dane wejściowe i wyjściowe oraz ograniczenia, kod stanie się ogólny i często niepewny.
- Dzielenie się poufnymi informacjami bez zastanowienia. Klucz API, hasło i dane klienta nie powinny być udostępniane bez uprzedniego oczyszczenia.
- Mylenie języka precyzyjnego z dokładnością. Im pewniej mówi sztuczna inteligencja, tym bardziej powinieneś zachować ostrożność; Pewny ton nie jest dowodem.
- Delegowanie decyzji do AI. Decyzja o wprowadzeniu do produkcji, bezpieczeństwa i architektury pozostaje w gestii inżyniera; AI produkuje tylko materiały.
Podsumowując
Sztuczna inteligencja przyspiesza powtarzalne i czasochłonne części pracy oprogramowania: kod szkieletowy, tworzenie testów, zawężanie błędów, dokumentacja. Jednakże decyzja i odpowiedzialność pozostają po stronie inżyniera. Każde wyjście musi przejść trzy warstwy kontroli (kompilacja/statyczna, testowanie, źródło). Pisanie podpowiedzi z kontekstem i usuwanie ukrytych informacji to dwa kluczowe nawyki, które będziemy powtarzać w każdej części tego modułu. Kiedy używasz sztucznej inteligencji z dyscypliną, zyskujesz prędkość; jeśli używasz go bez dyscypliny, przenosisz błędy i luki w zabezpieczeniach do produkcji.
Zadanie aplikacji
Wybierz małe zadanie kodowania z własnej pracy lub z wyimaginowanego projektu (np. funkcja sprawdzania poprawności). Najpierw napisz słaby znak zachęty i uzyskaj wynik. Następnie zastosuj potężny wzór podpowiedzi z tej jednostki: dodaj język/wersję, umowę wejścia-wyjścia, ograniczenia i oczekiwania testowe. Połóż oba wydruki obok siebie i zapisz różnicę. Następnie skompiluj solidne dane wyjściowe i przetestuj je z co najmniej trzema przypadkami brzegowymi (format zerowy, zero/ujemny, nieoczekiwany) i zanotuj, co znajdziesz w którym teście.
lista kontrolna
- [ ] Dodałem język, wersję i umowę wejścia-wyjścia do zachęty.
- [ ] Napisałem „Nie wymyślaj, powiedz mi, jeśli nie jesteś pewien” i ograniczenie zakresu.
- [ ] Skompilowałem/uruchomiłem kod, sprawdziłem, czy nie ma ostrzeżeń statycznych.
- [ ] Testowałem z co najmniej trzema przypadkami Edge.
- [ ] Sprawdziłem użyte interfejsy API na podstawie oficjalnej dokumentacji.
- [ ] Wyczyściłem wszelkie tajne kody/dane uwierzytelniające lub użyłem narzędzia korporacyjnego.
- [ ] Potwierdziłem, że decyzja o uruchomieniu produkcji i zabezpieczeniu pozostaje w gestii człowieka.