Зазвичай я вчуся новому тоді, коли цього вимагає реальний клієнтський проєкт.
Я стежу за інструментами, трендами й новими підходами до роботи, але більшість відкриттів стають “справжніми” лише тоді, коли вони вирішують конкретну задачу тут і зараз. Саме так сталося і з цим зрушенням.
Роками мій надійний WordPress-стек виглядав приблизно так: Blocksy, блоковий редактор і плагіни на кшталт Greenshift, коли потрібна була більша свобода в дизайні. Якщо клієнт не мав дуже точного візуального напрямку, я часто стартував із шаблону й далі працював від нього: замінював секції, додавав нові, прибирав зайве і поступово формував сайт так, щоб він відповідав потрібному результату за виглядом, структурою та функціоналом.
Це працювало. І досі працює.
Але це займає час, і значна частина цього часу йде на ручний сетап, повторюване складання сторінок, розміщення контенту та базову підготовку проєкту ще до того, як починається справжнє полірування.
У 2026 році слово вручну починає зникати з мого підходу до роботи, і клієнтський проєкт на кшталт Happy Mortgage став моментом, коли я реально відчув цю зміну в практиці.
AI змінив масштаб того, що здається можливим
Це не перший раз, коли я використовую AI в роботі з WordPress. Я вже застосовував його для планування, написання коротких фрагментів коду, генерації контенту, і навіть для створення кастомних плагінів або утилітної логіки під проєкти.
Що змінилося для мене останнім часом це усвідомлення, що AI-агент на кшталт Codex може зробити набагато більше автономної роботи, ніж я спочатку думав.
Не лише генерація коду. Не лише поради. Реальна робота над проєктом.
За правильного доступу він може підготувати структуру сайту, створити сторінки, змінити налаштування, попрацювати з кастомними типами постів і взяти на себе значну частину WordPress-сетапу ще до того, як я глибоко зайду в етап візуального дизайну.
Багато з цього стає можливим завдяки WP-CLI.
WordPress це CMS, але він також дуже скриптований. З WP-CLI можна встановлювати й оновлювати плагіни, імпортувати контент, створювати користувачів, робити search-replace у базі, керувати multisite, налаштовувати параметри і збирати це в скрипти, cron або кроки деплою. Значна частина роботи, яка раніше жила лише в адмінці, тепер може бути автоматизована з термінала.
Це змінює ритм проєкту.
Замість того, щоб робити кожен крок руками, я можу описати потреби проєкту, дати агенту підготувати структуру і витратити більше часу на рев’ю, напрям і покращення.
Вибір стеку, з яким Codex працює найкраще
На момент написання в мене були активні ліцензії на:
- Blocksy Pro + helper plugin
- Greenshift Pro
- Breakdance Builder Pro
- GeneratePress + GenerateBlocks Pro
Я запитав Codex, який стек буде для нього найпростішим і найнадійнішим, і він обрав GeneratePress + GenerateBlocks Pro.
Це логічно.
GenerateBlocks легший, Gutenberg-native і структурно чистіший за важкі візуальні білдери. Він використовує більш передбачувану блокову систему, тому агенту простіше його аналізувати та змінювати без боротьби з великим шаром пропрієтарної абстракції. Breakdance потужний, Greenshift теж багато вміє, але GenerateBlocks виглядає найкращою відправною точкою, якщо мета співпрацювати з AI-агентом, а не лише руками “малювати” сторінки.
Я також знайшов GitHub-скіл, сфокусований на GenerateBlocks і зроблений спеціально для роботи з LLM: GenerateBlocks Skills. Такі ресурси роблять процес практичнішим, бо допомагають моделі працювати з плагіном більш структуровано, а не здогадуватися.
Мій новий підхід
Ось підхід до роботи, який я почав використовувати, і не думаю, що скоро від нього відмовлюся:
- SSH-доступ до сервера, де встановлений WordPress
- WP-CLI доступний на цьому сервері
- стек, з яким агент може працювати
- AI-агент на кшталт Codex із доступом до термінала
Я збираю інформацію про проєкт в одній папці: бізнес-нотатки, ідеї структури, напрямок для текстів і кілька дизайн-референсів. Потім прошу Codex попрацювати з цим матеріалом і задеплоїти все прямо в WordPress.
У цей момент я менше “виконавець” і більше оркестратор.
Саме це мене найбільше здивувало. Я можу спланувати, підготувати основу і налаштувати структуру сайту одним промптом ще до того, як зайду в детальну роботу з дизайном.
Чи ідеальний результат?
Ні. Навіть близько.
Принаймні поки що.
Щоб випустити справді відполірований сайт, мені все ще потрібна серія ітерацій із Codex: дрібні правки лейауту, відступів, зміни у формулюваннях, виправлення ієрархії й поведінки. Частину речей я все одно роблю вручну, бо інколи швидше пересунути блок самому, ніж ідеально описати візуальний нюанс.
AI-згенерована секція на GenerateBlocks після кількох промптів, яку я потім трохи дополіював вручну.
Але це не зменшує цінність цього підходу. Він все одно економить багато часу.
Менше планування з нуля. Менше повторюваного сетапу. Менше копіювання. Менше “збирання” контенту. Менше нудної бази, яка раніше з’їдала години до початку справді цікавої частини.
Тепер моя основна задача це тримати рівень, який я напрацював за роки, закривати прогалини та полірувати дизайн і UX, доки все не виглядатиме завершеним.
Це дуже інша роль, ніж робити кожен крок вручну.
Куди це рухається
Це все ще ранній етап, і саме тому це так цікаво.
Я не думаю, що WordPress кудись зникне. Він і далі буде сильним CMS, особливо для клієнтських проєктів. Але я вважаю, що спосіб, у який сторінки будуються всередині WordPress, сильно зміниться протягом найближчих років.
Для мене vibe coding це не про “натиснув кнопку і сайт готовий”. Це про те, щоб прибирати дедалі більше тертя між наміром і виконанням.
А коли відчуєш цю зміну в реальному проєкті, її складно ігнорувати.
