Вайбкодинг, за который мне не стыдно

Вайбкодинг, за который мне не стыдно

Коротко: В комментарии к посту в LinkedIn читатель написал, что у него не открываются ссылки на мой блог. С помощью pi + GLM 5.1 я сделал автоматически обновляемую HTML-страницу с мониторингом доступности. По цифрам на ней увидел проблему скорости: блог отдавал страницы по 3–5 секунд. Попросил агента исследовать причину и предложить решение. Мы выбрали кэш на уровне nginx. Код генерации страницы, сам HTML и конфиги nginx я не смотрел. Я задавал вопросы агенту, направлял его и принимал внешний вид страницы мониторинга. Для меня это и есть вайбкодинг — подход, который раньше я не принимал.

Кому полезно: тем, кто ищет альтернативы Cursor, Claude Code, Codex, Google Antigravity или хочет снизить зависимость от дорогих подписок. В статье пример того, что получилось сделать с помощью pi + GLM 5.1: страницу мониторинга и решение devops-задач.

За пределами Cursor, Claude Code, Codex и Antigravity

В ИИ-разработке на слуху Cursor, Claude Code, Codex, Google Antigravity. У каждого инструмента есть свои приверженцы. Кто-то сидит в Cursor, кто-то в Claude Code, кто-то в Codex, кто-то использует несколько инструментов сразу.

В этой истории я использовал другую связку: pi + GLM 5.1. Я последнее время пробую эту пару на разных задачах и накапливаю практический опыт. Причина простая: pi очень простой, без лишних надстроек; GLM 5.1 по опубликованным бенчмаркам выглядит неплохо и в моих задачах тоже показывает себя достойно.

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

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

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

С чего всё началось

Я опубликовал пост в LinkedIn про то, как выстраиваю процесс для ИИ-агентов в проекте: инструкции, роли, контроль качества и критерии готовности. В комментариях Костя Демидов написал:

«Привет, Дима! Засада в том, что LinkedIn работает из РФ только с VPN, а твой блог, на который ты дал ссылки, видимо, работает только из РФ (то есть с VPN не работает), поэтому они не открываются.»

Я списался с Костей в Telegram и уточнил детали:

  • из Латвии и Литвы блог не открывается;
  • из Финляндии открывается;
  • VPN — Red Shield.

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

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

Этап 1: HTML-страница с мониторингом доступности

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

Агент предложил check-host.net: ноды по всему миру, HTTP-проверки, без оплаты. Собрал первую версию дашборда.

Результаты насторожили. Часть нод показывала таймауты или полную недоступность. Но я не был уверен, что проблема в хостинге блога: локально всё открывалось, а в Яндекс.Метрике была статистика посещений. Ноды бесплатные, выбираются случайно — часть из них могла просто не работать. Например, Иран показывал DOWN, но я знал, что в это время там отключили интернет из-за военных действий. Блог ни при чём.

Я добавил google.com и ya.ru как эталон для проверки самих нод. Логика простая: если мой блог медленнее Google — проблема на моей стороне. Если Google тоже показывает таймаут — барахлит нода, и мой блог ни при чём.

Дальше правки шли потоком:

  • убрал проверку из Ирана и Украины, попросил добавить ноды США и удалённые регионы России;
  • добавил проверку с локальной машины и со своих серверов;
  • развёл частоту проверок: свои серверы — каждые 15 минут, check-host — раз в час, чтобы не упереться в лимиты;
  • поставил всё в cron.

Цифры показали то, на что я не обращал внимания: блог prikotov.pro отдавал страницы по 3–5 секунд. Я обсудил с агентом варианты ускорения — решили добавить кэш на уровне nginx. Сначала на главную, после проверки — на все публичные страницы.

Но с мониторингом иногда возникали проблемы. Со временем я добавил в проверку зеркала блога — mirror1.prikotov.pro, mirror2.prikotov.pro, mirror4.prikotov.pro. Check-host за раз не проверял все сайты — API возвращал данные только по части. Я разбил проверки в кроне, чтобы каждый сайт запускался отдельно.

