Najpopularniejsza teza ostatnich dwóch lat w polskiej branży WordPress brzmi: AI zastąpi developerów. Pojawia się w prezentacjach na konferencjach, w postach na LinkedInie, w komentarzach pod każdym wpisem o AI w WordPressie, w rozmowach na grupach branżowych. Czasem w tonie ostrzeżenia („przygotujcie się”), czasem entuzjazmu („wreszcie taniej”), czasem rezygnacji („już po nas”).
W poprzednim wpisie mini-serii postawiłem dwa wektory ekonomiczne — AI obniża koszt wykonania, agentic webpodnosi koszt niewdrożenia agent-readiness. W tym wpisie skupiam się na tym pierwszym. Konkretnie: co AI w pracy developera WordPress dziś faktycznie automatyzuje, czego nie automatyzuje, i dlaczego teza „AI zastąpi developerów” — brana dosłownie — jest błędna.
To nie jest obrona stanowiska „wszystko będzie po staremu”. Wręcz przeciwnie. Praca developera WordPress w 2026 zmienia się znacząco — i ten kto tego nie widzi, faktycznie traci pozycję. Ale zmiana nie jest tym samym, co zastąpienie. I dokładnie ta różnica decyduje, kto na rynku zostanie, a kto zniknie.
Co AI dziś automatyzuje w pracy developera WordPress
Cztery obszary, w których AI w 2026 roku faktycznie zastępuje pracę, którą wcześniej robił człowiek.
Pierwszy — boilerplate code. Customowe typy postów, taksonomie, pola, podstawowe shortcody, integracje z popularnymi wtyczkami przez ich publiczne API — to są zadania, które rok temu wymagały godziny-dwóch pracy, dziś wymagają opisania promptem i weryfikacji wyniku. Cursor, Claude Code, GitHub Copilot, plus polskie laboratoria typu Promptujemy — wszystkie one obsługują tę warstwę kompetentnie. Developer, który wciąż pisze boilerplate ręcznie, marnuje swój czas i czas klienta.
Drugi — modyfikacje motywów i child themes. Customowe child themes pod konkretne potrzeby klienta, modyfikacje funkcji w functions.php, własne hooki, custom shortcuts — to zadania, które AI dziś robi z dokładnością wystarczającą do produkcji. Nie wszystkie modyfikacje, nie zawsze za pierwszym razem — ale w stopniu, który redukuje czas pracy z dni do godzin.
Trzeci — debugowanie błędów. Stack trace z PHP, nieoczekiwane zachowanie wtyczki, konflikt między motywem a WooCommerce — wklejasz problem do modelu i dostajesz hipotezę o przyczynie wraz z propozycją naprawy. Często trafna, czasem trzeba korygować, ale to jest radykalnie szybsze niż klasyczne debugowanie. Developer, który tego nie używa, jest dziś dwukrotnie wolniejszy od kolegi, który używa.
Czwarty — generowanie treści technicznych. Dokumentacja kodu, README dla wtyczki, opis modułu na docs, instrukcja konfiguracji — to wszystko AI dziś robi sprawnie. Pisałem o ograniczeniach generowania w mini-serii o AI do treści, ale w warstwie technicznej, gdzie ślad autora jest mniej istotny, generowanie działa lepiej niż w content marketingu.
Razem te cztery obszary obejmują znaczącą część typowej pracy developera WordPress. Według mojego szacunku — ostrożnego, opartego na obserwacji własnej praktyki i rozmów w branży — można dziś automatyzować około 30-50% czasu typowego projektu WordPressowego. Czyli to, co rok temu zajmowało developerowi 80 godzin, dziś zajmuje 40-55. Spadek realny, mierzalny, znaczący.
To jest argument za tezą „AI zastępuje developerów” — w tej części, w której teza jest prawdziwa.
Czego AI nie zastępuje — i nie zastąpi w 2026
Trzy obszary, w których teza upada przy konfrontacji z konkretem.
Pierwszy — architektura. Decyzje o tym, jak ułożyć strukturę projektu, jakie wtyczki dobrać, czy budować custom czy używać gotowca, jak zaprojektować bazę danych dla niestandardowych potrzeb, jak rozłożyć logikę między motyw a wtyczki, jak zorganizować workflow developerski — to są decyzje wymagające zrozumienia kontekstu projektu, klienta i rynku. AI w 2026 nie rozumie żadnej z tych warstw na tyle, żeby podjąć decyzję, która za rok-dwa nie wymaga refaktoryzacji.
Konkretnie: AI zapytane „stwórz mi sklep WooCommerce sprzedający kursy online” da kod, który działa. Ale tego kodu nie zaprojektuje tak, żeby skalował się do 10 tysięcy kursów, integrował z systemem płatności partnerskich klienta, przewidywał ich planowane wprowadzenie programu lojalnościowego, i był utrzymywalny przez kogoś, kto przyjdzie po roku. Architektura wymaga rozumienia, którego AI nie ma. Ma wzorce, które kopiuje. Decyzje, które są kontekstowe — nie potrafi.
Drugi — agent-readiness. O tym pisałem w serii Agent-ready. Sześć filarów przygotowania strony na agentów AI to nie jest warstwa techniczna w sensie pisania kodu. To jest warstwa decyzji strategicznych — jakie dane strukturalne ma generować strona, kogo wpuszczać, jak segmentować ruch agentowy, jakie polityki ustawić w robots.txt, kiedyimplementować propozycje typu llms.txt czy WebMCP, czego się jeszcze nie wdrażać.
Każda z tych decyzji wymaga zrozumienia rynku, dostawców AI, polityki vendorów, regulacji EU, ekonomii projektu. AI w 2026 teoretycznie może wykonać każdy techniczny element po podjęciu decyzji. Decyzji nie podejmie. To jest przestrzeń, w której pracuje człowiek — i to coraz droższy człowiek, w miarę jak rynek wycenia tę kompetencję.
Konkret: narzędziownia iFox, w której zbieram narzędzia agent-readiness (m.in. GEO checker, generator schema, generator alt-tekstów), to jest produkt zbudowany przez praktyka świadomego, które warstwy agent-readiness mają sens, które są jeszcze w fazie eksperymentu, których nie warto dziś implementować. AI mogło wygenerować większość kodu. Ale decyzję, co w tej narzędziowni ma się znaleźć i dlaczego, podjął człowiek. To jest dokładnie ten typ kompetencji, którego AI nie zastępuje.
Trzeci — odpowiedzialność. Strona klienta przestała działać. Płatności nie przechodzą w sklepie. Agent z OpenAI zaczął generować ruch atakujący formularze. RODO inspektor zwraca uwagę na pliki cookie. Klient potrzebuje kogoś, kto bierze za to odpowiedzialność. AI tej roli nie pełni. Może pomóc w diagnozie, w naprawie, w komunikacji — ale odpowiedzialność jest po stronie człowieka. I za odpowiedzialność klient płaci stawkę, której AI nie zniweluje.
Pisałem o ryzyku ataków na agenty na CyberFluxie — szczegółowe mechanizmy prompt injection, permission injection, agent hijackingu. To są ryzyka, których automatyczne narzędzia nie eliminują. Wymagają człowieka, który rozumie, co może pójść źle, i bierze za to odpowiedzialność.
Dwa rodzaje developerów WordPress w 2026
Z obu list — co AI zastępuje i czego nie zastępuje — wyłaniają się dwie kategorie developerów.
Box: profile rynkowe developera WordPress w 2026
Profil 1 — developer wykonawczy. Pracuje głównie w warstwie boilerplate, child themes, prostych integracji, debugowania. Klient płaci za godziny. Konkurencja: każdy inny developer plus AI, które robi 30-50% tej pracy automatycznie. Pozycja rynkowa: kurcząca się. Strategia ucieczki: specjalizacja w niszy, której AI nie zastępuje.
Profil 2 — developer strategiczny. Pracuje w warstwie architektury, agent-readiness, integracji systemów AI z WordPressem, optymalizacji pod cytowalność modeli, zabezpieczania krytycznych akcji. Klient płaci za kompetencję i odpowiedzialność. Konkurencja: niewielka, bo specjalistów w każdej z tych warstw jest mało. Pozycja rynkowa: rosnąca. Strategia rozwoju: pogłębianie specjalizacji.
Profile pośrednie — większość developerów dzisiaj. Część pracy w warstwie wykonawczej, część w strategicznej. Decyzja, w którą stronę się przesuwać, jest strategiczną decyzją zawodową, nie tylko technologiczną. Im dłużej zostaje się w profilu 1, tym trudniej później przejść do profilu 2.
Ta dwoistość rynku jest dziś najsilniejszą konsekwencją AI w pracy developera WordPress. Nie „AI zastępuje developerów”. Tylko „AI zastępuje jedną kategorię developerów, jednocześnie podnosząc wartość drugiej kategorii„. To jest zupełnie inne stwierdzenie — z innymi konsekwencjami praktycznymi.
Co konkretnie warto zrobić w 2026
Dla developera WordPress, który czyta to z perspektywy własnej kariery, trzy rekomendacje praktyczne.
Po pierwsze — używaj AI do warstwy wykonawczej, niezależnie od profilu. Cursor, Claude Code, Copilot, plus polskie narzędzia laboratoryjne typu Promptujemy. To nie jest opcja, to jest standard. Developer, który nie używa tych narzędzi, jest dwukrotnie wolniejszy od kolegi, który używa, przy tej samej jakości wyniku. To nie jest moralna decyzja — to jest decyzja konkurencyjna. Klient nie zapłaci więcej za kod napisany ręcznie tam, gdzie AI robi go w godzinę, niezależnie od twoich preferencji.
Po drugie — buduj kompetencję agent-readiness. To jest nisza, w której konkurencja jest dziś mała, popyt rośnie, a AI jej nie zastępuje. Sześć filarów, narzędzia diagnostyczne, monitoring ruchu, dane strukturalne, polityki w robots.txt, llms.txt, integracje z agentami — każda z tych warstw to potencjalna specjalizacja. Hub Agent-readiness jest wymaganą lekturą dla każdego, kto chce się w tę niszę przesunąć.
Po trzecie — przesuń się od godzin do projektów. Stawka godzinowa to model, który AI zniweluje, bo godziny się skracają. Stawka projektowa, oparta na wartości dostarczanej dla klienta, jest mniej wrażliwa na ten spadek. „Audit agent-readiness twojego sklepu i implementacja niezbędnych warstw — 8000 zł” jest wyceną, którą można obronić, bo wartość dla klienta jest mierzalna (wzrost cytowalności, zmniejszenie ryzyka). „Praca developerska — 200 zł/h” jest wyceną, która znika w erze AI, bo godziny przestają być adekwatną metryką pracy.
Co z tego wynika dla całej branży
Polska branża WordPress jest dziś w fazie cichej restrukturyzacji. Część developerów już zauważyła zmianę i przesuwa się w stronę profilu 2 — specjalizacja w agent-readiness, w integracjach AI, w architekturze rozwiązań pod konkretne segmenty rynku. Część nie zauważyła i wciąż pracuje w profilu 1, czując, że „klientów jest mniej i są tańsi”.
To pierwsze przesunięcie nie jest jeszcze masowe. Ale to fala wczesnych przesunięć, która dziś, w 2026, dotyczy może 10-15% polskich developerów WordPress. Za rok-dwa będzie 30-40%. Za trzy-cztery — większość. I rynek dla developerów, którzy nie zrobili przesunięcia, będzie radykalnie mniejszy niż dziś.
Teza „AI zastąpi developerów” wymaga więc precyzyjnego dopisku. AI zastępuje developerów, którzy nie przesunęli się w stronę kompetencji, których AI nie zastępuje. Brzmi banalnie, ale w branży, która dyskutuje teraz o tym binarnie („AI nas zastąpi” vs „AI nam pomoże”), to jest rozróżnienie, którego brakuje.
Złota zasada — zmienia się to, kim jest developer, nie czy istnieje
Najprostsza reguła z tego wpisu: AI nie zastępuje developera WordPress. AI zastępuje typ pracy, który dotąd nazywaliśmy „pracą developera”. To, kim jest developer w 2026, jest definiowane przez to, czego AI nie zastępuje — architekturę, agent-readiness, odpowiedzialność. Reszta jest narzędziowo wspomagana.
Następny wpis dotyczy agencji — bo to, co dla developera jest decyzją zawodową, dla agencji jest decyzją biznesową. Zmiana ta sama, ale w innej skali i z innymi konsekwencjami operacyjnymi.
