Vibecoding a WordPress

Zanim odpowiemy, czy to problem dla WordPressa, warto powiedzieć wprost, o czym mowa, bo termin robi zawrotną karierę i rozumiany jest różnie.

Warto też zaznaczyć jedno zastrzeżenie do samej liczby. Różne zbiory danych opowiadają różne historie. W3Techs pokazuje spadek i wzrost kategorii bez wykrywalnego CMS-a, ale to jeden pomiar oparty na własnej metodzie wykrywania. Inne źródła kładą akcenty inaczej. Nie zmienia to kierunku, bo kierunek potwierdza kilka niezależnych obserwacji, ale każdy, kto rzuca jedną liczbą jako dowodem, upraszcza. Nas nie interesuje tu dokładny procent, tylko zjawisko: część rynku faktycznie odchodzi od gotowych CMS-ów w stronę stron generowanych z promptu.

#Czym jest vibecoding

Vibecoding to budowanie aplikacji przez opisywanie ich modelowi językowemu i akceptowanie tego, co wygeneruje, bez czytania kodu linijka po linijce. Narzędzia to Lovable, Bolt.new, v0 od Vercela, Replit Agent i Base44. Wpisujesz “zrób sklep z logowaniem i płatnościami”, dostajesz działający frontend, bazę (zwykle Supabase) i deploy w kilka minut.

Dla prototypu, wewnętrznego narzędzia albo landingu, który ma żyć tydzień, to naprawdę dobre. Robimy tak własne makiety, żeby pokazać klientowi kierunek, zanim ktokolwiek napisze produkcyjny kod. Problem zaczyna się dopiero wtedy, gdy taki wynik trafia na produkcję jako fundament biznesu.

#Vibe coding a agentic coding: fala narzędzi 2026

Pod hasłem “niech AI to napisze” kryją się dziś dwie różne rzeczy i warto je rozdzielić, zanim ocenisz, na co właściwie patrzysz. Narzędzia prompt-to-app (Lovable, Bolt.new, v0, Replit Agent, Base44) generują całą działającą aplikację z jednego zdania i chowają kod przed oczami. Agentic coding to fala, która przebiła się w 2026 roku: agenci kodujący, którzy pracują wewnątrz prawdziwego repozytorium (Cursor, Claude Code oraz nowe agentowe IDE Google Antigravity i AWS Kiro), napędzani modelami z pierwszej ligi, jak Gemini 3, edytują pliki, uruchamiają testy i otwierają pull requesty tak, jak zrobiłby to programista.

Narzędzia agentowe dają zauważalnie bardziej utrzymywalny kod niż generacja prompt-to-app, bo działają na realnej bazie kodu z kontrolą wersji, a nie na zaplombowanym podglądzie. To realna poprawa i właśnie dlatego zainteresowanie w wyszukiwarce wokół nich rośnie. Tu też wkrada się nieporozumienie: lepsze generowanie kodu to nie to samo co odpowiedzialność. Agentowe IDE i tak wrzuci klucz Supabase do bundla, i tak zostawi trasę admina bez autoryzacji, i tak wyrenderuje katalog wyłącznie po stronie klienta, jeśli nikt mu nie każe inaczej, bo model optymalizuje pod “funkcja działa, gdy ją testuję”, a nie pod “to przetrwa realny ruch, audyt i unijne wymogi dostępności”. Narzędzie weszło o szczebel wyżej. Dystans między działającym demo a systemem produkcyjnym, za który ktoś odpowiada, nie drgnął. Którekolwiek narzędzie to zbudowało, pytania z dalszej części tego tekstu pozostają te same.

#Gdzie vibecodowane strony się sypią

To nie jest obrona WordPressa z urzędu. To lista tego, co realnie widać, gdy ktoś przychodzi z prośbą “działało, a teraz nie działa”:

• Klucze w bundlu. Model wrzuca klucz service_role Supabase do kodu, który ląduje w przeglądarce. Każdy z narzędzi deweloperskich go odczyta. W 2025 roku przez wycieki kluczy z aplikacji budowanych w Lovable i bazy Supabase bez włączonego Row Level Security wyciekały całe tabele użytkowników.
• Endpointy bez autoryzacji. Prompt “zrób panel admina” generuje panel, ale trasa /api/admin nie sprawdza, kto puka. Wygląda, że działa, bo autor testuje ją zalogowany na własne konto.
• Brak walidacji i limitów. Formularz kontaktowy bez rate limitingu i sanityzacji staje się otwartą bramą do wysyłki spamu i prób iniekcji.
• Niewidzialność w wyszukiwarce. Treść renderowana dopiero po stronie klienta, bez renderowania po stronie serwera, to dla robota Google pusta strona. Katalog produktów, który nie istnieje w kodzie HTML, nie trafi do indeksu.
• Zero ścieżki utrzymania. Brak migracji bazy, backupów, wersjonowania i pipeline’u. Pierwsza poważniejsza zmiana to przepisywanie od zera, bo nikt, łącznie z autorem promptu, nie wie, dlaczego to zostało zbudowane tak, a nie inaczej.
• Dostarczalność maili na łasce dostawcy. Wygenerowany formularz wysyła maile przez darmowy provider bez SPF, DKIM i DMARC. Potwierdzenia zamówień lądują w spamie, a właściciel dowiaduje się o tym od klientów, nie z panelu.
• Dostępność zignorowana. Kontrast, focus, obsługa klawiaturą, etykiety pól. Model generuje ładny ekran, nie dostępny interfejs. W Unii, przy wymogach European Accessibility Act, to nie jest kosmetyka, tylko ryzyko prawne.
• Uzależnienie od jednej platformy. Kod jest spięty z konkretnym hostingiem preview i konkretną bazą. Wyjście z tego ekosystemu, gdy rachunki zaczną rosnąć wraz z ruchem, oznacza migrację, na którą nikt się nie przygotował.

Dwa konkretne przypadki z ostatnich miesięcy. Startup zbudował panel klienta w Bolt.new i ruszył w tydzień. Po dwóch tygodniach okazało się, że użytkownicy widzą i edytują dane z cudzych kont, bo anon key Supabase leżał w kodzie, a Row Level Security nie było w ogóle. Druga firma postawiła “sklep” w v0. Ładny, szybki, i po trzech miesiącach zerowy ruch z Google, bo cały katalog renderował się dopiero w przeglądarce. Obie strony wyglądały bez zarzutu w dniu premiery. To jest pułapka vibecodingu: demo jest bezbłędne, a rachunek przychodzi później.

#Niewidzialna nie tylko dla Google, ale i dla AI

Jest w tym ironia. Vibecoding to produkt ery AI, a strony, które tworzy, bywają niewidzialne właśnie dla AI. Jeśli treść pojawia się dopiero po uruchomieniu skryptu w przeglądarce, to nie widzi jej ani robot Google, ani silniki odpowiedzi, które budują AI Overviews i podobne funkcje. Model, który podsumowuje sieć, czyta HTML, a nie renderuje aplikacji. Nie ma w HTML katalogu, nie ma go w odpowiedzi.

To podwójna strata. Strona traci ruch z klasycznych wyników i jednocześnie wypada z nowego kanału, na którym coraz częściej zaczyna się ścieżka zakupowa. Widoczność w funkcjach generatywnych da się mierzyć, o czym piszemy osobno, ale najpierw treść musi w ogóle istnieć w kodzie, który maszyna potrafi przeczytać. Strona zbudowana wyłącznie po stronie klienta tego progu nie przechodzi.

#Dlaczego wygenerowany kod trudno utrzymać

Problem nie kończy się na pojedynczych lukach. Chodzi o strukturę. Model optymalizuje pod to, żeby ekran zadziałał teraz, a nie pod to, żeby ktoś rozwijał kod za pół roku. W praktyce oznacza to kilka powtarzalnych wzorców: ta sama logika skopiowana w pięciu miejscach zamiast wydzielona raz, brak podziału na warstwy, brak testów, które ostrzegłyby, że zmiana coś zepsuła, i zależności dobrane pod modę, a nie pod stabilność.

