AI w kodowaniu: gdzie naprawdę pomaga, a gdzie przeszkadza

Gdy produkt stworzony głównie za pomocą AI trafia do Wix za 80 milionów dolarów zaledwie pół roku po debiucie, łatwo dojść do wniosku, że narzędzia AI do kodowania to po prostu czysta wygrana. Prawda jest jednak bardziej fascynująca i wymaga więcej niż jednego zdania: te narzędzia świetnie działają w jednym rodzaju pracy, a kompletnie zawodzą w innym. Zespoły, które rozumieją tę różnicę, dostarczają szybciej — bez ukrytego długu technicznego.

Problem z odczuciami

Badanie METR zabrało doświadczonych programistów do rozwiązywania realnych problemów w ich własnych, dużych codebase'ach i zmierzyło faktyczny czas pracy z pomocą AI i bez niej. Zanim zaczęli, uczestnicy szacowali, że AI przyspieszy ich o około 24%. Po zakończeniu pracy mówili o 20%. Tymczasem rzeczywisty pomiar pokazał, że z pomocą AI poruszali się o 19% wolniej.

Ta rozbieżność między odczuciami a rzeczywistością to najważniejsze odkrycie w badaniach nad AI w kodowaniu. Asysta AI przyspiesza etap pisania kodu, ale spowalnia etap przeglądu. I ludzie są fatalni w szacowaniu tego drugiego kosztu, bo czuje się on jak zwykła praca. Piętnaście minut zaoszczędzone na szkielecie projektu wygląda jak wygrana. Dwadzieścia pięć minut spędzone na debugowaniu "prawie dobrego" kodu, który wypluł nam model, nie czuje się jak porażka — czuje się jak normalna robota.

Gdzie przyspieszenie naprawdę działa

Badania są zgodne w jednym obszarze: nowy kod w nieznanym terenie. Kontrolowane badanie GitHuba wykazało, że programiści zbudowali serwer web od zera o 55% szybciej z Copilot. Eksperymenty terenowe w różnych firmach pokazały o 26% więcej ukończonych zadań, a młodsi programiści zyskali 27-39% więcej outputu przy krótkich zadaniach. Prace laboratoryjne McKinsey wskazują, że dokumentacja i completely new kod powstają w mniej więcej połowie czasu.

To jest profil MVP. Pusty projekt, stos technologiczny, którego się uczysz, boilerplate, który właściwie sam się kopiuje, albo funkcja, którą da się opisać krótkim promptem. Przy takiej pracy narzędzia robią dokładnie to, co obiecuje reklama. Kluczowe jest jednak zrozumienie, że to nie jest całość programowania.

Gdzie pojawia się spowolnienie

Spowolnienie w badaniu METR wystąpiło dokładnie tam, gdzie można się było spodziewać: doświadczeni programiści utrzymujący codebase'y, które sami pisali od lat. Model wypluł kod brzmiący wiarygodnie dla systemu, którego nie rozumiał, programista poświęcił czas na ocenę, czy jest poprawny — i ta ocena kosztowała więcej niż samo napisanie funkcji.

Na skali to właśnie tam zespoły wpadają w kłopoty. Startup, który mocno polega na AI kodowaniu przy budowie MVP, łapie product-market fit, zaczyna rosnąć, i trzy miesiące później odkrywa, że "działający kod" zawiera kontrole row-level security zakomentowane, panel admina dostępny dla każdego uwierzytelnionego użytkownika, i klucze API, które trafiły do client-side bundle. AI napisało szybko. AI wprowadziło też security review, której nikt nie zaplanował.

Badanie Faros AI, które objęło ponad 10 000 programistów w realnych zespołach, wykazało, że asysta AI faktycznie spowalniała zespoły w 20-40% scenariuszy — szczególnie w codebase'ach powyżej 100 000 linii, gdzie context window nie jest w stanie pomieścić całego obrazu. To jest problem brownfield, i to jest miejsce, gdzie większość dojrzałych zespołów spędza większość czasu.

