Habr: autor explicó por qué AI no debe reducirse solo a vibe coding

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

Не код ради кода

Текст начинается с претензии не к моделям, а к слову «вайб-кодинг» как к слишком узкой рамке. Если постоянно мыслить в логике «сейчас нагенерим приложение», легко пропустить более практичные решения. Для отчёта по данным иногда достаточно попросить ИИ собрать Excel-файл с формулами и понятной структурой. Для контентного проекта — подобрать связку из готовой CMS, шаблона и плагинов, вместо того чтобы тратить время на фронтенд, деплой и отладку собственного стека.

«ИИ в ваших руках — это шикарный мультитул, а не молоток».

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

Блог вместо своей CMS

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

Вместо самописного приложения был выбран прагматичный стек: VPS на Ubuntu, nginx, PHP 8.3, MySQL 8.0, WordPress с темой GeneratePress.

ИИ при этом никуда не исчез — он использовался как исполнитель через SSH, писал PHP, правил конфиги, настраивал тему и собирал кастомизации через mu-plugins. За пару спокойных вечеров проект получил рабочую основу: сервер с nginx, PHP-FPM, MySQL, SSL, firewall и fail2ban журнальную главную страницу с hero-блоком, карточками статей и сеткой разделов базовое SEO, sitemap и человекочитаемые URL 12 mu-plugins для точечной кастомизации * около 600 строк CSS и несколько вспомогательных Python-скриптов По сути, автор не отказался от ИИ — он перестал заставлять ИИ строить то, что уже существует. Это и есть центральный аргумент статьи: во многих проектах выигрыш приходит не от максимального объёма сгенерированного кода, а от умения опереться на готовую платформу и допилить только узкие места.

Где ИИ реально полезен

Самая сильная часть текста — описание реального процесса, без магии и без рекламного пафоса. ИИ не сделал всё «по одной команде». Работа шла итерациями: человек формулирует задачу, модель делает примерно 80% нужного, затем начинается цикл проверки, поиска визуальных проблем и точечных правок.

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

В одном случае ИИ сделал блок категорий статическим HTML, и после переименования рубрик на главной ничего не обновлялось. Исправление пришло только после нескольких итераций: сначала через фильтр the_content, потом через отказ от захардкоженных slug'ов в пользу get_terms(). В другом случае пришлось отдельно разбираться, почему WordPress core-стили ломают трёхколоночную сетку, и поднимать приоритет кастомных стилей до 999.

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

Что это значит

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