WordPress не умрёт, но сайтов станет меньше: вайб-кодинг, Gutenberg, фриланс и CMS после прихода ИИ — интервью с Александром Сокиркой

ИИ-агент уже способен написать плагин для WordPress, активировать его через WP-CLI и выполнить часть действий, ради которых разработчик ещё недавно вручную ходил в админку. Но означает ли это, что сам WordPress становится не нужен? Или, наоборот, огромная экосистема CMS просто получит новый интерфейс — разговор с агентом вместо десятков настроек, плагинов и ручных операций? Александр Сокирка считает, что WordPress никуда не исчезнет, хотя новым разработчикам уже не обязательно начинать карьеру именно с него. (Будущее WordPress. шаблоны, нейросети, фриланс, Wordpress выживет. Александр Сокирка.docx)

С Александром поговорили о том, почему WordPress стало меньше в инфополе, как школьный фриланс с баннерами за пять долларов привёл его сначала к Joomla, а затем к WordPress, почему сегодня для некоторых MVP ему проще взять Laravel и ИИ, чем устанавливать знакомую CMS, чем Gutenberg отличается от Elementor, когда оправдан Headless WordPress и зачем WordPress-разработчику Docker и CI/CD. Отдельная большая тема — фриланс: классические биржи, продажа тем на ThemeForest, зависимость от платформ, работа с американскими студиями и вопрос, куда сегодня идти новичку. Сам Александр пришёл в веб ещё школьником и переходил от дизайна и вёрстки к PHP, CMS и коммерческой разработке постепенно. (Будущее WordPress. шаблоны, нейросети, фриланс, Wordpress выживет. Александр Сокирка.docx)

WordPress пропал из инфополя — или просто изменился сам рынок

Александр: Раньше про WordPress было очень много видео, статей, уроков, вокруг него существовало заметное информационное поле. Сейчас свежего контента как будто стало меньше. Почему, на ваш взгляд, так произошло?

Александр Сокирка: Мне кажется, меняется не только рынок WordPress, а интернет в целом. Последние несколько лет очень активно развиваются нейросети, поэтому люди адаптируются: у кого-то появляется страх, кто-то бросает старое направление, кто-то ищет новые ниши и темы.

Поэтому привычные заголовки вроде WordPress, разработки мобильных приложений и других классических направлений могут отходить на второй план. Про SEO тоже постоянно говорят, что оно умирает или становится менее важным. Я бы не сказал, что всё это обязательно исчезает. Скорее рынок трансформируется, и вслед за ним меняется то, о чём люди говорят и что считают перспективным.

Александр: Тогда начнём с самого начала. Как вы вообще пришли в разработку сайтов и почему в итоге выбрали WordPress, а не Joomla, Drupal или другую CMS?

Александр Сокирка: Всё началось очень давно, ещё в школе. Один знакомый рассказал мне, что можно делать сайты и продавать их на фрилансе. Я тогда вообще не понимал, что такое фриланс. Он объяснил: есть биржи, вы регистрируетесь, находите клиентов и выполняете заказы.

Я зарегистрировался на одной из таких бирж, хотя программировать не умел. Немного разбирался в Photoshop, нажимал какие-то кнопки, пытался что-то рисовать. Мой первый заказ — баннер за пять долларов. Я его нарисовал, продал клиенту и был невероятно счастлив.

Но конечной целью всё-таки оставались сайты. Я самостоятельно читал PDF-книги вроде «HTML для чайников», потом «PHP для чайников» и постепенно переходил к более сложным задачам. Сначала делал дизайн одной страницы в Photoshop и продавал условно за 50 долларов. Потом добавил вёрстку — получалось уже около 100. Через полгода или год изучил PHP, смог добавлять динамику и продавал примерно за 150 долларов дизайн, вёрстку и небольшую самописную CMS.

Так постепенно дошёл до готовых CMS. В русском сегменте тогда была очень популярна Joomla. Это было примерно 17–18 лет назад. Я делал на ней сайты под ключ, получал порядка 200 долларов за проект и проработал так, наверное, год или полтора.

Потом тот самый знакомый, который когда-то привёл меня во фриланс, позвал в компанию, где разрабатывали сайты на WordPress. На тот момент у меня уже было примерно два года фриланса и портфолио. Получилась забавная ситуация: я пришёл собеседоваться как WordPress-разработчик, хотя все предыдущие проекты делал на Joomla.

О WordPress я знал только то, что такая система существует. Мне сказали: «С WordPress знакомы?» Я ответил, что знаком. Показал портфолио на бирже — там в основном были скриншоты сайтов. Меня взяли на двухнедельный тестовый период.

За эти две недели я освоил основные вещи: структуру WordPress, иерархию файлов, устройство тем и плагинов, основные принципы разработки. Со стороны фраза «выучил WordPress за две недели» звучит странно, но важно понимать, что я уже знал PHP, HTML, вёрстку, дизайн и принципы CMS. Мне не пришлось изучать веб-разработку с нуля — нужно было понять устройство конкретной системы.

Александр: У меня путь был очень похожим: книги «для чайников», затем Joomla и только потом WordPress. Причём переходить на новую CMS сначала совсем не хотелось. Почему люди так держатся за уже знакомую систему?

Александр Сокирка: Это совершенно естественно. Когда человек привыкает к какой-то CMS, ему тяжело перейти на новую. Мне кажется, этим отчасти объясняется и популярность WordPress: огромное количество людей к нему привыкло, накопило проекты, знания, плагины, темы, процессы — и просто так от всего этого отказываться никто не собирается.

Я иногда рассказываю на своём канале, что сейчас с помощью нейросетей можно буквально за несколько минут поднять какую-то админку. В комментариях сразу пишут: «Зачем? WordPress прекрасно это умеет».

И я с ними не спорю. Это как раз показывает силу привычки и экосистемы.

Когда-то похожая ситуация была с Joomla. В русском сегменте многие сайты делались на ней, клиенты видели это вокруг и сами просили Joomla. Позднее стало заметнее, что на западном рынке много проектов делают на WordPress, и даже русскоязычные клиенты начали чаще его заказывать. Так пошла новая волна.

То есть победа CMS — это не только вопрос того, какая система технически лучше. Огромную роль играет установленная база, привычки разработчиков, требования клиентов и накопленная экосистема.

Коротко:

• WordPress стало меньше в информационном шуме не потому, что CMS уже исчезает: меняется весь рынок разработки, а значительную долю внимания забрали ИИ и новые способы создания продуктов.
• Сила WordPress — не только в коде. Миллионы существующих проектов, привычки пользователей, разработчиков и клиентов создают инерцию, которую невозможно отменить одной новой технологией.

WordPress против ИИ — неправильная постановка вопроса

Александр: WordPress тоже пытается двигаться в сторону искусственного интеллекта. Как вы считаете, сможет ли он конкурировать с ИИ, вайб-кодингом и такими инструментами, как Codex?

Александр Сокирка: Думаю, сможет. Более того, он уже это делает и никуда не исчезнет.

За WordPress стоит огромнейшее сообщество. Люди не станут просто так переносить существующие сайты на новые CMS или фреймворки только потому, что появилась нейросеть. У меня самого есть ряд сайтов для собственных проектов. У малого бизнеса огромное количество работающих сайтов. Какой смысл выбрасывать всё это и начинать с нуля?

Скорее существующие проекты будут улучшать при помощи ИИ. Где-то он поможет подтянуть безопасность, где-то — скорость загрузки, где-то — дизайн или разработку новой функции. Но сам проект при этом останется на WordPress.

Мне ближе идея, что искусственный интеллект будет не каждый раз изобретать новый софт, а автоматизировать работу с уже существующим. И WordPress для этого подходит очень хорошо.

Я специально экспериментировал с Codex на собственном сайте с уроками и статьями про WordPress. Меня удивило, что агент без дополнительных подсказок использует WP-CLI.

Когда я записываю обычный видеоурок по разработке плагина, процесс выглядит так: мы написали код, затем заходим в админку WordPress, находим плагин и нажимаем «Активировать». Когда похожую задачу выполнял агент, я открыл админку — плагин уже активирован.

Я посмотрел логи и увидел, что агент сам вызвал WP-CLI и активировал плагин через командную строку. То есть даже это ручное действие ему не потребовалось отдавать отдельно.

Плюс развивается история с MCP и интеграциями, через которые агенты смогут работать с WordPress ещё теснее. Поэтому я не воспринимаю ИИ как отдельную CMS, которая обязательно должна уничтожить WordPress. Скорее это новый слой управления существующим софтом.

Александр: А новое поколение разработчиков вообще будет изучать WordPress? Мы выросли на HTML, PHP, самописных сайтах и CMS. Сейчас человек может сразу прийти к нейросети и попросить сделать ему магазин или корпоративный сайт.

Александр Сокирка: Мне кажется, значительная часть нового поколения действительно не будет специально изучать WordPress. Более того, многие не станут сначала глубоко изучать Computer Science. Люди устроены так, что ищут более простой путь. Если можно сформулировать задачу нейросети, очень многие именно это и выберут.

Можно будет попросить: сделайте сайт такой-то сложности. Нейросеть сама подберёт CMS или фреймворк под задачу. Но качество результата будет очень сильно зависеть от качества запроса.

Если вы составили профессиональный, грамотный промпт, результат может быть хорошим. Если написали только «сделайте мне сайт», получите примерно такой же уровень определённости в результате.

Поэтому я допускаю, что новое поколение не станет усложнять себе жизнь обязательным изучением WordPress.

И здесь возникает парадокс: я сам много лет занимаюсь WordPress, но в последнее время для некоторых собственных MVP использую Laravel. Мне нравится наблюдать, как с ним работает ИИ.

Я всегда смотрю логи агента: что он делает, какие вопросы себе задаёт, какие инструменты вызывает. В Laravel мне особенно нравится, что после задач агент способен создавать тесты. И это не тест ради теста. Я открываю его и вижу нормальную функциональную проверку.

В небольшом проекте у вас постепенно может накопиться, условно, 200 тестов. Перед деплоем они запускаются, и вы намного спокойнее добавляете новые функции: если сломалось что-то старое, тесты должны это показать.

В моём историческом подходе к WordPress такого процесса почти не было.

У WordPress есть одновременно достоинство и своеобразное «проклятие»: он создавался так, чтобы им могли пользоваться люди без навыков программирования. В нём много UI и UX, многое делается кнопками. Благодаря этому в экосистему пришло огромное количество людей, далёких от разработки.

