Generujesz kod przez AI? Możesz stracić fortunę. Ekspert: „To jak chodzenie po polu minowym”
Wiktor Cyrny, My Company Polska: Eksperci z branży IT, z którymi przeprowadzałem wywiady nie raz podkreślali, że żyjemy w czasach, w których programowanie przestało być wiedzą tajemną. Czy dziś rzeczywiście każdy, kto potrafi napisać odpowiednie prompty w wybranym modelu generatywnej AI, może czuć się "twórcą oprogramowania"?
Tomasz Ludward (New Business Developer w Ambiscale): Jesteśmy świadkami fascynującego trendu demokratyzacji tworzenia software'u. Dziś marketing i biznes coraz śmielej „wchodzą w development”. Ta swoboda wyrównuje szanse między osobami nietechnicznymi a ekspertami. Coś, co kiedyś wymagało miesięcy pracy zespołu, dziś może zostać przekute z pomysłu w realizację nawet tego samego dnia. Zaryzykuję tezę, że nigdy w historii łatwość stworzenia skomplikowanej aplikacji czy platformy sprzedażowej nie była tak duża jak w erze LLM-ów.
Brzmi to jak sielanka dla przedsiębiorców. Gdzie zatem tkwi haczyk?
Problem pojawia się w momencie, gdy taki twórca bez doświadczenia uznaje projekt za zakończony. Na tym etapie często nie widzi już potrzeby dalszej weryfikacji pod kątem bezpieczeństwa, skalowalności czy faktycznej gotowości produktu do wejścia na rynek. Proces tworzenia zostaje przedwcześnie zamknięty, podczas gdy jego realne, często bolesne konsekwencje dopiero zaczynają się ujawniać. Obok namacalnych efektów szybko pojawia się cały wachlarz problemów jakościowych w kodzie, których laik po prostu nie dostrzeże.
Czy to właśnie ten moment, w którym do gry wchodzi nowa specjalizacja? W naszej rozmowie przed wywiadem wspomniał Pan o „Sprzątaczu po AI”. Kim on właściwie jest?
To nowy zawód, który rodzi się na naszych oczach. Tak jak kiedyś pojawił się DevOps, tak dziś firmy zaczynają płacić software house’om za „Sprzątaczy po AI” lub „Sprzątaczy po vibe codingu”. Podczas gdy DevOps łączy ekspertów od programowania i serwerów, nowa funkcja to efekt konfrontacji osób walidujących swoje pomysły z rzeczywistością technologiczną. To nie tylko rodzi nieporozumienia, ale przede wszystkim redefiniuje termin długu technologicznego.
Czym różni się „bałagan” zostawiony przez człowieka od tego wygenerowanego przez sztuczną inteligencję?
Przed 2025 rokiem dług technologiczny odnosił się do pracy ekspertów. Oprogramowanie budowano w jasnych ramach kontroli: były testy jednostkowe, code review, audyty bezpieczeństwa czy zgodność z WCAG. Dług z vibe codingu to zupełnie inna para kaloszy. Odpowiedzialność zostaje przeniesiona na narzędzie. Często nie jest to efekt przemyślanego procesu, lecz niewłaściwego lub nieświadomego promptowania. Co gorsza, AI nie posiada mechanizmu refleksji – nie zatrzyma się, gdy stworzy niespójny system. Dlatego „sprzątanie” po AI to nie klasyczne utrzymanie, ale odwracanie długu, który narastał tygodniami. Trzeba na nowo definiować architekturę i tworzyć dokumentację, która nigdy nie powstała.
Jakie jeszcze wyzwania czekają "Sprzątaczy po AI"?
Kiedy jedyną dokumentacją są prompty, których autor już nie pamięta, każda kolejna osoba wchodząca w projekt de facto zaczyna od nowa. I dzieje się to za każdym razem. Można nawet powiedzieć szerzej: każdy nowy zespół zaczyna od zera. W podejściu projektowym nie można bowiem myśleć w kategoriach jednostki - to zawsze ekosystem ról: programistów, project managerów, specjalistów QA i testów jednostkowych, designerów czy ekspertów SEO. Brak dokumentacji i wiedzy o tym, jak system faktycznie działa, generuje dodatkowy czas i koszty dla całego zespołu, a nie tylko dla jednej osoby przejmującej kod.
Jest tu jeszcze jeden istotny wymiar technologiczny. Jeśli myślimy o vibe codingu i osobie, która nie jest programistą, to całą ekspertyzę oddaje się narzędziu. To ono wybiera język, biblioteki, całą metodologię i sposób, w jaki aplikacja zostanie stworzona. Kiedy taki projekt trafia do programisty lub firmy przejmującej aplikację, pojawia się dodatkowe wyzwanie: w zależności od użytej metodologii, osoby sprawdzające i czyszczące kod muszą się znać na tych konkretnych technologiach. Jeżeli był użyty React albo konkretna technologia backendowa, ekspert przejmujący kod musi być w niej biegły. Ta dysproporcja pomiędzy tym, jak coś zostało stworzone, a jak będzie poprawiane i utrzymywane, jest ogromna i w praktyce generuje istotne obciążenie operacyjne.
Wśród problemów wokół tego "bałaganu" pojawia się aspekt widoczności w sieci. Wiele firm uważa, że AI pomoże im napędzić ruch na portalach. Pan jednak ostrzega, że brak nadzoru nad kodem to koniec tradycyjnego SEO i prosta droga do spadku przychodów.
Przez lata wierzono, że za sukces e-commerce odpowiada layout i łatwa ścieżka zakupowa. Z czasem świadomość rosła – doszło SEO, wydajne serwery, kampanie. Bariera sukcesu systematycznie rosła. Kod generowany przez AI jest niezwykle czuły na błędy. Wystarczy jedna błędna struktura danych czy nadmiarowy kod, by wywołać realne skutki biznesowe. Choć Google nie karze bezpośrednio za użycie AI, to błędy techniczne w warstwie serwisu wystarczą, by zachwiać całą konstrukcją. Przez to, z dnia na dzień, mogą spaść m.in. wyniki odwiedzalności strony.
Czyli oszczędność na programiście może nas kosztować pozycję w wyszukiwarce?
Skutkuje to obniżeniem widoczności, spadkiem ruchu, a w konsekwencji realną stratą pieniędzy. Spadek z pierwszej na drugą stronę wyników Google to scenariusz skrajny, ale będący efektem kumulacji błędów. Jak wspomniałem, to pole minowe. Co najgorsze, odwrócenie takiej negatywnej reakcji łańcuchowej rzadko następuje w 24 godziny; to proces rozłożony na tygodnie, a nawet miesiące.
Czy mamy jakiekolwiek twarde dane obrazujące tę nieefektywność? Ile czasu tracimy na poprawianie sztucznej inteligencji?
Dane branżowe są bezlitosne: 67% developerów spędza obecnie więcej czasu na debugowaniu [usuwaniu błędów] kodu wygenerowanego przez AI niż na pisaniu go od zera. To mówi samo za siebie. W profesjonalnym zespole mamy wersjonowanie kodu, środowiska stagingowe i automatyczne testy. Jeśli coś pójdzie nie tak, wiemy dokładnie gdzie. W przypadku projektu AI proces naprawy często sprowadza się do powrotu do samego początku. Nie da się „postawić nogi w drzwi” i wskazać, że błąd powstał przy dziesiątym prompcie.
Wspomina Pan również o zjawisku „ukrytego lock-inu”. Czy przedsiębiorcy nieświadomie uzależniają się od dostawców narzędzi AI?
Dokładnie tak. W przypadku projektu stworzonego przez AI ten proces często sprowadza się niestety do powrotu do samego początku. Niemożliwe jest postawienie nogi w drzwi i powiedzenie: "tu, przy dziesiątym prompcie, była pomyłka". Na każdą aplikację zawsze trzeba patrzeć holistycznie. I przynajmniej dążyć do tego, żeby pewne rzeczy były udokumentowane, bo w przypadku konieczności powrotu czy modyfikacji, identyfikacja problemów będzie po prostu trudniejsza. Szczególnie w systemach CRM czy ERP silne powiązanie narzędzi AI z ich infrastrukturą chmurową tworzy sytuację, w której logika integracji pozostaje uwięziona u dostawcy. Migracja lub użycie tego kodu we własnych systemach staje się ekstremalnie trudne.
Tomasz Ludward, New Business Developer w Ambiscale
Kolejnym „trupem w szafie” wydaje się być bezpieczeństwo i RODO. Czy AI dba o dane naszych klientów?
AI nie myśli o konsekwencjach. Zespół deweloperski wie, że po wdrożeniu następuje etap monitorowania i supportu – AI nie daje żadnej gwarancji. Tymczasem sklepy i aplikacje przetwarzają wrażliwe dane: e-maile, adresy, daty urodzenia. Każdy ten element musi być zgodny z RODO. Analizy wskazują, że ponad 10% aplikacji budowanych na platformach typu Lovable miało podatności mogące prowadzić do nieautoryzowanego dostępu do danych. To ogromne ryzyko prawne i wizerunkowe.
Czy może Pan podać przykład z życia, gdzie vibe coding bez nadzoru doprowadził do ściany?
Klasycznym przypadkiem jest aplikacja, która świetnie działa lokalnie na komputerze twórcy, ale jest niemożliwa do wdrożenia na serwer produkcyjny. Przyczyną bywa brak właściwej konfiguracji zmiennych czy logika działająca tylko w idealnych warunkach „bańki” deweloperskiej. Znam też sytuacje, gdzie działy marketingu miesiącami „ulepszały” serwis z AI. Każda zmiana wydawała się działać, ale ich kumulacja doprowadziła do momentu, w którym serwis trzeba było przepisać od zera, bo fundamenty przestały istnieć.
To wszystko brzmi jak przestroga przed AI. Trochę Pan straszy, a przecież sam znam komercyjne sukcesy founderów, którzy przy tworzeniu nowych aplikacji skorzystali z VibeCodingu. Czy Pan jako ekspert jest przeciwny tej technologii?
Absolutnie nie! Vibe coding jest świetnym narzędziem, jeśli wiesz, po co go używasz. W naszej organizacji AI realnie skraca czas pracy nad żmudnymi zadaniami. Przykład? Sortowanie dwóch milionów plików zajęło nam jeden dzień zamiast tygodnia. Dodanie 50 tysięcy przekierowań zajęło 30 godzin zamiast... 36 miesięcy manualnej pracy. To są konkretne metryki.
Jaka jest zatem złota zasada bezpiecznego korzystania z AI w biznesie?
Tomasz Ludward: Kluczowa różnica polega na tym, że doświadczony deweloper rozumie, co robi, weryfikuje output i odpowiada za architekturę. AI pozostaje narzędziem, a nie autonomicznym budowniczym. Warto przyjąć zasadę: prototypujmy śmiało, wdrażajmy ostrożnie. Jeśli projekt wychodzi z fazy eksperymentu i ma obsługiwać użytkowników, dane czy płatności, musi zaangażować się w to ktoś, kto rozumie technologię. Pamiętajmy: koszt profesjonalnego przeglądu kodu jest wielokrotnie niższy niż koszt sprzątania po tym, co AI zbudowało bez żadnej kontroli.
