Ниже — готовая редакционная версия. Последовательность тем и вопросов сохранена по исходному интервью о WordPress; по трём приложенным образцам я взял формат с лидом, тематическими частями, подписями спикеров и короткими выводами в конце каждого блока. (Будущее WordPress. шаблоны, нейросети, фриланс, Wordpress выживет. Александр Сокирка.docx) (C++ в 2026-м.docx) (React в 2026 году.docx) (Шрифт — это не просто буквы.docx) По композиции ориентировался и на присланный пример с Хабра: сильный заголовок, вводный лид и дальнейшее деление большого разговора на самостоятельные смысловые главы. (habr.com)

WordPress не умрёт — но работать с ним по-старому уже не получится: ИИ-агенты, вайб-кодинг, Laravel, фриланс и сайты после прихода нейросетей

WordPress хоронят не первый год. Сначала ему должны были помешать конструкторы сайтов, затем современные JavaScript-фреймворки, headless-подход, облачные платформы — а теперь на сцену вышли нейросети, которые способны не просто написать кусок PHP, но самостоятельно пройтись по проекту, вызвать WP-CLI, активировать плагин, подготовить тесты и задеплоить изменения. Возникает неудобный вопрос: если сайт можно попросить изменить обычной фразой, зачем новому поколению вообще изучать WordPress — и что тогда останется разработчику?

Об этом поговорили с Александром Сокиркой — разработчиком, который пришёл во фриланс ещё школьником, начинал с баннера за пять долларов, затем делал сайты на Joomla и WordPress, продавал десятки шаблонов на маркетплейсах, работал с американскими студиями и последние месяцы активно экспериментирует с вайб-кодингом. Внутри — WordPress и Laravel, Copilot, Claude, Codex и Qwen, рынок фриланса и зависимость от платформ, Elementor и Gutenberg, ACF и таксономии, Docker и CI/CD, WooCommerce, выгорание, роботы — и ответ на главный вопрос: что вообще имеет смысл учить разработчику сегодня.

WordPress исчезает из инфополя — но не обязательно с сайтов

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

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

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

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

Выжимка:

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

Баннер за пять долларов, Joomla и WordPress, выученный за две недели

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

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

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

Но конечная цель у меня всё-таки была другой: хотелось разрабатывать сайты. Я самостоятельно читал PDF-книги вроде «HTML для чайников», позже — «PHP для чайников» и постепенно переходил к более сложным задачам.

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

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

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

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

На собеседовании меня спрашивают:

— С WordPress знакомы?

Я говорю:

— Да, знаком.

— Покажите, что делали.

И я открываю своё портфолио на фриланс-бирже. Там были просто скриншоты сайтов — по ним невозможно понять, на какой CMS всё сделано. Посмотрели: нормальные сайты. Сказали: «Берём».

Мне дали двухнедельный испытательный период. За эти две недели я подтянул базовые вещи WordPress и начал нормально работать.

Со стороны фраза «выучил WordPress за две недели» звучит странно. Но здесь важно понимать, что я не начинал с нуля. У меня уже были PHP, HTML, вёрстка, дизайн, понимание CMS. Мне нужно было разобраться именно в WordPress: посмотреть его Codex, иерархию файлов, устройство тем и плагинов.

Когда фундамент уже есть, перейти на новый инструмент намного проще.

Александр: У меня путь очень похожий. Тоже были книги «для чайников», Joomla, JoomShopping. Я довольно долго не хотел уходить с Joomla: казалось, зачем менять то, что работает. Потом коллега сказал: «Все уже идут в WordPress», — мы перешли и в итоге не пожалели.

Александр Сокирка: Так часто и происходит. Когда человек привык к определённой CMS, перейти на что-то новое тяжело.

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

И это нормальная реакция.

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

Так постепенно появилась новая волна.

Выжимка:

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

Агент уже умеет активировать плагины: сможет ли WordPress пережить ИИ

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

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

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

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

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

Я экспериментировал с Codex на собственном сайте с уроками и статьями по WordPress. И меня очень удивило, как агент сам работает с системой.

Например, когда раньше я записывал урок о создании плагина, сценарий выглядел так: мы пишем код, создаём плагин, потом я открываю админку WordPress и объясняю зрителям: «Теперь нужно нажать кнопку “Активировать”».

С ИИ-агентом произошло иначе. Он написал код плагина, я открыл WordPress — а плагин уже активирован.

Полез смотреть логи: оказалось, агент самостоятельно использовал WP-CLI и через командную строку активировал плагин. Я его специально этому не учил.

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

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