Но отсюда же появляются темы и плагины очень разного качества. В одном месте смешиваются PHP, JavaScript, HTML и CSS, а единый инженерный стандарт выдерживается далеко не всегда. То, как современные агенты работают со структурированным Laravel-проектом, мне сейчас нравится больше.

Александр: Но представим практическую ситуацию. Вы сделали человеку при помощи ИИ интернет-магазин. Что клиент будет делать дальше? Как передавать такой проект, если нет привычной документации и разработчик уже ушёл?

Александр Сокирка: Здесь мы, возможно, смотрим на будущее глазами прошлого.

Мы привыкли считать, что работающему сайту обязательно нужен человек: администратор, разработчик или сам клиент, который умеет что-то исправлять. Я допускаю другую модель: дальше с этим сайтом тоже будет работать нейросеть.

Прослойка разработчиков не обязательно исчезнет, но изменятся задачи. Самому клиенту не потребуется разбираться в каждом техническом действии. Вместо поиска разработчика он сможет обратиться к агенту.

Я вполне представляю, что внутри WordPress появится полноценное окно, куда владелец сайта пишет: «Перекрасьте эту кнопку», «Добавьте такие поля», «Сделайте фильтрацию», — а система выполняет изменение.

Код нейросетей всё ещё нужно проверять, и качество сильно зависит от модели и контекста. Но мы уже ушли от времени, когда любой сгенерированный код автоматически считался бесполезным или небезопасным.

Главный вопрос в другом: откуда обычный клиент узнает, какой промпт правильный?

Александр: Именно. Многие пользователи не хотят разбираться даже с VPN или сертификатом HTTPS. Почему они внезапно станут экспертами по промптам?

Александр Сокирка: А им и не обязательно становиться такими экспертами.

Сейчас в агентной разработке популярны большие файлы инструкций: agents.md, другие файлы с контекстом, правилами проекта, требованиями к архитектуре. Почему WordPress не может подготовить этот технический контекст за пользователя?

Представьте: человек пишет в админке одно обычное предложение. Если запрос простой — например, перекрасить кнопку, — агент решит его практически напрямую.

Если запрос сложнее — добавить метаполя, создать несколько таксономий, построить фильтрацию, — WordPress может автоматически приложить к пользовательской фразе контекст текущего проекта, собственную документацию и технические правила: как работать с экранированием данных, как соблюдать архитектуру, какие решения считать безопасными, чего не делать.

То есть человек вводит простую человеческую фразу, а модель фактически получает профессиональный запрос, как будто его подготовил разработчик, хорошо знающий WordPress.

Это, конечно, гипотеза. Я очень часто меняю своё мнение, когда получаю новые данные. Рынок в любом случае сам покажет, какая модель победит.

Александр: Не напоминает ли это предыдущую волну с конструкторами? Когда появилась Tilda и другие платформы, тоже говорили, что больше никому не понадобятся разработчики и CMS. Но WordPress остался.

Александр Сокирка: Я бы вообще не ставил вайб-кодинг в один ряд с CMS или конструкторами.

Вайб-кодинг — не отдельная платформа, которая обязательно конкурирует с WordPress. С помощью агента можно писать самописный PHP, Laravel, Symfony, WordPress-плагин или WordPress-тему. Можно работать практически с любой открытой системой.

Поэтому корректнее сравнивать между собой WordPress, Joomla, Drupal, Shopify, Magento, Bitrix и похожие платформы. В определённых задачах можно добавить к сравнению фреймворки, хотя CMS и фреймворк всё-таки решают разные классы задач.

А ИИ находится над этим уровнем. Он может работать с каждой из систем.

Я видел даже специализированные решения, которые генерируют блочную WordPress-тему по запросу. В другом проекте агент может написать плагин. В третьем — собрать приложение на Laravel.

То есть нейросеть не обязательно «заберёт долю WordPress». Скорее она изменит роль программиста. Мы уже постепенно перешли от ручного написания каждой строки к постановке задач. А иногда даже текст запроса не печатаем — просто проговариваем задачу голосом.

Александр: Вы часто упоминаете Laravel. Получается, сейчас вы выбрали его вместо WordPress?

Александр Сокирка: Нет. Я не выбрал Laravel вместо WordPress.

Я использую Laravel там, где целесообразен Laravel, и WordPress там, где нужен WordPress.

Если клиент скажет: «Мне нужен сайт на WordPress», — я не буду его переубеждать ради принципа. Если человек просто опишет задачу, тогда уже подберу систему исходя из опыта.

В последнее время я часто говорю про Laravel только потому, что делал несколько проектов, которые не были обычными сайтами.

Например, создавал мобильное приложение — детский обучающий фитнес-трекер. Для бэкенда там использовал Laravel. Ставить WordPress просто потому, что я его хорошо знаю, было бы странно.

Другой пример — мой интерес к фондовому рынку. Я использовал Notion для идей и журнала, Google Sheets — для сделок и статистики, плюс отдельно брокерский аккаунт. Получалось несколько сервисов.

Я решил объединить всё в одну собственную систему. Поскольку к тому моменту уже поработал с Laravel и вайб-кодингом, за несколько дней собрал сервис с привычными мне функциями, но с хранением данных у себя.

WordPress в такой задаче можно было бы использовать, но зачем прикручивать его только из-за собственной привычки?

Раньше у меня действительно была обратная предвзятость. Приходил клиент — и я старался привести проект к WordPress, потому что эту CMS знал лучше всего и мог быстро получить результат.

Сегодня для маленького MVP мне в некоторых случаях проще дать задачу агенту и собрать решение на Laravel, чем проходить привычный путь установки и настройки WordPress.

Поэтому главный принцип для меня сейчас очень простой: под конкретную задачу — конкретная система.

Коротко:

• ИИ и WordPress необязательно конкуренты: агент может стать новым способом разработки и управления самим WordPress, а не заменой CMS.
• Выбор между WordPress, Laravel и другими технологиями разумнее начинать не с любимого инструмента разработчика, а с характера продукта, его данных, нагрузки и дальнейшей поддержки.

От автодополнения к агентам: как вайб-кодинг вошёл в рабочий процесс

Александр: Расскажите подробнее про вайб-кодинг. Cursor, Claude Code, Copilot, Codex — что вы пробовали и как изменилось ваше отношение к таким инструментам?

Александр Сокирка: Активно использовать вайб-кодинг я начал сравнительно недавно. До этого долго сопротивлялся — примерно так же, как многие люди в комментариях под моими видео. Логика была понятной: нейронки небезопасны, пишут плохой код, полагаться на них нельзя.

Потом решил специально делать проекты ради эксперимента: брать разные модели, давать им реальные задачи и смотреть, что получится.

Начинал с GitHub Copilot. Автодополнение действительно ускоряло работу — условно процентов на 60, но код всё равно в основном писал я. Это ещё нельзя было назвать полноценным вайб-кодингом. Скорее автоматизация старого подхода: вы начинаете писать код, система предлагает большой блок продолжения, вы проверяете и принимаете.

Потом попробовал другой режим: вообще не писать реализацию руками, а формулировать задачу и работать скорее редактором результата.

Через Copilot использовал разные модели, в том числе Claude. Тогда очень быстро столкнулся с экономикой токенов. Иногда вы просите исправить один Tailwind-класс, а дорогая модель расходует почти столько же условных лимитов, сколько на значительно более крупную операцию.

После этого я стал разделять задачи. Если нужно поменять очевидный класс Tailwind — быстрее сделать руками. Для простых задач можно взять более дешёвую модель. Для комплексных — более сильную.

Когда лимиты Copilot закончились, я оформил подписку OpenAI и установил Codex в Visual Studio Code. После этого моё мнение о вайб-кодинге стало меняться ещё быстрее. Качество растёт очень заметно.

Но результат по-прежнему зависит от того, какие инструкции вы дали, как организовали проект и какой контекст передали агенту.

Для PHP и Laravel мне также понравился Qwen. В какой-то момент я много работал с ним и получил очень хорошие результаты.

Вообще я не стесняюсь спрашивать модель: «Как это сделать лучше?», «Как бы вы построили это решение?», «Что предложил бы более опытный разработчик?»

Не стоит считать собственный старый подход автоматически самым правильным. С моделью полезно вести технический диалог. Очень быстро становится видно, насколько хорошо она понимает задачу.

Если уже на простом запросе ответ плавает и явно не соответствует ожидаемому результату, для серьёзного проекта я бы такой модели не доверял.

Александр: Сейчас конкуренция между моделями огромная. Вы считаете, что хорошие лимиты и относительно дешёвые подписки сохранятся?

Александр Сокирка: У меня есть сомнения.

Современная модель фактически предоставляет вам огромный объём вычислений. То, на что раньше разработчик мог потратить месяц, в отдельных сценариях теперь действительно удаётся заметно ускорить.

Поэтому я скептически отношусь к идее, что доступ к самым мощным агентам всегда будет стоить условные 10–20 долларов без серьёзных ограничений.

Есть стоимость дата-центров, электричества, чипов, инфраструктуры. Да, технологии оптимизируются, и вычисления будут дешеветь. Но параллельно мы всё больше привыкаем к тому, что можем описать задачу текстом и получить огромный объём работы.

Я бы не удивился, если со временем самые сильные режимы станут ощутимо дороже либо будут гораздо жёстче ограничиваться по лимитам.

У меня был похожий опыт с Qwen: сначала определённые возможности были очень доступными, затем условия изменились. Это нормальная логика для сервиса, который несёт огромные расходы на вычисления.

Александр: Вы пробовали запускать модели локально?

Александр Сокирка: Да. Ставил локальные варианты Qwen, Gemma и другие модели, которые можно было запустить на собственном компьютере.

И у меня результат оказался совсем не таким приятным, как в облаке.

Компьютер достаточно мощный, с 64 гигабайтами оперативной памяти. Когда-то я даже использовал его как домашний сервер. Модели на нём запускались, но скорость меня не устраивала.

Простой запрос через облачный сервис мог возвращаться почти сразу, а локально приходилось ждать значительно дольше. Возможно, у меня была неидеальная конфигурация и специалист по локальному inference смог бы всё настроить лучше. Я говорю только о своём опыте.

При этом процессор и память работали почти под полной нагрузкой. За время экспериментов я даже заметил ощутимый рост расходов на электричество.