Позже добавил Globalping как дублирующий сервис на случай проблем с check-host.

Финальный крон на сегодня — пример для двух сайтов:

# свои серверы — каждые 15 минут
2,17,32,47 * * * * refresh_own.sh --disable-node=www1

# check-host — каждые 4 часа
52 0-23/4 * * * refresh_checkhost.sh --site=prikotov.pro --disable-node=www1
57 2-23/4 * * * refresh_checkhost.sh --site=google.com --disable-node=www1

# Globalping — каждые 4 часа, со сдвигом
18 0,4,8,12,16,20 * * * refresh_globalping.sh --site=prikotov.pro --limit=3 --locations=DE,US,RU
33 1,5,9,13,17,21 * * * refresh_globalping.sh --site=google.com --limit=3 --locations=DE,US,RU

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

В результате получилась страница мониторинга с тремя источниками проверок:

  • локально с десктопа;
  • с моих серверов в Нидерландах, России, Франции и Германии;
  • через check-host.net и Globalping.

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

Почему блог был медленным и как мы его ускорили

Блог работает на Grav CMS. Я выбрал Grav из-за markdown-файлов вместо базы — пишу статьи в Obsidian и переношу на сайт. Архитектура Grav такова, что каждый запрос поднимает PHP-FPM и загружает bootstrap фреймворка примерно на 12 МБ — плагины, тема, конфигурация. Grav кэширует обработанные Markdown-страницы и Twig-шаблоны, но PHP всё равно стартует на каждом запросе, чтобы прочитать этот кэш. На слабой VPS это ощутимо. Когда один человек открывает статью рядом с сервером — терпимо. Но мониторинг отправляет несколько параллельных запросов с разных нод, и на слабой VPS это сразу чувствуется: время ответа вырастает до 3–5 секунд.

Я обсудил с агентом варианты ускорения и решили добавить fastcgi_cache в nginx поверх Grav-кэша.

Смысл простой: nginx сохраняет готовый HTML и при следующем запросе отдаёт его сам. PHP-FPM не стартует, Grav-кэш не нужен — nginx отдаёт страницу быстрее, чем PHP её сгенерирует. Для блога это работает: большинство страниц публичные и меняются редко.

Средний результат после настройки (TTFB — время до первого байта от сервера):

  • с сервера: 500ms → 50ms;
  • из Нидерландов: 5800ms → 45ms;
  • из Сингапура: 5800ms → 976ms.

Ускорение в 10 раз получилось из-за внедрения кэширования. А мониторинг дал инструмент: увидеть проблему, решить её и проверить результат. Ценность здесь не в коде, а в скорости загрузки блога.

Мне немного стыдно признаться 😅 но конфиг nginx я тоже не смотрел — как и код генератора мониторинга. Если посмотрю — это уже будет не вайбкодинг.

Вайбкодинг работает, когда важен артефакт

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

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

В моём случае результат — страница мониторинга и ускоренный блог.

Ранее с тем же подходом я собрал для себя ещё два дашборда: продуктивность по GitHub и маркетинг и продвижение.

Важна идея, реализация ничего не стоит

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

В стартап-культуре принято говорить: «Идея ничего не стоит, важна реализация» (англ. ideas are worthless, execution is everything). Эта фраза родилась в мире, где реализация дорогая: найти разработчика (а чаще — команду), написать ТЗ, дождаться результата, проверить, платить за поддержку.

ИИ-агенты меняют экономику мелких инструментов. Реализация дешевеет. Код, скрипты, HTML-отчеты и прочее превращаются в материал, который можно быстро собрать, проверить и переделать. Формула переворачивается: реализация ничего не стоит, важна идея (англ. execution is worthless, ideas are everything).

Дорожает другое:

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

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

Итог

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

Pi + GLM 5.1 оказались достаточными для этой задачи. Для меня эта пара ещё и запасной вариант: выручает, когда не хватает лимитов в Codex или есть проблемы с доступом по сети.

Ссылки: