Это не статья «что такое вайбкодинг» — для определения и инструментов есть отдельная страница про вайбкодинг. Тут — практика: где он работает, где нет, и что в реальности меняется в инженерной рутине.

Где AI-кодинг реально выигрывает

1. Перевод между языками и стеками

Самый стабильный кейс. Дать агенту 200 строк Python-скрипта и попросить эквивалент на Go — 95% попадание с первого раза. Перевод React-компонента в Vue, миграция тестов с Jest на Vitest, портирование curl-команды в Python requests — рутинная работа на минуты вместо часов.

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

2. Тесты, валидация, обвязка

Тесты — следующий стабильный кейс. Покрытие класса, генерация edge cases, моки, фикстуры. Особенно сильно AI выигрывает на параметризованных тестах: «напиши тестовые случаи для всех граничных значений этой функции». Человек устаёт думать об edge cases, модель — нет.

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

3. Багфиксы по точному описанию

Если вы можете чётко описать симптом и место («нажимаю кнопку X, ошибка Y в консоли, файл Z.tsx, строка 142 примерно»), AI-агент в 60–70% случаев найдёт и предложит фикс быстрее, чем вы сами добежите до этого места.

Тонкость: если описание плавающее («иногда не работает»), агент уходит в догадки и тратит токены впустую. Сначала локализуйте — потом отдавайте.

4. Документация и комментарии

README, ADR, doc-strings, ченджлоги, описания PR. Модели хорошо знают форматы, видят код, могут адаптировать тон. Слабое место — корректность примеров: их надо проверять руками, потому что AI любит приводить «правильно выглядящие» примеры, которых нет в реальности.

Где AI-кодинг бесполезен или вреден

1. Архитектурные решения с нуля

Попросите «спроектируй сервис уведомлений» — получите шаблонную микросервисную раскладку с Kafka и Redis, независимо от того, нужна она вам или нет. AI не знает ваших нагрузок, бюджета, команды, оперирует усреднёнными паттернами.

Тут он годится как brainstorm-партнёр (накидать варианты), но финальное решение — за инженером. Я видел проекты, где «архитектуру нарисовала модель», и через полгода команда переписывала её, потому что под реальные нагрузки она не легла.

2. UI/UX вкус

AI-сгенерированные интерфейсы узнаются за полсекунды: одинаковые градиенты, одинаковые карточки, одинаковая «правильность». Если вы делаете продукт, в котором интерфейс — конкурентное преимущество, дизайн полировать руками.

Это не значит «не используйте». Базовая разметка, типовые компоненты, доступность (a11y), responsive-сетки — отдавайте смело. А визуальный язык бренда — нет.

3. Криптография и безопасность

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

Аналогично с авторизацией: rate limiting, валидация ввода, защита от инъекций — AI пишет «учебниковый» код, который часто упускает специфику вашего стека.

4. Длинные многошаговые задачи без контроля

Дать агенту задачу на 4 часа и уйти — почти всегда плохая идея в 2026. Через пару часов модель «уходит в свою задачу»: правит файлы, которые не должна была трогать, переписывает то, что работает, не замечает простого подхода и строит свой.

Работает разделение: дать задачу на 20–40 минут с чёткими критериями «когда стоп». Прийти, проверить, дать следующий шаг.

Реальные кейсы из работы команды IT-ХОЗЯЕВА

Кейс 1: переписали Telegram-бот с polling на webhook

Задача: бот на Go (Telegram Bot API), нужно перевести с long polling на webhook с проверкой подписи. Около 800 строк кода затронуто.

  • Подход: Claude Code, одна сессия ~1,5 часа.
  • Результат: переписан, добавлены тесты на подпись, обновлён docker-compose. С первого раза не сработало (модель забыла про graceful shutdown), исправлено за 10 минут.
  • Без AI: оценочно 1–2 дня.
  • Что сэкономлено: ~80% времени, но 20% ушло на ревью и доводку.

Кейс 2: миграция базы данных на новую схему

Задача: добавить новую колонку с backfill для 50М строк в Postgres, без даунтайма.

  • Подход: Claude Code сгенерировал план в 5 шагов и SQL-скрипты.
  • Результат: план оказался шаблонным (lock-free через batch update), пришлось руками править под нашу нагрузку. Сами скрипты получились рабочие.
  • Без AI: 4–6 часов.
  • С AI: 2 часа, но 50% времени — это ревью и доработка плана.

Кейс 3: фронтенд-форма с валидацией и API-интеграцией

Задача: форма создания заявки на 12 полей, валидация, отправка на бэкенд, обработка ошибок.

  • Подход: Cursor + Composer.
  • Результат: форма за 40 минут, включая Tailwind-стилизацию по существующим компонентам. UX оказался скучный (одинаковые поля, без визуальной иерархии), пришлось дорабатывать руками 20 минут.
  • Без AI: 2–3 часа.
  • С AI: 1 час с дизайн-полировкой.

Кейс 4: попытка реализовать realtime-фичу без контроля

Задача: добавить чат с WebSocket в существующий продукт. Дали Claude Code задачу на ночь.

  • Результат: к утру был «работающий» чат, но без аутентификации, с in-memory хранилищем (а должен был быть Redis), без масштабирования.
  • Пришлось переписать 60% — модель сделала демо-уровень, а не продакшен.
  • Урок: для нетривиальной фичи нужен поэтапный контроль. Дать 1 час на «спроектируй интерфейсы и протокол», потом ревью, потом следующий час на реализацию.

Метрики продуктивности

Цифры, которые повторяются у инженеров, переходящих на вайбкодинг:

  • Рутинный код: ускорение в 3–5 раз стабильно. Если у вас рутины 50% — общий выигрыш ~2x.
  • Сложные задачи: ускорение 1,2–1,5x (за счёт документации, поиска по кодовой базе, генерации тестов). Главную часть работы всё равно делает человек.
  • Багфиксы: от –20% (если задача плохо локализована и AI уходит в догадки) до +3x (если описано точно).
  • Архитектура и дизайн: чистого ускорения нет, но качество brainstorm-фазы повышается.

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

Топ-5 ошибок начинающих вайбкодеров

  1. Принимают diff не глядя. «Работает же». Через месяц кодовая база — каша из несовместимых стилей, дубликатов и тонких багов.
  2. Не пишут инструкции для агента. Без CLAUDE.md / .cursorrules модель угадывает соглашения проекта по верхушке, и часто угадывает неправильно.
  3. Стучатся в модель за каждой строкой. Простые правки руками быстрее. AI имеет смысл, когда задача больше 10 строк или повторяющаяся.
  4. Игнорируют тесты. Без тестов вы не сможете проверить, что агент не сломал соседнюю фичу. Парадокс: AI пишет тесты быстро — заведите их.
  5. Доверяют ответам про индустрию и компании. Модель уверенно расскажет про процессы Yandex или Tinkoff — и наполовину выдумает. Факты о людях и компаниях — у людей.

Что отрабатываем на воркшопах

В IT-ХОЗЯЕВА каждую неделю проходит воркшоп по vibe coding: 1,5 часа, разбираем реальные задачи участников в Cursor и Claude Code, обсуждаем промпты, ошибки и хуки. Доступ — по подписке от 520 ₽/мес. Параллельно — закрытые AI-беседы, где обсуждаем свежие модели, MCP-серверы, продуктовые применения.

Если хотите глубже разобраться в инструментах — сравнение Cursor, Claude Code и Windsurf в отдельной статье.