После такого эксперимента иначе воспринимаешь цену облачных нейросетей. Когда вы платите сравнительно небольшую подписку и мгновенно получаете ответ от модели, где-то за этим стоят дата-центры, оборудование и огромный расход энергии.

Александр: Тогда идея «держать собственную нейросеть дома и ни от кого не зависеть» для обычного разработчика не очень реалистична?

Александр Сокирка: Она рабочая, но не уверен, что экономически разумна именно для обычного пользователя.

Если у вас большой капитал, вы строите вычислительный центр и получаете эффект масштаба — это другая история. Я вообще думаю, что вычислительные мощности будут становиться всё более важным ресурсом.

Но дома вы покупаете дорогое железо, память, видеокарты, платите за электроэнергию, занимаетесь настройкой — и при этом часто получаете результат хуже удобного облачного сервиса.

Как хобби, исследовательская задача или сценарий, где принципиальна локальная обработка данных, это имеет смысл. Как универсальная замена облаку для каждого разработчика — по моему опыту пока нет.

Я допускаю, что производители будут активно продавать компактные «ИИ-компьютеры» и обещать почти дата-центр на столе. Но к таким обещаниям я бы относился спокойно: всегда нужно смотреть на реальную производительность и стоимость владения.

Коротко:

• Вайб-кодинг для опытного разработчика — это не «перестать писать код», а перейти в роль постановщика задачи, редактора и контролёра результата.
• Цена ИИ — это не только стоимость подписки: за быстрым ответом стоят дорогие вычисления, поэтому локальные модели и облачные сервисы нужно сравнивать по реальной экономике, а не только по тарифу.

Вайб-кодер без базы: почему Git, diff и Computer Science всё ещё нужны

Александр: Если новое поколение действительно сразу пойдёт в ИИ, что будет с фундаментальными знаниями? Можно ли добиться серьёзного результата, вообще не изучая программирование?

Александр Сокирка: Вот здесь у меня позиция уже жёстче. Человек действительно может начать с нейросети, но если он хочет стать профессионалом, без базы будет очень тяжело.

Разработчик с опытом понимает, что такое CI/CD, GitHub Actions, секреты, SSH-ключи, деплой, сервер, база данных. Он понимает, что происходит за интерфейсом агента.

Имея эти знания, вы намного грамотнее работаете с вайб-кодингом.

А человек, который пришёл полностью с нуля и знает только поле для промпта, первые годы будет набивать шишки. Он действительно сможет генерировать проекты, и часть из них внешне будет работать, но внутри могут быть серьёзные проблемы — в безопасности, архитектуре, данных, поддерживаемости.

Поэтому тому, кто хочет быть профессионалом, всё равно нужен технический фундамент.

Университет здесь интересен не только тем, что на первом курсе вам показывают C++ или C#. В учебной программе есть математика, механика, алгебра и другие предметы, которые напрямую могут не понадобиться при разработке сайта, но формируют структуру мышления.

То же самое с ИИ: начинать только с коллекции «идеальных промптов» я бы не советовал. Лучше понимать, что вы вообще просите модель сделать.

Александр: Тогда какой практический минимум вы дали бы молодому разработчику, который говорит: «Ваш PHP и CSS мне уже не нужны, я всё соберу через агента»?

Александр Сокирка: Первая рекомендация — работать там, где вы видите исходный код.

Мне ближе Visual Studio Code с агентом через расширение или CLI. Есть другой класс сервисов: вы вводите запрос, что-то происходит «под капотом», а затем вам показывают готовый продукт, почти не демонстрируя исходники.

Для разработки я такой подход не люблю. Вы теряете контроль.

Создали пустую папку — первым делом инициализируйте Git-репозиторий. Ещё лучше сразу создайте репозиторий на GitHub и свяжите его с локальным.

После этого открывайте агента и просите его работать.

Но ваша главная вкладка в этот момент — не только чат. Смотрите изменения в Git: какой файл создан, какой изменён, какие строки добавлены, какие удалены. Используйте diff.

Нейросеть регулярно пишет вещи, которые нужно исправлять. Даже не будучи суперэкспертом, иногда легко заметить: вы попросили изменить кнопку на одной странице, а агент полез редактировать совершенно другой файл.

Поэтому Git плюс доступ к исходному коду для меня обязательны.

Что касается обучения, я действительно считаю, что подход должен немного измениться.

Смотреть пятичасовой туториал «как полностью сделать регистрацию на сайте» и механически повторять каждый шаг сегодня, возможно, уже не так полезно.

Но изучить синтаксис PHP — полезно. Понять HTML, CSS, JavaScript, базы данных — обязательно. Если используете Tailwind CSS, надо понимать, что делают его классы. Если работаете с React — нужно знать базовые принципы.

Допустим, вы хотите немного сдвинуть кнопку. Можно полминуты объяснять агенту, что именно не нравится, тратить токены, потом получить не тот результат и объяснять ещё раз.

А можно открыть файл, изменить один понятный класс и продолжить работу.

Базовые знания в таких мелочах одновременно экономят время, токены и количество ошибок.

Вторая рекомендация — коммит после законченной итерации.

Представьте старую видеоигру. Перед сложной миссией вы обязательно сохранялись. Git здесь работает примерно так же.

Попросили агента сделать функцию. Получили результат. Проверили. Всё устраивает — commit и push.

Только после этого давайте следующую задачу.

У меня неоднократно было: сделал первую функцию, не сохранил состояние, попросил агента решить следующую задачу, а он испортил и новую, и предыдущую. После этого приходится либо откатываться, либо полчаса объяснять, что именно нужно восстановить.

Третья рекомендация — не засорять контекст.

Если одна задача закончена, а следующая никак с ней не связана, я предпочитаю открыть новый чат. Старый контекст может не помогать, а, наоборот, сбивать модель.

И ещё я практически всегда рекомендую иметь в корне проекта agents.md с правилами работы.

Необязательно писать его вручную. Раньше я именно так и делал: описывал стек, технические требования, структуру проекта. Потом попробовал попросить самого агента просканировать репозиторий и подготовить файл инструкций.

И, честно говоря, результат часто оказался лучше того, что я написал бы самостоятельно.

При этом я стараюсь не привязывать весь workflow к одной конкретной нейросети. Сегодня используете Claude, закончились лимиты — хотите переключиться на Codex, Gemini или Qwen. Чем универсальнее описаны правила проекта, тем меньше стоимость такого переключения.

Александр: Но даже хороший файл с инструкциями не гарантирует одинакового результата?

Александр Сокирка: Конечно.

У меня был сценарий, где одну и ту же задачу нужно было повторять с разными массивами данных. Один промпт отработал хорошо первый раз, второй, третий. И вы уже начинаете думать: всё, я нашёл паттерн.

На условной седьмой итерации результат внезапно другой. Часть инструкций модель проигнорировала.

Почему именно — пользователь не всегда может узнать. Возможно, повлиял контекст, возможно, стохастичность самой модели, возможно, нагрузка и внутренняя инфраструктура сервиса. Но практический вывод один: одинаковый промпт не гарантирует побитово одинаковое и всегда правильное поведение.

Поэтому Git, diff и человеческое ревью никуда не исчезают.

Александр: Используете ли вы нейросети вне непосредственной разработки?

Александр Сокирка: Использую, хотя иногда ловлю себя на забавной вещи: начинаю придумывать применение только потому, что уже заплатил за подписку и жалко не использовать лимит.

Например, я сделал себе собственный сервис для работы с инвестиционными данными — объединил вещи, которые раньше держал в нескольких инструментах.

Однажды перед записью видео подумал: хорошо бы иметь кнопку, которая скрывает или размывает общий размер портфеля. Вдруг я когда-нибудь покажу этот сервис на YouTube.

Функция совершенно необязательная. Не факт, что это видео вообще появится. Но токены есть, идея возникла — открыл Visual Studio Code, описал задачу, проверил, задеплоил.

И здесь есть интересная сторона нынешнего ИИ-бума: нас очень активно подталкивают что-то создавать. Сервисы предлагают сделать приложение, интерфейс, дизайн, новый продукт.

Технический барьер резко снизился. Но из этого не следует, что миру автоматически нужны все эти продукты.

Я, например, сделал мобильное приложение практически целиком через вайб-кодинг. Люди зашли, посмотрели, сказали, что интересно. Но это ещё не означает, что появился настоящий рынок.

Если тысячи разработчиков начнут генерировать приложения просто потому, что теперь это легко, магазины приложений могут получить огромное количество продуктов, которыми почти никто не пользуется.

Поэтому скорость разработки сама по себе ещё не создаёт ценность.

Александр: Есть и другой вопрос: мы бесплатно или дёшево пользуемся новыми моделями, даём им код, подтверждаем или отклоняем предложения. Не становимся ли мы заодно тестировщиками и источником данных для этих систем?

Александр Сокирка: Я об этом думал ещё во времена раннего GitHub Copilot.

Когда работает автодополнение, вы начинаете писать код, система предлагает продолжение, а вы принимаете или отклоняете вариант. Интуитивно возникает ощущение, что такая обратная связь чрезвычайно ценна для разработчика модели.

У меня был период, когда я даже специально отключил автодополнение, потому что не хотел участвовать в этом процессе. Потом понял, что проблема значительно шире: код проекта всё равно может храниться на GitHub, мы пользуемся облачными инструментами, передаём данные множеству сервисов.

Поэтому сегодня я смотрю на вопрос не с позиции «никогда ничего не использовать», а с позиции контроля.

Особенно внимательно отношусь к агентам, которым вы даёте доступ к локальному компьютеру. Не стоит ставить первый попавшийся репозиторий только потому, что он обещает удобную ИИ-функцию.

Агент потенциально получает доступ к файлам, терминалу и другим ресурсам системы. Нужно понимать, что именно устанавливаете и какие разрешения выдаёте.

Приватность тоже остаётся важной. В какой-то период я сознательно старался пользоваться меньшим числом провайдеров, рассуждая так: если Google и так является частью моей повседневной инфраструктуры — браузер, почта и другие сервисы, — возможно, лучше не разбрасывать данные ещё по десятку компаний.

Это не универсальный рецепт, но принцип простой: удобство агента не отменяет ответственность за то, куда вы отдаёте код и данные.

Коротко:

• Если агент пишет большую часть кода, фундаментальные знания становятся не менее, а местами более важными: без них разработчик не понимает, когда модель уверенно делает неправильную вещь.
• Минимальная страховка при вайб-кодинге — исходники перед глазами, Git, частые коммиты, просмотр diff, ограниченный контекст и понятные инструкции проекта.