Скорее нейросеть станет ещё одним слоем управления над WordPress.

Александр: Но есть новое поколение разработчиков. Мы с вами выросли на самописных сайтах, CMS, ручной вёрстке. А человек, который начинает сегодня, вообще будет учить WordPress? Или сразу пойдёт в вайб-кодинг?

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

Александр Сокирка: Мне кажется, новое поколение в массе своей действительно не будет специально изучать WordPress. Более того, многие не захотят глубоко изучать и computer science.

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

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

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

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

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

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

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

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

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

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

За счёт низкого порога входа в экосистему пришло огромное количество людей. В результате в репозиториях появлялись плагины и темы очень разного качества, а внутри проектов смешивались PHP, JavaScript, HTML и CSS. У каждого автора мог быть свой подход.

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

Поэтому в каком-то смысле я начинаю разговор с того, что WordPress никуда не денется, а заканчиваю тем, что сам всё чаще беру Laravel.

Александр: Но у WordPress есть очевидный плюс: проект можно кому-то передать. Допустим, вы сделали интернет-магазин при помощи нейросети. А что потом делать владельцу? Где документация, где понятные процессы, кому передавать сопровождение?

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

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

А я допускаю другой вариант: дальше с этим сайтом тоже будет работать нейросеть.

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

Клиенту не обязательно будет искать человека, чтобы поменять кнопку или добавить какое-то поле. Возможно, внутри того же WordPress появится полноценное окно общения с агентом. Владелец пишет: «Сделайте мне вот это изменение», — и система его выполняет.

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

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

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

Александр Сокирка: Но клиенту и необязательно знать всю техническую часть.

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

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

Но пользователь может написать и что-то сложнее: «Добавьте несколько метаполей, создайте таксономии и сделайте фильтрацию».

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

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

Вот это, на мой взгляд, и есть перспективная модель.

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

Выжимка:

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

Вайб-кодинг — не новая CMS: почему Tilda, WordPress и нейросети конкурируют не напрямую

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

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

Вайб-кодинг — это не отдельная система вроде WordPress, Joomla или Wix. При помощи него можно писать самописный PHP, Laravel, Symfony, WordPress. Можно генерировать плагин, тему или целый проект.

Поэтому фраза «вайб-кодинг отберёт долю рынка у WordPress» для меня не совсем корректна.

WordPress, Joomla, Drupal, Shopify, Magento, Bitrix могут в каком-то смысле конкурировать друг с другом. У них есть пересекающиеся сценарии.

Laravel местами тоже можно поставить рядом, хотя CMS и фреймворк всё-таки предназначены для разных задач.

А нейросеть — это инструмент, который может работать внутри каждого из этих вариантов.

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

Поэтому ИИ, скорее, конкурирует не с WordPress, а с частью нашей работы как программистов.

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

Вот такая эволюция.

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

Александр Сокирка: По моим словам действительно может показаться, что я «перешёл на Laravel». Но это не так.

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

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

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

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

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

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

Я подумал: почему бы не собрать всё в одну систему?

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

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

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

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

Александр: У меня был похожий опыт. Я когда-то хотел сделать сервис для поиска тренеров по большому теннису и по привычке пытался уложить всё в WordPress. Но появились личные кабинеты, более сложная логика — и стало понятно, что WordPress не всегда уместен.

Тогда давайте перейдём непосредственно к вайб-кодингу. Cursor, Claude Code, Copilot — чем вы пользовались и как менялось ваше отношение к этим инструментам?

Выжимка:

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

От автодополнения до разработчика-редактора: Copilot, Claude, Codex и Qwen

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

В комментариях часто писали: «Вайб-кодинг небезопасен», «нейронки — зло». У меня самого было похожее отношение.

Потом решил: вместо споров нужно просто сделать несколько проектов и посмотреть руками, какая модель что умеет.

Начинал с GitHub Copilot. Тогда он в первую очередь помогал автодополнением. Вы пишете код руками, а инструмент предлагает следующую пачку строк. В моём случае это могло ощутимо ускорять работу — условно процентов на 60.

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

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

Работал через чат Copilot, пробовал модели Claude. Для сложных задач использовал Claude Opus. Быстро понял одну особенность тарифов и лимитов: нет смысла тратить дорогую модель на изменение одного Tailwind-класса.

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

Позже перешёл на инструменты OpenAI и Codex в Visual Studio Code. И здесь моё отношение к вайб-кодингу стало меняться ещё сильнее.

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

Для PHP мне также понравился Qwen. Я много использовал его с Laravel.

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

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

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

