Popularna narracja wokół programowania z AI promuje prosty scenariusz: otwierasz edytor, wpisujesz w okno czatu luźne polecenie i patrzysz, jak model generuje gotowy ficzer. W małych, izolowanych skryptach pisanych od zera ten styl pracy czasem się sprawdza. W WordPressie prowadzi wprost do zepsutych stron i błędów na produkcji.
WordPress nie jest zbiorem niezależnych plików PHP. To połączony organizm, w którym zachowanie kodu zależy od stanu bazy danych, priorytetów hooków, aktywnych wtyczek i ukrytych opcji. Gdy prosisz agenta o napisanie kodu na podstawie zdawkowego promptu, model musi zgadywać brakujący kontekst. Kod wygląda składniowo poprawnie, ale wywraca się w działaniu.
Gdy w projektach dla klientów pracuję z WordPressem i korzystam z agentów kodujących, zależy mi przede wszystkim na przewidywalności. Dlatego całkowicie porzuciłem swobodne promptowanie. Zastąpiłem je czterema zsynchronizowanymi warstwami: Document-Driven Development (DDD), analizą statyczną z mostem do środowiska uruchomieniowego przez Novamira MCP na devie, weryfikacją wizualną z człowiekiem w pętli oraz linkami podglądu przez WordPress Studio.
Warstwa 1: Document-Driven Development odcina zgadywanie
W tekście analizującym gdzie agenci AI radzą sobie najlepiej w starciu Laravela, WordPressa i Astro pokazałem, że agenci zawodzą najczęściej wtedy, gdy prawda o systemie leży poza repozytorium. Jeżeli model nie zna reguł biznesowych, schematu danych ani warunków brzegowych, po prostu je zmyśla.
Zgadywaniu zapobiega Document-Driven Development. Zanim agent dotknie pojedynczej linijki kodu w PHP czy JavaScript, przygotowuję konkretny dokument techniczny dla danego ficzera. Ten plik opisuje trzy kluczowe elementy:
Po pierwsze, precyzuje problem biznesowy i ograniczenia. Wskazuje dokładnie, co ficzer ma realizować, a czego ma celowo nie dotykać.
Po drugie, definiuje struktury danych, sygnatury funkcji i nazwy hooków. Jeśli funkcja operuje na custom post types albo wpisach w tabeli opcji, dokładne klucze i schematy znajdują się w dokumencie.
Po trzecie, zawiera mechaniczną checklistę kryteriów akceptacji. Agent przystępujący do pracy czyta ten dokument jako główny kontekst zadania. Zamiast improwizować, realizuje spisaną specyfikację. Przygotowanie takiego dokumentu zajmuje kwadrans, a oszczędza godziny debugowania kodu, który powstał z błędnych założeń.
Warstwa 2: Narzędzia statyczne, WP-CLI i runtime MCP przez Novamirę
Nawet najlepsza specyfikacja zostawia agenta częściowo ślepym, jeśli analizuje on wyłącznie statyczne pliki na dysku. Standardowe narzędzie AI widzi kod w Twoim edytorze. Nie wie jednak, jakie wtyczki są włączone w bazie, jakie wartości przechowuje tabela wp_options ani jak zaindeksowano tabele niestandardowe.
W środowisku deweloperskim łączę twarde reguły statyczne z dostępem do działającego środowiska. Zanim kod zostanie wykonany, lintery i narzędzia analizy statycznej weryfikują typy, standardy formatowania i błędy składniowe. Równolegle używam WP-CLI do operacji wsadowych, czyszczenia cache’u i deterministycznej weryfikacji konfiguracji systemu.
Lukę między statycznym kodem a silnikiem WordPressa zamyka połączenie agenta z runtime’em przez wtyczkę Novamira wykorzystującą Model Context Protocol (MCP).
Na maszynie deweloperskiej Novamira daje agentowi pełne uprawnienia programistyczne. Model może badać bazę danych przez $wpdb, sprawdzać zarejestrowane hooki, weryfikować wpisy konfiguracyjne i testować wywołania funkcji PHP w realnym kontekście aplikacji.
Novamira odblokowuje również zaawansowaną integrację z edytorem blokowym. Agent potrafi badać szablony Full Site Editing (FSE), sprawdzać atrybuty bloków i bezpiecznie modyfikować ich strukturę. Ponieważ Gutenberg bazuje na komentarzach HTML i atrybutach JSON, bezpośrednia edycja bloków przez runtime zapobiega uszkodzeniom znaczników.
Ten pełny dostęp rezerwuję wyłącznie dla środowisk lokalnych i stagingowych. Na serwerach produkcyjnych nigdy nie instaluję wtyczek MCP. Produkcja przyjmuje wyłącznie przetestowane commity z repozytorium.
Warstwa 3: Weryfikacja wizualna w przeglądarce i rola człowieka (HITL)
Czyste przejście testu jednostkowego i brak błędów składniowych w PHP nie oznaczają, że interfejs działa. W WordPressie style motywu, globalne arkusze CSS i style panelu administracyjnego nieustannie wchodzą ze sobą w konflikty.
Agent potrafi wygenerować poprawny logicznie kod, który na ekranie tworzy bezużyteczny widok. Przyciski nachodzą na siebie, elementy łamią siatkę na urządzeniach mobilnych, a powiadomienia systemowe zasłaniają formularze. Żaden statyczny linter nie wykryje takich wad.
Do weryfikacji interfejsu stosuję stałą pętlę podglądu w przeglądarce z udziałem człowieka (Human-in-the-Loop). Przy prostych korektach CSS model radzi sobie szybko, ale przy złożonych komponentach i realnych interakcjach ocena programisty pozostaje niezastąpiona.
Obserwuję stronę w oknie obok edytora, sprawdzając zachowanie interfejsu w realnych warunkach. Testuję responsywność, badam wyrenderowane drzewo DOM i sprawdzam wyliczone style CSS.
Gdy pojawia się błąd wizualny, przekazuję agentowi konkretne zachowanie layoutu w przeglądarce. Dzięki precyzyjnej informacji zwrotnej o realnym renderowaniu, model natychmiast koryguje style bez zgadywania.
Warstwa 4: Podgląd dla klienta w WP Studio, produkcja klasycznie
Kiedy ficzer spełnia kryteria ze specyfikacji, przechodzi weryfikację w runtime i wygląda poprawnie w przeglądarce, wymaga weryfikacji poza lokalną maszyną. Prezentacja zmian interesariuszom wymaga działającego, publicznego linku.
Do publikowania szybkich podglądów w chmurze na potrzeby akceptacji klienta wykorzystuję WordPress Studio. Narzędzie pozwala błyskawicznie wystawić działające środowisko demonstracyjne bez angażowania serwerów stagingowych czy konfigurowania tymczasowego hostingu.
Gdy klient zaakceptuje wprowadzone zmiany, proces wdrożenia wraca na klasyczne tory inżynierskie. Wdrożenia produkcyjne nie odbywają się przez przyciski w lokalnych narzędziach. Prawdziwe wydania na produkcję przechodzą przez system kontroli wersji, testy w CI i procedury wdrożeniowe na serwerze docelowym. Rozdzielenie demonstracji dla klienta od wdrożenia produkcyjnego chroni stabilność systemu.
Dlaczego ten proces wygrywa ze zwykłym promptowaniem
Wielu programistów wciąż patrzy na WordPressa przez pryzmat przypadkowych wtyczek albo od razu sięga po architekturę headless, nawet gdy uporządkowany monolit byłby prostszy w utrzymaniu. W tekście o WordPressie kontra reszcie świata CMS-ów argumentowałem, że platforma zachowuje potężne zalety aplikacyjne, o ile podchodzimy do niej z inżynierską dyscypliną.
Swobodny „vibe coding” traktuje tworzenie oprogramowania jak luźną rozmowę towarzyską. W złożonych systemach CMS takie podejście szybko się załamuje. Gdy oprzesz swój workflow na spisanej dokumentacji, bezpośrednim wglądzie w stan aplikacji, weryfikacji wizualnej i przewidywalnym wdrożeniu, agenci AI przestają być nieprzewidywalną ciekawostką.
Ten proces nie obiecuje magicznych cudów w kilka chwil. Sprawia natomiast, że dowożenie stabilnych funkcji jest zauważalnie tańsze, szybsze i o wiele mniej podatne na błędy architektoniczne niż tradycyjny development. Document-Driven Development wyznacza granice, Novamira daje wgląd w stan WordPressa, człowiek w pętli chroni doświadczenie użytkownika, a klasyczne procedury wdrożeniowe zabezpieczają produkcję.