Vibe Coding

Jędrzej
17 gru 2025
5 minut(y) czytania

Czym jest vibe coding?

Cytując Wikipedię [2]:

Vibe coding to podejście do tworzenia oprogramowania oparte na chatbotach, w którym programista opisuje projekt lub zadanie dużemu modelowi językowemu (LLM), który generuje kod na podstawie podpowiedzi. Programista nie weryfikuje ani nie edytuje kodu, lecz korzysta wyłącznie z narzędzi i wyników podanych przez LLM, aby go ocenić i prosi LLM o wprowadzenie ulepszeń. W przeciwieństwie do tradycyjnego kodowania wspomaganego sztuczną inteligencją, programista unika analizy kodu, akceptuje sugerowane przez sztuczną inteligencję uzupełnienia bez weryfikacji przez człowieka i koncentruje się bardziej na iteracyjnym eksperymentowaniu niż na poprawności lub strukturze kodu.

Innymi słowy, mówimy o tworzeniu oprogramowania, w którym żaden człowiek nigdy nie widział, a tym bardziej nie rozumiał, kodu źródłowego. Czy może to być korzystne dla firm? Oczywiście, że tak. Ale może być też szkodliwe.

Dlaczego?

Zanim zagłębimy się w potencjalne korzyści i zagrożenia, zastanówmy się najpierw, dlaczego ktoś miałby chcieć tworzyć i używać niestandardowych aplikacji.

Z perspektywy dużej firmy korzyści są oczywiste. Mogą mieć narzędzie, które rozwiązuje problem, a wdrożenie tego narzędzia zajmuje kilka dni (albo godzin), a nie kilka miesięcy. A co najlepsze, nie potrzeba do tego wysoko opłacanego informatyka. Każdy w firmie może stworzyć aplikację, z której będą mogli korzystać wszyscy. Aplikacja jest gotowa w mgnieniu oka, można ją modyfikować niemal od ręki, a koszt wdrożenia wyniósł 0 EUR. Świetnie, prawda?

Coś podobnego już się dzieje; wystarczy pomyśleć o VBA lub Power Automate. Użytkownicy mogą tworzyć własne automatyzacje niektórych zadań. To fajne, ale wymaga pewnej znajomości narzędzia, którego się używa. Nie każdy rozumie, jak skomplikowany może być Power Automate. Jak trudno jest czasami sprawić, by faktycznie robił to, czego chcemy. VBA jest jeszcze trudniejszy i wymaga odpowiedniej wiedzy programistycznej, niestety.

W przypadku vibe coding nie są wymagane żadne umiejętności. Wystarczy zapytać LLM, czego chcesz, a on to dla Ciebie stworzy. Chcesz czegoś innego? Po prostu zapytaj ponownie. Kodowanie AI może przyspieszyć Twój przepływ pracy, niezależnie od tego, czy jesteś programistą, czy przeciętnym użytkownikiem. Wydaje się to błogosławieństwem dla pracowników pod ciągłą presją, by dawać więcej za mniej.

Potencjalne przypadki użycia

Potencjalne zastosowania są niemal nieograniczone. Wystarczy pomyśleć o dowolnym powtarzalnym zadaniu, które wykonujesz każdego dnia. Możesz stworzyć do niego aplikację.

Kilka prostych pomysłów, prawdopodobnie możliwych do zrealizowania przy użyciu Power Automate lub po prostu odrobiny Pythona ;)

Przygotuj dzienny raport giełdowy, wrzuć go do szablonu firmowego i wyślij swojemu szefowi.
Aplikacja do rejestracji na imprezę firmową, zawierająca przycisk umożliwiający przekazanie darowizny na cele charytatywne.
Automatycznie generowane firmowe e-maile. Wpisujesz wiadomość, a aplikacja umieszcza ją na firmowym papierze i wysyła. Może to obejmować panel śledzenia aktywności, który pozwala podejrzeć, ile osób otworzyło Twoją wiadomość.

Pomysły są nieograniczone.

Czym jest sztuczna inteligencja?

Czy naprawdę wiesz, czym jest AI? Sztuczna inteligencja, mówisz? W pewnym sensie. To właśnie oznacza AI, ale narzędzia, które obecnie są reklamowane jako narzędzia AI, nie mają nic wspólnego z inteligencją. To tak zwane „Duże Modele Językowe” (z angielskiego Large Language Models, LLMs). To bardzo skomplikowane modele statystyczne, które przewidują, jakie słowa powinny zostać wyświetlone na podstawie zapytania. Obliczają pierwsze słowo, a następnie wracają do modelu, aby obliczyć drugie, trzecie i tak dalej. Zostały zaprogramowane tak, aby symulować ludzką osobowość. Spróbuj, wpisz coś niemiłego w wiersz poleceń ChataGPT, a program zacznie Cię przepraszać.

Maszyna nie jest świadoma ani inteligentna!

Wszystkie LLMy wchłonęły całą wiedzę internetu. Każde możliwe źródło treści stworzonych przez człowieka znajduje się w ich bazie danych. Odpowiedzi, które widzisz, opierają się na tym, co LLM widział wcześniej na jakimś forum lub stronie internetowej. To nie jest odpowiedź inteligentnej maszyny; to replika ludzkiego zachowania, symulacja.