Александр: За последние месяцы действительно произошёл заметный скачок. Сначала много внимания забрал Claude Code, затем усилился Codex. Похоже, конкуренция будет только ускорять развитие.

Александр Сокирка: Я тоже думаю, что качество моделей будет расти очень быстро.

Но есть ещё экономическая сторона. Сейчас многие ИИ-инструменты стоят для пользователя сравнительно недорого. При этом за одним запросом стоят дата-центры, дорогое оборудование, GPU, электроэнергия.

Поэтому я не уверен, что нынешняя стоимость навсегда останется такой же.

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

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

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

Я ставил локальные модели на собственный компьютер — Qwen, Gemma и другие. Сравнивал с облачным вариантом.

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

Александр: Почему? Не хватало железа?

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

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

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

Но больше меня удивила не скорость, а энергопотребление. Во время экспериментов процессор и память постоянно были загружены почти на 100%. И за период активного тестирования счёт за электричество ощутимо вырос.

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

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

Александр Сокирка: Рабочая — но не обязательно экономически разумная.

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

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

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

Поэтому маркетинговые обещания в духе «купите маленькую коробочку — и получите дома аналог огромного облачного ИИ» я бы воспринимал осторожно.

Выжимка:

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

«Не начинайте с промптов»: что должен знать человек, который входит в разработку вместе с ИИ

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

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

Возьмём разработчика, который несколько лет всё делал руками. Он понимает, как устроен процесс. Знает, что такое CI/CD, GitHub Actions, SSH, деплой, сервер, база данных.

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

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

Поэтому я остаюсь сторонником базы.

Если человек хочет быть профессионалом, ему полезно изучать computer science, понимать, как работают компьютеры и сети, что происходит с данными.

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

То же самое здесь.

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

Александр: В интернете сейчас много красивых историй: «Посмотрите, что я собрал за вечер». Но уже появляются и заказы «исправить проект после вайб-кодера». Что вы конкретно посоветовали бы начинающему? Что изучать: HTML, CSS, PHP — всё то, что учили мы?

Александр Сокирка: Я бы дал несколько технических советов.

Во-первых, мне больше нравится способ работы, при котором вы видите исходный код.

Например, Visual Studio Code, расширение с чатом или агент, работающий через CLI. Вы ставите задачу, но одновременно видите, какие файлы он создаёт и что в них меняет.

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

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

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

Поэтому первое правило — Git и доступ к исходному коду.

Я бы вообще начинал проект с пустой папки, сразу инициализировал Git-репозиторий, связал его с GitHub и только после этого запускал агента.

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

Вы становитесь редактором.

Что при этом изучать?

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

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

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

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

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

База экономит не только время, но и токены.

Второй важный принцип — фиксировать каждую удачную итерацию.

Попросили ИИ выполнить задачу. Он её сделал. Вы посмотрели изменения, проверили результат — commit и push.

После этого переходите к следующей задаче.

Я воспринимаю это примерно как сохранение перед сложной миссией в старых играх. Сделали что-то полезное — сохранитесь.

У меня неоднократно было так: агент нормально завершал одну задачу, я забывал сделать commit, давал следующую — и он ломал одновременно новое и то, что только что работало.

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

Третий принцип — не перегружать контекст.

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

Старый контекст способен не помогать, а мешать.

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

У разных систем есть собственные форматы файлов, но мне удобнее начинать с одного универсального описания проекта. Сегодня вы работаете с Claude, завтра заканчивается лимит — переключаетесь на Codex или Qwen. Хорошо, когда базовый контекст проекта не привязан к одному конкретному поставщику.

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

Потом попробовал попросить самого агента сначала просканировать проект и подготовить agents.md.

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

Но всё равно нельзя считать инструкции стопроцентной гарантией результата.

У меня был один промпт, который я много раз применял к похожим массивам данных. Первый запуск — идеально. Второй — идеально. Третий — тоже. И где-то на седьмой итерации модель внезапно стала делать по-другому.

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

Вот зачем нужен Git, diff и человеческая проверка.

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

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

Выжимка:

• Современный новичок может меньше времени тратить на ручное производство типового кода, но HTML/CSS, JavaScript, язык бэкенда, базы данных, Git и базовые принципы работы систем всё равно нужны.
• Безопасный вайб-кодинг — это не «сказал фразу и забыл», а короткий цикл: задача → изменения → diff → проверка → commit → следующая задача.

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

Александр: А вне клиентской разработки вы используете нейросети? Какие сценарии вошли в обычную жизнь?

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

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

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

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

