В этой статье — реальный опыт команды targetai по внедрению вайб-кодинга: как сократить цикл разработки в 8–12 раз без потери качества. Поделимся цифрами, инструментами и подходом, который помогает избежать как отставания от конкурентов, так и погружения в «нейрослоп».
Мы работаем в продуктовой ИТ-компании, где основной продукт — платформа коммуникативных ИИ-агентов. Также у нас есть система голосовых тренажёров и омниканальная платформа автоматизации контакт-центров. Все решения поддерживают on-premise-установку, что накладывает жёсткие ограничения на используемые технологии.
Технологический стек:
- Python / Go для бэкенда
- React для фронтенда
- Микросервисная архитектура
- Открытые и проприетарные LLM-модели
- Продакшн: k8s, Helm, ArgoCD
- Observability: Victoria Metrics, Grafana, Alert Manager, Loki
Около полугода назад мы начали использовать вайб-кодинг для креативных экспериментов и быстрого прототипирования. Уже на ранних этапах продуктивность выросла в 3–4 раза.
Что такое вайб-кодинг?
Термин, популяризированный Карапатым, успел растянуться до бессмыслицы. Для одних — это любое использование LLM в разработке. Для других — полная передача контроля модели: разработчик описывает идею, а ИИ сам строит архитектуру и пишет код.
Мы под вайб-кодингом понимаем нечто среднее: инженер делегирует LLM значительную часть работы, но сохраняет контроль и инженерную ответственность.
Критики называют такой подход «нейрослопом» — код, полный скрытых багов, непредсказуемый и непригодный для продакшна. У этой позиции есть основания.
Основные проблемы:
- Траблшутинг: разработчик, не писавший код, окажется беспомощен при инциденте в 3 часа ночью.
- Архитектура: LLM генерирует локально работающие, но плохо масштабируемые решения.
- Производительность: модель не оптимизирует то, о чём её не спросили.
Но эти проблемы — не следствие использования LLM, а результат отсутствия чётких рамок: архитектурных, функциональных, инженерных. Проблема не в инструменте, а в неправильной постановке задачи.
Золотая середина: эффективность без хаоса
Реальный прирост — между «не пишу ни строчки» и «LLM только для автодополнения». Компетентный инженер задаёт стек, архитектурные принципы и требования. LLM реализует, человек контролирует.
Год назад разработчик сам детализировал задачу и передавал кусочки ИИ. Сейчас даже декомпозиция автоматизируется — благодаря скиллам.
Скиллы и агенты: как это работает
Скилл — это контекст, который задаёт агенту знания конкретной роли: продуктолога, архитектора, аналитика, специалиста по безопасности. В Cursor можно настроить глобальные скиллы: агент сам выбирает нужный, но можно и явно указать.
Например, вы пишете: «Хочу написать ТЗ». Агент подключает скилл бизнес-аналитика, задаёт уточняющие вопросы, формирует план. План передаётся другим агентам. Результат — структурированный, воспроизводимый процесс, а не код «из воздуха».
Сегодня уже существуют развитые экосистемы скиллов:
Инструменты, которые мы используем
Основные инструменты — Cursor и Claude Code. Codex от OpenAI используем редко, в исключительных случаях.
По моделям: claude-opus-4.6 от Anthropic стабильно превосходит GPT-5.x в задачах разработки, несмотря на бенчмарки OpenAI. Отдельно выделим Qwen Coder 235B — китайская модель, сравнимая с Claude Sonnet, активно догоняет лидеров.
Поддержка скиллов — стандартная функциональность современных IDE для вайб-кодинга.
Реальный пример: продукт за 4 недели
Первый продукт, разработанный с помощью агентов и скиллов, был готов за 4 недели. Без LLM на это ушло бы 6–12 месяцев. Оценка — не теоретическая, а основанная на аналогичных проектах.
На момент запуска у продукта ещё мало живых пользователей, поэтому объём доработок пока небольшой.
В разработке использовались следующие агентские роли (синонимы — «скилл» и «роль»):
- Продуктолог (создаёт PRD)
- Архитектор (по PRD формирует спеку, контракты, модель данных, миграции)
- Дизайнер (делает постановку для фронтенда)
- Бэкенд-разработчик (Python)
- Бэкенд-разработчик (Go)
- Фронтенд-разработчик
Каждый агент оставляет промежуточные артефакты. Например, PRD — выходной результат продуктолога. Это требует от разработчика чётко формулировать требования, что повышает зрелость процесса.
В условиях срочного дедлайна люди склонны пропускать этапы. Мультиагентный подход делает это невозможным: каждая фича оставляет след — артефакты, тест-кейсы, мануалы.
Кроме того, скиллы, основанные на лучших практиках, автоматически обеспечивают их соблюдение. В результате — высокая скорость без потери качества.
Как мы измеряем прогресс
Три ключевые метрики:
- Доля кода: соотношение строк, написанных человеком и моделью, смещается в сторону LLM.
- Объём делегирования: от технических подзадач — к end-to-end реализации сервисов по описанию.
- Lead time: время от постановки задачи до результата сократилось в разы.
«А почему не полная автономия?» Мы пробовали.
Цепочка «агент-продуктолог → архитектор → разработчик → ревьюер → тестировщик» выглядит красиво, но на практике каждое звено накапливает и усиливает ошибки предыдущего.
К третьему этапу отклонение от исходного замысла становится критичным, а ловить его некому. Разные подходы к промптингу не решают проблему — нет контрольной точки.
Результат: формально рабочий код, но хрупкое решение. Мы не отвергаем полную автономию навсегда, но сегодня инженер в роли оркестратора даёт более предсказуемый и сопровождаемый результат.
Наш путь: компромисс, который работает
Ни отказ от LLM, ни слепой вайб-кодинг не работают. Первое — медленно. Второе — создаёт долг, стоимость которого растёт со временем.
Золотая середина — инженер задаёт рамки, агент реализует, скиллы обеспечивают экспертизу — позволяет создавать за месяц то, на что раньше уходил год.
Тренд на скиллы развивается последние месяцы. Если он продолжится, порог входа в качественную разработку через LLM резко снизится — и это изменит рынок быстрее, чем многие ожидают.