Фриланс постоянно умирает — но умирает его форма

Александр: После всей этой истории с автоматизацией возникает очевидный вопрос: фриланс вообще жив?

Александр Сокирка: Для меня это сложный вопрос, потому что почти вся моя профессиональная жизнь связана именно с фрилансом — больше 18 лет.

Были периоды работы в компаниях, но сравнительно короткие. В основном я работал самостоятельно или с иностранными клиентами через собственное юридическое лицо. Формально это можно назвать аутсорсом, но по ощущениям для меня это всё равно было продолжением фриланса.

За это время я прошёл три разные модели.

Первая — классический фриланс. Есть биржа, клиент публикует заявку, вы откликаетесь, предлагаете услугу, вас выбирают.

Лет 15–18 назад эта схема прекрасно работала. Клиентов было много, исполнителей — меньше. Бизнесу нужны были сайты и приложения.

Потом количество разработчиков резко выросло. Особенно много обучающих материалов появилось вокруг PHP и WordPress. В профессию пришло больше людей, конкуренция на русскоязычных и зарубежных биржах стала значительно выше.

На зарубежном рынке добавлялся ценовой демпинг. В какой-то момент я понял, что больше не хочу всю жизнь продавать часы.

Если ваш час стоит 30 долларов, есть естественный потолок: невозможно масштабировать собственное время бесконечно.

А продукт работает иначе. Вы один раз что-то сделали и можете продать тот же результат десяти, ста или тысяче людей.

Так я пришёл ко второй модели — тому, что сам называю пассивным фрилансом.

В мобильной разработке похожего человека могли бы назвать solo developer, в играх — indie-разработчиком. В моём случае это были темы и другие продукты для WordPress.

Вы создаёте тему, публикуете на маркетплейсе, и продажи могут происходить без вашего личного участия — ночью, днём, пока вы занимаетесь другим. Конечно, остаётся поддержка, вопросы пользователей, багфиксы, обновления.

Но вы уже продаёте не каждый свой час отдельно.

Для меня это оказалось очень важным переходом.

Ещё школьником на классическом фрилансе я накопил около 10 тысяч долларов и смог купить автомобиль. Для тогдашнего меня это были огромные деньги.

Но основная часть капитала позднее пришла именно из продуктовой модели и продажи тем.

Первый шаблон на маркетплейсе каким-то образом очень хорошо стартовал: в первую неделю принёс примерно 6000 долларов, хотя аналогичный сайт для одного клиента я мог тогда сделать за 300.

За всё время этот шаблон, насколько помню, принёс около 20 тысяч долларов.

После такого психологически очень трудно вернуться к модели, где вы снова продаёте похожую работу одному клиенту за 300.

Но здесь важно не рисовать сказку про пассивный доход.

Следующие продукты могли зарабатывать гораздо меньше. Один приносит несколько тысяч долларов, другой — несколько сотен. Вы можете потратить месяцы на разработку и почти ничего не получить.

Никакой гарантии нет.

Плюс со временем конкуренция выросла уже и на маркетплейсах. Крупные темы с огромной пользовательской базой, бюджетами и рекламой получают ещё больше внимания. Небольшому автору сложнее занять место рядом с ними.

Поэтому примерно семь лет назад я постепенно ушёл и от этой модели.

Третий этап — прямые клиенты и студии через LinkedIn.

Я в основном работал с американскими компаниями. Условно студия платит мне почасовую ставку и гарантирует full-time-загрузку. Если у неё самой в конкретный момент нет подходящего проекта, она может подключить меня к проекту партнёрской студии.

Для меня это было намного спокойнее классической биржи. Есть предсказуемая загрузка, нет постоянного страха «будет ли завтра заказ», меньше случайных клиентов.

Причём оплачивается не только момент, когда вы нажимаете клавиши. Можно обсуждать архитектуру, созваниваться, анализировать проект — это тоже работа.

Но потом я начал замечать, что проектов именно под PHP и WordPress становится меньше. Сначала их стало меньше у основного клиента, затем — у партнёрских студий. В конце концов мы прекратили сотрудничество, потому что компания уже не могла обеспечить постоянную загрузку.

Поэтому и третий мой вариант фриланса в какой-то момент закончился.

Но отсюда я не делаю вывод, что фриланс как явление умер.

Мне нравится другая формулировка: фриланс постоянно умирает, потому что постоянно умирает его очередная форма.

Когда-то всем нужны были сайты на биржах. Потом можно было хорошо продавать темы. Потом работали другие каналы. Завтра людям будут нужны совсем другие продукты.

Клиенты адаптируются — и исполнителю тоже приходится адаптироваться.

Александр: При этом вы отдельно говорите об опасности зависимости от платформ.

Александр Сокирка: Да, это очень важная причина, почему сегодня мне психологически не нравится строить всю карьеру вокруг одной площадки.

Представьте: несколько лет прокачиваете профиль, собираете отзывы, рейтинг, портфолио. Для клиента этот профиль и есть доказательство вашей репутации.

Потом площадка вас блокирует.

Причина может быть ошибочной, а может быть совершенно справедливой — в моём случае нарушение действительно было. Но для вашей экономики результат один: актив, который вы создавали годы, внезапно перестаёт работать.

Я даже экспериментировал с Upwork ради обучающего видео. У меня к тому моменту был огромный опыт и портфолио. На ThemeForest за первые годы мы сделали порядка 50 тем, общие продажи были очень существенными. Казалось бы, этот опыт должен говорить сам за себя.

Но на новой бирже без рейтинга и отзывов всё это не обязательно помогает получить первый заказ.

Платформа хочет собственную историю внутри своей системы.

Александр: А за что именно вас когда-то заблокировали на маркетплейсе?

Александр Сокирка: Нарушение было реальным, я этого никогда не скрывал.

Для нового продукта рейтинг очень важен. Если тема только появилась и уже имеет несколько пятизвёздочных отзывов, новый покупатель воспринимает её спокойнее, а алгоритмы площадки могут дать ей больше внимания.

Я решил проверить очень плохую идею: купил собственную тему через несколько аккаунтов и поставил себе высокие оценки.

Причём сделал это максимально прямолинейно, даже платежи были связаны со мной. Никакой сложной схемы.

Через некоторое время площадка обнаружила нарушение и заморозила профиль примерно на полгода. На счёте находилась заметная сумма, продажи остановились, продукты исчезли из выдачи.

И самое неприятное произошло даже не в момент блокировки.

Через полгода аккаунт вернули, темы снова стали доступны, но их прежние позиции уже не восстановились. Ссылки и SEO, которые я строил вокруг страниц продуктов, за время отсутствия потеряли эффект. Профиль фактически вернулся на рынок уже другим.

Это был сильный удар.

Поэтому Envato дважды очень серьёзно повлиял на мою жизнь: сначала продуктовая модель позволила хорошо заработать, а потом зависимость от одной площадки показала, насколько быстро этот источник можно потерять.

После этого я стал гораздо больше думать о том, как строить работу в обход единственной платформы.

Александр: Тогда чем вы зарабатываете сейчас? Курсы, насколько я понял, не стали основным бизнесом, а активной клиентской разработкой вы занимаетесь меньше.

Александр Сокирка: Последние годы основным источником денег была работа с клиентами через LinkedIn и собственную компанию.

Но уже довольно продолжительное время я практически не зарабатываю непосредственно на разработке.

YouTube тоже нельзя назвать серьёзным источником дохода. Канал нишевый — веб-разработка, WordPress. Просмотров немного, аудитория специфическая, рекламодателям это не всегда интересно.

Была идея построить полноценную школу веб-разработки — Genius.Courses. Я запустил её как раз после истории с блокировкой маркетплейса: хотелось иметь свой сайт и свою платформу, которую никто внезапно не выключит.

Проводил обучение, собирал группы. Но там быстро появляется потолок.

Если вы хотите качественно работать с учениками, нельзя бесконечно увеличивать группу. Допустим, 15–20 человек. Если курс стоит сравнительно недорого, а на его подготовку, запись, проверку и работу с группой уходят месяцы, экономика легко оказывается хуже обычного фриланса.

В итоге школа для меня превратилась скорее в платформу, где я делюсь знаниями и демонстрирую экспертизу. Большая часть материалов стала бесплатной, а многое из того, что раньше было платным, можно найти на сайте и YouTube.

То есть контента я сделал значительно больше, чем получил прямого финансового результата.

Александр: Но на что тогда живёте?

Александр Сокирка: Меня выручило то, что я достаточно разумно распорядился деньгами, заработанными раньше.

Покупал недвижимость, инвестировал в офис, который можно сдавать, построил дом. Благодаря этому есть пассивный доход и нет необходимости соглашаться на любой проект только потому, что срочно нужны деньги.

Для меня это особенно важно на нынешнем фрилансе, где очень жёсткая ценовая конкуренция.

Я не считаю, что сложная работа за компьютером должна автоматически стоить дёшево только потому, что со стороны она выглядит комфортной.

Про разработчиков любят показывать красивую картинку: человек проснулся, сделал кофе, сел в красивой комнате за ноутбук и спокойно работает из любой точки мира.

Реальность часто другая.

Мозг продолжает решать задачу после того, как вы закрыли ноутбук. Ночью вы можете лежать и думать, почему что-то не работает. Плюс постоянный стресс от клиентов, дедлайнов и следующего заказа.

Я несколько раз переживал сильное выгорание.

Когда делал свою первую успешную тему для маркетплейса, днём работал в компании над WordPress-сайтами, вечером возвращался домой, немного отдыхал, а примерно с девяти вечера до трёх ночи продолжал делать собственный шаблон.

Так продолжалось около двух месяцев.

Потом человек видит цифру продаж и думает: «Повезло, сделал один сайт и заработал». Но за ней не видно этих ночей.

Александр: Здесь я всё же поспорю. У меня был опыт тяжёлого физического труда — дороги, асфальт, стройка. Когда после этого впервые пришёл в офис делать сайты, ощущение «я сижу в тепле за компьютером» было невероятным. Не романтизируем ли мы сложность интеллектуальной работы?

Александр Сокирка: Думаю, это ещё раз доказывает поговорку «хорошо там, где нас нет».

Я люблю что-то физически делать дома: могу заняться забором, бетоном, участком. После офисной работы мне иногда кажется, что физический труд проще: вы устали телом, отдохнули — и восстановились.

Но вы правы: одно дело строить забор у себя дома, когда захотелось, и совсем другое — каждый день делать тяжёлую физическую работу по графику.

Так же и с компьютером.

Нельзя сравнивать приятный личный проект с многолетним фрилансом под дедлайнами.

У каждого труда есть своя цена.

Поэтому мой настоящий совет начинающим не «фриланс хуже стройки» и не наоборот. Он гораздо скучнее: научитесь соблюдать баланс раньше, чем организм заставит вас это сделать.

И ещё важно не верить в рекламную картинку фриланса. Кто-то получит хороший первый проект, быстро соберёт портфолио и будет получать удовольствие. Другой месяцами не сможет найти заказ.

Это две совершенно реальные, но очень разные истории.

Коротко:

• «Фриланс умер» почти всегда означает, что умер конкретный способ находить клиентов или продавать работу. Биржи, маркетплейсы и LinkedIn могут переживать разные циклы, но сама модель независимой работы остаётся.
• Профиль на платформе — полезный актив, но опасно превращать его в единственный актив. Собственные навыки, репутация вне площадки, прямые контакты и финансовая подушка дают намного больше устойчивости.

Что учить новичку: WordPress или фундамент, который переживёт WordPress

Александр: Представим человека 23–24 лет. У него есть семья, он знает HTML, CSS и немного JavaScript, возможно, уже сталкивался с WordPress. Что бы вы посоветовали сейчас: глубоко изучать WordPress, идти на биржи, искать найм через LinkedIn, делать собственные продукты?

Александр Сокирка: Я бы не говорил: «Идите и обязательно учите именно WordPress».

Я бы сказал: учите базу.

PHP, JavaScript, возможно, популярные библиотеки и фреймворки. Понимайте, как устроен веб, как работают сервер, база данных, браузер, API.

Не нужно первым делом погружаться во все внутренние детали WordPress Codex.

Если появится заказ на WordPress, имея хороший фундамент, вы сможете довольно быстро разобраться в конкретной CMS при помощи документации, видео и нейросетей.

Это не сделает вас экспертом за два дня. Экспертность всё равно появляется после многих лет и проектов. Но начать работать станет намного проще.

Если говорить о классическом вебе, мне до сих пор нравится связка PHP плюс JavaScript. Я считаю, что PHP далеко не умер. Но если молодому человеку ближе другой стек — прекрасно. Изучайте то, что вам интересно.

По биржам мне сложнее давать категоричный совет, потому что я давно не живу классическим Upwork каждый день. А я стараюсь уверенно советовать только то, где есть свежий личный опыт.

Но зарегистрироваться на бирже полезно хотя бы как исследователю рынка.

Смотрите заявки. Что заказывают сегодня? Сайты? Мобильные приложения? Автоматизацию? Какие технологии повторяются?

Биржа становится источником данных.

Если площадка даёт бесплатные кредиты на отклики — используйте. Можно потратить небольшую сумму на дополнительные отклики. Повезёт — получите проект.

Но строить всю карьеру вокруг одной биржи я бы сегодня точно не стал.

Александр: А собственные продукты? Сейчас ведь через ИИ стало невероятно просто делать приложения и сервисы.

Александр Сокирка: Именно поэтому там тоже растёт конкуренция.

Ещё недавно я сам думал: буду заниматься solo-разработкой, создавать небольшие игры, приложения для Android и iOS, веб-сервисы.

Сделал мобильное приложение почти полностью с помощью вайб-кодинга и увидел вторую сторону.

Технически продукт создать действительно стало намного проще.

Но кто будет им пользоваться?

Если раньше сложность разработки ограничивала количество приложений, сейчас этот фильтр становится слабее. Тысячи людей смогут делать по десять, сто, тысячу продуктов.

Но внимание пользователей не увеличивается в тысячу раз.

У меня на телефоне, например, количество регулярно используемых приложений со временем скорее уменьшается. Думаю, я не уникален.

Поэтому современная проблема переносится с уровня «можете ли вы сделать?» на уровень «зачем это кому-то нужно?»

ИИ радикально удешевляет производство, но не создаёт спрос автоматически.

То же самое касается информационных сайтов и SEO. Я ожидаю, что часть поиска информации будет всё сильнее забираться ассистентами и агрегаторами. Человеку не всегда понадобится переходить по десяти сайтам, если ответ уже собран в одном интерфейсе.

Для человека, который десятилетиями работает с SEO и знает рынок изнутри, там ещё может быть отличный бизнес. Но новичку я бы не продавал старую схему как гарантированный способ заработка.

Александр: Можно посмотреть на это и позитивнее. Когда появились станки, электричество, автомобили и экскаваторы, люди не исчезли — выросла производительность и появились новые профессии. Почему с ИИ обязательно должно быть иначе?

Александр Сокирка: Производительность точно вырастет — с этим я согласен.

Один человек уже сегодня может сделать намного больше.

Раньше разработчику требовалась команда или месяцы времени. Сейчас часть работы берут агенты. Это означает больше продуктов, больше автоматизации, больше возможностей.

Моё беспокойство только в одном отличии.

Прежние инструменты усиливали человеческие руки, но решение всё равно оставалось за человеком. Станок делает работу быстрее, но кто-то им управляет.

Современный ИИ постепенно начинает не только исполнять команды, но и выбирать промежуточные действия.

Когда я смотрю лог хорошего coding-agent, он может сам разбить задачу, вызвать другой инструмент или более дешёвую модель, поручить ей часть работы и затем использовать результат.

Например, нужно перевести большой массив данных. Основной агент понимает, что задача однообразная, делегирует её другой модели — а вы видите этот процесс в логе.

Формально это, конечно, не человеческий мозг. Это LLM и программная агентная система. Я использую слово «мозг» образно.

Но с пользовательской точки зрения впечатляет уже не только скорость генерации текста, а способность системы выбирать следующий шаг.

Александр: Зато это резко увеличивает производительность одного специалиста. Получается, разработчик знает PHP, умеет работать с Codex или Claude — и может вести намного больше задач.

Александр Сокирка: Да, и это очень сильная сторона.

Если раньше пятнадцать человек делали определённый объём работы, а благодаря новым инструментам его выполняет один специалист, производительность растёт.

Вопрос лишь в том, что произойдёт дальше с остальными четырнадцатью.

Возможно, общество создаст для них новые виды деятельности, как это много раз происходило в истории. Возможно, изменится рабочая неделя, появятся другие экономические механизмы.

Я не знаю.

Мне не хочется изображать человека, который умеет предсказывать будущее. Я скорее вижу огромное изменение и пытаюсь понять его направление.

При этом моя практическая позиция намного проще этих философских разговоров: если ИИ уже даёт вам преимущество в работе, игнорировать его бессмысленно. Но одновременно отказываться от понимания профессии тоже опасно.

Александр: Вы приводили пример переводов в приложении, где ИИ не просто перевёл текст, а учёл структуру предложения.

Александр Сокирка: Да. Для меня это был один из моментов, когда особенно хорошо чувствуется разница между старой автоматизацией и современной моделью.

Я переводил приложение на несколько языков.

Раньше, когда делал темы для маркетплейса, локализацию приходилось во многом готовить вручную: копировать строки, прогонять через переводчик, проверять.

В приложении были квизы. В предложении специально пропущено слово, а ниже даны варианты ответа.

При буквальном переводе можно оставить пропуск в той же позиции — и получить неестественную фразу, потому что в другом языке порядок слов другой.

ИИ без отдельной инструкции переставлял этот пропуск так, чтобы конструкция выглядела естественнее для конкретного языка.

Конечно, любой перевод всё равно стоит проверять носителем или специалистом, если от него зависит серьёзный продукт. Но как инструмент ускорения это очень впечатляет.

Коротко:

• Новичку полезнее инвестировать время в PHP, JavaScript, базы данных, Git, устройство веба и работу с ИИ, чем строить всю идентичность вокруг одной CMS.
• Когда производство кода дешевеет, главным дефицитом становится не способность «сделать ещё одно приложение», а хорошая задача, понимание пользователя и умение превратить техническую возможность в востребованный продукт.

WordPress изнутри: какие плагины нужны разработчику и почему «премиум-тема» ничего не гарантирует

Александр: Вернёмся непосредственно к WordPress. Какие плагины вы устанавливаете почти в каждый проект?

Александр Сокирка: Здесь я сразу сделаю оговорку: я отношусь скорее к разработчикам, которые часто пишут собственные решения.

Человек, который каждую неделю собирает новый сайт из готовых плагинов, вероятно, даст более актуальный список. Экосистема постоянно меняется, выходят новые решения.

У меня исторически есть несколько типов плагинов, которые почти всегда присутствуют в стартовой сборке.

Первый — SEO.

Второй — безопасность.

Третий — технический мониторинг, чтобы сразу после запуска посмотреть запросы и понять, нет ли проблем с производительностью. Такой инструмент может быть нужен только первые несколько дней, после диагностики его можно удалить.

Вообще у меня на GitHub есть стартовая болванка WordPress-проекта, где часть подобных вещей можно быстро развернуть.

Главный принцип — не «ставить десять обязательных плагинов из статьи в интернете», а понимать, зачем вам каждый из них.

Александр: А готовая тема — это хорошая идея? Или профессиональнее всегда делать собственную?

Александр Сокирка: Всё зависит от автора темы.

Если покупаете очень популярную тему уровня Avada, которой пользуется огромное количество людей, у неё есть сильное преимущество: продукт годами проверяли тысячи реальных пользователей. Большая часть распространённых проблем уже всплывала и исправлялась.

Это может быть вполне хорошим выбором.

Но у меня были и противоположные случаи.

Я покупал сторонние темы для своих проектов, причём у авторов, которых нельзя назвать новичками. Визуально всё прекрасно.

Проблема в том, что автор небольшой темы часто концентрируется именно на внешнем виде. Он делает красивую демонстрацию, несколько типовых страниц, базовую логику.

На пустом демо всё работает быстро.

А что произойдёт после нескольких тысяч публикаций, сложных метаполей и реальной нагрузки — неизвестно.

Для своего сайта с курсами я однажды купил красивую тему. Сначала никаких проблем не заметил.

Позже, когда накопилось много контента, главная страница админки начала открываться чуть ли не несколько минут.

Поставил инструмент мониторинга и увидел огромное количество запросов к базе. Оказалось, в теме был кастомный виджет для dashboard, внутри которого неудачно построена логика.

Я просто убрал эту функцию из исходного кода.

Но обычный пользователь сделать этого не сможет. Он напишет автору: «У меня тормозит админка». И очень легко получить ответ: «Возьмите хостинг дороже, добавьте память».

Хотя проблема вообще не в сервере.

Другой конфликт вокруг готовых тем — ожидания поддержки.

Покупатель платит условные 40 долларов и иногда считает, что вместе с темой приобрёл бесконечную индивидуальную разработку.

А автор отвечает за баги своего продукта и совместимость, но не обязан бесплатно реализовывать любую кастомную хотелку конкретного клиента.

У меня был покупатель, который настроил мою тему уже для своего клиента. Ему потребовалось индивидуальное изменение. Я предложил сделать его как отдельную оплачиваемую работу.

Человек возмутился: «Я же уже купил тему».

Но тема стоила десятки долларов, а его собственный заказ от конечного клиента — намного больше.

Это классическая проблема продуктовой разработки: цена лицензии не превращает автора в бесплатного штатного программиста.

Александр: Ещё одна проблема — такие темы потом очень трудно кому-то передать. Исправляете одну вещь, начинает ехать другая.

Александр Сокирка: Особенно это касается старых тем.

Раньше разработчики часто складывали в тему вообще всё, что знали. Даже функциональность, которая архитектурно должна жить в плагине.

На старых маркетплейсах было огромное количество проектов, где в теме находилась сложная PHP-логика: custom post types, таксономии, метабоксы.

И затем возникает проблема.

Пользователь годами наполнял сайт. У него тысячи записей, свои сущности, категории, дополнительные поля.

Он отключает старую тему и включает новую — внезапно значительная часть сайта «исчезает».

Данные физически могут оставаться в базе, но WordPress больше не знает, как с ними работать, потому что регистрация post type или taxonomy находилась внутри PHP-кода старой темы.

Поэтому маркетплейсы со временем начали жёстче разделять ответственность: бизнес-логика и сущности — в плагинах, представление — в теме.

Это очень правильная идея. Тогда тему можно менять, не теряя структуру контента.

Современный Full Site Editing дополнительно двигает WordPress в сторону более декларативных блочных тем, где меньше причин складывать огромный PHP-core непосредственно в шаблон.

Александр: Раз уж упомянули таксономии: что это такое и зачем они нужны?

Александр Сокирка: Таксономия позволяет классифицировать контент.

После установки WordPress у вас есть базовые сущности — например, записи и страницы.

Но реальный сайт сложнее.

Допустим, мы создаём каталог из тысячи автомобилей. Для автомобилей делаем отдельный post type.

Теперь эти автомобили нужно группировать: по марке, цвету, типу коробки передач и другим признакам.

Для каждой такой классификации можно создать taxonomy.

И в результате мы уже не просто имеем тысячу одинаковых записей. Можно строить фильтры и выборки: показать автомобили конкретной марки, определённого цвета, только с автоматической коробкой.

Именно такие механизмы позволяют превратить WordPress из «блога с двумя категориями» в довольно гибкую систему управления структурированным контентом.

Александр: А ACF? Что дают дополнительные поля?

Александр Сокирка: Advanced Custom Fields позволяет создавать дополнительные метаполя через удобный интерфейс в админке.

По умолчанию у записи есть заголовок, основной текст и другие стандартные поля. Но для профессионального проекта этого часто мало.

Возьмём тот же автомобиль. Нужно отдельно хранить тип салона, объём двигателя, пробег и другие характеристики.

Можно просто написать всё одним текстом. Но тогда программе намного сложнее использовать эти данные.

Если «кожаный салон» — отдельное структурированное метаполе, вы можете построить выборку: показать все автомобили с кожаным салоном.

ACF особенно удобен людям, которые не хотят самостоятельно писать интерфейс для этих полей.

Александр: Почему тогда вы сами ACF используете не всегда?

Александр Сокирка: Потому что как разработчику мне иногда проще написать нужную небольшую функцию напрямую.

Если для конкретной сущности нужны три простых поля, я могу сделать форму достаточно небольшим количеством кода.

Подключать ради этого весь дополнительный слой плагина мне не всегда хочется.

Но это не означает, что ACF плохой. Просто у человека, который пишет код, и у человека, который собирает сайт через интерфейс, разные критерии удобства.

Коротко:

• Хорошая готовая тема может сильно ускорить запуск, но слово premium не является технической гарантией качества. Важнее репутация автора, реальная история эксплуатации и то, как тема ведёт себя на больших данных.
• Логику, определяющую структуру данных сайта, безопаснее отделять от визуальной темы. Тогда смена дизайна не превращается в потерю custom post types, таксономий и метаданных.

Elementor или Gutenberg: рынок выбрал один, инженерный вкус — другой

Александр: Elementor — зло или хороший инструмент?

Александр Сокирка: Я вообще не люблю классифицировать инструменты в категориях «зло» и «добро».

Если Elementor стал настолько популярным, значит, рынок решил, что инструмент решает реальную проблему.

У него миллионы установок, огромная экосистема, множество готовых тем. Клиенту удобно открывать страницу и визуально редактировать контент.

Когда я делал коммерческие темы, мне тоже приходилось поддерживать Elementor. Это было требование рынка: покупатели хотели именно такой редактор.

Александр: Но у подобных сайтов часто есть репутация тяжёлых и сложных в поддержке. На фриланс-биржах много заказов «починить сайт на Elementor».

Александр Сокирка: Моё личное отношение к Elementor сейчас скорее отрицательное, но важно объяснить почему.

Не потому, что я считаю каждый сайт на нём плохим. У меня самого при разработке виджетов серьёзных проблем не было.

Перелом произошёл во время работы с американскими студиями с достаточно дорогими проектами.

Они категорически не хотели Elementor. Требование было другое: Gutenberg, блочные темы, Full Site Editing — то есть современный нативный стек WordPress.

Причём иногда клиенту нужен был быстрый MVP и казалось логичным просто подобрать готовую тему. Но найти красивую полноценную FSE-тему оказывалось сложнее, потому что рынок исторически заполнен классическими шаблонами и билдерами.

Тогда мы брали понравившийся клиенту визуальный референс и фактически собирали нужную часть дизайна заново на Gutenberg.

После многих таких проектов я сам стал намного больше ценить этот подход.

Есть и техническая причина.

В Gutenberg вы работаете с JavaScript и React, можете хорошо разделять блок на небольшие модули: отдельно стили, отдельно логику, отдельно компоненты.

Мне вообще нравится модульность — маленькие понятные части вместо одного гигантского файла.

В старых page builder-подходах я часто видел большие PHP-классы, куда складывались настройки целого виджета. С WPBakery была похожая история.

Это не означает, что Elementor нужно срочно удалить со всех сайтов. Если бизнесу удобно, команда умеет его поддерживать и производительность устраивает — инструмент выполняет свою задачу.

Но если я сегодня начинаю собственный WordPress-проект и могу выбирать, мне ближе Gutenberg и Full Site Editing.

Коротко:

• Популярность Elementor не случайна: он сделал визуальное редактирование WordPress доступным огромной аудитории и остаётся полезным там, где эта скорость важнее инженерной чистоты.
• Для новых собственных проектов Сокирка предпочитает Gutenberg/FSE: ему ближе нативная архитектура WordPress, React-компоненты и более модульное устройство кода.

Headless WordPress, большие проекты и главное правило: не тащить любимый стек в каждую задачу

Александр: Как вы относитесь к архитектуре, где WordPress остаётся админкой, а фронтенд делается отдельно на React или Angular? Хорошая идея или лишняя сложность?

Александр Сокирка: Headless WordPress сейчас действительно популярен, но я бы не делал его архитектурой «по умолчанию».

Важно понимать, откуда вообще возникает подобная необходимость.

Представьте стартап. Нужно быстро проверить идею. WordPress идеально подходит для MVP: готовая админка, пользователи, API, работа с контентом, огромная экосистема.

Можно даже не делать отдельный JavaScript-фронтенд — запустить обычную тему или Gutenberg.

Проект выстреливает.

Допустим, это большой американский новостной сайт о спорте. Через несколько лет у него миллионы записей, огромное количество метаданных и очень много посетителей.

Теперь изначальная архитектура начинает упираться в масштаб. Фронтенд тормозит, админка становится тяжёлой, журналистам неудобно добавлять материалы.

Но просто выбросить WordPress уже сложно: внутри накоплены данные, процессы, редакционная команда привыкла к интерфейсу.

Вот здесь Headless становится естественным следующим этапом.

Можно отделить фронтенд, построить его на технологии, подходящей для высокой нагрузки, а WordPress оставить как существующую CMS и источник данных.

Параллельно оптимизировать саму админку, SQL-запросы и работу с миллионами сущностей.

То есть мы пришли к Headless не потому, что разработчику однажды захотелось соединить WordPress и React, а потому, что реальный выросший продукт создал такую потребность.

Если же вы заранее знаете, что делаете не обычный контентный сайт, а большой сервис, API для мобильного приложения или специфичный backend-продукт, я бы сразу посмотрел на другие решения.

Для некоторых подобных задач мне сейчас ближе Laravel.

Александр: Значит ли это, что крупные проекты вообще не стоит делать на WordPress?

Александр Сокирка: Нет. У меня нет хейта к WordPress.

Если большой проект использует именно те возможности, которые WordPress хорошо даёт, я вполне могу выбрать WordPress.

Большой контентный сайт, сложная CMS, редакционная система — почему нет?

Я скорее разделяю сайты и продукты другого типа.

Если нужен API для мобильного приложения, специфичная бизнес-логика или сервис, где CMS-функции WordPress почти не используются, я не вижу смысла брать его только из-за привычки.

А если задача действительно про страницы, публикации, редакторов, контент — WordPress может быть совершенно уместен даже на большом проекте.

Александр: Получается тот же принцип, что с 1С и Bitrix: в одном рынке определённая интеграция может быть важнее абстрактной любви к конкретной технологии.

Александр Сокирка: Именно.

Вы, например, смотрите на задачу через опыт российского рынка, где 1С чрезвычайно распространена.

Я работал преимущественно с другим сегментом, где такого контекста практически нет. Поэтому для меня интеграция с 1С вообще не является аргументом при выборе стека.

Зато я долго работал с американскими заказчиками, которые требовали Gutenberg и Full Site Editing. Я сделал много таких проектов и естественно смотрю на WordPress через этот опыт.

Мы все пропускаем технические решения через собственную историю.

Поэтому особенно важно отделять «мне привычно» от «это объективно лучше для данного проекта».

Александр: Есть ли смысл WordPress-разработчику изучать Docker?

Александр Сокирка: Я использую Docker постоянно, мне очень удобно.

Когда я начинал, локальное окружение приходилось настраивать руками. Ставить сервер, PHP, базу, переносить файлы.

С Docker вы можете описать окружение и запускать проект практически одинаково на разных машинах.

Клонировали репозиторий, выполнили команду — получили PHP, базу данных, WordPress и необходимые вспомогательные сервисы.

Это убирает огромный объём рутины.

Но я бы не говорил: «Вы не WordPress-разработчик, пока не знаете Docker». Это преувеличение.

Чтобы начать делать сайты на WordPress, Docker необязателен.

Но как общий инженерный инструмент его стоит изучить. Чтобы понять Docker, контейнеры и Docker Compose на базовом уровне, не нужны годы. Несколько хороших практических занятий уже дают понимание.

В компаниях подобный подход давно стал привычным, потому что команда заинтересована в воспроизводимом окружении.

На одиночном фрилансе люди иногда годами продолжают работать старым способом просто потому, что никто не показал альтернативу.

Александр: А CI/CD имеет смысл в WordPress?

Александр Сокирка: Я использую CI/CD практически везде.

Новичкам трудно представить, сколько ручной рутины было в старых процессах.

Когда-то мы открывали FTP-клиент, вводили логин и пароль, вручную перетаскивали файлы на сервер. Если появился срочный баг — исправили локально и снова руками отправили.

Теперь весь код лежит в GitHub.

Я внёс изменение, сделал commit и push. Дальше GitHub Actions может выполнить подготовленный workflow.

Можно настроить автоматический деплой. Я часто предпочитаю ручной trigger: нажал кнопку — система сама отправила проверенную версию на сервер.

Главное преимущество даже не в том, что не приходится открывать FTP.

Перед выкладкой можно запустить проверки.

Например, в Laravel-проектах у меня перед deployment выполняются форматирование и тесты. Если условные 200 тестов не прошли, новая версия просто не уедет на production.

Это очень важная страховка.

В серьёзном проекте можно иметь staging-сервер: сначала deployment идёт туда, выполняются дополнительные проверки, затем — production.

Настройка зависит от проекта, но сама идея универсальна: чем меньше критических операций человек делает руками, тем меньше случайных ошибок.

Коротко:

• Headless WordPress особенно логичен как эволюция уже выросшего WordPress-проекта. Создавать Headless с первого дня только потому, что архитектура модная, необязательно.
• Docker и CI/CD не являются обязательными условиями входа в WordPress, но сильно улучшают воспроизводимость, автоматизацию и качество процесса разработки.

WooCommerce, большие платформы и WordPress через пять лет

Александр: На чём вы делаете интернет-магазины? Насколько активно работали с WooCommerce?

Александр Сокирка: Если говорить честно, я не называю себя большим экспертом именно по гигантским WooCommerce-магазинам.

В моей практике было больше LMS — систем обучения — и крупных контентных или membership-проектов.

С WooCommerce я работал много в контексте коммерческих тем. Практически каждая тема на маркетплейсе должна была поддерживать интернет-магазин, потому что так продукт лучше продавался.

Поэтому я делал визуальную часть, шаблоны страниц товара, UX-функции вроде покупки в один клик, перехода сразу к checkout и других вещей.

Но у меня не было сотен проектов, где десятки тысяч товаров постоянно создавали специфические WooCommerce-проблемы.

И я предпочитаю об этом говорить прямо, а не изображать эксперта во всём WordPress.

Зато были очень большие проекты другого типа.

Например, мы работали над платформой для актёров: membership-система, обучение, кабинеты, большая база пользователей. Команда несколько человек работала над ней примерно год, бюджет был очень серьёзным.

И всё это было на WordPress.

Поэтому тезис «WordPress годится только для маленького блога» я точно не поддерживаю. На нём можно строить достаточно большие системы, если задача подходит платформе и команда понимает, что делает.

Александр: На одном таком проекте вы уже использовали ChatGPT ещё до нынешней волны coding-agents?

Александр Сокирка: Да.

Тогда полноценного современного вайб-кодинга ещё не было, но ChatGPT уже помогал отдельными кусками кода.

У нас, например, была интерактивная SVG-карта Соединённых Штатов. При клике на штат нужно было показывать определённые эффекты и данные — школы, офисы и другую информацию, связанную с этим регионом.

Я задавал вопросы ChatGPT и достаточно быстро собрал связку, на которую без помощника мог бы потратить значительно больше времени, читая документацию и перебирая варианты через поиск.

То есть даже ранняя модель уже работала как ускоритель поиска технического решения.

Александр: Если завтра придёт клиент и скажет: «Мне нужен интернет-магазин», вы откажетесь из-за того, что не считаете себя экспертом по огромным WooCommerce-проектам?

Александр Сокирка: Нет, с удовольствием возьмусь, если проект мне интересен.

Если появятся специфичные проблемы, будем их решать.

Я просто разделяю две вещи: способность разработчика разобраться в задаче и право публично заявлять, что у вас огромная экспертиза именно в узкой категории проектов.

Мне не нравится второе без реального опыта.

Александр: И всё-таки главный вопрос: что будет с WordPress через пять лет?

Александр Сокирка: Мне кажется, ничего катастрофического с ним не произойдёт.

WordPress останется.

Он уже активно двигается навстречу ИИ, и я думаю, мы дойдём до ситуации, когда агент сможет управлять огромной частью сайта.

Владелец перестанет заходить в десять разделов админки.

Он скажет: «Создайте статью на такую тему». Или: «Посмотрите, сколько заявок пришло по этому товару». Или: «Проверьте остатки в WooCommerce». Или: «Измените этот блок».

Агент сам выполнит необходимые операции.

И это уже не выглядит чистой фантастикой, потому что отдельные части такого процесса работают сегодня. Я своими глазами видел, как coding-agent управляет WordPress через CLI.

Ещё несколько лет назад я делал плагин, который помогал готовить текст статьи через API ChatGPT. Схема была полуавтоматической: вы формулируете тему, API возвращает черновик, затем вручную его редактируете и публикуете.

Современный агент потенциально может пройти всю цепочку самостоятельно.

Поэтому WordPress не исчезнет из-за ИИ.

Но его доля рынка новых сайтов, на мой взгляд, может постепенно снижаться.

Не потому, что существующие пользователи начнут массово выбрасывать WordPress, а потому, что самих сайтов некоторых типов станет меньше.

Особенно это касается информационных проектов.

На моём Genius.Courses огромное количество статей и уроков. В определённый момент поисковый трафик был очень хорошим. Затем с развитием ответов непосредственно в поисковых системах и ИИ-интерфейсах посещаемость заметно снизилась.

Когда человек получает ответ до перехода на сайт, экономика информационного ресурса меняется.

То же может происходить с сетками сайтов, создававшимися прежде всего ради SEO.

Если часть поиска и навигации уйдёт в ИИ-ассистентов, потребность в таких проектах снизится.

Есть и второй фактор: новый владелец малого бизнеса часто вообще не думает о технологии.

Ему всё равно, WordPress это, Wix, Tilda или что-то ещё. Он увидел рекламу конструктора в подходящий момент, попробовал, получил результат — для первого сайта этого достаточно.

Если позже упрётся в ограничения, тогда может прийти к WordPress и разработчику.

Новые программисты тоже могут чаще начинать с вайб-кодинга и получать решения на разных фреймворках, а не автоматически ставить WordPress.

Поэтому я представляю будущее так: доля будет медленно снижаться, но огромная существующая база останется.

Есть серьёзные порталы, магазины, редакции, корпоративные сайты. Никто не станет мигрировать их просто ради технологической моды.

Маркетплейс тем тоже никуда мгновенно не исчезнет. Для многих людей намного удобнее открыть каталог из сотни готовых дизайнов, выбрать понравившийся и через час получить узнаваемый результат, чем весь день объяснять агенту визуальную идею и расходовать токены на итерации.

WordPress останется именно потому, что вокруг него уже построен огромный работающий мир.

Коротко:

• Через пять лет WordPress, вероятно, станет значительно более «агентным»: многие операции в CMS можно будет выполнять человеческим языком, а не через ручную навигацию по админке.
• Главный риск для доли WordPress — не появление одной «CMS-убийцы», а сокращение самого класса сайтов, которые раньше массово создавались ради информационного поиска и SEO.

За пределами WordPress: футбол, предпринимательство и жизнь после одной профессии

Александр: Есть ли у вас хобби, никак не связанное с разработкой?

Александр Сокирка: В разные периоды были разные увлечения.

В детстве занимался нумизматикой, собирал монеты. Сейчас коллекцию передал сыну — ему это стало интересно.

Очень люблю спорт, особенно футбол.

Сам в детстве занимался футболом совсем недолго: сходил в секцию, сломал ногу, несколько месяцев провёл в гипсе и на этом спортивная карьера фактически закончилась.

Но любовь к футболу осталась.

Сейчас сын занимается им уже несколько лет. Практически каждые выходные у нас турниры — ездим по стране, иногда в соседние страны.

Поэтому нынешнее хобби — это, наверное, футбол и наблюдение за успехами сына.

Александр: А если бы не разработка, WordPress и программирование — чем могли бы заниматься?

Александр Сокирка: Возможно, работал бы с детьми в спорте.

У меня был небольшой опыт, когда пришлось временно заменять детского футбольного тренера и проводить несколько тренировок. Мне понравилось.

Но вообще я и сейчас не совсем воспринимаю себя как классического программиста.

Человек смотрит мой канал «Быть Программистом», видит много контента про код и естественно думает: перед ним разработчик с большим стажем.

А я себя скорее называю онлайн-предпринимателем.

Почти всё, что делал в интернете, было на стыке разных профессий.

Начинал с дизайна в Photoshop. И сегодня, если делаю собственный продукт, всё равно могу открыть Photoshop и доработать графику — даже если базовую картинку создал ИИ.

Могу открыть Figma и самостоятельно сделать интерфейс.

Пишу код, занимаюсь структурой продукта, думаю о продвижении, записываю контент.

Получается широкий стек: везде понемногу.

