Jakie błędy popełniają deweloperzy pracując z asystentami AI?

Asystenci AI tacy jak Copilot, Claude i wbudowane modele w Cursor zmieniły szybkość pisania kodu. Nie zmieniły szybkości, z jaką kod musi być przeglądany. Większość uszkodzeń, które widziałem w kodzie asystowanym AI, wynika z kilku powtarzających się nawyków, a nie z samych modeli.

Akceptowanie sugestii bez ich przeczytania

Najwększym problemem jest zaakceptowanie uzupełnienia przez tab, bo wygląda wiarygodnie i się kompiluje. Wiarygodne nie znaczy poprawne. Widziałem, jak sugerowany zapytanie SQL po cichu usunęło klauzulę WHERE podczas refaktoryzacji, a osoba je zaakceptowała, bo nazwy zmiennych się zgadzały. Jeśli nie czytasz każdej linii, którą dostaniesz od asystenta, z taką samą szybkością jak pull requesta kolegów, będziesz wysyłać kod, którego nie rozumiesz. Traktuj każdą sugestię jako pierwszy szkic od juniora, który jest szybki, ale nie pamięta konwencji twojego kodbase'u.

Zaufanie asystentowi w kodzie wrażliwym na bezpieczeństwo

Asystenci AI są trenowani na ogromnych ilościach publicznego kodu, a wiele tego kodu ma wbudowane problemy bezpieczeństwa. Poproś o szybki handler wysyłania plików, a często dostaniesz coś bez sprawdzenia rozszerzenia, bez limitu rozmiaru i ze ścieżką zbudowaną przez konkatenację stringów zamiast os.path.join lub bezpiecznego wywołania biblioteki. Taka sama historia z auth: asystenci uwielbiają sugerować przechowywanie JWT w localStorage, albo porównywanie sekretów z == zamiast porównania w stałym czasie. Nic z tego nie jest złośliwe, to po prostu statystycznie częste w danych treningowych. Dla wszystkiego dotykającego autentykacji, I/O plików, deserializacji lub SQL, napisz logikę sam lub uruchom wyjście AI przez te same pytania modelowania zagrożeń, które zadałbyś każdemu nowemu kodowi: co się dzieje ze złośliwym wejściem, co się dzieje jeśli to wywołanie się nie powiedzie, kto jeszcze może dostać się do tego endpointa.

Pozwalanie mu wymyślać zależności i API

Modele halucynują nazwy pakietów i sygnatury funkcji z całkowitą pewnością. To jest problem "slopsquattingu" — atakujący rejestrują fałszywe nazwy pakietów, które modele często sugerują, więc niezweryfikowany pip install lub npm install może ściągnąć coś, co w ogóle nie jest twoją biblioteką logowania. Zanim dodasz jakąś zależność, którą sugeruje asystent, sprawdź, czy naprawdę istnieje na PyPI lub npm, sprawdź liczbę pobrań i datę ostatniej publikacji, i przejrzyj źródła, jeśli są wystarczająco małe. Ta sama ostrożność dotyczy wywołań API: jeśli asystent odwołuje się do metody, której nie rozpoznajesz, sprawdź rzeczywistą dokumentację zanim założysz, że istnieje.

Utrata mentalnego modelu własnego kodu

Kiedy piszesz kod sam, budujesz mentalną mapę tego, dlaczego każdy element istnieje. Kiedy akceptujesz duże bloki kodu wygenerowanego przez AI w trakcie sesji, ta mapa szybko się wyczerpuje. Potem bug pojawia się trzy tygodnie później i debugujesz kod, którego nigdy naprawdę nie napisałeś i nie pamiętasz w pełni. Rozwiązanie nie polega na unikaniu kodu wygenerowanego przez AI, a na spowolnieniu, aby wyjaśnić każdy fragment sobie albo kolegom z zespołu, zanim go scalić. Jeśli nie potrafisz wyjaśnić, co funkcja robi i dlaczego to robi w taki sposób, nie scalaj jej jeszcze.

Pomijanie testów bo kod