Współczesny rynek wymaga od firm bardzo szybkich decyzji i adaptacji do zmieniających się warunków rynkowych, żeby zachować przewagę konkurencyjną. Szybkość wdrożenia produkcyjnego pomysłów, które mogą generować przychody, ma szczególne znaczenie zwłaszcza w okresie spowolnienia gospodarczego, kiedy trudniej niż wcześniej o wzrosty w wynikach. W tym kontekście nie powinna dziwić rosnąca popularność no-code, low-code czy vibe coding.
Na czym polega kodowanie bez kodu?
No-code czy low-code polega na korzystaniu z technologii przez osoby, które nie potrafią programować albo znają zaledwie podstawy programowania. Osoby takie tworząc aplikacje wykorzystują platformy, które w oparciu o wizualne interfejsy, gotowe komponenty i logikę „przeciągnij i upuść” pozwalają tworzyć działające rozwiązania. Vibe coding idzie jeszcze dalej, bo bazuje na pogłębiającej się automatyzacji i docelowo – eliminacji pracy człowieka w tym procesie dzięki użyciu dedykowanego „programującego” AI. Takie podejście ma tyle samo zwolenników co przeciwników, ale oceniając jego korzyści i zagrożenia, jak zawsze można powiedzieć, że finalnie „to zależy”. Jakie są jego praktyczne zalety i wady?
Potencjalne korzyści „vibe coding” dla biznesu to niezaprzeczalnie:
- szybsze wdrażanie rozwiązań: możliwość samodzielnego zrobienia działającej aplikacji znacząco skraca czas potrzebny na stworzenie i wdrożenie nowego rozwiązania; dzięki prostocie obsługi i dostępności gotowych komponentów, firmy mogą szybciej reagować na potrzeby rynku i wdrażać innowacyjne rozwiązania,
- uniezależnienie od zewnętrznych dostawców: minimalizacja ryzyka „utknięcia” w określonej technologii zastosowanej przez dostawcę oprogramowania, możliwość samodzielnego rozwoju aplikacji,
- redukcja kosztów: wydatki na tworzenie aplikacji w pełnym cyklu – projektowanie, testowanie, debugowanie i produkcja, są znaczącą pozycją w budżetach nie tylko dużych korporacji,
- zaangażowanie w proces osób o najlepszej wiedzy o procesach operacyjnych: lepsze zrozumienie potrzeb biznesowych i tworzenia bardziej dopasowanych rozwiązań szybciej, bo bez potrzeby tłumaczenia pomysłów „biznesu” na język programowania oraz większe zaangażowanie pracowników w implementację.
Ryzyka i wyzwania związane z „vibe codingiem” można sprowadzić do:
- ograniczenia funkcjonalności: gotowe rozwiązania siłą rzeczy nie są personalizowane, więc mogą oferować ograniczoną funkcjonalność w porównaniu do tradycyjnego programowania, mogą więc nie być w stanie obsłużyć skomplikowanych logik biznesowych, niestandardowych integracji lub specyficznych wymagań technicznych,
- problemy ze skalowalnością i wydajnością: aplikacje stworzone bez przejścia przez cały cykl tworzenia oprogramowania mogą zaskoczyć twórców „zadyszką” przy zwiększaniu obciążenia w miarę wzrostu skali realizowanych w nich procesów, co będzie wymagało analizy potrzeb systemowych „post factum” (co może zdublować prace w porównaniu do standardowej ścieżki),
- trudności w utrzymaniu i rozwoju: modyfikowanie i rozwijanie aplikacji przy braku dostępu do kodu źródłowego i nieznajomości pełnej architektury systemu, ograniczeniach co do możliwości debugowania oraz braku wiedzy o wpływie aktualizacji oprogramowania systemowego (i innych „back endowych” komponentów) może być utrudnione,
- zależność od użytej platformy: mimo podobieństw związanych ze stosowanymi rozwiązaniami, platformy dostarczające środowiska do vibe codingu różnią się między sobą, co może powodować trudności z migracją do innego środowiska bez wsparcia technicznego;
- kwestie bezpieczeństwa: brak odpowiedniej wiedzy i doświadczenia związanego z projektowaniem może spowodować, że w aplikacji powstanie luka, która pozwoli na dostęp do danych osobom nieuprawnionym, a nie zostanie wykryta przez twórcę; ryzyko jest tym większe im bardziej aplikacja ma być zintegrowana z innymi systemami firmy, szczególnie w kwestii szyfrowania danych i zarządzania uprawnieniami;
- problem odpowiedzialności za luki w kodzie: pracownicy realizują działania z limitem odpowiedzialności, wynikającym z przepisów kodeksu pracy, a osoby na B2B mogą nie mieć jasno zdefiniowanej odpowiedzialności, co będzie stanowiło problem zwłaszcza w razie braku procedur dotyczących stosowania AI w firmie (więcej możesz przeczytać tutaj).
Kluczowe jest to, co chcemy zautomatyzować
Decydującym czynnikiem przy ocenie, czy korzyści z vibe codingu przeważają nad ryzykiem, jest charakter procesów, które mają być zautomatyzowane za pomocą samodzielnie tworzonych aplikacji. Istotne są również wymagane funkcjonalności, przewidywana skalowalność rozwiązania i jego cykl życia.
Szczególną uwagę należy zwrócić na kwestie bezpieczeństwa danych. Czy tworzone rozwiązanie będzie miało dostęp do firmowych baz danych? Jeśli tak, kluczowe staje się uwzględnienie ryzyka ujawnienia poufnych informacji, które mogą podlegać szczególnym regulacjom, lub przypadkowego usunięcia danych z serwerów. Czy aplikacja będzie przetwarzać dane klientów lub kontrahentów? W takim przypadku niezbędne jest zapewnienie zgodności z przepisami o ochronie danych osobowych (RODO) i wymogami dotyczącymi prywatności. Należy również rozważyć, czy aplikacja będzie analizować dane, które mogą zakwalifikować ją jako system AI wysokiego ryzyka (np. dane dotyczące zdrowia, finansów lub zachowań użytkowników).
Co to oznacza dla biznesu? Nie należy zostawiać rozwiązań związanych z samodzielnym tworzeniem aplikacji w sferze niedomówień. Wiele polskich firm ma świadomość samodzielnego korzystania przez pracowników z usprawnień bazujących na AI. Nie zabrania wprost ich używania, ale nie określa też na co pracownicy powinni zwracać uwagę decydując się na usprawnienia. W praktyce uregulowanie tych kwestii wcale nie musi być ani uciążliwe, ani kosztowne.
Podmioty KSC nie mają pełnej swobody korzystania z vibe codingu
Analiza kodu źródłowego i opracowanie dokumentacji systemu odgrywają kluczową rolę w zapewnieniu bezpieczeństwa informacji zgodnie z normą ISO/IEC 27001. W załączniku A tej normy jest kilka punktów, które określają zabezpieczenia w tych obszarach. Co to oznacza?
Bez wsparcia ze strony dostawcy platformy, który wykona i udostępni analizę kodu stosowanych rozwiązań trudno będzie zapewnić zgodność z tym standardem. Dodatkowo ograniczenie etapów tworzenia oprogramowania przez eliminację projektowania architektury i przeprowadzania testów bezpieczeństwa, stanowi niezgodność z wymogami bezpiecznego programowania. Można oczywiście wprowadzić odpowiednie zapisy w dokumentacji systemu lub wykluczyć dane zabezpieczenie, jednak oznacza to konieczność akceptacji ryzyka związanego z taką sytuacją, które to ryzyko stanie się rezydualnym. Co ma doniosłe konsekwencje dla stanu cyberbezpieczeństwa organizacji, która wykona taki krok. Ryzyko w imię postępu i pogoni za jeszcze szybszym rozwojem.
Jeżeli chcesz zobaczyć podsumowanie dotyczące ryzyk biznesowych od strony przepisów prawa, zapraszam do lektury artykułu na LinkedIn i śledzenia naszych kolejnych publikacji, gdzie pojawią się również treści dotyczące ryzyk i wymogów wynikających z przepisów regulującymi tworzenie sztucznej inteligencji.