Даже утром перед этим интервью я включил компьютер проверить камеру и микрофон. До разговора оставалось время. Открыл Visual Studio Code и дал агенту несколько задач, которые давно крутились в голове.

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

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

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

Google активно продвигает собственные ИИ-инструменты, студии для дизайна и создания приложений. Вы постоянно видите: «Создайте приложение», «Сделайте интерфейс».

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

И всё.

Рынок от самого факта появления ещё одного приложения не стал в нём нуждаться.

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

То же самое касается сайтов.

Мы научились очень дёшево производить контент и программные продукты, но спрос человека не вырос в сто раз. У него по-прежнему 24 часа в сутках.

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

Поэтому нас ждёт интересная ситуация: создавать становится легче, а завоевать внимание — сложнее.

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

Александр Сокирка: Такая мысль у меня тоже возникала.

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

В какой-то момент я даже специально отключал Copilot, потому что думал: не хочу участвовать в обучении модели своими действиями.

Потом понял, что это довольно условная защита, если мой код всё равно хранится на GitHub.

Но вопрос приватности для меня важен.

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

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

Был период, когда я принципиально использовал в быту в основном Gemini. Логика была иронично простая: Google и так знает обо мне огромное количество информации — почта, браузер и другие сервисы. Мне казалось странным дополнительно разносить ещё больше данных по десятку новых платформ.

Сейчас для повседневных задач мне по-прежнему нравится Gemini, а для программирования много использую инструменты OpenAI.

Причём подписку OpenAI изначально купил вообще не ради кода. Мне понадобилось сгенерировать много изображений для проекта. Бесплатного лимита не хватало — взял подписку.

Потом подумал: раз подписка уже есть, почему бы не поставить Codex в Visual Studio Code?

Так я в очередной инструмент разработки попал почти случайно.

Выжимка:

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

Фриланс, который «умирал» трижды: биржи, шаблоны и американские клиенты

Александр: После всего разговора про ИИ давайте перейдём к рынку. Фриланс вообще жив?

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

Были небольшие периоды, когда я устраивался в компании. В нескольких местах работал по восемь месяцев, где-то около года. Но в основном у меня всегда были собственные клиенты, в том числе из США. Иногда юридически это выглядело как работа через мою компанию на аутсорсе, но я всё равно воспринимал это как фриланс: я не был классическим сотрудником «на дядю».

Начинал с самой обычной схемы: фриланс-биржа, заявки, отклики, клиент выбирает исполнителя.

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

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

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

В какой-то момент я понял, что мне всё меньше нравится продавать время за деньги.

У вас есть физический предел. Один час можно продать за 30 долларов. Можно стать очень сильным специалистом и продать дороже. Но масштабировать именно час бесконечно нельзя.

А продукт масштабируется.

Вы делаете что-то один раз и можете продать за 30 долларов одному человеку, потом ещё одному, потом сотне людей.

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

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

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

И именно этот этап довольно сильно изменил мою жизнь.

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

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

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

А похожий сайт на обычном фрилансе я тогда мог делать примерно за 300.

После этого психологически очень тяжело возвращаться к модели «сделал сайт одному заказчику — получил 300 долларов».

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

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

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

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

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

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

Примерно семь лет назад я почти перестал заниматься этим видом фриланса.

После этого значительная часть клиентов приходила через LinkedIn.

Александр: То есть вы фактически ушли от бирж к работе напрямую со студиями?

Александр Сокирка: Да. В основном это были американские студии, которым нужен опытный WordPress/PHP-разработчик.

Схема мне нравилась намного больше классической биржи.

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

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

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

И отношения с клиентами были другими. Если мы 40 часов обсуждаем проект, созваниваемся, изучаем задачу — это тоже работа, и она оплачивается. Не существует требования, что все 40 часов я должен физически печатать код.

Но постепенно я заметил важный процесс.

Сначала у моей основной студии становилось всё меньше проектов именно по PHP и WordPress. Потом они всё чаще передавали меня партнёрам. Затем и у партнёров таких проектов стало меньше.

Воронка сужалась.

В какой-то момент контракт закончился просто потому, что студия больше не могла гарантировать мне full-time загрузку.

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

Даже с 17–18 годами опыта найти подходящий проект стало сложнее.

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

Поэтому фраза «фриланс умер» для меня одновременно и верна, и неверна.

Умерли конкретные формы фриланса, через которые прошёл лично я.

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

Исполнителю тоже придётся адаптироваться.

Александр: Вы ещё упоминали зависимость от платформ. Насколько это серьёзная проблема?

