Dlaczego kod generowany przez AI wymaga ludzkiej recenzji (i czemu to nie problem)

Rozwój oprogramowania przechodzi rewolucję. Narzędzia jak Claude czy ChatGPT pozwalają zamienić pomysł w działający kod w kilka dni. Opisz funkcję, zaakceptuj zmiany, popraw i wdrażaj. To przyspiesza pracę jak nigdy.

Ale diabeł tkwi w szczegółach.

Ostatnio przejrzałem taki kod – prosty wewnętrzny tool, nie krytyczny dla biznesu. Pokazywał, jak wielu z nas koduje w 2024 roku. Nie znalazłem niczego dramatycznego w stylu "AI oszalało". Problemy były przyziemne: aż 28 błędów, głównie związanych z bezpieczeństwem. Większość to luki z listy OWASP Top 10, znane od lat.

To nie wina AI. Chodzi o to, że błyskawiczne budowanie funkcji wyprzedza myślenie o strukturze, która chroni przed kłopotami.

Problem leży w pytaniach, których nie zadałeś

Kod był solidny. Architektura trzymała poziom. Komponenty dobrze podzielone. Biblioteki sensowne. Gdybym pisał to sam w weekend, nikt by nie zauważył różnicy na pierwszy rzut oka.

Różnica kryje się głębiej. W warstwie "przed pierwszym linijkami kodu".

AI świetnie robi to, co każesz. Poproś o system zarządzania użytkownikami – dostaniesz go. Ale nie zapyta sam: kto ma dostęp? Jakie dane są wrażliwe? Gdzie trzymasz autentykację? Co jeśli ktoś ominie frontend?

AI buduje funkcje. Nie architekturę bezpieczeństwa, przy której śpisz spokojnie.

Konkretny przykład: admin bez ochrony

Wyobraź sobie serverless function do operacji admina – tworzenie użytkowników, reset haseł, usuwanie kont. Zwykła sprawa. Zespół słusznie ukrył silne credentials po stronie serwera.

Brakowało sprawdzenia autentykacji.

Nie słabego. Nie złego. Żadnego. Każdy z DevTools, endpointem i POST-em mógłby tworzyć adminów, resetować hasła czy kasować bazę.

Frontend miał poprawne sprawdzenie praw – ukrywał przycisk admina przed zwykłymi userami. Brzmiało bezpiecznie. I było bezużyteczne – bezpieczeństwo w UI to iluzja.

Klasyczny bypass autoryzacji, na liście luk od 2003 roku. AI nie zgłosiło, bo prompt brzmiał: "zbuduj funkcję do tworzenia użytkowników przez admina". Zrobiło to. Nie powiedziałeś, że nie-admini nie mogą.

Klucz: AI nie wie, co pominąłeś w prompcie.

Baza danych bezpieczna tylko na papierze

Inny schemat. Twoja baza ma row-level security – ogranicza dostęp do wierszy na podstawie tożsamości usera. Dobry model, zwłaszcza gdy frontend wysyła API key w JS.

Inżynier poprosił AI o wsparcie multi-user. AI stworzyło migracje z nowymi tabelami i RLS. Super.

Ale pięć starych tabel z danymi biznesowymi? Niewruszone. RLS włączone czy nie – migracja nie sprawdziła, nie włączyła, nie wspomniała.

Wypchnij npm run db:push na czystym środowisku. Nowe tabele zablokowane, stare otwarte dla każdego z netem i endpointem.

AI nie zbłądziło. Po prostu zrobiło minimum – zabezpieczyło nowe tabele auth. Nie zapytało: a reszta?

Co to oznacza dla twojego zespołu

Nie chodzi o rezygnację z AI. Szybkość to skarb. Iteracje i szybkie wdrożenia są kluczowe. Ale wymaga to dyscypliny: doświadczeni inżynierowie muszą oceniać architekturę, nie tylko składnię.

Oto, co działa:

Stwórz checklistę bezpieczeństwa przed startem. Pytaj: kto woła ten endpoint? Co jeśli bez praw? Dane world-readable? Każda tabela z RLS? Dokumentuj założenia.

Seniorzy robią threat modeling, nie czytanie linijka po linijce. Te 28 błędów to nie literówki. To braki w designie. AI generuje kod. Ludzie myślą o zagrożeniach.

W promptach precyzuj auth i authz. Zamiast "endpoint do userów", napisz: "endpoint do userów tylko dla zalogowanego admina, opisz założenia autentykacji". To zmusza AI do myślenia.

Testuj autoryzację oddzielnie. Sprawdź, że nie-auth nie może nic zrobić. Nie tylko, że auth może.

Schemat, który musisz ogarnąć

AI nie generuje złego kodu. Jest mistrzem w robieniu dokładnie tego, co każesz. I zerem w wykrywaniu pominięć.

To zaleta, nie wada – narzędzia mają słuchać promptów, nie wymyślać wymagań. Ale odpowiedzialność spada na ciebie. AI nie myśli o bezpieczeństwie za ciebie. Wykonuje twoje decyzje na skalę.

W moim kodzie wystarczyło ludzkie "hej, endpoint potrzebuje auth". Poprawka w minuty. Stara luka kontra nowy workflow – wygrał workflow, bo ktoś czujny patrzył.

Model na lata: AI dla prędkości, ludzie dla architektury. Oba niezbędne.

Chcesz uniknąć takich pułapek w kodzie? W NameOcean widzimy, jak startupy walczą z długiem technicznym po szybkich wdrożeniach. Nasz platforma hostingu chmurowego ma wbudowane mechanizmy bezpieczeństwa – rate limiting, zarządzanie API keyami, audit logging. Działa zawsze, nawet jeśli zapomnisz o to poprosić. Jedna rzecz mniej na głowie, gdy team leci na pełnych obrotach.