Kontakt z redakcją
Zachęcamy do współpracy. Jeśli masz ciekawy tekst i chcesz go u nas opublikować, napisz do nas. Chętnie go przeczytamy i odezwiemy się z odpowiedzią.
Dane z formularza wykorzystujemy wyłącznie do odpowiedzi na Twoją wiadomość.
Vibecoder: tylko slogan czy realna profesja na rynku pracy
Osoby, które najlepiej zarabiają na budowaniu aplikacji z pomocą AI, rzadko wpisują „vibecoder” w nagłówku swojego profilu – to słowo lepiej sprzedaje się w mediach społecznościowych niż w rozmowie z klientem. Ten tekst pokazuje, kto dziś faktycznie wykonuje tę pracę, czego rynek oczekuje, żeby dało się ją nazwać zawodem, jak się ją wycenia i co powinien wiedzieć ktoś, kto chce taki projekt zlecić.
Kto dziś nazywa siebie vibecoderem i co faktycznie dostarcza
Określenie, które zaczęło się od żartobliwego opisu weekendowego programowania z modelem językowym, przylgnęło do kilku bardzo różnych grup. Pierwszą są founderzy, którzy zamiast szukać wspólnika technicznego budują pierwszą wersję produktu sami: formularz zapisów, panel dla pierwszych klientów, prosty system płatności. Ich celem nie jest kod, tylko odpowiedź na pytanie, czy ktoś za ten pomysł zapłaci.
Druga grupa to marketerzy, analitycy i specjaliści operacyjni, którzy automatyzują własną pracę. Budują skrypty łączące arkusze z systemem CRM, generatory raportów, narzędzia do porządkowania danych z kampanii. Często nie nazywają tego programowaniem, choć efektem jest działające oprogramowanie używane codziennie przez cały dział.
Trzecia grupa jest najbliższa zawodowi w klasycznym sensie: freelancerzy, którzy dla małych firm robią proste aplikacje i narzędzia. Kalkulator ofert, system rezerwacji dla gabinetu, wewnętrzny panel do zarządzania zamówieniami. Czwarta to projektanci, którzy zamiast statycznych makiet pokazują klikalny prototyp z prawdziwymi danymi. Wspólny mianownik jest jeden: dostarczają działający program szybciej i taniej, niż było to możliwe jeszcze niedawno, ale zakres tego, co dostarczają, bywa bardzo różny.
Jak wygląda codzienna praca poza samym pisaniem poleceń
Z zewnątrz ta praca wygląda jak rozmowa z czatem. W praktyce największa jej część to precyzyjne opisywanie wymagań. Klient mówi „chcę, żeby system wysyłał przypomnienia”, a ktoś musi ustalić, komu, kiedy, jakim kanałem, co się dzieje przy odwołanej wizycie i kto może wyłączyć powiadomienia. Model wygeneruje kod do każdej z tych wersji, ale nie wybierze za człowieka, która jest właściwa.
Druga część to iteracje i testowanie. Każda zmiana wymaga sprawdzenia, czy nowa funkcja działa i czy przy okazji nie zepsuła poprzedniej. Doświadczone osoby szybko uczą się, że klikanie po interfejsie nie wystarcza, i zaczynają prosić model o testy, przygotowywać zestawy danych próbnych, sprawdzać nietypowe przypadki: pusty formularz, bardzo długie nazwisko, dwa zamówienia złożone w tej samej sekundzie.
Trzecia część to integracje z gotowymi usługami. Mało kto buduje od zera logowanie, płatności czy wysyłkę e-maili. Praca polega na połączeniu kilku zewnętrznych usług w spójną całość, skonfigurowaniu ich kont, uprawnień i kluczy dostępu oraz zrozumieniu, co się stanie, gdy jedna z nich przestanie odpowiadać. Ta część pochłania zaskakująco dużo czasu i wymaga wiedzy, której model nie ma, bo dotyczy konkretnego konta klienta, a nie ogólnych zasad.
Co odróżnia profesję od hobby
Hobby kończy się w momencie, w którym program działa na komputerze autora. Profesja zaczyna się tam, gdzie ktoś inny polega na tym programie i płaci za jego działanie. Od osoby, która chce na tym zarabiać, rynek oczekuje kilku rzeczy niezależnych od narzędzia:
- rozumienia problemu klienta na tyle dobrze, żeby zaproponować prostsze rozwiązanie niż to, o które prosił;
- umiejętności sprawdzania wyników, czyli odróżnienia programu, który działa, od programu, który tylko tak wygląda przy normalnym użyciu;
- podstaw bezpieczeństwa i ochrony danych, w tym wiedzy, gdzie trzymać klucze dostępu i kto odpowiada za dane osobowe użytkowników;
- gotowości do utrzymania, czyli odpowiedzi na pytanie, kto naprawi aplikację, gdy za pół roku zmieni się zewnętrzna usługa, od której zależy.
Każdy z tych punktów wymaga w jakimś stopniu rozumienia kodu i architektury. Osoba, która je spełnia, przestaje być vibecoderem w pierwotnym znaczeniu – kimś, kto świadomie nie czyta kodu – i zbliża się do programisty, który po prostu pracuje szybciej dzięki AI. Granica zaciera się od strony kompetencji, a nie narzędzi: obie grupy korzystają z tych samych modeli, różni je to, ile rozumieją z tego, co powstaje.
To samo zjawisko widać z drugiej strony, na stanowiskach juniorskich. Zadania, które kiedyś były szkołą dla początkujących programistów – proste formularze, powtarzalne funkcje, przepisywanie kodu według wzoru – model wykonuje dziś w kilka chwil. Junior przestaje być potrzebny jako ktoś, kto pisze prosty kod, a zaczyna być oceniany za to, czy potrafi taki kod ocenić, przetestować i wpasować w większy system. Wejście do zawodu nie znika, ale przesuwa się wyżej.
Jak brzmią stanowiska i jak wycenia się taką pracę
W ofertach pracy słowo „vibecoder” pojawia się rzadko i zwykle w firmach, które chcą zasygnalizować luźną kulturę. Znacznie częściej te same kompetencje kryją się pod nazwami takimi jak AI engineer, product builder, automation specialist czy po prostu full-stack developer z dopiskiem o pracy z narzędziami AI. Pracodawcy szukają osób, które dowiozą działający produkt, a sposób pisania kodu traktują jako szczegół techniczny, nie jako nazwę roli.
Inaczej zmienia się też wycena. Rozliczanie godzinowe traci sens, gdy zadanie, które kiedyś zajmowało tydzień, można wykonać w jeden dzień. Freelancerzy częściej wyceniają więc efekt: działające narzędzie, zautomatyzowany proces, zaoszczędzony czas zespołu. Klient płaci za rozwiązany problem, a nie za liczbę wpisanych poleceń. To uczciwsze dla obu stron pod warunkiem, że zakres jest dobrze opisany, bo przy wycenie za efekt każda niedoprecyzowana funkcja staje się polem sporu.
Coraz częściej osobną pozycją w wycenie staje się utrzymanie. Aplikacja zbudowana w kilka dni nadal wymaga aktualizacji zależności, reakcji na zmiany w zewnętrznych usługach i poprawek zgłaszanych przez użytkowników. Wykonawcy, którzy traktują tę pracę poważnie, proponują stały abonament na opiekę techniczną zamiast jednorazowej faktury, bo wiedzą, że prawdziwy koszt projektu ujawnia się dopiero po wdrożeniu.
Ryzyka dla klienta i jak je ograniczyć
Największe ryzyko dla firmy zlecającej projekt nie leży w jakości samego kodu, tylko w zależności od jednej osoby. Jeśli aplikacja powstała na koncie wykonawcy, w narzędziu, do którego tylko on ma dostęp, a jedyną dokumentacją jest historia jego rozmów z modelem, każda przyszła zmiana wymaga powrotu do tej samej osoby. Gdy ona zniknie, projekt praktycznie trzeba zaczynać od nowa.
Pierwszym zabezpieczeniem jest umowa, która jasno określa przeniesienie praw do kodu, zakres utrzymania po wdrożeniu i odpowiedzialność za przetwarzanie danych osobowych. Drugim jest wymóg, żeby kod od początku trafiał do repozytorium należącego do klienta, a konta zewnętrznych usług były zakładane na firmę, nie na wykonawcę. Trzecim jest niezależny przegląd przed uruchomieniem produkcyjnym: ktoś, kto rozumie kod, sprawdza uprawnienia, obsługę danych i miejsca przechowywania kluczy. Taki przegląd kosztuje ułamek ceny naprawy po incydencie.
Dla kogo to realna ścieżka i jak się w niej uwiarygodnić
Najbardziej naturalna jest dla osób, które znają jakąś branżę od środka i widzą w niej konkretne problemy do rozwiązania. Marketer, który rozumie, jak działa agencja, zbuduje dla agencji lepsze narzędzie niż programista bez tej wiedzy. Mniej sensowna jest dla kogoś, kto liczy, że samo korzystanie z modeli wystarczy, żeby konkurować z doświadczonymi zespołami przy dużych, krytycznych systemach.
Uwiarygodnia się to w prosty sposób: portfolio działających projektów, z których ktoś naprawdę korzysta, zamiast listy demonstracji. Warto przy każdym móc powiedzieć, jaki problem rozwiązał, jak był testowany i kto go dziś utrzymuje. Drugim elementem jest nauka podstaw: kontroli wersji, działania baz danych, uwierzytelniania, czytania kodu na tyle, żeby rozpoznać, co robi. Nie chodzi o to, żeby stać się klasycznym programistą, tylko żeby móc wziąć odpowiedzialność za to, co się dostarcza. Od tego zależy, czy „vibecoder” pozostanie sloganem, czy stanie się opisem zawodu.