Александр Сокирка: Для меня — одна из главных.

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

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

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

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

Но без развитого профиля и отзывов именно на Upwork этот внешний опыт практически не помог.

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

У меня уже был болезненный урок на Envato.

Александр: Что произошло?

Александр Сокирка: Я действительно нарушил правило и этого не скрываю.

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

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

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

Платформа обнаружила нарушение и заморозила профиль.

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

Через полгода профиль вернули. Формально продукты тоже вернулись.

Но их позиции уже были потеряны. Все внешние ссылки, SEO, история продаж — экосистема за это время изменилась.

До блокировки у меня был живой бизнес. После разблокировки — практически мёртвый профиль.

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

Нарушение было моим — здесь спорить бессмысленно. Но сам уровень зависимости меня испугал.

После этого хотелось строить то, что не может исчезнуть вместе с одним аккаунтом.

Выжимка:

• Фриланс не исчезает, но его рабочие модели постоянно меняются: биржа → продажа продуктов → прямые клиенты → новые форматы, которых сегодня ещё может не существовать.
• Чем сильнее доход зависит от одной платформы, тем больше риск. Рейтинг и профиль могут выглядеть как собственный актив, но технически контролирует их площадка.

На чём живёт разработчик, который перестал зарабатывать разработкой

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

Александр Сокирка: Последние активные годы основной доход шёл от прямой работы с клиентами через LinkedIn.

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

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

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

Доход от встроенной рекламы символический. Интеграций почти нет.

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

Набирал группы студентов, преподавал.

Но там быстро появляется потолок.

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

Экономика получается хуже, чем на обычном фрилансе.

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

Большая часть материалов стала бесплатной. То, что когда-то продавалось, я постепенно выкладывал открыто — и на сайт, и на YouTube.

Так что последние годы вопрос «на чём вы зарабатываете?» действительно интересный.

Александр: И всё-таки — как тогда устроена ваша жизнь сейчас?

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

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

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

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

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

Выжимка:

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

Кухонный стол до трёх ночи: почему «работа мечты» тоже заканчивается выгоранием

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

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

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

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

Но в момент разработки я параллельно работал в компании.

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

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

Несколько часов сна — и утром снова на работу.

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

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

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

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

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

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

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

Александр Сокирка: Это как раз подтверждает поговорку «хорошо там, где нас нет».

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

И правда есть у обоих.

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

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

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

А реальный фрилансер ночью может думать: «Где взять следующий проект? Что сделает ИИ с моим рынком? Почему клиент не отвечает?»

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

У них просто разные истории.

Выжимка:

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

Что учить 23-летнему разработчику: WordPress — не первым пунктом

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

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

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

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

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

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

Но новичку всё равно сначала нужно стать разработчиком, а уже потом — специалистом по конкретному инструменту.

Лично я по-прежнему считаю хорошей базой PHP и JavaScript.

PHP, кстати, я не воспринимаю как умерший язык. Наоборот, мне кажется, вокруг него снова много интересного.

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

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

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

Вы видите, что именно заказывают клиенты.

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

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

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

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

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

Поэтому и сделал детский фитнес-трекер.

Но этот эксперимент охладил мой энтузиазм.

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

Моё приложение месяц лежало в магазине, и сам магазин практически не привёл пользователей.

До публикации я думал: «Как легко! Сейчас сделаю сто приложений».

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

И конкуренция будет только увеличиваться.

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

То есть конкуренция теперь растёт уже не только внутри биржи.

Люди при этом перенасыщены сервисами. У меня самого на телефоне остаётся всё меньше сторонних приложений.

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

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

Такой гарантированной ниши сейчас просто нет.

Выжимка:

• Учить лучше не «профессию WordPress-разработчика», а фундамент веб-разработки. Тогда WordPress, Laravel или следующий популярный инструмент становятся осваиваемыми надстройками.
• Биржа, собственные приложения и контентные сайты могут быть каналами, но каждый из них уже сильно конкурентен. Навык создавать продукт теперь менее дефицитен, чем навык найти реальную потребность и аудиторию.

Если ИИ пишет код, останется ли человеку хотя бы одна работа

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

Александр Сокирка: Я с этим согласен лишь частично.

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

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

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

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

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

Это начинает напоминать взаимодействие людей: один поставил задачу другому, проверил результат и продолжил.

Поэтому риск отличается от истории с экскаватором.

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

Куда это приведёт — я не знаю.

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

Возможно, ИИ не только кого-то заменит, но и позволит отдельному человеку создавать намного больше.

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

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

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