Każda z tych rzeczy z osobna jest do przełknięcia. Razem tworzą kod, w którym drobna zmiana potrafi zepsuć coś odległego, a nikt nie wie o tym, dopóki nie zadzwoni klient. Utrzymanie strony to nie jest dorzucanie funkcji. To pewność, że dorzucenie funkcji niczego nie wywróci. Wygenerowany kod tej pewności nie daje, bo nikt go nie projektował z myślą o zmianie.

#Jak rozpoznać vibecodowaną stronę

Nie trzeba do tego dostępu do kodu. Kilka sygnałów wystarczy:

• Podgląd źródła (Ctrl+U) pokazuje niemal pusty <body> i jeden duży plik JavaScript. Treść pojawia się dopiero po załadowaniu skryptu.
• Wyłączenie JavaScriptu zostawia białą stronę zamiast tekstu.
• W wynikach Google strona nie ma podstron poza główną, mimo że w przeglądarce widać ich wiele.
• Brak strony logowania pod własną domeną albo panel oparty wyłącznie o zewnętrzny serwis bez konfiguracji uprawnień.
• Nagłówki odpowiedzi wskazują na hosting typu preview (Vercel, Netlify) bez własnej warstwy aplikacji.

Żaden z tych punktów osobno nie jest wyrokiem. Razem układają się w obraz strony, która powstała z promptu i nigdy nie dostała fundamentu.

#Vibecoding a WordPress na produkcji

Tabela nie mówi, że vibecoding jest zły. Mówi, do czego każde z narzędzi pasuje. Do sprawdzenia pomysłu w weekend, vibecoding wygrywa bez dyskusji. Do serwisu, który ma zarabiać za rok, wygrywa fundament.

#Co realnie sprawdza audyt strony zrobionej przez AI

Kiedy trafia do nas taka strona, nie zaczynamy od przepisywania. Zaczynamy od diagnozy, bo “działało, a teraz nie działa” ma zwykle kilka warstw. Kolejność jest zawsze podobna:

1. Bezpieczeństwo najpierw. Czy w kodzie ładowanym do przeglądarki są klucze, których tam być nie powinno. Czy baza ma włączone reguły dostępu. Czy endpointy sprawdzają uprawnienia. To decyduje, czy stronę można w ogóle bezpiecznie zostawić w sieci na czas naprawy.
2. Renderowanie i indeks. Czy treść jest w HTML, czy dopiero w JavaScript. Ile podstron faktycznie widzi Google. Czy są przekierowania, kanoniczne i mapa strony. To odpowiada na pytanie, dlaczego ruch organiczny nie przychodzi.
3. Dane i ciągłość. Gdzie są dane, czy są kopie, czy da się je wyeksportować. Bez tego każda dalsza decyzja jest ryzykowna.
4. Decyzja: ratować czy przepisać. Dopiero teraz. Czasem wystarczy dołożyć warstwę, której zabrakło. Czasem taniej i bezpieczniej jest przenieść treść na fundament, który da się utrzymać. Audyt mówi, która z tych dróg jest tańsza w skali roku, a nie tylko w tym tygodniu.

Najważniejsze, że to nie jest praca dla kolejnego promptu. Prompt nie przeczyta cudzego kodu ze zrozumieniem odpowiedzialności za skutki. Inżynier tak.

#Dlaczego to nie koniec WordPressa

Udział spada, bo dolna półka rynku, czyli proste strony stawiane kiedyś na WordPressie “bo tak”, faktycznie przenosi się na AI. I dobrze. To była najmniej dochodowa, najbardziej jednorazowa część rynku. WordPress traci to, na czym i tak nikt nie zarabiał.

Zostaje reszta: sklepy WooCommerce z realnym obrotem, serwisy z wielojęzycznością i poprawnym hreflang, strony pod RODO i inne wymogi zgodności, projekty, które mają żyć pięć lat i przetrwać kilkanaście aktualizacji. Tam vibecoding nie sięga, bo tam nie chodzi o wygenerowanie ekranu, tylko o fundament: bezpieczeństwo, wydajność mierzalną w Core Web Vitals, utrzymanie i odpowiedzialność za to, co stanie się o drugiej w nocy w szczycie Black Friday.