Rachunek za bezpieczeństwo, którego nikt nie wspomina

Co tydzień pojawia się kolejna historia: startupowy kod wygenerowany przez AI naraził dane użytkowników, albo wdrożenie z asystą AI zostawiło otwarty port bazy danych, albo prompt injection znalazł drogę do produkcyjnego systemu. To nie są egzotyczne edge cases. To przewidywalny output wkierowania narzędzia zoptymalizowanego pod wiarygodnie brzmiący kod w obszary wrażliwe na bezpieczeństwo — bez eksperta od security, który wynik sprawdzi.

Wzorzec jest spójny. Narzędzia AI do kodowania są trenowane na publicznie dostępnym kodzie, a ten kod zawiera mnóstwo kodu z znanymi podatnościami, źle skonfigurowanymi uprawnieniami i zahardcodowanymi sekretami. Gdy prosisz takie narzędzie o zbudowanie systemu autoryzacji użytkowników albo integracji płatniczej, dostajesz często wiarygodnie wyglądającą wersję tego, jak to może wyglądać — co może, ale nie musi być wersją bezpieczną.

Dla startupów działających szybko to krytyczne ryzyko. Nie budujesz tylko MVP — budujesz reputację i powierzchnię compliance. Wyciek danych w pierwszym roku to nie problem techniczny. To problem, który kończy firmę.

Praktyczny framework

Badania wskazują na jasny model operacyjny:

Używaj AI agresywnie w pracy greenfield. Nowe projekty, prototypy, szkielety, nieznane stosy technologiczne i dobrze zdefiniowane funkcje — tu przyspieszenie jest realne i duże. To jest większość tego, co sprawia, że MVP ląduje na produkcji, i to jest miejsce, gdzie te narzędzia zarabiają swoją subskrypcję.

Używaj AI wybiórczo w pracy brownfield. W codebase'cie, który znasz dobrze, albo przy czymkolwiek dotykającym autoryzacji, płatności czy danych użytkowników — traktuj output AI jako pierwszy szkic, który wymaga przeglądu bezpieczeństwa. Czas, który budżetujesz na ten przegląd, to prawdziwy koszt narzędzia przy tego typu pracy. Nie daj się nabrać na sygnał "czuję się szybciej" i nie pomijaj tego.

Dostarczaj mało, z testami. Niestabilność w outputcie AI objawia się najbardziej przy dużych, złożonych zmianach. Małe, inkrementalne zmiany z prawdziwym pokryciem testami łapią subtelne błędy, które przechodzą przez przegląd i powodują incydenty na produkcji. To dobra praktyka ogólnie, ale staje się krytyczna, gdy AI jest w pętli.

Hartuj przed kontaktem z użytkownikami. Włącz kontrole row-level security. Usuń sekrety z client-side kodu. Nie kieruj agenta AI na produkcyjną bazę danych. To nie są egzotyczne środki bezpieczeństwa — to baseline dla każdego systemu obsługującego prawdziwe dane użytkowników. AI kodowanie nie zmienia tego baseline'u; po prostu sprawia, że łatwiej go przeoczyć.

Podsumowanie

Narzędzia AI do kodowania są naprawdę użyteczne. Wprowadzają jednak koszty, które są realne, przewidywalne i niemal nigdy nie wspominane w materiałach marketingowych. Zespoły dostarczające najszybciej to nie te, które używają AI do wszystkiego — to te, które używają jej strategicznie, tam gdzie przyspieszenie jest realne, chroniąc jednocześnie części systemu, gdzie poprawność jest ważniejsza niż velocity.

Jeśli budujesz MVP na Vibe Hosting, używaj AI do szybkiego działania na częściach, które mogą się zmieniać. Używaj jej ostrożnie na częściach, które muszą być prawidłowe. A jeśli nie wiesz, które to które — to prawdopodobnie jest twoje następne pytanie.