Rozwój kodowania na wyczucie: czy może być przydatne dla kierowników projektów?
Rozwój kodowania na wyczucie: Kodowanie na wyczucie przekształciło się z niszowej koncepcji w zjawisko zyskujące uwagę w kręgach technologicznych i biznesowych.
Kierownicy projektów: Kierownicy projektów, biegli w jasnej komunikacji, są zaskakująco dobrze predysponowani do osiągania sukcesów w kodowaniu na wyczucie.
Przykłady z praktyki: Praktyczne zastosowania kodowania na wyczucie pokazują jego potencjał do tworzenia narzędzi na potrzeby niszowych zastosowań.
Wyzwania: Chociaż kodowanie na wyczucie przyspiesza początkowy etap tworzenia, skalowanie i zarządzanie jakością nadal stanowią trudne aspekty.
Świadomość zagrożeń: Twórcy bez wiedzy technicznej mogą napotkać zagrożenia, w tym problemy ze skalowalnością i luki w zabezpieczeniach, podczas kodowania na wyczucie.
W ciągu ostatniego roku lub dwóch lat „vibecoding” przeszedł drogę od niszowego terminu krążącego w zakątkach internetu skupionych wokół entuzjastów AI do koncepcji, która zaczyna przebijać się do głównego nurtu — przynajmniej w kręgach technologicznych, biznesowych i związanych z produktywnością. Spędziłem niezliczone godziny na rozmowach o AI z ekspertami, a sam całkowicie zanurzyłem się w fascynacji vibecodingiem, i zauważyłem pewien schemat: vibecoding często staje się kolejnym krokiem dla osób, które dotarły do granicy możliwości istniejących narzędzi AI. Jeśli nie możesz znaleźć tego, czego szukasz, dlaczego po prostu nie zbudować tego samodzielnie?
Problem polega na tym, że większość osób, z którymi rozmawiam, nadal o nim nie słyszała. To wciąż naprawdę niszowa koncepcja, o której rzadko mówi się konkretnie w kręgach zarządzania projektami. Dlatego zacząłem szukać osób, które faktycznie się tym zajmują: prawdziwych kierowników projektów i liderów operacyjnych, którzy po cichu włączyli narzędzia stworzone za pomocą vibecodingu do swojej codziennej pracy, i zapytałem ich, jak im idzie.
Niezależnie od tego, czy jesteś kierownikiem projektu ciekawym tego, dokąd AI może cię zaprowadzić, czy liderem próbującym wyprzedzić to, z czym twój zespół może już eksperymentować, potraktuj ten tekst jako wprowadzenie do vibecodingu — częściowo inspirację, a częściowo ostrzeżenie.
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
Czym właściwie jest vibecoding?
Choć nie istnieje jeszcze formalna definicja „vibecodingu”, ponieważ jest to nowy termin, zdefiniujemy go następująco: to programowanie poprzez wydawanie modelowi LLM poleceń w języku naturalnym, po których generuje on kod.
Na potrzeby tego artykułu chcę również zaznaczyć, że „vibecoding” (przynajmniej w rozumieniu, w jakim używam tego terminu) różni się od programowania wspomaganego przez AI — w którym posiadający umiejętności techniczne programista korzysta z narzędzi takich jak GitHub Copilot, aby przyspieszyć pracę, którą już potrafi wykonywać.
Dlaczego kierownicy projektów są zaskakująco dobrze przygotowani do tego zadania?
Na pierwszy rzut oka vibecoding może wydawać się narzędziem dla przedsiębiorców lub hobbystów zainteresowanych technologią. Jednak im więcej osób poznawałem, tym wyraźniej wyłaniał się inny profil: osoba odnosząca sukcesy w vibecodingu niekoniecznie jest najbardziej techniczną osobą w pomieszczeniu. To osoba, która najlepiej wie, czego chce, i potrafi jasno to wyrazić — a jeśli się nad tym zastanowić, opisuje to dobrego kierownika projektu niemal idealnie.
Tim Fisher, wiceprezes ds. AI w The Digital Project Manager, ujął to w ten sposób: „To sposób komunikacji, który wcześniej nie istniał”. Postrzega vibecoding mniej jako umiejętność techniczną, a bardziej jako nowy sposób przekształcania pomysłów w coś namacalnego. „Wartość tych narzędzi dla osób nieprogramujących polega na możliwości skrócenia takich procesów jak uzgadnianie pomysłu i przejście przez etap «czy to zadziała?»”.
Vibecoding to sposób komunikacji, który wcześniej nie istniał.
To, co opisał Tim, doskonale odpowiada zestawowi umiejętności kierownika projektu: pisanie wymagań, przekładanie potrzeb biznesowych na jasne specyfikacje, komunikacja między zespołami technicznymi i nietechnicznymi — to wszystko czynności, które kierownicy projektów wykonują każdego dnia, a które okazują się dokładnie tym, co daje przewagę w vibecodingu.
Aniket Ghonge, starszy menedżer ds. łańcucha dostaw w Amazon, opisał swoją drogę do vibecodingu w sposób, który przemówi do wielu kierowników projektów. Lata przed pojawieniem się agentowej AI pomagał prowadzić zespół programistyczny budujący wewnętrzne narzędzie, spisując wymagania i opisując to, czego potrzebował. „Nic nie zbudowałem. Niczego nie zakodowałem. Po prostu powiedziałem: «Oto, czego potrzebujemy. Tak powinien wyglądać przebieg». A oni zbudowali to na podstawie moich wymagań. Właśnie tak zaczęła się moja podróż. Teraz, dzięki agentowej AI, robię to samo. Spisuję wymagania, ale to AI zajmuje się kodowaniem”.
Jaka jest teraz jedyna różnica? Nie potrzebuje już zespołu programistycznego.
Co właściwie budują ludzie?
Najbardziej przekonującym dowodem na potencjał vibecodingu nie jest teoria — lecz konkretne, praktyczne rzeczy, które ludzie po cichu wdrożyli, podczas gdy reszta z nas wciąż zastanawiała się, czy warto próbować.
Oto przykłady tego, co zbudowało czworo praktyków bez wykształcenia technicznego:
Dixie Willard, założycielka i główna strategka projektów w Poised and Plumb, pracuje przede wszystkim z projektantami wnętrz i całkowicie samodzielnie stworzyła narzędzie do budowania zakresu prac. Aplikacja pozwala projektantowi przeprowadzić konsultację z klientem na tablecie, w czasie rzeczywistym odhaczać pomieszczenia, wybory i etapy projektu oraz od razu generować przejrzysty dokument zakresu prac — coś, co wcześniej wymagało notatek, pamięci i wielu godzin pracy administracyjnej po spotkaniu. Stworzyła ją, ponieważ nic podobnego nie istniało. „Po prostu nie ma takiego narzędzia. A jest wiele narzędzi, z których projektanci mogliby korzystać, ale one po prostu nie istnieją”. Tak wyjaśnia, dlaczego tworzenie kodu z pomocą AI ma znaczenie w takich branżach jak jej: „Myślę, że niszowe przypadki użycia są prawdopodobnie największym powodem, aby korzystać z tworzenia kodu z pomocą AI. To po prostu znacznie ułatwia życie”.
Myślę, że niszowe przypadki użycia są prawdopodobnie największym powodem, aby korzystać z tworzenia kodu z pomocą AI. To po prostu znacznie ułatwia życie.
Aniket Ghonge poświęcał od 16 do 18 godzin tygodniowo na ręczne przetwarzanie danych dotyczących prognozowania popytu dla setek przewoźników w całej sieci logistycznej Amazonu — kopiowanie danych między arkuszami kalkulacyjnymi, ręczne wykonywanie obliczeń i powtarzanie tego wszystkiego w kolejnym tygodniu. „To ręczny proces. Zajmowało mi to około 16–18 godzin tygodniowo. Nie mogę dalej robić tego ręcznie i popełniać błędów, ponieważ gdy człowiek zajmuje się czymś na dużą skalę, zawsze pojawia się ryzyko błędów”. Stworzył więc z pomocą AI pełną aplikację internetową, która obecnie automatyzuje większość tej pracy. Porównanie z wcześniejszą sytuacją jest uderzające: „Kilka lat temu musiałem współpracować z programistą internetowym, projektantem UX, kierownikiem produktu, technicznym kierownikiem programu i wieloma innymi osobami, aby stworzyć produkt oparty na mojej koncepcji. Dziś nie mam żadnych blokad i w ciągu dwóch tygodni zbudowałem aplikację. Podobna aplikacja, którą wcześniej wspierałem, zajęła dwa lata”.
Michael Gold, tymczasowy dyrektor ds. realizacji i założyciel Gold Project Management, stworzył w Lovable niestandardowy system CRM, który łączy się ze stroną internetową jego firmy i integruje z Fireflies, jego narzędziem do transkrypcji spotkań. Każdego ranka on i jego wspólnik omawiają podczas rozmowy swój lejek sprzedażowy, a gdy kończą, wystarczy jedno naciśnięcie przycisku: „Mogę po prostu kliknąć opcję aktualizacji na podstawie transkrypcji, a system automatycznie przeanalizuje transkrypcję i przypisze ją właściwej osobie. Dodaje też notatki i zadania oraz przypisuje je nam”. Od tego czasu poszedł o krok dalej i zaczął tworzyć kod z pomocą AI, współpracując z programistą nad pełnym narzędziem do automatyzacji usług profesjonalnych, które zmierza obecnie do publicznej premiery.
Harry Max, tymczasowy menedżer i autor książki „Zarządzanie priorytetami”, obserwował, jak jego wspólnik przez dziewięć miesięcy od podstaw tworzył z pomocą Claude Code zaawansowaną platformę do ustalania priorytetów — bez zespołu programistycznego i zewnętrznego finansowania. Porównanie przedstawione przez Harry’ego Maxa było trudne do zignorowania: „W ciągu dziewięciu miesięcy jeden człowiek zbudował coś równie zaawansowanego jak oprogramowanie, które 20 lat temu tworzyliśmy w 14 osób za 2 miliony dolarów”.
W ciągu dziewięciu miesięcy jeden człowiek zbudował coś równie zaawansowanego jak to, co 20 lat temu tworzyliśmy w 14 osób za 2 miliony dolarów.
Szczera prawda: nie wszystko przebiega gładko
Każda osoba, z którą rozmawiałem, była szczerze entuzjastycznie nastawiona do tworzenia kodu z pomocą AI. Jednocześnie bez wyjątku otwarcie mówiły o tym, co staje się trudne.
Najczęstsze doświadczenie wydaje się podobne do tego, które opisał Michael: „Można szybciej niż kiedykolwiek przejść od zera do 60, ale nadal uważam, że przejście z 60 do 100 jest naprawdę trudne. Jeśli naprawdę chcesz doprowadzić projekt do końca, nadal potrzebujesz fachowej wiedzy”.
Harry Max wskazał bardziej subtelną pułapkę — atrakcyjność samego procesu. „Ciągłe wprowadzanie zmian jest bardzo kuszące, a za każdym razem, gdy coś zmieniasz, coś się psuje. I nie znajdziesz tego, co się zepsuło, jeśli naprawdę nie przemyślisz, jak będziesz zarządzać procesami zapewniania jakości i testowania”. Zwrócił też uwagę na otrzeźwiający problem rezultatów, które wyglądają lepiej, niż są w rzeczywistości: „To, że możesz stworzyć z pomocą AI coś, co wygląda pięknie, nie oznacza, że jest użyteczne. Nie oznacza, że działa. Nie oznacza, że rozwiązuje problem — ale wygląda świetnie”.
[Dzięki vibecodingowi] możesz przejść od zera do 60 szybciej niż kiedykolwiek, ale nadal uważam, że przejście od 60 do 100 jest naprawdę trudne.
Aniket Ghonge osobiście nauczył się jednej z trudniejszych lekcji. Chcąc dalej tworzyć funkcje, pominął etap testowania, co drogo go kosztowało: „Nagle straciłem 50% swojej pracy i to trochę mnie przestraszyło. To była dla mnie trudna lekcja. Dobrze, przed wprowadzeniem zmiany w środowisku produkcyjnym trzeba przetestować funkcję w środowisku testowym”. Udało mu się odzyskać pracę, ale zajęło to wiele godzin — i wiązało się ze znacznym niepokojem.
More Articles
- 3 alternatywy dla zastąpienia ludzkich kierowników projektów agentami sztucznej inteligencji
- Menedżer projektów i edukator wspomagany przez AI przedstawia prosty przepływ pracy AI, który zasadniczo zmienia sposób realizacji projektów
- Rzeczywiste przepływy pracy z AI stosowane przez szefa realizacji w agencji wdrażającej Asanę
- Jedyne narzędzie do zarządzania projektami, z którego nigdy bym nie zrezygnował
- Narzędzia do zarządzania projektami, z których kierownicy projektów musieli zrezygnować
Ryzyka, których osoby nietechniczne tworzące narzędzia nie zawsze dostrzegają
Entuzjazm praktyków jest prawdziwy, ale prawdziwe są również zagrożenia strukturalne — i właśnie w tym miejscu postanowiłem poprosić Tima o szczerą opinię techniczną.
Gdy zapytałem Tima, co sądzi o tym, że kierownicy projektów tworzą własne narzędzia za pomocą vibecodingu, jego perspektywa nie polegała na zniechęcaniu ludzi, lecz raczej na upewnieniu się, że zaczynają z pełną świadomością sytuacji. Jego najważniejsza obserwacja brzmiała: „Ogólnie rzecz biorąc, jeśli nie wiesz, czego nie wiesz, nie możesz zakładać, że agent kodujący ci to wyjaśni”.
Dotyczy to w szczególności skalowalności. „Ogólnie rzecz biorąc, wszystkie projekty stworzone za pomocą vibecodingu nie są skalowalne, głównie dlatego, że nie prosisz agenta o uwzględnienie skalowania. Osoby nietechniczne prawdopodobnie nawet nie proszą o takie rzeczy jak obsługa błędów”. Narzędzie stworzone za pomocą vibecodingu może działać idealnie dla pięciu użytkowników, a przy pięćdziesięciu po cichu przestać sobie radzić — a osoba, która je stworzyła, może nie mieć pojęcia, dlaczego tak się stało.
Ogólnie rzecz biorąc, wszystkie projekty stworzone za pomocą vibecodingu nie są skalowalne, głównie dlatego, że nie prosisz agenta o uwzględnienie skalowania.
Pojawia się tu również kwestia odpowiedzialności, która staje się szczególnie istotna, gdy narzędzie zyskuje popularność w organizacji. „Jeśli stworzysz coś, na czym ludzie polegają, musi się to stać czymś więcej niż tylko projektem stworzonym za pomocą vibecodingu; musi zostać przejęte przez osoby, które zawodowo się tym zajmują i wiedzą rzeczy, o które nawet nie wiesz, że trzeba zapytać”. Fisher przedstawił konkretny scenariusz, który wydawał się bardzo realistyczny: „Jeśli ktoś zapyta tę osobę: «Czy informacje, które uzyskuję z twojego narzędzia, są dokładne?», a ona nie wie wystarczająco dużo o jego działaniu, ponieważ pozwoliła agentowi wykonać całą pracę, nie będzie potrafiła odpowiedzieć na to pytanie”.
Nawet Dixie Willard, która aktywnie tworzy narzędzia, w które wierzy, przyznała, że pod ekscytacją kryje się niepokój: „To właśnie zawsze mnie denerwuje, bo myślę sobie: a co, jeśli wystąpi problem z bezpieczeństwem?”.
Warto zauważyć, że luki w zabezpieczeniach — ujawnione klucze API, niezabezpieczone dane użytkowników, narzędzia, które przypadkowo przetwarzają dane osobowe bez odpowiednich zabezpieczeń — należą do najczęstszych zagrożeń, na które Tim zwrócił uwagę w naszej rozmowie. To kwestie, którymi programista zajmuje się rutynowo, ale osoba korzystająca z vibecodingu może po prostu nie wiedzieć, że trzeba je uwzględnić.
Czy zatem warto spróbować?
Szczera odpowiedź brzmi: to zależy od tego, co tworzysz i co zamierzasz z tym zrobić.
Vibecoding jest naprawdę potężnym narzędziem do tworzenia prototypów i komunikacji. Jeśli masz pomysł, chcesz sprawdzić, czy działa, lub musisz pokazać interesariuszom coś konkretnego przed zainwestowaniem w rzeczywisty rozwój, możliwości są ogromne, a ryzyko można kontrolować. Tim trafnie to ujmuje: najważniejszą wartością jest szybsze niż kiedykolwiek wcześniej przejście przez etap „czy to zadziała?”.
Sprawa komplikuje się, gdy narzędzie stworzone za pomocą vibecodingu przechodzi od prototypu do czegoś, na czym ludzie zaczynają polegać. Wtedy luki w skalowalności, obsłudze błędów i bezpieczeństwie, które na początku można było zignorować, zaczynają mieć znaczenie — a osoba, która je stworzyła, może nie dysponować technicznym słownictwem pozwalającym jej nawet wiedzieć, gdzie szukać.
Praktycy opisani w tym artykule na bieżąco mierzą się z tym napięciem. Niektórzy przekazują narzędzia programistom. Inni uczą się w miarę postępów. Wszyscy krok po kroku, za pomocą kolejnych promptów, odkrywają, gdzie dokładnie przebiegają granice tej technologii.
Dla kierowników projektów szansa jest realna — ale realna jest również odpowiedzialność, która się z nią wiąże. Dobrą wiadomością jest to, że wiedza o tym, czego chcesz, zadawanie właściwych pytań i rozumienie, kiedy należy poprosić o pomoc, to rzeczy, które dobrzy kierownicy projektów już potrafią. Vibecoding w najlepszym wydaniu jest po prostu nowym kontekstem dla tych samych umiejętności.
Chcesz uzyskać więcej podobnych informacji? Załóż bezpłatne konto DPM, aby poznać opinie większej liczby ekspertów.
