AI-driven подход в разработке: как перестроить процесс команды, а не просто подключить агента

Что такое AI-driven разработка

AI-driven development — это подход к организации процесса разработки, при котором программист на каждом этапе решает, какую часть работы выполнить самому, а какую делегировать ИИ.

Раньше разработчик получал от аналитика бизнес-требования и писал по ним весь код сам. Теперь он изучает требования и решает, какие части задачи передать ИИ, а какие сделать самому.

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

AI-driven подход не заменяет Agile или Scrum. Он добавляет к процессу команды набор правил: что меняется на этапе постановки задачи, кодирования, тестирования и ревью. Качество результата определяет не столько модель, сколько качество постановки задачи. Границы, данные и ограничения разработчик фиксирует в спецификации — документе, по которому ИИ пишет код, а команда потом проверяет результат. Разработчик, который составил такой документ четко, получает код, близкий к готовому.

Чем AI-driven разработка отличается от вайбкодинга и других похожих терминов

Термины AI-driven development, «вайбкодинг», spec-driven development ai и «агентная разработка» часто путают друг с другом. На деле в каждом подходе команда проверяет результат по-разному: где-то сверяет с самим кодом, где-то — со спецификацией, которую написали до начала работы.

Главное отличие AI-driven разработки от вайбкодинга — в роли разработчика. В вайбкодинге человек описывает результат словами и почти не участвует в решении: ИИ придумывает архитектуру сам. В AI-driven подходе разработчик заранее очерчивает границы задачи и передает ИИ только конкретные, четко описанные части.

Отдельно стоит развести AI-driven development с двумя похожими по названию, но не связанными областями.

1. AI-driven design — это применение ИИ в дизайне интерфейсов и в проектировании электронных схем.
2. AI-driven systems — термин из системной инженерии для автоматизации проектирования промышленных и инфраструктурных систем.

Оба термина не относятся к разработке программного обеспечения, о которой рассказываем в этой статье.

Почему AI-driven подход появился именно сейчас

1. Модели стали писать больше кода за один запрос. Раньше модель дописывала одну функцию или строку. Сейчас она выдает связный модуль системы: код, тесты к нему и обработку ошибок — за один запрос.
2. У роста возможностей моделей есть предел. Модель хорошо справляется с конкретной частью задачи, а на расплывчатый запрос про весь проект целиком выдает результат с багами. Разработчик просит поправить кнопку на форме — агент заодно переписывает систему авторизации, потому что сам додумал, что так лучше. Отсюда сдвиг в логике разработки: раньше единственной опорой служил код, теперь эту роль берет на себя спецификация — документ, который описывает, что система должна делать, до того как появился код.
3. Вендоры инструментов поддержали спецификации. С 2025 года крупные среды разработки одна за другой добавили работу по спецификациям: GitHub выпустил открытый набор инструментов Spec Kit, Amazon встроил такой же режим в свою среду Kiro. Экосистема вокруг спецификаций выросла быстро — от единичных экспериментов до нескольких конкурирующих инструментов за год.

Как устроена разработка с AI-driven подходом

Разберем, что происходит на каждом этапе — от появления задачи до релиза и обратной связи от пользователей.

Восемь фаз в этой таблице в индустрии называют AI-driven PDLC — жизненный цикл разработки от требований до мониторинга, где на каждом этапе есть роль и для человека, и для ИИ.

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

Что такое spec-driven development и почему он стал ядром подхода

Spec-driven development — это разработка, при которой разработчик или тимлид сначала описывает задачу в спецификации, а агент строго по ней пишет код.

Spec-driven development называют ядром AI-driven подхода неслучайно: без спецификации у разработчика, у агента и у проверяющего на ревью три разных представления об одной задаче. Со спецификацией тесты, ревью и метрики опираются на один документ, а не на абстрактные ожидания участников разработки.

Рабочая спецификация обычно описывает:

• Цель задачи — что система должна уметь после реализации. Например, пользователь получает уведомление об оплате в течение пяти секунд.
• Границы — какие возможности система не должна включать. Например, форма не хранит номера карт, для оплаты подключают внешний сервис.
• Данные и модели, с которыми работает решение, — например, личные данные пользователей или каталог из 10 000 товаров.
• Роли участников и права доступа — кто может создавать, читать, редактировать и удалять записи.
• Сценарии использования, включая нестандартные случаи — например, что показывать, если пользователь дважды нажал кнопку оплаты.
• Критерии приемки — по каким признакам поймут, что задача выполнена. Например, форма проходит 20 автотестов и не пропускает e-mail без специальных символов.
• Правила обработки ошибок и ограничения по технологическому стеку — например, какой текст показывать при сбое сервера и какие библиотеки нельзя использовать.

Как внедрить AI-driven подход в команде

Вот семь шагов, которые помогут команде протестировать AI-driven подход.

1. Зафиксируйте показатели команды до старта. Узнайте средний срок задачи от постановки до релиза, число возвратов кода после ревью и количество инцидентов после релизов. Через четыре-восемь недель сравните новые цифры с полученными — так вы поймете, стал ли процесс разработки быстрее и стабильнее на самом деле.
2. Выберите пилотную фичу с понятными границами. Возьмите одну конкретную функцию продукта, а не ядро системы и не всю разработку сразу — так проще заметить эффект и откатить решение, если понадобится.
3. Определите контур данных. Решите, какой код и какие данные можно передавать во внешние ИИ-сервисы, а какие нет, и зафиксируйте список в документе, открытом всей команде.
4. Свяжите спецификацию с проверкой кода. Напишите спецификацию на выбранную функцию так, чтобы критерии приемки на деле не пускали в релиз код, который им не соответствует, — иначе документ разойдется с кодом уже после первой правки.
5. Договоритесь о правилах ревью агентского кода. Зафиксируйте три конкретных правила. Например, каждое изменение размером больше 200 строк проверяют два разработчика, а не один, и агент переиспользует существующие компоненты проекта вместо того, чтобы писать код заново.
6. Назначьте ответственного за метрики. Пусть один из разработчиков раз в неделю сверяет цифры и следит, что команда соблюдает договоренности по ревью и контуру данных.
7. Примите решение через четыре-восемь недель. Сравните накопленные цифры с исходными и решите: внедрять подход в другие потоки задач, корректировать правила или отказаться.

Какие метрики показывают, что AI-driven подход работает

Команде стоит следить за несколькими показателями вместе, а не по отдельности.

• Время от постановки задачи до выхода в продакшен. Показывает, стала ли команда быстрее доводить изменения до пользователей, а не только быстрее писать код.
• Доля правок после ревью. Если агент часто выдает код, который приходится сильно переделывать, стоит пересмотреть спецификации или правила работы с ИИ.
• Частота релизов. Сколько раз в неделю или месяц команда выпускает изменения в продакшен.
• Стабильность релизов и доля откатов. Сколько релизов проходит без сбоев, а сколько приходится откатывать назад из-за ошибок.
• Время восстановления после инцидента. Сколько времени команда тратит на то, чтобы починить систему после сбоя.
• Доля задач без возврата на доработку. Сколько задач проходят весь цикл от постановки до релиза без дополнительных кругов правок.

Количество строк сгенерированного кода вводит в заблуждение: агент пишет тысячу строк за минуту, но это не значит, что тысяча строк решает задачу лучше, чем сто. Рост частоты релизов вместе с ростом числа откатов означает, что команда выпускает изменения быстрее, но теряет в стабильности.

Какие риски есть в AI-driven разработке

Шесть рисков встречаются чаще остальных — от роста технического долга до утечки данных.

1. Технический долг растет быстрее. Агент пишет код быстрее человека, и вместе с объемом растет число скрытых ошибок и уязвимых мест в системе. Снижают риск обязательное ревью, четкие архитектурные рамки для агента и лимит на размер одного изменения.
2. Решения становятся непрозрачными. Команде сложно понять, почему агент выбрал именно такое решение, если оно нигде не зафиксировано. Помогает утверждение решений в спецификации и в описании изменения на ревью.
3. Код расходится с задачей. ИИ заново интерпретирует требования на каждом шаге, и результат постепенно далек от того, что просил разработчик. Чтобы снизить риск, не забывайте сверять код со спецификацией по ходу работы.
4. Тестирование становится узким местом. Скорость генерации кода растет быстрее, чем процессы тестирования успевают под нее подстроиться. Помогают параллельный дизайн тестов и автоматизация проверок.
5. Дефекты сложно воспроизвести. Чтобы исправить баг, разработчик сначала должен повторить условия, при которых он возник. При агентной разработке это сложнее: AI мог принять решение, которое нигде не зафиксировано. Снижают риск логирование сессий агента и фиксация контекста, в котором он работал.
6. Есть риск утечки данных. Команде стоит заранее определить, что можно передавать во внешние сервисы. Например, код с персональными данными пользователей, ключами доступа или коммерческой логикой компании передавать нельзя, а обычный код интерфейса — можно.

Какие инструменты используют в AI-driven разработке

Разберем категории инструментов и вопросы, которые стоит задать перед выбором любого из них.

• Среда разработки с поддержкой спецификаций. Редактор кода или отдельная платформа, где разработчик пишет спецификацию, а инструмент помогает превратить ее в план задач для AI. Стоит проверить, умеет ли инструмент работать с командой одновременно, а не только с одним человеком.
• Инструмент для хранения правил и инструкций агента. Отдельный файл или сервис, где команда держит правила работы с агентом. Стоит проверить, хранятся ли эти правила прямо в репозитории вместе с кодом — так их проще контролировать и обсуждать на ревью.
• Инструмент для автоматизации тестов и статического анализа. Сервис, который прогоняет тесты и проверяет код на типовые ошибки после каждого изменения. Здесь важно, успевает ли инструмент проверять код с той скоростью, с которой агент его генерирует.
• Инструмент для подключения агента к рабочим системам команды. Обычно это делают через протокол вроде MCP — он дает агенту доступ к задачам в трекере и коду в репозитории без ручной передачи файлов. Стоит уточнить, можно ли ограничить агенту доступ только к тем системам, которые нужны для задачи.
• Способ размещения модели. Модель можно использовать в облаке, запускать локально на серверах компании или работать с ней в закрытом контуре без выхода в интернет. Перед выбором стоит спросить у поставщика, где физически хранятся обрабатываемые данные.

Как команде держать задачи, спецификации и обсуждения в одном месте

AI-driven процесс создает много документов: спецификации, планы, решения по ревью, результаты тестов. Если они разбросаны по разным сервисам, команда не может быстро найти, почему в прошлый раз выбрали именно такую архитектуру.

Собрать рабочий контур можно в Битрикс24:

• Задачи и проекты. Хранить спецификацию конкретной задачи вместе с историей правок и обсуждением.
• База знаний. Держать регламенты и шаблоны спецификаций в общем месте, а не в личных документах отдельных сотрудников.
• Чаты и видеозвонки. Обсуждать и фиксировать решения по ревью так, чтобы к ним можно было вернуться, а не искать в личной переписке.
• AI в пространстве для работы. Готовить черновики описания задачи, чтобы разработчик не начинал спецификацию с чистого листа.

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

Если рабочий контур команды пока разбросан по десятку чатов и таблиц, разумно начать с малого — перенести в одно место спецификации и задачи для одной пилотной фичи.

Когда AI-driven подход не нужен

• Разработчик пишет разовый скрипт или одноразовую автоматизацию. Он потратит время на спецификацию, но код больше никто не откроет и не будет дорабатывать — вложение не окупится.
• Команда решает исследовательскую задачу. Заранее неизвестно, каким должен быть результат, поэтому формальная спецификация только свяжет руки — разработчику проще пробовать разные варианты напрямую с AI.
• Команда из двух-трех человек работает над проектом всего месяц. Так настройка процесса не окупится — выгоду AI-driven подход дает на повторяющихся задачах, а не на разовых.
• Компания разрабатывает продукт с высокой ценой ошибки — например, медицинское или финансовое ПО. Здесь ошибка обходится дороже, чем выигрыш в скорости.
• В команде и без ИИ нет порядка в задачах и ревью. Искусственный интеллект здесь только усугубит уже существующий хаос.

Частые вопросы