Vibe coding w 2026 r.: co CTO powinien wiedzieć

W skrócie

• Vibe coding to opisanie tego, czego chcesz, pozwolenie modelowi, żeby to napisał, i ocenianie wyniku po tym, czy działa. W amerykańskich i europejskich zespołach produktowych to już norma, a wąskie gardło przesuwa się z pisania kodu na jego przegląd.
• Dane działają w obie strony. 45 procent próbek kodu generowanego przez AI nie przechodzi testów bezpieczeństwa (Veracode), doświadczeni programiści byli o 19 procent wolniejsi z AI w kontrolowanym badaniu (METR), a stabilność dostarczania spada wraz z adopcją AI (DORA). Nic z tego nie kasuje przyspieszenia przy prototypach i narzędziach wewnętrznych.
• Seniorzy zyskują na wartości, a nie tracą. Rzadką umiejętnością jest osąd: co generować, co czytać linijka po linijce i czego nigdy nie wpuszczać na produkcję.

Zeszłego lata krążył pewien zrzut ekranu. Bill Gates pyta, co oznacza VIBE w „vibe coding". Linus Torvalds odpowiada: Very Inefficient But Entertaining. Dwanaście tysięcy odpowiedzi, trzydzieści pięć tysięcy polubień.

To fałszywka. Torvalds nigdy nie miał konta na X, a nazwa konta na obrazku to parodia. Żart i tak się przyjął, bo jest blisko tego, co Torvalds powiedział naprawdę. W listopadzie 2025 r. na Open Source Summit mówił, że jest „raczej pozytywnie" nastawiony do vibe codingu jako sposobu, by ludzie zmusili komputer do czegoś, czego inaczej by nie zrobili, i jednym tchem dodał, że „może to być okropny, okropny pomysł z punktu widzenia utrzymania". Dwa miesiące później wspomniał, że wizualizator w Pythonie w jego hobbystycznym projekcie AudioNoise został „w zasadzie napisany metodą vibe codingu". Dobre do efektu gitarowego. Nie do jądra.

Mniej więcej tam też wylądowaliśmy w Inuits, a wprowadzanie seniorów do zespołów produktowych to nasza codzienność. To jest więc wersja argumentu, którą przedstawiamy klientom: czym jest vibe coding, gdzie się opłaca, gdzie po cichu tworzy ryzyko i dlaczego czyni seniorów bardziej wartościowymi, a nie mniej. Ciągnie wątek z tekstu AI miało zlikwidować wszystkie miejsca pracy, ale… czy na pewno?, w którym patrzyliśmy, jak AI przekształca popyt na inżynierów, zamiast go wymazywać.

Czym jest vibe coding

Termin ukuł Andrej Karpathy we wpisie na X w lutym 2025 r.: „nowy rodzaj kodowania, który nazywam vibe codingiem: w pełni poddajesz się wibracjom, przyjmujesz wykładniczy wzrost i zapominasz, że kod w ogóle istnieje". Dziewięć miesięcy później Collins Dictionary uznał go za Słowo Roku. Jak na inżynierski slang to szybko, a liczby wyszukiwań tłumaczą dlaczego: około 87 000 wyszukiwań miesięcznie w USA, 14 000 w Niemczech, 13 000 w Wielkiej Brytanii.

Bez szumu definicja jest krótka. Opisujesz efekt zwykłym językiem. Model pisze implementację. Wynik oceniasz głównie przez uruchomienie, a nie przez czytanie każdej linijki.

Ta ostatnia część to cała różnica względem programowania wspomaganego AI i ma znaczenie dla ładu:

• Programowanie wspomagane AI. Inżynier nadal czyta i rozumie każdą zaproponowaną zmianę. Model przyspiesza znajomy proces.
• Vibe coding. Inżynier świadomie pomija przegląd linijka po linijce przy wybranych zadaniach i ocenia wynik po zachowaniu.

Vibe coding często bierze się za kodowanie bez myślenia. To raczej odwrotność. Pisania jest mniej; myślenie przesuwa się w górę: do definicji problemu, ograniczeń i walidacji. Kto steruje, ten nadal odpowiada za wynik.

Jak to działa w praktyce

Pętla jest krótka i się powtarza:

1. Opisz. Cel, ograniczenia, kontekst. „Wewnętrzny dashboard z tygodniowymi metrykami dostarczania per zespół, czytający z naszego Postgresa, bez nowych zależności."
2. Wygeneruj. Model tworzy działającą pierwszą wersję, często całość, a nie fragment.
3. Uruchom. Odpalasz, przeklikujesz i sprawdzasz zachowanie względem tego, co miałeś na myśli.
4. Popraw. Korygujesz kurs zwykłym językiem i lecisz dalej.

