В этой статье я расскажу о том, как не потерять голову от LLM-инструментов и при этом сократить цикл разработки в 8–12 раз без потери качества. Поделюсь реальными цифрами и подходом, апробированным моей командой в targetai.
Контекст
Я работаю в типовой продуктовой ИТ-компании, с соответствующими этому статусу задачами, процессами и подходами к разработке и эксплуатации. Ядром нашей продуктовой линейки является платформа коммуникативных ИИ-агентов. Есть еще несколько дополнительных продуктов — система голосовых тренажёров, а также омниканальная платформа автоматизации работы сотрудников контакт-центра, как в чате, так и в голосе. Кому интересны подробности — ссылка на сайт в описании профиля.
Технологически наши продукты реализованы на следующем стеке технологий:
-
Python / go для бэкэнда
-
React дляфронтенда
-
Микросервисная архитектура (критерии соответствия этому — отдельная большая тема, мы по крайней мере к этому стремимся 🙂
-
LLM-модели — используются как открытые, так и проприетарные
-
Прод — k8s, helm, ArgoCD
-
Observability стэк: Victoria Metrics, Grafana, Alert Manager, Loki
Важный момент — наши продукты должны обеспечивать возможность инсталляции в информационный контур клиента по модели on-premise. Это задаёт определённые рамки и ограничения в отношении решений, которые мы можем использовать под капотом.
Примерно с полгода назад мы в команде начали использовать вайб-кодинг с фокусом на креативные эксперименты с промптами и архитектурой для быстрого прототипирования новых фич агентов. По самым грубым подсчетам продуктивность выросла раза в 3-4.
Что это вообще за зверь такой?
Термин «вайб-кодинг» с легкой руки Карапатого уже стал настолько популярным, что успел растянуться до размытия смысла. Одни называют вайб-кодингом любое использование LLM в разработке — даже один запрос в день в Cursor — уже «вайб-кодинг» . Другие понимают под ним экстремальный сценарий: разработчик не пишет ни строчки вручную, а просто описывает желаемое приложение без архитектурных и алгоритмических деталей и итеративно получает результат от модели.
Второй вариант — не просто философия, это вполне реализуемо сегодня, и именно он провоцирует самые жёсткие споры. Далее, упоминая вайб-кодинг, я имею в виду нечто среднее: разработчик активно делегирует LLM растущую долю работы, но сам остаётся в контексте и сохраняет инженерную ответственность за результат.
Лагерь противников генерации кода часто апеллирует к понятию «нейрослоп» — якобы всё, что «выходит” из LLM — непредсказуемо, полно скрытых багов и непригодно для продакшна. Если разобраться, у этой позиции есть вполне конкретная фактическая база.
Первая проблема — траблшутинг. Разработчик, который не писал код сам и плохо в нём ориентируется, окажется беспомощным, когда что-то сломается в продакшне в три ночи. Вторая — архитектура: LLM без жёстких рамок склонна генерировать решения, которые работают локально, но плохо масштабируются и трудно расширяются. Третья — производительность: без явных требований к нагрузке модель не будет оптимизировать то, о чём её не спросили.
Все эти проблемы реальны. Но они возникают не из-за самого факта использования LLM — они возникают, когда изначально не заданы архитектурные рамки, требования по надёжности, доступности и стеку. На мой взгляд проблема не в инструменте, а в том, что его использовали без акцента на этапе постановки задачи.
Золотая середина, генерирующая результат
Есть пространство между «не пишу ни строчки сам» и «LLM только для автодополнения». Именно в нём находится реальный прирост эффективности. Компетентный инженер задаёт рамки: стек, архитектурные принципы, требования к надёжности — и дальше делегирует реализацию LLM-агенту. LLM пишет код, человек контролирует направление и принимает архитектурные решения.
Примерно год назад у нас типичный рабочий процесс выглядел так: разработчик декомпозировал задачу на детально описанные технические кусочки и подавал каждый ИИ-агенту. Это работало, но требовало значительной предварительной работы вручную. Сейчас эта предваряющая часть тоже автоматизируется — во многом благодаря механике так называемых скиллов.
Скиллы и агенты: как это работает на практике
Скилл — это по сути обеспечение агента знаниями для конкретной предметной области или функциональной роли. Владелец продукта, IT-архитектор, специалист по кибербезопасности, бизнес-аналитик — каждый скилл задаёт агенту нужный контекст, подтягивает релевантные стандарты и фреймворки. В Cursor могут быть заданы глобальные скиллы — они регистрируются один раз, после чего агент сам определяет, какой скилл подходит под текущий запрос. При этом остается возможность явно указать скилл для выполнения текущего запроса.
Ты пишешь «хочу написать ТЗ» — агент понимает, что здесь нужен скилл технического писателя или бизнес-аналитика, подключает его, проводит с тобой интервью, задаёт уточняющие вопросы и формирует план работы. Этот план дальше уходит к другим агентам. Человек без глубокого технического бэкграунда, используя правильно настроенные скиллы, получает на выходе структурированный и воспроизводимый результат — а не хаотичный код, сгенерированный «из воздуха».
На сегодняшний день уже собраны развитые экосистемы агентских скиллов. На мой взгляд особого внимания заслуживают следующие проекты:
Также наша компания активно применяет агентские скиллы для решения задач бизнес-процессов, прямо не относящихся к области разработки и эксплуатации. Однако данный опыт и сложности вокруг него достойны отдельной статьи, напишите в комментариях.
Инструменты: что используется у нас
Основные инструменты, используемые для разработки в targetai — Cursor и Claude Code. Codex от OpenAI набирает популярность в отрасли, но мы пока прибегаем к его использованию скорее в исключительных ситуациях (например, при изменении стратегии и критериев блокировки доступа к Claude Code).
По моделям: наш опыт устойчиво показывает, что claude-opus-4.6 от Anthropic опережает GPT-5.х в задачах разработки — несмотря на то что OpenAI периодически сообщает о более высокой позиции в специфических бенчмарках. Отдельно стоит отметить Qwen Coder 235B — китайская модель сопоставима с Claude Sonnet по ряду показателей и активно догоняет лидеров. Что будет к концу года — вопрос открытый. Подключение агентских скиллов уже является стандартом для сред разработки, поддерживающих вайб-кодинг. Это коробочная функциональностью любого их упоминаемых выше инструментов.
Реальный пример из нашей жизни: продукт за 4 недели
Первый продукт, полностью разработанный через модель скиллов и агентов, был готов за 4 недели силами одной команды. Без LLM та же команда потратила бы на него 6–12 месяцев. Это не теоретическая оценка — это оценка по аналогичным задачам, которые решались раньше.
Здесь необходимо сделать оговорку — на настоящий момент у данного ИТ-продукта только появляются первые живые пользователи. Соответственно — объем задач-доработок, получаемых непосредственно от пользователей, на настоящий момент незначительный.
Именно при разработке данного продукта в полный рост использовался предлагаемый подход. В ходе разработки были выделены следующие агентские роли (здесь и далее подразумеваем тождественными понятия “скилл” и “роль”):
-
Продуктолог (создаёт PRD)
-
Архитектор (берёт PRD, пишет спеку для бэка, контракты, модель данных, миграции, интеграции, ивенты)
-
Дизайнер (берёт PRD, пишет постановку для фронта)
-
Бэкэндер Python
-
Бэкэндер Go
-
Фронтендер
Разбиение агентов на делаем необходимым наличие промежуточных артефактов. Простой для понимания пример — это PRD (Product Requirements Document) — это артефакт, являющийся основным выходным для агента-продуктолога. Это требование автоматически приводит нас в состояние, когда каждая итерация работы любого агента оставляет явные следы.
И… задает такие рамки, где разработчик вынужден фокусироваться на максимально подробном описании требований к результату! Подобное требование является обязательным атрибутом достаточно зрелого процесса разработки. Что присуще и не агентской разработке ИТ-решения. НО — когда задача вдруг сваливается на команду (людей) в режиме “должно быть в проде ещё вчера” — людям обычно свойственно выхолостить некоторые этапы в угоду скорости реализации. Мультиагентный же подход делает это безальтернативно обязательным! Таким образом, данный подход ставит разработчиков в условия, когда любая фича оставляет набор необходимых артефактов. Более того — это переориентирует разработчика на фокус именно на этапе проектирования.
Наличие качественных артефактов позволяет в последующем иметь гораздо более понятную картину влияния предлагаемых изменений на уже существующую функциональность. Кроме того — при таком подходе условно автоматически появляются такие артефакты как тест-кейсы и пользовательский мануал по работе с какой-то фичей. В то же время — создание скиллов агента на основании лучших отраслевых практик (упомянутые выше репозитории наборов агентских ролей) позволяет сразу обеспечить следование этим практикам.
Как результат — мы получаем огромный буст к скорости разработки, нивелируя при этом недостатки, обычно присущие выборочному использованию ИИ-агентов для решения узкой технической задачи. Что и позволило нам получить не прототип, а готовое к нагрузке решение в пределах 1 месяца.
Как мы измеряем изменения
Есть три метрики, которые наглядно отражают суть сдвига. Первая — доля строк кода, написанных человеком против написанных моделью: соотношение стабильно смещается в сторону LLM. Вторая — область задач, делегируемых модели: год назад это были точечные технические подзадачи, сейчас — end-to-end «сделай мне сервис с такими-то требованиями». Третья и самая показательная — lead time решения задачи от постановки до готового результата.
«А почему не полная автономия?» Мы пробовали. Цепочка «агент-продуктолог → агент-архитектор → агент-разработчик → агент-ревьюер → агент-тестировщик» выглядит красиво на схеме, но на практике каждый следующий агент наследует и усиливает ошибки предыдущего.
К третьему звену накапливается отклонение от первоначального замысла, которое никто не ловит, потому что ловить некому. Да, мы пробовали разные подходы к промптингу проблема не в конкретной реализации, а в отсутствии контрольной точки между звеньями.
Результат формально рабочий код собирается, тесты проходят но решения, принятые полностью без человека, оказываются хрупкими. Мы не отвергаем полную автономию принципиально, мы попробовали и увидели, что сегодня инженер в роли оркестратора даёт более предсказуемый и сопровождаемый результат.
И мы не перестаём проверять гипотезы и подходы при работе с агентами
Наш компромиссный путь
Ни полный отказ от LLM, ни бездумный экстремальный вайб-кодинг не дают хорошего результата. Первый оставляет вас медленнее конкурентов. Второй создаёт долг, работа над которым имеет возрастающую со временем стоимость . Золотая середина — инженер задаёт рамки, агент реализует, скиллы обеспечивают качество предметной экспертизы — позволяет создавать за месяц то, на что раньше уходил год.
Тренд со скиллами начал активно развиваться буквально в последние месяцы. Если он продолжится, порог входа в качественную разработку через LLM будет снижаться — и это изменит расстановку сил быстрее, чем многие ожидают.
ссылка на оригинал статьи https://habr.com/ru/articles/1026182/