Иногда сам не понимаю, правильнее ли было всю жизнь копать одну область максимально глубоко или именно такой широкий путь дал мне больше возможностей.

Но поэтому слово «предприниматель» мне ближе, чем «чистый программист».

Если однажды ИИ действительно радикально сократит потребность в моей нынешней работе, мне была бы интересна сфера общения с людьми — возможно, работа детским тренером.

Мне кажется важным иметь возможность положительно влиять хотя бы на небольшую группу детей: через спорт, дисциплину, команду, нормальное человеческое взаимодействие.

Александр: Последний вопрос: у вас есть мечта?

Александр Сокирка: Наверное, моя мечта — быть счастливым, приносить пользу людям и много зарабатывать.

Для меня эти вещи связаны.

Без достаточного количества денег сложно чувствовать полную свободу и спокойствие. Но и большие деньги, если вы вообще никому не приносите пользы, лично для меня не выглядят хорошей целью.

Поэтому я хотел бы, чтобы эти три вещи сочетались.

Коротко:

• Карьера Сокирки давно шире одной роли WordPress-разработчика: дизайн, программирование, продукты, обучение и предпринимательство для него всегда существовали рядом.
• Технологии могут менять профессии и инструменты, но долгосрочная цель остаётся человеческой: делать полезные вещи, сохранять интерес к жизни и иметь экономическую свободу.

Глоссарий

ACF (Advanced Custom Fields) — популярный плагин WordPress для создания дополнительных полей и структурированных метаданных через интерфейс админки.

agents.md — текстовый файл с инструкциями и контекстом проекта для coding-agents: в нём можно описать стек, архитектурные правила, команды проверки, ограничения и другие требования.

API (Application Programming Interface) — интерфейс, через который одна программа или часть системы взаимодействует с другой. Например, отдельный фронтенд может получать данные из WordPress через API.

Backend (бэкенд) — серверная часть приложения: бизнес-логика, работа с базой данных, API, авторизация и другие операции, которые обычно выполняются не в браузере пользователя.

Bitrix / 1С-Битрикс — семейство программных продуктов для управления сайтами и бизнес-процессами; в статье упоминается в контексте выбора технологии под конкретную инфраструктуру заказчика.

Block theme (блочная тема) — современный тип темы WordPress, построенный вокруг блочного редактора и Full Site Editing.

ChatGPT — интерфейс и семейство ИИ-возможностей OpenAI для работы с текстом, кодом и другими типами данных.

CI/CD (Continuous Integration / Continuous Delivery или Deployment) — набор практик автоматической проверки, сборки и доставки изменений. Например, после push система может запустить тесты и только затем разрешить деплой.

CLI (Command-Line Interface) — интерфейс командной строки, где действия выполняются текстовыми командами вместо графических кнопок.

CMS (Content Management System) — система управления контентом. Позволяет создавать, редактировать и публиковать материалы сайта через административный интерфейс. WordPress, Joomla и Drupal — примеры CMS.

Codex — инструменты и модели OpenAI, ориентированные в том числе на программирование и агентную работу с кодовой базой.

Coding-agent / ИИ-агент — система на базе ИИ, которая может не только отвечать текстом, но и выполнять последовательность действий: читать файлы, редактировать код, запускать команды и тесты, анализировать результат и переходить к следующему шагу.

Commit — зафиксированное состояние изменений в Git с собственным идентификатором и описанием.

Computer Science — фундаментальная область знаний о вычислениях, алгоритмах, структурах данных, архитектуре компьютеров и принципах программных систем.

CSS — язык описания внешнего вида веб-страниц: размеров, цветов, расположения, адаптивности и других визуальных параметров.

Custom post type — пользовательский тип контента в WordPress. Кроме стандартных записей и страниц можно создать, например, сущности «Автомобили», «Курсы» или «Актёры».

Deployment / деплой — процесс доставки новой версии приложения или сайта на сервер, где она становится доступна пользователям.

Diff — представление различий между двумя версиями файла: какие строки были добавлены, удалены или изменены.

Docker — платформа контейнеризации, позволяющая описать окружение приложения и воспроизводимо запускать его на разных компьютерах.

Docker Compose — инструмент для описания и одновременного запуска нескольких связанных контейнеров, например WordPress, PHP, базы данных и почтового сервиса.

Elementor — популярный визуальный page builder для WordPress, позволяющий собирать страницы через графический интерфейс.

Envato Market — экосистема маркетплейсов цифровых продуктов. В статье упоминается в связи с продажей коммерческих тем WordPress.

Framework / фреймворк — программная основа, задающая структуру приложения и набор правил разработки. Laravel — пример PHP-фреймворка.

Full Site Editing (FSE) — подход WordPress, при котором с помощью блоков можно редактировать не только содержимое отдельной страницы, но и шаблоны сайта: header, footer, архивы и другие части.

Git — распределённая система контроля версий. Позволяет сохранять историю изменений, создавать ветки и возвращаться к предыдущим состояниям проекта.

GitHub — сервис хранения Git-репозиториев и совместной работы над кодом.

GitHub Actions — система автоматизации внутри GitHub. С её помощью можно запускать тесты, сборку, проверки и deployment после определённых событий.

Gutenberg — современный блочный редактор и связанная с ним архитектура WordPress. Блоки могут использовать JavaScript и React и служат основой Full Site Editing.

Headless WordPress — архитектура, при которой WordPress используется преимущественно как CMS и источник данных, а пользовательский фронтенд создаётся отдельно на другом технологическом стеке.

HTML — язык разметки, задающий структуру веб-страницы: заголовки, текст, ссылки, формы и другие элементы.

JavaScript (JS) — основной язык программирования для интерактивной логики веб-интерфейсов; также используется за пределами браузера.

Joomla — CMS, особенно популярная в веб-разработке 2000-х и начала 2010-х; в интервью упоминается как система, с которой Сокирка работал до перехода на WordPress.

Laravel — популярный PHP-фреймворк для создания веб-приложений и backend-систем. В интервью противопоставляется не WordPress «вообще», а его использованию в задачах, для которых CMS может быть избыточной.

LLM (Large Language Model) — большая языковая модель. К этому классу относятся современные генеративные модели, способные работать с естественным языком и программным кодом.

LMS (Learning Management System) — система управления обучением: курсы, уроки, ученики, прогресс, подписки и другие образовательные функции.

Marketplace / маркетплейс — площадка, на которой множество независимых продавцов предлагают цифровые или физические продукты. ThemeForest — пример маркетплейса тем для сайтов.

MCP (Model Context Protocol) — протокол, позволяющий ИИ-системам стандартизированно подключаться к внешним инструментам и источникам данных.

Metadata / метаданные — дополнительные структурированные данные, связанные с объектом. Для автомобиля это могут быть пробег, цвет, двигатель или тип салона.

Metabox / метабокс — блок дополнительных полей в административном интерфейсе WordPress, связанный с записью или другой сущностью.

MVP (Minimum Viable Product) — минимально жизнеспособная версия продукта, которую создают для быстрой проверки идеи до дорогостоящей полноценной разработки.

Page builder — визуальный инструмент сборки страниц из готовых элементов и секций без необходимости вручную писать всю разметку.

PHP — серверный язык программирования, на котором написана значительная часть WordPress и его экосистемы.

Plugin / плагин — модуль, расширяющий функциональность WordPress без изменения ядра CMS.

Post type — тип сущности в WordPress. Стандартные примеры — post и page; разработчик может регистрировать собственные типы.

Production / продакшен — рабочая среда приложения, которой пользуются реальные пользователи.

Prompt / промпт — текстовая инструкция, которую пользователь передаёт ИИ. Качество промпта включает не только формулировку задачи, но и контекст, ограничения и критерии результата.

Push — отправка локальных Git-коммитов в удалённый репозиторий, например на GitHub.

Qwen — семейство ИИ-моделей Alibaba; в интервью упоминается в контексте экспериментов с PHP, Laravel и локальным запуском моделей.

React — JavaScript-библиотека для создания пользовательских интерфейсов; используется в современной экосистеме WordPress, в частности вокруг Gutenberg.

Repository / репозиторий — хранилище проекта с его файлами и, в случае Git, историей изменений.

SEO (Search Engine Optimization) — оптимизация сайта и его контента для поисковых систем.

SSH — защищённый протокол удалённого доступа, широко используемый для управления серверами и автоматизации deployment.

Staging — тестовая серверная среда, максимально похожая на production. На неё можно выложить новую версию до того, как изменения увидят реальные пользователи.

Symfony — PHP-фреймворк и набор компонентов для разработки веб-приложений.

Tailwind CSS — CSS-фреймворк, построенный вокруг большого набора небольших utility-классов, которые применяются непосредственно в разметке.

Taxonomy / таксономия — механизм классификации контента WordPress. С его помощью объекты можно группировать, например, по марке, цвету или типу.

Theme / тема WordPress — слой, который определяет внешний вид и шаблоны отображения сайта.

ThemeForest — маркетплейс из экосистемы Envato, известный продажей тем и шаблонов для WordPress и других платформ.

Token / токен — условная единица текста, с которой работает языковая модель. Лимиты и стоимость ИИ-сервисов часто связаны с количеством обработанных токенов.

UI (User Interface) — пользовательский интерфейс: кнопки, формы, меню, страницы и другие элементы, с которыми взаимодействует человек.

UX (User Experience) — пользовательский опыт: насколько понятно, удобно и предсказуемо человек взаимодействует с продуктом.

Vibe coding / вайб-кодинг — подход, при котором разработчик формулирует желаемый результат на естественном языке, а ИИ генерирует значительную часть реализации. В профессиональном варианте человек при этом контролирует архитектуру, исходный код и результат.

Visual Studio Code — популярный редактор кода, поддерживающий расширения, Git и интеграцию с различными ИИ-инструментами.

Wix — облачный конструктор сайтов; в интервью используется как пример платформы, которая конкурирует с другими способами создания сайтов, но не является прямым аналогом вайб-кодинга.

WooCommerce — популярный плагин электронной коммерции для WordPress: товары, корзина, checkout, заказы и другие функции интернет-магазина.

WordPress — открытая CMS, вокруг которой создана большая экосистема тем, плагинов, разработчиков и сервисов.

WPBakery — визуальный page builder для WordPress, особенно широко использовавшийся в классических коммерческих темах.

WP-CLI — интерфейс командной строки для управления WordPress: позволяет, например, устанавливать и активировать плагины, работать с пользователями, базой данных и другими функциями без входа в графическую админку.