Realny przypadek: team lead potrzebuje małego narzędzia, które zbiera dane z trzech systemów i flaguje anomalie dla opsów. Tradycyjnie leży to w backlogu kwartał, bo nikt nie chce spalić na to dwóch tygodni. W tej pętli używalna wersja istnieje po południu, a reszta pracy to decyzja, czy jest poprawna, bezpieczna i warta utrzymania.

Zwróć uwagę, co w każdym cyklu należy do człowieka: intencja, ograniczenia, walidacja. Model nie ma zdania o twoich zasadach retencji, zakresie zgodności ani o tym, czy to narzędzie w ogóle powinno istnieć.

Gdzie się opłaca

• Prototypy i MVP. Pomysły, których walidacja wymagała tygodni, stają się klikalnymi demami w kilka godzin. To zmienia, co jesteś skłonny testować.
• Boilerplate. Ekrany CRUD, wrappery API, standardowe integracje, kod sklejający. Dokładnie te wzorce, z którymi modele radzą sobie dobrze.
• Małe narzędzia dla nieprogramistów. Analitycy, PM-owie i founderzy mogą budować proste narzędzia wewnętrzne bez czekania w kolejce do inżynierów.
• Tańsze eksperymenty. Sprawdzenie dwóch czy trzech podejść przed decyzją przestaje być luksusem.

Z liczbami o produktywności ostrożnie. Dostawcy podają dwucyfrowe wzrosty i niektóre zespoły faktycznie je widzą. Jedyne randomizowane badanie, któremu warto ufać, METR z lipca 2025 r., dało 16 doświadczonym programistom open source 246 prawdziwych zadań w ich własnych, dojrzałych repozytoriach. Z narzędziami AI byli o 19 procent wolniejsi, a po fakcie szacowali, że AI przyspieszyło ich o 20 procent. Rozrzut między zespołami jest duży, a te na górze skali mają silną dyscyplinę przeglądu, nie największy entuzjazm do adopcji.

Gdzie się psuje

Vibe coding „może być okropnym, okropnym pomysłem z punktu widzenia utrzymania". Linus Torvalds, Open Source Summit, listopad 2025

Kontekst rozstrzyga niemal wszystko.

Dobre zastosowania: prototypy i MVP, gdzie celem jest nauka, a nie trwałość; narzędzia wewnętrzne, dashboardy i panele administracyjne dla małej, znanej grupy odbiorców; landing page'e i kampanijne mikrostrony o krótkim życiu; skrypty automatyzujące i klej między systemami.

Ryzykowne bez mocnego nadzoru: wszystko, co dotyka danych osobowych lub informacji regulowanych, co dla zespołów europejskich oznacza obowiązki z RODO, których nie da się delegować na model, a dla amerykańskich HIPAA, zakres SOC 2 i umowne zobowiązania bezpieczeństwa; płatności, procesy zgodności, kluczowe integracje ERP lub CRM; oraz każdy kod, który przez lata będą utrzymywać ludzie, którzy go nie pisali.

Tryb awarii, który widzimy w praktyce, rzadko brzmi „AI napisało zły kod". Częściej kod wygenerowany przez AI dryfuje z weekendowego prototypu w zależność produkcyjną, nigdy nie przechodząc prawdziwej bramki przeglądu.

Liczby o bezpieczeństwie

Veracode przetestował ponad 100 modeli na 80 zadaniach programistycznych w czterech językach do swojego raportu 2025 GenAI Code Security Report. 45 procent wygenerowanych próbek oblało testy bezpieczeństwa z podatnością z OWASP Top 10. Nowsze i większe modele częściej pisały działający kod i wcale nie bezpieczniejszy: wynik bezpieczeństwa był płaski niezależnie od rozmiaru modelu.

Sam cross-site scripting: modele nie obroniły się przed nim w 86 procentach odpowiednich próbek. Prawdopodobne to nie to samo co bezpieczne.

Raport DORA 2025 Google dokłada perspektywę dostarczania. Adopcja AI koreluje już dodatnio z przepustowością i nadal ujemnie ze stabilnością dostarczania oprogramowania. Ich odczyt pokrywa się z tym, co widzimy u klientów: AI podnosi tempo generowania kodu szybciej, niż przegląd i wdrożenia są w stanie wchłonąć.

Razem lista ryzyk wygląda tak:

• Bezpieczeństwo. Patrz wyżej.
• Dojrzałe systemy. AI jest najmocniejsze w kodzie od zera i standardowych wzorcach. Najsłabsze dokładnie tam, gdzie żyje praca enterprise: duże bazy kodu, głębokie zależności, niepisane konwencje, lata nagromadzonego kontekstu.
• Zrozumienie. Jeśli nikt w zespole naprawdę nie wie, jak coś działa, każda kolejna zmiana jest zgadywaniem. Ten dług jest niewidoczny do pierwszego incydentu.
• Zgodność. Wygenerowany kod, który po cichu loguje dane osobowe, woła niezweryfikowaną usługę zewnętrzną albo ignoruje zasady retencji, to problem regulacyjny, nie techniczny.
• Obciążenie przeglądem. Generowanie kodu jest teraz tanie. Przeglądanie nie. Bez świadomego procesu przegląd staje się nowym wąskim gardłem.

Dlaczego seniorzy liczą się bardziej

Każde z tych ryzyk łagodzi to samo: senior z osądem. Ktoś, kto ustawia barierki, zanim zacznie się generowanie, rozpoznaje złą decyzję architektoniczną w diffie, który poza tym wygląda dobrze, i mówi wprost, kiedy prototyp nie jest gotowy, by stać się infrastrukturą.

To ta sama zmiana, którą opisaliśmy we wcześniejszym tekście o AI i pracy programistów. Co klienci mówią nam teraz:

• Przestali prosić o „programistę Reacta z pięcioletnim doświadczeniem", a zaczęli o ludzi, którzy potrafią wziąć problem od początku do końca i dobrze używać AI po drodze.
• Podział na front-end i back-end dalej się zaciera, bo jeden mocny inżynier z AI pokrywa więcej terenu.
• Presja spada na pomiar i nadzór, nie na budujących.
• Juniorzy mają trudno właśnie dlatego, że wąskie gardło przesunęło się z pisania kodu na jego przegląd i ocenę, czyli trudniejszą umiejętność do zdobycia.

Vibe coding nie zmniejsza wartości seniorów. On ją koncentruje.

Vibe coding, programowanie wspomagane AI i low-code obok siebie

Porównanie, o które ludzie zwykle pytają, to vibe coding kontra low-code, a to w gruncie rzeczy pytanie o własność. Dostajesz elastyczność i przenośność, a w zamian bierzesz odpowiedzialność za projektowanie i przegląd tego, co powstaje.

Cztery ruchy dla twojej strategii inżynierskiej

1. Zacznij tam, gdzie promień rażenia jest mały. Najpierw prototypy i narzędzia wewnętrzne. Nie płatności, nie nic, co trzyma dane klientów.
2. Spisz zasady dla kodu generowanego przez AI. Co musi być przejrzane linijka po linijce, co można ocenić po zachowaniu, czego nigdy nie wolno generować. Niejasność w tym miejscu to tam, gdzie kumuluje się ryzyko.
3. Traktuj to jako mnożnik dla seniorów, nie substytut. Mocny inżynier z AI jest dramatycznie szybszy. Słaby proces z AI jest dramatycznie szybszy w produkowaniu problemów.
4. Zmień, pod co rekrutujesz. Sprawdzaj odpowiedzialność za problem, projektowanie systemów i umiejętność krytycznego przeglądu wygenerowanego kodu. Znajomość stacku nadal się liczy; przestała być wyróżnikiem.

Jak pracujemy z tym w Inuits

Wprowadzamy polskich seniorów do amerykańskich i europejskich zespołów produktowych, a ludzie, o których klienci proszą teraz, to ci, którzy domyślnie pracują AI-first. Nie dlatego, że ekscytują się narzędziami, tylko dlatego, że używają AI, by szybko przejść przez części mechaniczne, a własny osąd stosują do całej reszty.

Nasze stanowisko jest proste. AI to silnik, ludzie to mózg. Inżynierowie, których wprowadzamy, projektują system, przeglądają to, co z niego wychodzi, i biorą za to odpowiedzialność. Programowanie wspomagane AI to metoda pracy, nie strategia, a klienci przychodzą do nas, kiedy chcą wyników, a nie opowieści o adopcji AI.

Jeśli zastanawiasz się, jak bezpiecznie wdrożyć vibe coding we własnym zespole, albo potrzebujesz seniorów, którzy już tak pracują, powiedz nam, czego potrzebujesz. Przyjrzymy się twoim obecnym zasadom dla kodu generowanego przez AI, lukom w przeglądzie i temu, pod co sprawdzać kolejnych kandydatów.