ИИ создаёт теоретическую возможность убрать и его.

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

Но изменения будут очень серьёзными.

И при этом я не хочу мистифицировать LLM. Я понимаю, что это языковая модель, а не человеческий мозг.

Слово «мозг» использую образно — из-за поведения, которое наблюдаю.

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

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

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

Я отдельно об этом не просил.

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

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

Александр Сокирка: Безусловно.

Выжимка:

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

Три плагина, премиум-шаблоны и ловушка красивой демки

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

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

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

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

Первая — SEO. Например, All in One SEO.

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

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

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

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

Александр: Тогда второй практический вопрос. Сайт на готовом шаблоне — нормальная идея или лучше делать собственную тему?

Александр Сокирка: Очень зависит от автора шаблона.

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

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

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

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

При этом никто не проверяет сайт на больших объёмах данных.

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

На пустом сайте всё работало нормально.

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

Поставил мониторинг запросов и увидел огромное количество обращений к базе. В кастомном dashboard-виджете темы был неудачно написанный цикл.

Я как разработчик просто нашёл код и отключил виджет.

Обычный пользователь написал бы автору: «У меня медленно работает админка».

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

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

Это одна сторона.

Вторая — экономика поддержки премиум-тем.

Пользователь платит за шаблон условные 40 долларов. Автор получает ещё меньше после комиссии.

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

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

Я объяснил: исправление ошибки темы — наша обязанность. Индивидуальная доработка — отдельная услуга.

И он очень удивился, потому что считал: «Я уже купил шаблон».

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

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

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

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

Раньше разработчик темы мог просто положить внутрь всё, что ему требовалось: регистрацию custom post type, таксономии, метабоксы, бизнес-логику.

В результате тема отвечала не только за внешний вид, но и за данные.

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

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

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

Современный Full Site Editing дополнительно двигает архитектуру в сторону блоков.

Поэтому сегодня я бы намного осторожнее относился к старым монолитным темам.

Выжимка:

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

Таксономии и ACF: зачем WordPress нужны данные сложнее «заголовок + текст»

Александр: Расскажите простыми словами, что такое таксономии и зачем они нужны.

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

Установили WordPress — можно создать тысячи статей и страниц. Но реальный сайт почти всегда сложнее простой ленты из тысячи записей.

Допустим, у нас сайт с автомобилями.

Мы создаём отдельный post type «Автомобили». Но сами машины нужно делить по разным признакам: марка, цвет, тип коробки передач.

Для каждого такого измерения можно использовать таксономию.

Одна — марки. Другая — цвета. Третья — коробки передач.

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

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

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

Александр: А ACF? Для чего нужны дополнительные поля?

Александр Сокирка: Речь про Advanced Custom Fields и метаполя.

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

Возьмём всё тот же автомобиль.

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

А если создать метаполе «Тип салона», вы сможете отдельно хранить значение и затем строить фильтр: показать все автомобили с кожаным салоном.

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

Это очень удобно для фрилансеров и владельцев сайтов.

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

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

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

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

Но это не значит, что ACF плохой.

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

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

Выжимка:

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

Elementor — зло? Нет. Но рынок и хороший код отвечают на разные вопросы

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

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

Александр: Почему спрашиваю: на досках объявлений постоянно встречаются заказы на исправление сайтов, собранных в Elementor. Человек сделал проект визуально, затем сайт тормозит, что-то сложно поменять.

А на американском рынке при этом Elementor очень популярен. Как к нему относиться?

Александр Сокирка: Если мы вообще сегодня обсуждаем Elementor, значит рынок уже доказал, что инструмент кому-то нужен.

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

Лично я отношусь к Elementor скорее негативно и для собственных новых проектов не выбираю.

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

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

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

У них было жёсткое требование: новые проекты — Gutenberg и Full Site Editing.

Иногда клиенту нужен был быстрый MVP. Мы искали готовый блочный шаблон — и с удивлением обнаруживали, что красивых современных FSE-тем на рынке заметно меньше, чем классических Elementor-тем.

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

После нескольких таких проектов у меня закрепилась привычка выбирать Gutenberg.

Технически мне вообще нравится модульность.

Есть блок — рядом его стили, JavaScript, логика. Маленькие независимые части.

В старых билдерах часто получались большие PHP-классы, куда складывалось слишком много настроек.

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

Просто для собственной разработки мне ближе Gutenberg и Full Site Editing.

Выжимка:

• Популярность Elementor объясняется реальной потребностью бизнеса: человек без программирования получает визуальное управление страницей.
• Для нового кастомного проекта более современная блоковая архитектура Gutenberg/FSE может оказаться предсказуемее и модульнее — особенно если команда готова с ней работать.

Headless WordPress: хорошая стратегия спасения и сомнительная стартовая архитектура

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

Александр Сокирка: Здесь нет универсального ответа.

Разработчик, который отлично знает WordPress, естественно, будет чаще выбирать WordPress. Иногда это правильно: знакомый инструмент снижает стоимость и риски.

Но если отвечать абстрактно «по книжке», я бы не выбирал WordPress в качестве headless-CMS только потому, что умею с ним работать.

Headless WordPress сегодня активно продвигается, но мне интереснее история, как такой подход вообще естественно появляется.

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

Команда делает MVP на WordPress: есть готовая админка, API, публикация контента, пользователи. Возможно, даже фронтенд первое время остаётся стандартным.

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

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

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

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

Тогда появляется рациональный headless-сценарий.

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

Параллельно оптимизируют базу и административную часть.

Вот такой путь мне понятен: WordPress был быстрым стартом, проект вырос, архитектура эволюционировала.

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

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

Через год я могу поменять мнение — я всегда оставляю такую возможность.

Александр: То есть вы не утверждаете, что крупный проект нельзя делать на WordPress?

Александр Сокирка: Конечно нет. У меня вообще нет хейта к WordPress.

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

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

Для сайта — вполне возможно WordPress.

Для продукта с совершенно другой предметной логикой — скорее другой стек.

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

То есть всё сводится к выбору технологии под задачу?

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

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

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

И с Gutenberg то же самое. Я много его использовал, клиенты его требовали, набил на этом руку — поэтому считаю его удобным.

Любой разработчик пропускает технологические решения через собственный опыт.

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

Выжимка:

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

Docker и CI/CD: почему WordPress тоже не обязан жить в мире ручного FTP

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

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

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

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

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

Это просто убирает рутину.

Но я не говорил бы: «Чтобы работать с WordPress, вы обязаны глубоко изучить Docker».

Достаточно понять базовые принципы, основные команды, Docker Compose и попробовать собрать локальный WordPress-проект.

После нескольких часов практики уже становится понятно, зачем это нужно.

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

Александр: А CI/CD для WordPress?

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

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

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

Сегодня, если весь исходный код уже лежит в GitHub, намного естественнее настроить GitHub Actions.

Я делаю изменения локально, проверяю, commit, push. После этого запускается нужный workflow.

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

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

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

В Laravel-проектах у меня, например, идут форматирование, тесты и только после успешного прохождения разрешается выкладка.

Если 200 тестов не прошли, код просто не попадёт на production.

Можно построить два этапа: сначала тестовый сервер, затем production.

Для каждого проекта процесс свой.

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

Выжимка:

• Docker и CI/CD нужны WordPress не ради моды, а чтобы устранить ручные различия окружений, FTP-переносы и человеческие ошибки.
• Чем больше проект, тем полезнее относиться к WordPress как к обычному программному продукту: репозиторий, тестовое окружение, автоматические проверки и контролируемый деплой.

WooCommerce и большие проекты: «я не эксперт» не означает «я не возьмусь»

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

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

Больше проектов связано с LMS — системами обучения, личными кабинетами, контентными платформами.

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

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

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

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

При этом крупные WordPress-проекты у меня были.

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

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

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

То есть я ни в коем случае не утверждаю: «Большой проект — немедленно сносим WordPress и переписываем на Laravel».

Если WordPress подходит, я только рад на нём работать.

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

Помню модуль с SVG-картой США. Нужно было нарезать штаты, обработать клики и показывать связанные школы или офисы.

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

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

Александр: То есть с WooCommerce вы знакомы, просто не специализировались на гигантских магазинах?

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

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

Александр Сокирка: Нет. С удовольствием возьмусь. Если в процессе появится проблема, буду её решать.

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

Выжимка:

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

Что будет с WordPress через пять лет: доля снизится, а сама система останется

Александр: Тогда главный прогнозный вопрос. Что будет с WordPress через пять лет?

Александр Сокирка: Мне кажется, он никуда не денется. С WordPress всё будет нормально.

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

Вам не обязательно вручную заходить в десяток разделов админки.

Можно будет попросить: «Создайте статью на такую-то тему», «Посмотрите статистику по этому товару», «Есть ли нужное количество на складе?», «Измените этот блок».

Вы общаетесь в одном окне, а агент сам взаимодействует с сайтом.

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

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

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

Поэтому с ИИ WordPress, на мой взгляд, совместим отлично.

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

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

Причина не в массовой миграции существующих владельцев WordPress на какую-то новую CMS.

Причина в том, что части новых сайтов вообще не понадобится.

Возьмём информационные проекты.

У меня есть собственный сайт с большим количеством материалов и уроков по WordPress. В какой-то период поисковый трафик был очень хорошим.

После появления поисковых AI-ответов посещаемость ощутимо упала.

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

Для целого пласта информационных сайтов это меняет экономику.

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

То есть меньше новых сайтов — автоматически меньше новых установок WordPress.

Новые разработчики, как мы уже говорили, тоже будут чаще приходить не с вопросом «какую CMS выучить?», а с вопросом «какой результат мне нужно получить?». А технологию им предложит агент.

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

Человеку нужен сайт. В нужный момент увидел рекламу Wix — попробовал Wix. Увидел другой конструктор — пошёл туда.

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

При этом огромная существующая база никуда не исчезает.

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

Даже рынок готовых тем останется аргументом.

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

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

Выжимка:

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

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

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

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

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

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

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

Но любовь осталась.

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

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

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

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

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

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

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

Потому что никогда не был человеком одного очень узкого стека.

Начинал с дизайна. Рисовал страницы в Photoshop.

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

Могу открыть Figma и собрать интерфейс.

Потом перейти к бэкенду, фронтенду, продвижению, контенту.

То есть я везде понемногу.

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

Поэтому слово «программист» описывает меня не полностью.

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

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

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

Работая тренером, такой шанс есть.

Александр: И заключительный вопрос. У вас есть мечта?

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

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

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

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

Так что, наверное, мечта — суметь совместить эти вещи.

Выжимка:

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

Глоссарий

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

AI / ИИ — искусственный интеллект. В статье прежде всего имеются в виду генеративные модели и агентные системы, которые работают с текстом и программным кодом.

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

API, Application Programming Interface — программный интерфейс, через который одна система может обращаться к функциям или данным другой.

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

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

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

CI/CD — набор практик автоматической проверки, сборки и доставки изменений. В статье в качестве примера используются GitHub Actions и автоматизированный деплой.

CLI, Command Line Interface — интерфейс командной строки, через который программы можно запускать и управлять ими текстовыми командами.

CMS, Content Management System — система управления содержимым сайта. WordPress, Joomla и Drupal — примеры CMS.

Codex — в контексте современной части интервью инструмент OpenAI для работы с программным кодом и проектами при помощи ИИ. Не следует путать с историческим WordPress Codex — документацией WordPress.

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

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

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

CSS — язык описания внешнего вида веб-страниц.

Custom Post Type / post type — пользовательский тип записей в WordPress. Позволяет хранить отдельно, например, автомобили, курсы, объекты недвижимости или другие сущности, отличные от обычных статей.

Deploy, деплой — доставка и публикация новой версии приложения или сайта в рабочем окружении.

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

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

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

Elementor — популярный визуальный конструктор страниц для WordPress.

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

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

Full Site Editing, FSE — современный подход WordPress, позволяющий строить и редактировать не только содержимое страницы, но и значительную часть структуры сайта при помощи блоков.

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

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

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

Gutenberg — блоковый редактор и связанная с ним современная архитектура редактирования WordPress.

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

HTML — язык разметки веб-страниц.

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

Joomla — CMS, которая была особенно популярна в русскоязычном сегменте в 2000-х и начале 2010-х.

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

LLM, Large Language Model — большая языковая модель, лежащая в основе многих современных генеративных ИИ-сервисов.

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

Marketplace, маркетплейс — площадка, на которой разные авторы продают цифровые или физические товары. В статье речь в основном о шаблонах и темах.

MCP — протокол и подход к подключению ИИ-моделей и агентов к внешним инструментам и данным через стандартизированные интерфейсы.

Meta field, метаполе — дополнительное структурированное свойство записи WordPress, например цвет автомобиля, тип салона или отдельная характеристика товара.

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

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

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

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

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

Prompt, промпт — запрос или инструкция, передаваемая нейросети.

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

Qwen — семейство языковых моделей Alibaba. В интервью упоминается как один из инструментов для программирования, в частности с PHP.

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

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

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

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

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

Taxonomy, таксономия — механизм WordPress для классификации и группировки контента по признакам: категориям, маркам, цветам и другим параметрам.

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

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

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

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

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

WooCommerce — популярный плагин электронной коммерции для WordPress, превращающий CMS в основу интернет-магазина.

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

WordPress Codex — историческая база документации и справочных материалов по разработке под WordPress.

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