Мне очень не нравится термин. Он подсознательно «сужает» взгляд на ИИ и ограничивает его использование.

«Когда у вас в руке молоток, все становится похожим на гвозди».

Вайб‑кодинг словно бы говорит: «Иди и программируй!»

Есть данные, и нужен какой‑то отчет? Иди вайбкодь! Бэкенд, фронтенд, VPS, вот это всё. А зачем, если тот же ИИ можно просто попросить сделать Excel файлик с нужной структурой и нужными формулами? И он будет понятнее, с ним можно будет работать в будущем, его можно отдать кому‑то, не решая вопросы про доступы, безопасность и тому подобное

Хотите запустить блог или какой‑то контентный проект? Иди вайбкодь! Изучай Next.js, Sanity, Supabase, Vercel! Деплой, отлаживай! Но зачем, если можно взять хоть Ghost, хоть WordPress, с помощью того же ИИ получить рекомендации по нужным плагинам и темам, настроить всю верстку, и получить понятное обновляемое решение?

Примерно так и начиналась эта статья, когда моя жена — директор небольшой частной школы — попросила меня помочь ей с новым ее проектом. За время работы у нее накопился большой опыт в разных вопросах, которые так или иначе связаны с образованием — от мотивации до подготовки к ОГЭ, ЕГЭ и тому подобное. Все это захотелось как‑то собрать, обобщить и поделиться этим. Сделать классный экспертный журнал об образовании.

Первая мысль — «сейчас мы быстро все навайбкодим!»

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

Бюджет на отдельного разработчика и дизайнера — ноль. Человек, который этим занимался на старте (я), — не фронтендер и не WordPress‑разработчик. Я разбираюсь в инфраструктуре, но вёрстка и PHP — вообще не мой профиль.

Почему не пишем свой движок

Первый соблазн — ну, реально, взять Codex или Claude Code, в очередной раз получить свою дозу дофамина от того, что «нейронка» возьмет неведомый тебе стэк, наваяет свою CMS, а оно раз — и заработает! Но если честно посмотреть на задачу: нужен блог с категориями, SEO, картинками, поиском, RSS и тому подобное. Это полностью решённая задача. WordPress делает именно это уже двадцать лет.

Писать свой движок — это не разработка журнала. Это разработка CMS, которая потом будет использоваться для журнала. Разница принципиальная. Мне нужно публиковать статьи, а не дебажить рендеринг Markdown.

WordPress — может быть, не самое элегантное решени. Но у него есть то, чего нет у самописного решения: уже готовая админка, медиатека, плагины для SEO, система ролей, REST API, WP‑CLI для автоматизации. Всё это бесплатно, задокументировано и работает.

Выбор стека: VPS на Ubuntu, nginx, PHP 8.3, MySQL 8.0, WordPress с темой GeneratePress. Ничего необычного. Вся кастомизация — через mu‑plugins и CSS.

Как устроена работа с ИИ

Весь проект в итоге делался через Claude Code — CLI‑инструмент, который подключается к серверу по SSH, пишет PHP, правит конфиги, заливает файлы. Я формулирую задачу на русском языке, он выполняет. Процесс выглядит примерно так:

Я: «Сделай главную страницу: hero‑блок с закреплённой статьёй, сетка последних статей в три колонки, блок популярного, список свежих записей, сетка разделов».

ИИ: генерирует PHP‑скрипт, который создаёт Gutenberg‑контент, прописывает CSS, настраивает тему.

Я: «Три колонки не работают, всё в одну».

ИИ: выясняет, что WordPress core‑стили перебивают кастомный CSS, переносит стили в mu‑plugin с высоким приоритетом.

Я: «Теперь работает. Но отступы слишком большие».

ИИ: правит.

И так далее.

Что реально получилось за пару вечеров в спокойном режиме

С нуля, от пустого VPS до работающего журнала:

• Настроенный сервер: nginx с кешированием, PHP‑FPM, MySQL, SSL сертификаты, firewall, fail2ban.

• WordPress с кастомной главной страницей журнального типа: hero, карточки статей, список свежих, сетка разделов.

• Дизайн: минималистичный, адаптивный, шрифт Inter, белые карточки на светлом фоне. Не шедевр UX, но выглядит аккуратно.

• SEO: Rank Math, sitemap, человеческие URL через ЧПУ, транслитерация slug'ов.

• 12 mu‑plugins для кастомизации всего — от шапки до подвала.

Итерационный процесс: как это выглядит на практике

Vibecoding — это не «сказал и готово». Это диалог. Иногда довольно утомительный.

Типичная итерация выглядит так:

1. Формулируешь задачу. Чем точнее — тем лучше результат.

2. ИИ делает. Обычно процентов на 80 правильно.

3. Проверяешь в браузере. Находишь проблему.

4. Описываешь проблему. «Текст прилипает к краям», «блок уехал», «на мобильном всё сломалось».

5. ИИ чинит. Иногда с первого раза, иногда нет.

6. Повторяешь с пункта 3.

Конкретный пример из проекта. Блок «Разделы» на главной странице. Изначально ИИ сгенерировал его как статический HTML — названия категорий были зашиты прямо в контент страницы. Я переименовал категории в админке WordPress, но на главной ничего не изменилось. Логично: HTML‑то статический.

