Что такое вайбкодинг
Определение простое: разработка IT-продуктов — программ, сайтов, приложений — с помощью естественного языка. Вы не пишете код, а описываете агенту, что нужно сделать, и он выполняет действия за вас.
За два года подход прошёл путь от «попроси чат написать функцию и скопируй результат» до полноценного прикладного инструмента, встроенного в среду разработки.
Чем агент в IDE отличается от чата в браузере
Это ключевое различие, которое стоит понять до начала работы.
Внешний чат-бот напишет код, ответит на вопрос и сформирует документацию — но он не находится в контексте вашего проекта. Агент, встроенный в редактор, всегда работает в контексте текущей директории: он видит проект целиком (или считывает его по частям, если проект большой), анализирует связи между файлами и понимает, что в нём происходит.
Второе отличие — отсутствие ручной работы. Агент сам меняет файлы, сам выполняет команды в терминале, сам запускает код. Вам не нужно копировать фрагменты туда-обратно: изменения предлагаются целиком, по аналогии с Git — принять всё или отменить.
При работе через SSH на внешних dev-окружениях агент под вашими правами может управлять базой данных, выполнять SQL-запросы, читать логи через Unix-команды и заниматься отладкой.
Инструменты
Cursor — самый распространённый вариант. Привычен разработчику, который уже работал с редакторами такого типа, и содержит под капотом все популярные модели. Есть бесплатная версия с ограниченным пакетом запросов, платная за $20 в месяц и тариф за $200 для активного использования.
GitHub Copilot — продукт Microsoft, интегрируется в VS Code. Из России без VPN может не запуститься: авторизация идёт через GitHub, и на этом этапе возникают конфликты.
Claude Code — терминальная среда, работающая на моделях Claude. Один из участников эфира перешёл на неё, продолжая запускать из того же Cursor.
MCP-серверы: что это и нужны ли они
Model Context Protocol — связующее звено между агентом и внешней постоянно активной средой. Через MCP-сервер агент получает доступ к боевому API, базе данных, большим массивам документации, почте или панели управления серверами.
Отдельно полезен браузерный MCP: он позволяет агенту не только написать код, но и открыть получившуюся страницу, посмотреть на неё «глазами», сделать скриншот и самостоятельно оценить, выполнена задача или нет.
Честный вывод обоих участников разговора: на практике MCP используется мало. Разработчику проще попросить агента выполнить консольную команду или HTTP-запрос напрямую — доступ к терминалу закрывает большинство задач. А индексация документации по ссылкам сейчас встроена в Cursor и отдельного сервера уже не требует.
Как выглядит рабочий процесс
Ключевая практика, на которой сходятся оба участника, — сначала план, потом код.
- Ставите верхнеуровневую задачу и явно просите не писать код, а сначала проанализировать текущую кодовую базу.
- Просите агента задать уточняющие вопросы. Отвечаете на них.
- Агент составляет план действий. Вы его подтверждаете, корректируете или даёте дополнительные вводные.
- Только после утверждения плана даёте команду выполнять.
- Валидируете результат.
Формулировка, с которой начинается работа: «Отвечай словами, код не пиши, задай вопросы».
Контекстное окно
У модели есть ограниченный объём информации, который она способна удерживать одновременно, — чаще всего порядка 200 тысяч токенов. Это своего рода оперативная память: всё, что не помещается, вытесняется.
Отсюда практические следствия:
- Не перегружайте контекст уточнениями. Лучше довести фичу до конца и при необходимости откатиться через checkpoint.
- Давайте точный контекст. Если дорабатываете конкретный дашборд — сразу укажите нужный файл, иначе агент будет несколько минут анализировать проект с нуля.
- Когда агент начинает откровенно буксовать — сбросьте контекст и начните в новом окне. Способ грубый, но рабочий.
Обратная сторона: каждое новое окно — это чистый лист. Агент не помнит ничего о проекте, над которым вы вместе работали неделями.
Где вайбкодинг работает точно
Сценарии, в которых соотношение трудозатрат к результату несопоставимо с ручной работой.
Базовые DevOps-задачи
Раньше на это уходили деньги на стороннего специалиста по ставке около 3000 рублей в час. Сейчас необходимость в этом для базовых операций отпала.
Как это выглядит: арендуете чистый VPS, получаете root-доступ, подключаетесь к серверу по SSH прямо из редактора и описываете задачу — поднять веб-сервер, установить Python и нужные библиотеки под конкретную задачу. Сюда же относятся написание shell-конфигов для последовательных операций и настройка Nginx или Apache.
Второй участник подтверждает практику: скрипты базовой настройки сервера (создание пользователя, настройка firewall, установка Nginx и Docker) пишутся один раз, валидируются вручную и дальше переиспользуются из проекта в проект как заготовка.
Работа с популярными CMS
Cursor из коробки умеет работать с WP-CLI, что даёт полное покрытие функциональности WordPress: работа с базой данных, отладка, интеграции. Отдельное преимущество — агент может исполнять PHP-файлы через консоль и сам выводить результаты по бэкенду, что радикально упрощает поиск ошибок.
Парсеры и скрипты
Парсеры пишутся отлично, чаще всего на Python. Сюда же:
- скрипты миграции данных (например, перенос номенклатуры из 1С, где характеристики товара нужно из отдельных сущностей превратить в часть номенклатуры);
- смена формата вывода данных — из XML в JSON и обратно;
- cron-скрипты и циклические операции.
Бэкенд на популярных стеках
Написание REST-эндпоинтов, особенно по фильтрам и небольшим операциям, отладка, документация, рефакторинг, автотесты. По оценке из эфира, до 60% бэкенд-задач среднего разработчика можно существенно разгрузить.
Важная оговорка про стек. Качество результата прямо пропорционально объёму обучающих данных. WordPress, TypeScript, Laravel — огромные сообщества, качественная документация, множество примеров, всё работает хорошо. Специфичные российские платформы вроде 1С-Битрикс — заметно хуже, потому что сообщество ограничено и примеров качественного исполнения меньше.
Типовые сущности по аналогии
Самый надёжный сценарий для клиентских проектов. Если в проекте уже есть структура — контроллеры, модели, сервисы — и нужно добавить новую сущность по образцу, задачу стоит отдавать агенту целиком. Он проанализирует проект, увидит принятые в нём соглашения и сделает по аналогии с высокой вероятностью пригодного для продакшена результата.
Ограничения, о которых нужно знать
Нейросеть не умеет вёрстку
Это главное ограничение, и оно принципиальное.
Причина не в качестве кода, а в расхождении понимания результата. Для разработчика результат вёрстки — масштабируемая дизайн-система на переиспользуемых компонентах. Агент же сделает каждую кнопку отдельным классом и жёстко закодирует макет: код будет выглядеть аккуратно, но при переносе или масштабировании компонента вы неизбежно упрётесь в рефакторинг.
Практический вывод, прозвучавший в эфире: хорошие верстальщики останутся востребованы надолго, и фронтендерам стоит вспомнить, чем grid отличается от flexbox.
Обходной путь, который используют оба участника: брать готовые библиотеки компонентов, переиспользовать и слегка трансформировать их. UX получается приличным сразу, UI дошлифовывается вручную.
Плохо работают и фронтенд-операции, завязанные на взаимодействие с интерфейсом: валидацию агент напишет, а анимацию — нет.
Нейросеть не понимает, зачем
Она понимает задачу только в момент, когда её получила. Довести до конца конкретную фичу — да. Понять замысел продукта, который вы держите в голове, — нет.
Отсюда правило: хороший вайбкодинг — максимально декомпозированный вайбкодинг. Нельзя выдать большое ТЗ и уйти пить кофе. Нужно вычленять часть функциональности и делать её в отдельном чате.
Проект деградирует по мере роста
Знакомая обоим участникам динамика: агент нормально доводит проект от небольшого до среднего, а дальше работать становится всё сложнее. Он дольше думает, каждый промпт требует заново поглощать контекст, качество падает.
Реальный кейс: чекаут на WooCommerce
История из коммерческой практики, показательная целиком.
Исходная ситуация. Разработчик написал чекаут плохо и ушёл с проекта. Срок сдачи близко. Подхватить задачу тяжело: чекаут имеет много взаимосвязей — сессия, мини-корзина, валидация полей, адреса доставки.
Что было сделано. Агента попросили снести всю логику старого чекаута — JS, PHP, вёрстку, шаблоны страниц. Справился. Затем — написать страницу оформления заказа с отдельным шаблоном, полями ввода, валидацией, способами оплаты и доставки.
Результат. Страница появилась за пару минут и на 90% соответствовала ожиданиям по функциональности. Ещё 5–6 промптов довели её до готовности.
Передача во фронтенд. Дальше — интересный приём: фронтенд-разработчику передали задачу удалить все стили, написанные нейросетью, оставив классы (агента заранее попросили именовать их по БЭМ, как принято в проекте), и перенести на готовый бэкенд собственную вёрстку.
Где всё пошло не так. При функциональном тестировании выяснилось, что один модуль работает не так. Попытки исправить это промптами приводили к тому, что агент менял всё подряд, трогал множество файлов и не добивал до нужного результата. Несколько дней ушло на то, чтобы понять, где именно он ошибся, — безрезультатно.
Пришёл разработчик и нашёл проблему сразу: одна маленькая функция теряла значение в массиве, который должен был возвращать бэкенд.
Вывод из кейса. Проект сдали, но часть функциональности пришлось переписать руками. Код, написанный нейросетью, формально соответствует стандартам, прокомментирован и задокументирован — и при этом плохо поддерживается человеком. Иногда нужно именно разработческое чутьё.
Внутренние продукты против клиентских
Разграничение, к которому пришли оба участника, — самое практичное, что есть в этом разговоре.
| Клиентские проекты | Внутренние инструменты | |
|---|---|---|
| Что отдавать | Только рутину: типовые сущности по аналогии, CRUD, парсеры, скрипты, отладка | Практически всё |
| Контроль | Жёсткая валидация каждого результата | Можно не изучать реализацию досконально |
| Фронтенд | Не экспериментировать | Готовые библиотеки компонентов |
На внутренних задачах вайбкодинг раскрывается полностью. Оба участника пишут таким образом дашборды, отчёты, календари ресурсного планирования, дашборды рентабельности проектов, графики утилизации часов в реальном времени. Типичный подход — скормить агенту OpenAPI-документацию используемого SaaS-сервиса и писать поверх неё нужные надстройки.
Цена такого подхода тоже понятна: дашборд собирается за полчаса, но если его захочется развивать, придётся потратить существенно больше времени на приведение кода в поддерживаемый вид.
Главная ловушка — жадность до результата
Самое ценное наблюдение эфира сформулировано так:
Мы настолько поражаемся скорости результата, что становимся жадными до него. И эта жадность до кода, нежелание декомпозировать и подходить к процессу с умом, разрушает архитектуру.
У обоих участников есть опыт, когда большой объём, написанный вайбкодингом, потом несколько дней стабилизировали, потому что всё разваливалось.
Противоядие — регулярная уборка. Вы можете за два часа сделать больше, чем за неделю обычной разработки, но нужно осознанно взять паузу и проверить, что получилось: пройтись по проекту вместе с агентом, наложить собственный опыт на его анализ, составить план того, что стоит улучшить, и навести порядок. Если это делать — результат будет production ready. Если полагаться только на скорость — получите многодневную боль.
Спор о деградации
Внутри команды возник показательный конфликт: талантливая разработчица отказывалась использовать агентов, аргументируя тем, что это ведёт к деградации и потере навыка писать код.
Позиции обеих сторон в эфире признали обоснованными.
За осторожность: нейронные связи программиста строятся именно потому, что он много думает и выстраивает логику в голове. Если за него думает модель, этот процесс останавливается. Прикладной аргумент от зрителя: на собеседованиях люди по-прежнему решают технические задания вручную — потеряв навык, вы не найдёте работу.
За внедрение: тот, кто понимает конечный результат, добивается его через агента быстрее и перестаёт зависеть от конкретного языка. Парсер на Python пишется, даже если вы Python никогда не трогали.
Итоговая формулировка, с которой согласились обе стороны: сейчас индустрия находится на стыке технологий, и каждому разработчику нужно найти свой баланс между ручным кодом и агентом как прикладным инструментом. Панацеей для профессионального роста вайбкодинг не является.
Что будет с рынком
Прогноз участников: в перспективе пяти лет вайбкодинг станет стандартом разработки. Ручной труд не исчезнет, но заметно сократится для базовых линейных операций и junior-грейдов.
Дальше включится экономика. Когда инструментами начнут активно пользоваться все, появится демпинг: задача, которая стоила восемь часов, делается за час — и рано или поздно за неё начнут платить как за час.
Контраргумент, который стоит держать в голове тем, кто работает в аутсорсе:
Бизнес приходит к производителю, потому что тот владеет процессами. Клиенту не важен стек — он платит за результат. А результат достигается процессом: менеджментом, зонами ответственности, тестированием итогового продукта.
Проблема, из-за которой заказывают разработку, никуда не делась: клиент делегирует головную боль. Рынок перетрясёт, стандарты поднимутся — как это происходило при появлении любой новой технологии. Адаптируются те, кто внедряет инструменты раньше остальных.
Отдельно про геймдев. Оценка лидов направления однозначная: делать игры нейросети не умеют. С графикой они нормально не работают, а в играх на 90% решают арт-дирекшн и геймдизайн, и только потом механики. Всплеска инди-игр по аналогии с прошлыми волнами ждать не стоит — игры делают энтузиасты, и душу в них модель не вложит.
Безопасность: что можно отдавать агенту
Вопрос от зрителя: насколько безопасно давать агенту доступ ко всей кодовой базе.
Позиция, прозвучавшая в эфире, прагматична: для типового сайта на популярной CMS риск утечки чего-то по-настоящему ценного невелик, и рефлексировать по этому поводу большого смысла нет.
Здесь стоит добавить необходимую оговорку. Отсутствие интереса со стороны разработчиков модели — не единственный вектор риска: ключи и доступы попадают в историю запросов, в логи, а иногда и в репозиторий вместе с кодом. Разумная практика не требует паранойи и сводится к малому — держать секреты в переменных окружения, а не в коде, и не отправлять в контекст боевые доступы к продакшену. Для всего остального кодовая база действительно скармливается спокойно.
Коротко
- Вайбкодинг — прикладной инструмент, а не замена разработчику. Эффективно вайбкодит тот, кто понимает, какой результат ему нужен.
- Планирование до кода — единственный рабочий режим. Сначала анализ и вопросы, потом план, потом реализация.
- Бэкенд на популярных стеках, DevOps-рутина, парсеры, скрипты и типовые сущности — отдавайте смело.
- Вёрстка, интерфейсные взаимодействия и архитектурные решения — оставляйте людям.
- На клиентских проектах — только рутина. Эксперименты — на внутренних инструментах и пет-проектах.
- Убирайте за агентом. Скорость без последующего наведения порядка превращается в неподдерживаемый код.
Материал подготовлен по видео We Wizards и Oxem «Вайбкодинг — зло или новое золото?».
