Kodowanie na wyczucie i bezpieczeństwo: co liderzy muszą wiedzieć o zespołach tworzących z użyciem AI
Nierówność wiedzy o AI: Liderzy mierzą się z wyzwaniami, ponieważ członkowie zespołów wyprzedzają ich pod względem znajomości narzędzi i możliwości AI.
Wyjaśnienie kodowania na wyczucie: Pracownicy nietechniczni tworzą funkcjonalne narzędzia za pomocą poleceń, niwelując lukę między pomysłem a jego realizacją.
Obawy dotyczące bezpieczeństwa: Niezarządzane narzędzia do kodowania na wyczucie stwarzają ryzyko niewłaściwego przetwarzania i ujawnienia danych, szczególnie podatność na wyciek danych osobowych.
Konsekwencje kosztowe: Niezoptymalizowane korzystanie z narzędzi AI może prowadzić do nieoczekiwanych wydatków i ryzyka finansowego.
Problemy ze skalowalnością: Skuteczne narzędzia stworzone poprzez kodowanie na wyczucie wymagają profesjonalnego nadzoru, aby zapewnić ich skalowalność i niezawodność.
Umówmy się: wszyscy jesteśmy w różnych miejscach, jeśli chodzi o AI. Dla liderów może to być niepokojące — częściej niż kiedykolwiek osoby im podlegające przewyższają swoich menedżerów wiedzą na temat AI i jego wdrażania, działają szybko i często coś psują.
Choć wiele organizacji zachęca do otwartego eksplorowania narzędzi AI, vibecoding — kolejny etap wdrażania AI dla wielu nietechnicznych pracowników — to przygoda wiążąca się z różnym stopniem ryzyka, zależnie od tego, co tworzysz, dla kogo to tworzysz oraz jakie dane są przechowywane i wykorzystywane.
Staje się to szczególnie powszechne w zespołach zarządzania projektami i operacyjnych, gdzie tworzenie własnych narzędzi jest często oczywistą odpowiedzią na potrzeby procesów — a dzięki agentom AI do programowania uzyskanie zgody na ich tworzenie nigdy nie było łatwiejsze.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Aby pomóc nam zrozumieć, na co zwracać uwagę, gdy zespoły zaczynają coś tworzyć, zaprosiłem Tima Fishera, wiceprezesa DPM ds. AI, aby przedstawił nam najważniejsze informacje. Ten artykuł jest przeznaczony dla każdego, kto usłyszał: „Hej, szefie, zobacz, jaki fajny projekt stworzyłem w Claude!” — mamy nadzieję, że okaże się pomocny.
Czym właściwie jest vibecoding i dlaczego jest naprawdę wartościowy?
Na potrzeby tego artykułu vibecoding oznacza programowanie za pomocą poleceń — konkretnie przez osobę nietechniczną. Różni się to od sytuacji, w której programista korzysta z narzędzia takiego jak GitHub Copilot, ponieważ człowiek nadal wnosi do pracy istotną wiedzę techniczną. Mówimy o dyrektorze finansowym, koordynatorze operacyjnym czy kierowniku projektu, który nigdy nie napisał ani jednej linijki kodu, a teraz tworzy funkcjonalne narzędzia, używając wyłącznie poleceń w języku naturalnym.
Początkowa opinia Fishera może cię zaskoczyć: jest on tym autentycznie entuzjastycznie nastawiony. „Podoba mi się pomysł, że osoby, które nie potrafią programować, mogą teraz przenieść to, czego chcą, ze swojej głowy do formy, którą każdy może zobaczyć, z którą każdy może się bawić i z której każdy może korzystać” — mówi. „To sposób komunikacji, który wcześniej nie istniał”. Postrzega to mniej jako zdolność techniczną, a bardziej jako nowy środek komunikacji — taki, który zmniejsza dystans między wizją a realizacją w przypadku osób, które zawsze miały pomysły, ale brakowało im technicznego słownictwa, aby je wyrazić.
Vibecoding to sposób komunikacji, który wcześniej nie istniał.
„To trochę przypomina wyzwania, z którymi ludzie mierzą się podczas pracy z zespołami projektowymi” — wyjaśnia Fisher. „Nie potrafię narysować nawet ludzika z patyczków. Kiedy więc chcę przekazać komuś coś wizualnego, bardzo się cieszę, że istnieją teraz narzędzia, które pozwalają mi wyjaśnić coś za pomocą wielu przemyślanych słów, w czym jestem dobry, a na drugim końcu otrzymać coś, na co ktoś, kto zna się na projektowaniu, spojrzy i powie: «Ach, teraz już wiem, o co ci chodzi»”.
Dla liderów ta zmiana perspektywy ma znaczenie. Odruch całkowitego zablokowania tego zjawiska pomija to, co jest w nim naprawdę użyteczne: vibecoding może przyspieszyć uzgadnianie, szybciej ujawniać pomysły i dać nietechnicznym członkom zespołu nowy sposób na wnoszenie wkładu. Pytanie nie brzmi, czy na to pozwolić. Chodzi o to, czy rozumiesz, co dzieje się po stworzeniu narzędzia.
Gdzie kończy się wartość — a zaczyna ryzyko
Fisher starannie oddziela fazę „komunikacji” w vibecodingu od tego, co zwykle następuje później — i właśnie wtedy zmienia ton. „Myślę, że wartość tego rozwiązania prawdopodobnie w większości przypadków kończy się właśnie w tym miejscu” — mówi. „To znacznie lepszy sposób komunikowania pomysłów i kierunku działania. Jednak odkrywamy, że później mogą wydarzyć się rzeczy wykraczające poza: «Hej, zobacz, przekazałem ci pomysł, teraz posługujemy się wspólnym językiem». I właśnie wtedy robi się przerażająco”.
Problemem nie jest formułowanie poleceń. Problemem jest wdrożenie. To moment, w którym prototyp staje się narzędziem używanym przez prawdziwych ludzi, przechowującym prawdziwe dane i działającym w tle na prawdziwej infrastrukturze — a osoba, która je stworzyła, nadal nie wie, co dzieje się pod spodem.
Luki w zabezpieczeniach, o których liderzy powinni wiedzieć
Dane osobowe i postępowanie z danymi
Najbardziej intuicyjne ryzyko dla większości liderów będzie dotyczyć danych osobowych umożliwiających identyfikację (PII). Fisher posługuje się konkretnym przykładem, aby zilustrować, gdzie znajduje się granica: „Myślę, że granica złożoności przebiega tuż przed wprowadzeniem danych pracowników lub klientów do systemu, który przekazuje te dane innym osobom. Wtedy pojawiają się problemy związane z PII”.
Uważam, że granica złożoności przebiegałaby tuż przed wprowadzeniem danych pracowników lub klientów do systemu, który następnie przekazuje te dane innym osobom.
Ryzyko rośnie wraz z wrażliwością danych i gronem odbiorców, którzy mogą uzyskać do nich dostęp — a w zespołach operacyjnych i zarządzających projektami dane te często obejmują informacje o klientach, dokumentację pracowników, dane dotyczące wynagrodzeń lub dane kontaktowe, które wiążą się z realnym ryzykiem prawnym.
Nieprzewidziane koszty i wykorzystanie tokenów
Jedno z zagrożeń, które zaskakuje wielu liderów, nie ma nic wspólnego z danymi, lecz dotyczy pieniędzy. Fisher opisuje scenariusz częstszy, niż większość osób zdaje sobie sprawę: „Załóżmy, że ktoś przypadkowo skieruje agenta programistycznego w niewłaściwą stronę, w wyniku czego utworzy on pętlę działającą cały czas i nieustannie generującą wysokie opłaty. Zanim się obejrzysz, projekt, który miał kosztować 5000 USD, kosztuje 50 000 USD, ponieważ nikt nie wiedział, co dzieje się pod spodem, i zakładał, że agent programistyczny sam to wykryje”.
Osoby bez wiedzy technicznej również rzadziej optymalizują ogólne wykorzystanie tokenów, co oznacza, że koszty mogą narastać po cichu i szybko. Bez wglądu w infrastrukturę, na której działają używane przez nich narzędzia, członkowie zespołu mogą nie zdawać sobie sprawy z problemu, dopóki nie otrzymają rachunku.
Klucze API i bezpieczeństwo informacji
W tym miejscu Fisher porusza temat, który nie pozwala zespołom ds. bezpieczeństwa spokojnie spać. Opisany przez niego scenariusz jest podręcznikowym przykładem tego, co dzieje się, gdy ktoś wie wystarczająco dużo, by stworzyć zagrożenie: „Częstym błędem jest sytuacja, gdy ktoś wie na tyle dużo, by wiedzieć i wyjaśnić, że potrzebuje klucza API, aby coś zadziałało. Wprowadza klucz do promptu, a on nie zostaje zapisany w bezpiecznej lokalizacji — po prostu trafia do pliku albo jest wpisywany bezpośrednio do skryptu. Następnie ktoś publikuje kod na GitHubie, być może zapominając ustawić go jako prywatny, i wtedy każdy, kto chce zrobić coś niegodziwego, na przykład wygenerować rachunek za tokeny w wysokości 100 tys. USD, może wykorzystać ten klucz API.”
Łatwo przeczytać ten scenariusz i pomyśleć, że wymaga on długiego łańcucha błędów. Fisher sprzeciwia się takiemu założeniu: „Może się wydawać, że jest to długa seria mało prawdopodobnych zdarzeń, ale wcale tak nie jest. To niezwykle częste, zwłaszcza w przypadku osób bez wiedzy technicznej”.
Być może najbardziej niepokojące zagrożenie wskazane przez Fishera dotyczy czegoś, w co wpadli nawet doświadczeni programiści. „Słyszałem przerażające historie o doświadczonych programistach, którzy wprowadzali cały kod firmy do agenta programistycznego i coś modyfikowali, a następnie cała baza kodu była ujawniana innej firmie, całkowicie w granicach prawa”. Jeśli doświadczeni programiści mogą popełnić taki błąd, profil ryzyka związanego z pracownikiem bez wiedzy technicznej, który szybko tworzy rozwiązanie bez nadzoru, jest znacznie wyższy.
More Articles
- Rozwój kodowania na wyczucie: czy może być przydatne dla kierowników projektów?
- Główny menedżer ds. inżynierii mówi, że liderzy dostarczania muszą wdrażać systemy działające w czasie rzeczywistym i oparte na sygnałach
- Lider ds. dostarczania w Google wyjaśnia, jak przepływy pracy agentowej zmieniają modele zarządzania produktem
- Były menedżer produktu Google zmienia sposób działania zespołów projektowych dzięki narzędziu AI dla menedżerów produktu, opartemu na agentach AI
- Jak doświadczona kierowniczka projektów wykorzystuje AI, aby usprawnić realizację
Problem skalowalności — co się dzieje, gdy rozwiązanie rzeczywiście działa
Jedną z trudniejszych rozmów dla liderów jest ustalenie, co zrobić, gdy narzędzie stworzone metodą vibe codingu rzeczywiście rozwiązuje problem, a ludzie zaczynają na nim polegać. Przypadek sukcesu może po cichu stać się obciążeniem. Fisher jasno wskazuje na problem strukturalny: „Ogólnie rzecz biorąc, żadne projekty tworzone metodą vibe codingu nie są skalowalne, głównie dlatego, że nie prosisz agenta o uwzględnienie skalowania. Osoby niebędące programistami prawdopodobnie nawet nie proszą o takie rzeczy jak obsługa błędów. Jeśli nie rozumiesz, w których miejscach rzeczywiście występują błędy, nie wiesz wystarczająco dużo, aby upewnić się, że agent je wykrywa i odpowiednio obsługuje”.
Ogólnie rzecz biorąc, wszystkie projekty tworzone metodą kodowania intuicyjnego nie są skalowalne, głównie dlatego, że nie prosisz agenta o uwzględnienie skalowania.
Luka odpowiedzialności staje się najbardziej widoczna pod presją. „Zwykle wygląda to tak, że ktoś stworzy coś metodą kodowania intuicyjnego i to działa, ale czy ta osoba zapewni temu produktowi wsparcie techniczne 24 godziny na dobę, 7 dni w tygodniu?”. Dla liderów odpowiedzialnych za dostarczanie rozwiązań i operacje jest to moment, w którym dobrze intencjonalne narzędzie wewnętrzne staje się ryzykiem organizacyjnym — ponieważ im bardziej zespoły na nim polegają, tym większe prawdopodobieństwo, że przestanie działać lub będzie wymagać stałego wsparcia technicznego.
Fisher zaleca, aby w przypadku narzędzi, które zyskują popularność, przeprowadzić sprawne przekazanie: „Jeśli zbudujesz coś, na czym ludzie polegają, musi się to stać czymś więcej niż tylko projektem stworzonym metodą kodowania intuicyjnego; powinno zostać przejęte przez osoby, które zawodowo się tym zajmują i wiedzą o rzeczach, o które nawet nie przyszłoby ci do głowy zapytać”.
Co mogą zrobić liderzy — praktyczne zabezpieczenia
Nie oznacza to, że rozwiązaniem jest całkowity zakaz. Fisher konsekwentnie podkreśla, że wartość kodowania intuicyjnego dla osób nietechnicznych jest realna, ale dotyczy konkretnego obszaru. „Wartość tych narzędzi dla osób, które nie programują, polega na tym, że mogą szybko przejść przez takie etapy jak uzgodnienie pomysłu i wyjście poza fazę «czy to zadziała?»” — mówi. Faza prototypowania, faza komunikacji, faza „czy w ogóle warto to budować?” — to właśnie tam kodowanie intuicyjne sprawdza się najlepiej, a ryzyko pozostaje możliwe do opanowania.
Dla liderów praktyczny plan działania wygląda mniej więcej tak: zachęcaj do wykorzystywania kodowania intuicyjnego jako narzędzia do prototypowania i komunikacji oraz ustal jasny próg, po którego przekroczeniu narzędzie zostanie sprawdzone przez osobę posiadającą wiedzę techniczną, zanim trafi do szerszego użycia. Prowadzenie takich rozmów z zespołem — aby jego członkowie rozumieli ryzyko i znali dostępne możliwości — odróżnia kulturę rozsądnego odkrywania możliwości AI od kultury, która po prostu działa szybko i liczy na najlepszy wynik.
Celem nie jest bycie liderem, który mówi „nie”. Chodzi o to, by być liderem, który upewnia się, że zespół wie, w co się angażuje — aby gdy ktoś stworzy coś świetnego, mogło to rzeczywiście znaleźć zastosowanie.
Chcesz poznać więcej podobnych informacji? Zarejestruj się, aby założyć bezpłatne konto DPM i poznać opinie kolejnych ekspertów.