Jakie są ryzyka?

Korzystając z programów LLM, które nie są autoryzowane w Twojej firmie, możesz niechący powodować wycieki danych dane. Czy wiesz, że wszystkie informacje, które prześlesz do tych narzędzi, zostaną wykorzystane do trenowania modelu dla wszystkich innych? Może on zatem odpowiedzieć na czyjeś zapytanie, korzystając z Twoich ściśle tajnych dokumentów. Dotyczy to nie tylko kodowania, ale wszystkich zapytań.

Kod, który generuje LLM, to kod kogoś innego, tylko nieznacznie zmieniony, aby pasował do twojego celu. LLM tego nie rozumie. Co się więc stanie, jeśli pierwotny autor kodu dowie się, że korzystasz z jego pracy? Może pozwać firmę.

Czy Twoja aplikacja jest bezpieczna? Jesteś pewien? Jak możesz zidentyfikować i śledzić wszystkie biblioteki, których LLM użył do wygenerowania Twojej aplikacji? Skąd możesz mieć pewność, że nie ma w nich luk bezpieczeństwa? Ponieważ nigdy nie napisałeś ani jednej linijki kodu, nie masz pojęcia, czy aplikacja jest bezpieczna, czy nie. Co gorsza, nie masz pojęcia, jak ją przetestować. Jednym z najprostszych problemów jest monit logowania i atak typu SQL injection. Co by się stało, gdybym wpisał swoją nazwę użytkownika jako TEST’ OR ´x´=´x i to samo jako hasło? Gdyby kod został napisany przy użyciu tylko podstawowej składni SQL, właśnie bym się zalogował, nie znając loginu.

Jeśli aplikacja korzysta z zewnętrznego interfejsu API, czy jest on bezpieczny? Skąd wiesz, jakie informacje są przesyłane przez ten interfejs? Możliwe, że wysyłasz dane do atakującego, a LLM nie poinformuje Cię o tym, ponieważ nie rozumie kontekstu bezpieczeństwa. Nazywa się to „atakiem na łańcuch dostaw”.

Jeśli Twoja aplikacja kiedykolwiek się rozrośnie i stanie się mega ważna dla firmy, kierownictwo może zdecydować o zatrudnieniu prawdziwego programisty do jej utrzymania i dalszego rozwoju. Taka osoba będzie potrzebowała dużo czasu, aby zrozumieć potencjalnie chaotyczny i nieudokumentowany kod napisany przez LLM. To spowalnia rozwój i może prowadzić do niewykrycia problemów bezpieczeństwa. Nazywam to „koszmarem debugowania”.

Przeciwdziałanie

Cały temat vibe codingu to poważny problem dla wewnętrznego działu IT. Podpada on pod „shadow IT”, gdzie użytkownicy znajdują sprytne sposoby na robienie rzeczy, których nie powinni robić.

Jeśli pozwolisz użytkownikom na tworzenie własnych aplikacji i akceptujesz ryzyko, w porządku. Nadal jednak zalecam wymuszenie weryfikacji kodu przez wewnętrzny dział IT. Przeprowadź testy penetracyjne, nawet te proste, jak opisane wcześniej ataki typu SQL injection. Ogranicz dostęp, jaki przyznajesz aplikacji. Uruchom ją w zabezpieczonej sieci lub na zabezpieczonej maszynie wirtualnej. Upewnij się, że naprawdę rozumiesz, co robi aplikacja, co wysyła i dokąd. Poinformuj użytkowników, że mogą nieumyślnie ujawniać dane.

Moim zdaniem, korzystanie z LLM-ów do pisania kodu ma sens tylko wtedy, gdy sam taki kod napiszesz i poprosisz sztuczną inteligencję o pomoc w określonych kwestiach. Ale nawet wtedy nie powinieneś po prostu bezmyślnie kopiować i wklejać kodu. Poświęć czas na jego przeczytanie, zrozumienie i upewnienie się, że nie robi niczego dziwnego ani nieoczekiwanego. Sam tak robię to za każdym razem, gdy utknę. LLM-y były bardzo pomocne w rozwijaniu wielu małych narzędzi, z których korzystam tylko ja, ale także w aplikacjach obejmujących całą firmę. Zawsze jednak poświęcałem czas na przeczytanie podanego kodu, sprawdzanie zależności i bibliotek.

Podsumowanie

Nie jestem przeciwny vibe codingowi, jeśli Twoja firma ma możliwości wdrożenia odpowiednich zabezpieczeń. Ten proces z pewnością może usprawnić wiele procesów w Twojej firmie. Musisz jednak edukować swoich użytkowników o zagrożeniach związanych z używaniem LLM do kodowania. Jeśli sam jesteś programistą, sugeruję korzystanie z narzędzi AI jako wsparcia, a nie ich zastępstwa. Pamiętaj, aby zawsze pisać kod zgodnie z zasadą „secure by design”.