WordPress nie wygrywa dlatego, że jest modny. Wygrywa dlatego, że ma dwadzieścia lat ekosystemu, przewidywalną ścieżkę utrzymania i człowieka, który wie, dlaczego coś jest zbudowane tak, a nie inaczej.

#Kiedy WordPress też nie jest odpowiedzią

Żeby było uczciwie: nie każdy projekt to WordPress. Jeśli budujesz aplikację czasu rzeczywistego, produkt oparty w całości na jednym interfejsie aplikacyjnym, panel z ciężką logiką po stronie klienta albo coś, co z natury jest aplikacją, a nie serwisem treści, to inne narzędzia będą lepsze. WordPress świetnie prowadzi treść, sklep, integracje i widoczność w wyszukiwarce. Nie jest uniwersalnym młotkiem i traktowanie go jak takiego kończy się równie źle jak wrzucenie sklepu na vibecodowany prototyp.

Różnica polega na tym, że wybór między WordPressem, dedykowaną aplikacją a czymś jeszcze innym to decyzja architektoniczna, którą ktoś podejmuje świadomie, znając konsekwencje. Vibecoding tej decyzji nie podejmuje. On generuje to, co statystycznie pasuje do promptu, i zostawia konsekwencje na później.

#Kto odpowiada, gdy coś pójdzie nie tak

To pytanie zwykle pada za późno, bo pada dopiero wtedy, gdy coś już poszło nie tak. Prompt nie ma dyżuru. Model nie oddzwoni, gdy w sobotę wieczorem sklep przestanie przyjmować płatności. Wygenerowana strona nie ma właściciela technicznego, który zna jej historię i wie, gdzie szukać.

Fundament to nie tylko kod. To ktoś, kto bierze odpowiedzialność za skutki. W erze, w której coraz więcej da się wygenerować, to właśnie odpowiedzialność staje się rzadkim towarem. Nie chodzi o to, żeby nie używać AI. Sami jej używamy codziennie. Chodzi o to, żeby między wygenerowanym ekranem a działającym biznesem stał człowiek, który rozumie różnicę i odpowiada za to, co ląduje na produkcji.

#Kiedy vibecoding ma sens, a kiedy zadzwonić po seniora

Prosto. Prototyp, MVP, wewnętrzne narzędzie albo landing na kampanię, vibecoduj śmiało. Szybko, tanio, wystarczająco. Sklep, serwis firmowy albo cokolwiek, co ma z czegoś żyć i istnieć za rok, potrzebuje fundamentu, a nie wygenerowanego ekranu.

Jest jeszcze pytanie o koszt, które pada najczęściej: skoro AI zrobiło to w dzień, to naprawa powinna być tania. Nie zawsze. Nakład zależy od tego, jak głęboko sięgają problemy. Jeśli brakuje tylko warstwy bezpieczeństwa i poprawnego renderowania, a treść i dane da się przenieść, praca jest ograniczona i przewidywalna. Jeśli fundamentu nie ma w ogóle, a strona już zebrała klientów, dane i pozycje w Google, to migracja z zachowaniem tego wszystkiego jest większym projektem niż zbudowanie od nowa na czystym gruncie. Dlatego audyt zaczyna się od diagnozy, a wycena jest zawsze indywidualna: dopiero po sprawdzeniu, co jest do uratowania, da się rzetelnie powiedzieć, która droga jest tańsza w skali roku.

Jeśli masz już stronę zbudowaną przez AI i coś zaczyna się sypać, od wycieków, przez brak ruchu, po “nie da się tego rozwinąć”, to zwykle naprawialne, ale nie kolejnym promptem. Naprawiamy strony zrobione przez AI: audyt bezpieczeństwa, SEO od zera i decyzja, co przepisać, a co uratować. Robi to programista, który przeczyta kod, którego nikt wcześniej nie czytał.