Решение — mu‑plugin с фильтром the_content, который при каждом показе страницы подставляет актуальные данные из базы. Но первая версия этого плагина содержала захардкоженный список slug'ов категорий. Я к тому моменту уже переименовал категории, slug'и изменились — и из восьми разделов на главной появились только два (те, чьи slug'и совпали со старыми).

Вторая итерация: вместо фиксированного списка — get_terms(), который берёт все категории из базы. Заработало.

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

Ещё пример: CSS. WordPress генерирует свои inline‑стили (класс is-layout-constrained и подобные), которые перебивают кастомный CSS из настроек темы. Несколько итераций ушло на то, чтобы понять, почему трёхколоночная сетка упорно рендерится в одну колонку. Решение — mu‑plugins с приоритетом 999, который гарантированно грузится после core‑стилей. Это неочевидное знание, если ты не живёшь в экосистеме WordPress. ИИ дошёл до него через пробы и ошибки — не сразу.

Где ИИ помог

Инфраструктура. Настройка nginx, PHP‑FPM, MySQL, SSL, firewall — всё сделано через SSH‑команды, которые генерировал ИИ. Для меня это рутина, но сильно экономит время. Главное — смотреть и проверять, что именно ИИ делает.

WordPress‑кастомизация. Я не знаю API WordPress на уровне хуков и фильтров. ИИ — знает. Он написал 12 mu‑plugins, каждый из которых решает конкретную задачу: убрать сайдбар, переопределить сетку, добавить поиск в шапку, сделать динамический блок категорий. Я бы потратил на это значительно больше времени, копаясь в документации.

CSS. Я описываю «карточки с тенью, hover с подъёмом, адаптив на мобильных» — получаю готовый CSS. Не идеальный, но рабочий. Дальше правим точечно.

Где ИИ не помог (или мешал)

Не видит результат. ИИ (по крайней мере, консольный Claude Code) не открывает браузер. Он не знает, как выглядит страница после его правок. Всё тестирование — на мне. Я смотрю, описываю словами, он правит. Это работает, но медленно. Иногда проще было показать скриншот, чем объяснять «вот тут текст прилипает к краю». Собственно, к этому подходу я в какой‑то момент и пришел.

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

Перебивает правки. Иногда, чиня одну проблему, ИИ ломает что‑то другое. Классика: исправил перенос заголовков в блоке «Свежие записи» через sed — случайно заменил стили и для даты тоже. Пришлось перезаливать файл целиком. Мелочь, но множится.

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

Плагины и экосистема. Установил Cyr‑To‑Lat для транслитерации slug'ов. Оказалось, что плагин транслитерирует только на стороне сервера при сохранении, а в Gutenberg‑редакторе до сохранения — нет. Мы потратили время, выясняя, что это нормальное поведение, а не баг. Разработчик с опытом в WordPress просто знал бы это.

Когда vibecoding подходит

• Прототипы и MVP. Когда нужно проверить идею, а не строить большую production систему. Наш журнал — это MVP, и он выполняет свою задачу.

• Стандартные задачи на незнакомом стеке. Я знаю, что мне нужно, но не знаю API конкретной платформы. ИИ закрывает этот разрыв.

• Малые команды и сольные проекты. Когда нет отдельного фронтендера, бэкендера и DevOps — ИИ позволяет одному человеку закрывать все роли. Не идеально, но достаточно.

• Кастомизация готовых решений. WordPress, Shopify, Bitrix — когда нужно допилить, а не построить с нуля.

Когда не подходит

• Безопасность критична. ИИ не думает о безопасности проактивно. Он не предложит rate limiting, не подумает о CSRF, не проверит SQL‑инъекции — если вы не попросите. Да, есть скиллы, в которые это все заложено по умолчанию. Но вы должны знать об этом и применять.

• Ты не понимаешь предметную область и надеешься, что ИИ «разберётся сам». Не разберётся. Он выдаст правдоподобный код, который развалится при первом контакте с реальностью.

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

Цифры

• Время: от пустого VPS до работающего журнала с контентом — пара выходных, по несколько часов в день.

• Стоимость инфраструктуры: VPS (примерно 500–700 руб/мес), домен, SSL бесплатный.

• Стоимость разработки: подписка на Claude. Ноль часов оплаченной разработки.

• Объём кода: ~12 mu‑plugins (PHP), ~600 строк CSS, несколько Python‑скриптов для сложных вопросов. Всё это написал ИИ, я — ни строчки.

• Количество итераций на типовую задачу: 2–4.

Выводы

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

Ключевое слово — «техническим бэкграундом». Я понимаю, что такое nginx, DNS, SSL, SQL, CSS‑специфичность, REST API. Я не знаю наизусть хуки WordPress, но я понимаю, что такое хук. Без этого фундамента vibecoding превращается в чёрный ящик — ты не можешь ни сформулировать задачу, ни проверить результат, ни понять, почему что‑то сломалось.

Наш журнал работает. Статьи публикуются. SEO настроен. Это не enterprise‑решение, но для задачи «контентный блог для школы» — более чем достаточно. И сделано это одним человеком, который параллельно занимался другими проектами.

Наверное, профессиональный WordPress‑разработчик сделал бы лучше. Наверняка, сделал бы правильнее. Но его не было, а журнал был нужен. И vibecoding позволил закрыть эту задачу — не идеально, но работоспособно. А в реальной жизни «работает сейчас» часто важнее, чем «идеально никогда».

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

Результат

Наша Школа Все Вместе — Журнал об образовании

Для старта, на мой взгляд, все вообще отлично!

Тексты — авторские, «крафтовые».

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