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

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

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

В этой статье разберём, что означает термин AI-driven, чем такой подход отличается от обычной автоматизации и классического SDLC, как работают двухконтурные и трёхконтурные модели разработки, зачем нужна спецификация, что такое SDD, почему контекст приходится разделять между агентами и откуда берётся «экономика токенов». Отдельно рассмотрим примеры решений на рынке: Digital Q от Диасофт, Platform V от СберТех и ELMA365 от ELMA.

Что такое AI-driven

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

AI-driven — это не синоним «мы подключили чат-бота к IDE». Это организационная и технологическая модель, в которой процессы изначально проектируются с учётом возможностей ИИ.

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

Понятие	Что находится в центре	Роль ИИ	Типичный результат
Обычная автоматизация	Заранее заданный алгоритм	Выполняет формальные правила	Стабильная повторяемая операция
AI-assisted разработка	Работа специалиста	Помогает написать, найти или объяснить	Фрагмент кода, подсказка, анализ
AI-driven разработка	Весь жизненный цикл продукта	Участвует в анализе, проектировании, реализации и проверке	Связанный набор артефактов и решений
Автономная разработка	Минимальное участие человека	Самостоятельно выполняет цепочку операций в заданных рамках	Изменение продукта с автоматическими проверками

Принципы

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

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

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

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

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

• Человекоцентричность: ИИ помогает принимать решения, но не отменяет ответственность владельца продукта и технических специалистов.
• Контрактность: функции, сервисы и агенты взаимодействуют через понятные интерфейсы и форматы данных.
• Наблюдаемость: сохраняются история изменений, запросы к моделям, результаты проверок и причины отклонения решений.
• Идемпотентность: повторный запуск операции не должен разрушать уже корректно выполненную работу.
• Ограниченность полномочий: агент получает доступ только к тем данным и инструментам, которые нужны ему для конкретной роли.
• Постепенная автономность: сначала автоматизируются безопасные операции, а затем, после накопления статистики, расширяются права агента.

Принцип	Практический смысл	Что произойдёт без него
Работа от спецификации	ИИ получает проверенное описание задачи	Генерация догадок и несогласованных функций
Разделение ролей	Каждый агент работает в ограниченной области	Потеря контекста и конфликт рекомендаций
Контроль качества	Результат подтверждается тестами и ревью	Ошибки доходят до эксплуатации
Безопасность по умолчанию	Доступы и действия ограничены	Утечки данных и опасные изменения
Наблюдаемость	Можно восстановить ход работы ИИ	Невозможно объяснить происхождение результата
Экономичность	Контекст и вызовы моделей оптимизируются	Непредсказуемый рост расходов

Пример 1. Задача для AI-driven команды

Плохо:
«Сделай модуль скидок для интернет-магазина».

Лучше:
Цель: рассчитывать скидку для зарегистрированного клиента.
Ограничения: скидка не суммируется с промокодом; максимум — 20%;
Источник данных: Customer API, поле loyaltyLevel.
Проверка: 12 сценариев, включая возврат товара.
Результат: спецификация, API-контракт, реализация, тесты, документация.

Так агент получает не только просьбу написать код, но и критерии, по которым можно проверить правильность работы.

Расшифровка и перевод

Термин AI-driven состоит из двух частей. AI — Artificial Intelligence, то есть «искусственный интеллект». Driven переводится как «управляемый», «движимый» или «основанный на». Поэтому буквальный перевод можно передать как «управляемый искусственным интеллектом» или «развиваемый на основе ИИ».

Однако буквальный перевод не всегда точно передаёт смысл. В русском языке формулировка «управляемый ИИ» может создать впечатление, будто люди полностью устраняются из процесса. На практике речь чаще идёт о модели, где ИИ становится ведущим инструментом выполнения и координации значительной части операций, но цели, ограничения и ответственность задаёт организация.

Английская формулировка	Возможный перевод	Когда уместен
AI-driven development	Разработка на основе ИИ	Нейтральный вариант для технического текста
AI-powered development	Разработка с использованием ИИ	Когда нужно подчеркнуть усиление возможностей команды
AI-assisted development	Разработка при поддержке ИИ	Если ИИ остаётся вспомогательным инструментом
AI-native development	Изначально ориентированная на ИИ разработка	Когда процессы и архитектура строятся вокруг ИИ с самого начала
Agentic development	Агентная разработка	Когда работу выполняют автономные или полуавтономные агенты

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

Пример 2. Разница между AI-assisted и AI-driven

AI-assisted:
Разработчик пишет:
«Создай SQL-запрос для отчёта по заказам за месяц».
ИИ предлагает запрос, человек проверяет и вставляет его в проект.

AI-driven:
Система получает утверждённую спецификацию отчёта, сама:
1. формирует модель данных;
2. предлагает API-контракт;
3. создаёт SQL и тестовые данные;
4. запускает проверки производительности;
5. формирует запрос на ревью;
6. публикует результат только после прохождения контрольных условий.

Простыми словами

Если объяснять без терминов, AI-driven разработка — это когда команда строит работу так, чтобы искусственный интеллект мог последовательно помогать создавать продукт от идеи до эксплуатации. Не просто «написать кусок программы», а понять задачу, задать вопросы, предложить решение, выполнить его, проверить и объяснить, что получилось.

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

Вопрос обычного читателя	Короткий ответ
ИИ сам придумывает продукт?	Может предложить идеи, но бизнес-цель и приоритеты должен определить человек.
ИИ полностью заменяет разработчиков?	Нет. Он меняет набор задач и повышает требования к постановке, проверке и архитектуре.
Можно ли просто подключить одну модель?	Для эксперимента — да. Для корпоративной работы нужны процессы, доступы, тесты и контроль.
Код всегда получается правильным?	Нет. Модель может ошибаться, придумывать несуществующие API и пропускать крайние случаи.
В чём основной выигрыш?	В сокращении времени между замыслом, проверкой решения и рабочей реализацией.

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

Особенности подхода + примеры из практики

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

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

Эти изменения особенно заметны в крупных организациях. В небольшом проекте разработчик может держать большую часть картины в голове. В корпоративной системе есть десятки интеграций, регламенты безопасности, устаревшие модули, разные команды и требования к аудиту. Здесь случайная генерация кода быстро становится источником технического долга.

Область	Классическая разработка	AI-driven разработка
Постановка задачи	Текстовое описание или устная договорённость	Структурированная спецификация с критериями проверки
Реализация	Преимущественно ручное программирование	Генерация, трансформация и ручная доработка
Тестирование	Часто начинается после разработки	Формируется параллельно с требованиями
Документация	Нередко запаздывает	Может создаваться как часть рабочего процесса
Коммуникация	Встречи, задачи, документы	Люди плюс агенты с формальными ролями
Контроль	Ревью кода и ручное тестирование	Набор автоматических и экспертных проверок

AI SDLC

AI SDLC — это переосмысление жизненного цикла разработки программного обеспечения с учётом активного участия искусственного интеллекта. В классическом SDLC обычно выделяют анализ, проектирование, разработку, тестирование, релиз и сопровождение. В AI SDLC эти этапы не исчезают, но становятся более цикличными, автоматизированными и связанными через спецификации.

Важная особенность — возможность запускать несколько рабочих потоков параллельно. Пока один агент уточняет требования, другой анализирует существующий код, третий подготавливает тестовые сценарии, а четвёртый оценивает риски. Однако параллельность не должна превращаться в соревнование независимых фантазий: результаты агентов необходимо синхронизировать через единые артефакты.

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

СберТех предлагает двухконтурную разработку AI-disrupt SDLC. В этой модели выделяются контур замысла и контур реализации. Первый отвечает за понимание бизнес-проблемы, целей, ограничений, требований и критериев успеха. Второй превращает согласованный замысел в архитектуру, код, тесты и работающий продукт.

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

Диасофт описывает трёхконтурную разработку, где перед контуром замысла и контуром реализации добавляется Discovery Loop. Этот контур предназначен для исследования: анализа предметной области, выявления потребностей, поиска вариантов, проверки гипотез и уточнения того, какую именно проблему стоит решать.

Модель	Контуры	Главный акцент	Когда особенно полезна
Классический SDLC	Анализ — проектирование — разработка — тестирование — эксплуатация	Последовательность этапов	Стабильные задачи с хорошо известными требованиями
AI-disrupt SDLC СберТех	Замысел — реализация	Разделение бизнес-идеи и технического исполнения	Быстрая разработка и контроль соответствия исходной цели
Трёхконтурная модель Диасофт	Discovery Loop — замысел — реализация	Исследование до фиксации решения	Новые продукты, сложные домены и неясные требования
Агентный SDLC	Набор циклов между специализированными агентами	Распределение задач и автоматические проверки	Большие проекты с множеством повторяемых операций

Пример 3. Трёхконтурная работа над функцией

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

Контур замысла:
Цель — увеличить долю завершённых заявок на 10%.
Решение — сохранение черновика и понятный индикатор этапов.
Метрика — completion rate за 30 дней.

Контур реализации:
Создать Draft API, изменить интерфейс формы, добавить события аналитики,
написать тесты восстановления черновика и провести A/B-проверку.

Для практического внедрения AI SDLC полезно определить контрольные точки. Например, агент может самостоятельно подготовить черновик требования, но не должен переводить его в разработку без подтверждения владельца продукта. Код может быть сгенерирован автоматически, но попасть в основную ветку только после прохождения тестов, статического анализа и проверки безопасности.

1. Зафиксировать бизнес-проблему и ожидаемый результат.
2. Провести исследование данных, пользователей и ограничений.
3. Сформировать и согласовать спецификацию.
4. Разделить работу между ролями и агентами.
5. Сгенерировать архитектурные и программные артефакты.
6. Проверить результат на функциональность, безопасность и стоимость.
7. Выпустить изменение по управляемому процессу.
8. Собрать обратную связь и обновить контекст проекта.

В центре внимания — спецификация

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

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

Спецификация — это не бюрократическая прослойка между идеей и кодом, а интерфейс взаимодействия людей и AI-агентов. Чем точнее этот интерфейс, тем меньше места остаётся для догадок модели.

В рамках такого подхода часто используют SDD — Specification-Driven Development, или «разработку, управляемую спецификацией». В SDD спецификация становится источником истины для последующих этапов. Из неё могут выводиться API-контракты, модели данных, тесты, документация и задачи для агентов.

SDD не означает, что документ нельзя менять. Напротив, спецификация должна эволюционировать вместе с пониманием продукта. Но изменение требований должно быть видимым: обновляется версия, фиксируется причина, пересматриваются зависимые тесты и повторно проверяется реализация.

Элемент спецификации	На какой вопрос отвечает	Что может сгенерировать ИИ
Цель	Зачем нужна функция	Формулировку результата и варианты метрик
Пользовательский сценарий	Кто и как будет использовать решение	Сценарии, альтернативные ветки, вопросы
Бизнес-правила	Какие условия обязательны	Таблицы решений, проверки и тестовые случаи
Границы	Что не входит в задачу	Контроль объёма и предупреждения о выходе за рамки
Нефункциональные требования	Какими должны быть скорость, надёжность и безопасность	Чек-листы и сценарии нагрузочного тестирования
Критерии приёмки	Как доказать, что задача выполнена	Автоматические тесты и отчёты проверки

Пример 4. Минимальная SDD-спецификация

Функция: восстановление пароля по электронной почте.

Цель: пользователь должен восстановить доступ без обращения в поддержку.

Правила:
— ссылка действует 30 минут;
— повторный запрос делает предыдущую ссылку недействительной;
— система не сообщает, зарегистрирован ли адрес;
— пароль должен соответствовать политике сложности.

Критерии приёмки:
— просроченная ссылка отклоняется;
— повторное использование ссылки невозможно;
— ответ одинаков для существующего и несуществующего адреса;
— событие восстановления записывается в журнал безопасности.

Хорошая SDD-спецификация должна быть удобна одновременно для трёх сторон: бизнеса, разработчиков и машинных агентов. Бизнесу нужен понятный результат, инженерам — точные контракты и ограничения, агентам — структурированный материал без неоднозначных формулировок.

Одна из распространённых ошибок — описывать только положительный сценарий. Например: «пользователь загружает документ, система его обрабатывает». Для реальной системы важны также пустой файл, неподдерживаемый формат, повторная загрузка, слишком большой размер, сбой внешнего сервиса, недостаток прав и частично сохранённая операция.

Пример 5. Превращение бизнес-правила в критерии приёмки

Бизнес-правило:
«Менеджер может согласовать заявку только в пределах своего лимита».

Критерии:
1. Заявка на сумму 100 000 ₽ при лимите 150 000 ₽ согласуется.
2. Заявка на сумму 150 001 ₽ блокируется.
3. Система учитывает валюту и применяемый курс.
4. Изменение лимита фиксируется в журнале.
5. Агент не должен создавать обходной путь через прямой вызов API.

Спецификация также помогает бороться с галлюцинациями. Если агент не находит в утверждённых источниках нужное правило или API, он должен сообщить о нехватке данных, а не уверенно придумать несуществующий endpoint. Для этого в правила агента можно включить режим «неизвестно»: при отсутствии подтверждения формируется вопрос или блокирующее предупреждение.

Управление контекстом

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

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

Контекст нужно не просто увеличивать, а проектировать: определять, какая информация необходима конкретному агенту, в каком виде она предоставляется и как проверяется её актуальность.

Один из практических вариантов — назначить каждой функции отдельного агента. Аналитический агент изучает пользовательские сценарии и бизнес-правила. Архитектурный агент работает с системными ограничениями и интерфейсами. Агент-разработчик получает только утверждённую спецификацию и относящиеся к задаче участки репозитория. Тестовый агент видит требования, критерии приёмки и изменённые компоненты.

Агент	Основной контекст	Инструменты	Ограничения
Discovery-агент	Интервью, аналитика, отзывы, рынок	Поиск, анализ документов, сводки	Не утверждает продуктовые решения
Аналитик	Процессы, роли, бизнес-правила	Работа со спецификациями и моделями	Не изменяет производственный код
Архитектор	Архитектура, интеграции, ограничения платформы	Диаграммы, анализ зависимостей	Не меняет требования единолично
Разработчик	Спецификация, код целевого модуля, стандарты	Репозиторий, IDE, тестовый контур	Нет доступа к секретам и лишним системам
Тестировщик	Критерии приёмки, контракты, тестовые данные	Запуск тестов, анализ отчётов	Не исправляет код без отдельного задания
Security-агент	Политики безопасности, модель угроз	Сканеры, анализ зависимостей, аудит	Может блокировать релиз при критическом риске

Разделение контекста между ИИ-агентами не обязательно означает физически разные модели. Это могут быть разные рабочие сессии, системные инструкции, наборы документов и права доступа. Важно, чтобы агент не видел автоматически всё, что теоретически доступно всей платформе.

Полезно выделять несколько слоёв контекста:

• Постоянные правила проекта: стандарты кода, политика безопасности, архитектурные принципы.
• Контекст задачи: текущая спецификация, связанные тикеты, критерии приёмки.
• Контекст компонента: конкретные файлы, API, схемы данных и зависимости.
• Временный контекст: логи текущего запуска, результаты тестов и сообщения об ошибках.
• Контекст истории: причины предыдущих решений и сведения о техническом долге.

Пример 6. Контекст агента-разработчика

Агент видит:
— спецификацию функции;
— контракт Payment API версии 3;
— два связанных сервиса;
— правила обработки персональных данных;
— команды запуска тестов.

Агент не видит:
— секреты production;
— персональные данные клиентов;
— несвязанные 40 000 файлов репозитория;
— черновые требования, отменённые владельцем продукта.

Правило:
если контракт Payment API противоречит локальному примеру,
агент не выбирает вариант самостоятельно, а создаёт запрос на уточнение.

Для передачи результатов между агентами полезны стандартизированные артефакты: JSON-схемы, OpenAPI-контракты, таблицы решений, чек-листы и отчёты. Свободный текст удобен для обсуждения, но хуже подходит как надёжный интерфейс между автоматизированными этапами.

Способ передачи контекста	Преимущество	Риск	Как улучшить
Большой общий prompt	Быстрый старт	Переполнение и потеря приоритетов	Разделить на инструкции и контекст задачи
Все файлы репозитория	Много исходных данных	Шум, утечки, дорогие вызовы	Использовать выборку по зависимостям
Краткое резюме	Дёшево и компактно	Потеря важных деталей	Хранить ссылки на первоисточники
Структурированный контракт	Однозначность и проверяемость	Нужно поддерживать актуальность	Ввести версионирование и автоматическую проверку
История чата	Сохраняет ход обсуждения	Содержит противоречия и случайные решения	Периодически извлекать утверждённые правила

Наконец, контекст должен обновляться. Устаревшая документация опаснее неполной: она создаёт у агента уверенность в неверном решении. Поэтому в зрелом процессе проверяют актуальность API, библиотек, политик и схем данных так же, как проверяют исходный код.

Экономика токенов

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

В маленьком учебном проекте стоимость токенов может быть почти незаметной. Если попросить модель реализовать сортировку пузырьком, расходы на генерацию кода действительно могут оказаться несущественными. Но корпоративное ПО — это миллионы строк, десятки репозиториев, длинные документы, повторные вызовы, анализ логов, тестовые прогоны и несколько агентов. Здесь расходы на контекст становятся частью себестоимости разработки.

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

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

Экономику токенов нужно рассматривать вместе с качеством. Дешёвая, но ошибочная генерация может привести к ручной переделке, инциденту или задержке релиза. Поэтому оптимизировать следует не только количество токенов, но и стоимость корректного результата.

Источник расходов	Почему возникает	Способ контроля
Большой входной контекст	Агенту передают лишние файлы и документы	Сокращение контекста, выборка по релевантности
Длинный ответ	Нет ограничения формата и объёма	Шаблоны, лимиты, структурированный вывод
Повторные вызовы	Каждый этап заново загружает одинаковые данные	Кэширование и хранение промежуточных артефактов
Ошибочные итерации	Нечёткая задача или неверные требования	Предварительная валидация спецификации
Цепочка агентов	Много ролей работают без остановок и критериев	Бюджеты, тайм-ауты, условия завершения
Проверка огромного репозитория	Анализируются несвязанные компоненты	Граф зависимостей и инкрементальный анализ

Для контроля расходов полезно установить бюджет на задачу, пользователя, команду и продукт. Бюджет может выражаться в рублях, количестве вызовов, токенах или времени работы агента. При достижении порога система должна не молча продолжать операцию, а остановить её или запросить подтверждение.

Пример 7. Ограничение бюджета AI-задачи

Задача: подготовить тесты для одного REST-контроллера.

Лимиты:
— не более 5 вызовов основной модели;
— не более 80 000 входных токенов;
— не более 20 000 выходных токенов;
— не более 10 минут автономной работы.

Остановка:
если после двух итераций покрытие не растёт,
агент формирует отчёт с причиной и передаёт задачу человеку.

Снизить расходы помогают несколько практик:

• использовать небольшие модели для классификации, поиска и форматирования;
• применять более мощные модели только для архитектурных и сложных аналитических задач;
• не передавать полный репозиторий, если достаточно связанных файлов;
• кэшировать неизменяемые инструкции и документы;
• хранить результаты анализа в структурированном виде, а не повторять длинный диалог;
• останавливать агента после выполнения критерия, а не после «ещё одного улучшения»;
• измерять стоимость не отдельного ответа, а завершённой функции.

Сценарий	Подход с низкой стоимостью	Подход с высокой стоимостью	Компромисс
Поиск по документации	Небольшая модель и релевантные фрагменты	Полный архив документов в каждом запросе	Индекс + выборка первоисточников
Генерация типового CRUD	Шаблоны и локальная модель	Сложная модель для каждой строки	Модель для проектирования, шаблон для реализации
Code review	Проверка изменённых файлов	Полный анализ всей системы	Инкрементальный review с периодическим аудитом
Исправление ошибки	Лог, спецификация и узкий контекст	Весь проект и длинная история чата	Сначала локализация, затем расширение контекста

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

Пример 8. Расчёт стоимости функции

Вариант A:
— 12 коротких вызовов;
— 3 повторных генерации;
— 2 часа ручной проверки;
— много лишних тестов.

Вариант B:
— 4 вызова с SDD-спецификацией;
— ограниченный контекст;
— автоматические критерии приёмки;
— 40 минут ручного ревью.

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

Примеры на рынке

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

Сравнивать такие решения только по вопросу «умеет ли платформа генерировать код» недостаточно. Важнее понять, какой участок жизненного цикла она покрывает и насколько контролируемым остаётся результат.

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

Решение	Компанией позиционируется как	Потенциальная роль в AI-driven подходе	Что важно уточнить перед выбором
Digital Q, Диасофт	Платформа и инструменты цифровой разработки	Исследование, формирование замысла, ускорение проектирования и реализации	Поддерживаемые сценарии, модели развертывания, интеграции и управление артефактами
Platform V, СберТех	Платформенный стек для корпоративной разработки	Реализация, архитектурные шаблоны, автоматизация разработки и AI-disrupt SDLC	Совместимость с ландшафтом, требования к инфраструктуре и процессам
ELMA365, ELMA	Low-code/no-code платформа для автоматизации бизнеса	Быстрое создание приложений и процессов с участием ИИ	Глубина кастомизации, ограничения low-code, интеграции и жизненный цикл решений

Digital Q от Диасофт

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

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

Пример 9. Как Digital Q-подход может применяться на практике

Запрос бизнеса:
«Нужно ускорить обработку обращений клиентов».

Discovery Loop:
— анализ текущего процесса;
— выявление ручных этапов;
— группировка типов обращений;
— поиск причин задержек;
— формулирование измеримой цели.

Замысел:
автоматически классифицировать обращения и направлять их
в нужную очередь с сохранением возможности ручной корректировки.

Реализация:
форма обращения, классификатор, маршрутизация,
журнал решений и отчёт по ошибочным классификациям.

Сильной стороной discovery-ориентированного подхода является снижение риска сделать «правильную систему не для той проблемы». До генерации интерфейсов и кода команда получает возможность проверить, действительно ли нужна новая функция, нельзя ли упростить процесс и какие данные потребуются для автоматизации.

При оценке Digital Q конкретной организацией стоит изучить не только демонстрационные сценарии, но и практические детали:

• как формируются и версионируются требования;
• можно ли связывать замысел с реализованными компонентами и тестами;
• как обеспечивается работа с корпоративными данными;
• какие модели и варианты развёртывания поддерживаются;
• как устроены роли, согласования и аудит действий;
• как решение интегрируется с существующим ИТ-ландшафтом.

Задача	Как AI-driven подход может помочь	Контрольный вопрос
Исследование процесса	Собрать и классифицировать сведения из документов и интервью	Подтверждены ли выводы реальными данными?
Формирование гипотез	Предложить варианты улучшений	Какая гипотеза проверяется первой и почему?
Проектирование	Подготовить модели процессов и сущностей	Согласованы ли правила и исключения?
Создание приложения	Ускорить подготовку типовых компонентов	Можно ли расширять результат без потери управляемости?
Сопровождение	Объяснять процессы и находить проблемные места	Актуальны ли данные и документация?

Platform V от СберТех

Platform V от СберТех представляет платформенный взгляд на корпоративную разработку. В контексте AI-driven он интересен тем, что связывает инструменты создания и эксплуатации программных решений с моделью AI-disrupt SDLC, разделяющей контур замысла и контур реализации.

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

Для корпоративной платформы важна не только скорость генерации. Важнее, чтобы результат можно было встроить в существующие регламенты, инфраструктуру, процессы безопасности и ответственность команд.

Практический интерес Platform V может быть связан с задачами, где необходимо создавать и развивать прикладные системы в едином технологическом контуре. AI-функции в таком сценарии должны помогать не только написать компонент, но и учитывать архитектурные ограничения, правила интеграции, требования к эксплуатации и поддерживаемые технологические стандарты.

Пример 10. Двухконтурная работа над корпоративным сервисом

Контур замысла:
Цель — сократить время согласования командировок.
Ограничения — политика расходов, уровни полномочий,
интеграция с кадровой системой и аудит решений.
Критерий — 90% заявок проходят без ручного перенаправления.

Контур реализации:
— модель заявки;
— сервис маршрутизации;
— интеграция с HR;
— правила эскалации;
— журнал аудита;
— нагрузочные и интеграционные тесты.

Перед внедрением платформы в крупной компании нужно заранее определить границы автономности. Например, агент может создавать черновики сервисов и тестов, но не должен самостоятельно менять политики доступа или публиковать изменения в продуктивной среде. Для критичных компонентов полезно сохранить обязательное архитектурное и security-ревью.

Уровень автономности	Разрешённые действия агента	Обязательный контроль
Подсказка	Объяснить код, предложить вариант	Проверка специалистом
Черновик	Создать проект решения и тесты	Ревью и запуск проверок
Ограниченная реализация	Изменить заданные файлы в ветке	CI/CD, тесты, code review
Автоматический выпуск	Провести изменение по конвейеру	Предварительно заданные политики и мониторинг
Самостоятельная оптимизация	Предложить или выполнить улучшения	Бюджеты, откат и отдельное подтверждение

Критически важно проверить совместимость с текущим ландшафтом: системами авторизации, хранилищами, шинами данных, CI/CD, мониторингом и инструментами управления задачами. Даже сильная платформа не даст ожидаемого эффекта, если её результаты приходится вручную переносить в десятки разрозненных систем.

ELMA365 от ELMA

ELMA365 — пример low-code/no-code-платформы, ориентированной на автоматизацию бизнес-процессов и создание прикладных решений с меньшим объёмом ручного программирования. В AI-driven контексте такие платформы позволяют приблизить создание приложений к владельцам процессов и аналитикам, а ИИ может помогать формировать процессы, поля, правила, формы и тексты.

Преимущество low-code-подхода проявляется там, где задача состоит из типовых бизнес-операций: заявок, согласований, маршрутизации, уведомлений, справочников, ролей и отчётов. В таких случаях визуальные модели и готовые компоненты ускоряют результат сильнее, чем генерация большого количества исходного кода.

При этом low-code не означает «ограничений нет». Сложные интеграции, нестандартные алгоритмы, высокие нагрузки, особые требования к транзакциям и глубокая кастомизация могут потребовать разработчиков. Поэтому AI-driven стратегия должна заранее разделить типовые и уникальные части решения.

Тип задачи	Насколько подходит low-code/AI-подход	На что обратить внимание
Согласование заявок	Очень хорошо	Матрица полномочий, исключения, аудит
Внутренний сервис подразделения	Хорошо	Права доступа и интеграция со справочниками
Сложный расчётный механизм	Зависит от платформы	Производительность и расширяемость
Критичная транзакционная система	Требует детальной оценки	Надёжность, отказоустойчивость, контроль изменений
Прототип процесса	Очень хорошо	План перехода от прототипа к промышленной эксплуатации

Пример 11. Применение ELMA365-сценария для закупки

Бизнес-процесс:
1. Сотрудник создаёт заявку.
2. Система проверяет бюджет и категорию расходов.
3. При превышении лимита заявка уходит руководителю.
4. После согласования создаётся задача закупщику.
5. Статус и история решения доступны инициатору.

AI может помочь:
— предложить структуру формы;
— найти пропущенные ветки;
— составить уведомления;
— подготовить тестовые сценарии;
— сформировать инструкцию для пользователей.

Человек проверяет лимиты, роли и юридически значимые правила.

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

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

Критерий выбора платформы	Вопрос для оценки ELMA365 или аналогичного решения	Почему это важно
Скорость прототипирования	Сколько времени занимает путь от идеи до тестового процесса?	Позволяет раньше проверить гипотезу
Глубина настройки	Можно ли реализовать нестандартные правила?	Снижает риск упереться в ограничения
Интеграции	Как подключаются внешние системы и API?	Бизнес-процесс редко существует изолированно
Контроль изменений	Есть ли версии, среды и откат?	Защищает от неконтролируемых обновлений
Безопасность	Как разделяются роли, данные и доступы?	Предотвращает утечки и нарушения регламентов
Масштабирование	Как система ведёт себя при росте пользователей и операций?	Прототип должен иметь путь к промышленной эксплуатации

Как внедрять AI-driven разработку в компании

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

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

Хороший пилот AI-driven — это не самая эффектная демонстрация. Это небольшой процесс с понятной базой сравнения, измеримым результатом и безопасными границами эксперимента.

Практический план может выглядеть следующим образом:

1. Выбрать участок разработки с повторяемыми операциями и низким риском.
2. Зафиксировать текущие показатели: срок, трудозатраты, количество дефектов, стоимость.
3. Описать спецификацию и критерии приёмки.
4. Определить роль ИИ: помощник, генератор черновика, проверяющий или автономный исполнитель.
5. Настроить доступ к контексту и исключить секретные данные.
6. Запустить пилот на ограниченном числе задач.
7. Сравнить результат с базовым процессом.
8. Разобрать ошибки и только затем расширять полномочия агента.

Этап внедрения	Основной вопрос	Артефакт на выходе
Подготовка	Какую проблему решаем?	Цель, границы и базовые метрики
Проектирование	Какие роли и агенты нужны?	Карта процесса и матрица доступов
Пилот	Даёт ли подход измеримую пользу?	Рабочий сценарий и отчёт сравнения
Стабилизация	Можно ли повторять результат?	Шаблоны, правила, тесты и регламент
Масштабирование	Как контролировать качество и расходы?	Платформа, бюджеты, мониторинг и обучение

Метрики должны отражать не только скорость. Полезно измерять долю принятых с первого раза результатов, количество дефектов после релиза, время ревью, объём переделок, стоимость токенов, количество эскалаций к человеку и удовлетворённость команды.

Пример 12. Набор метрик для пилота

До внедрения:
— средний срок подготовки интеграционного теста: 3 дня;
— ручная проверка: 6 часов;
— дефекты в тестовых сценариях: 12%.

После внедрения:
— срок: 1,5 дня;
— ручная проверка: 2,5 часа;
— дефекты: 8%;
— стоимость AI-вызовов: 420 ₽ на задачу.

Вывод:
ускорение есть, но нужно проверить,
не выросли ли расходы на сопровождение и контроль.

Не менее важна подготовка сотрудников. Разработчику теперь нужно уметь не только писать код, но и формулировать ограничения, проверять происхождение ответа, проектировать контекст и замечать опасные предположения модели. Аналитику полезно освоить структурированное описание требований и критериев приёмки.

Роль	Новые навыки	Типичная ошибка при переходе
Владелец продукта	Формулирование целей и измеримых критериев	Считать любой сгенерированный результат ценностью
Аналитик	SDD, таблицы решений, управление неоднозначностью	Передавать агенту расплывчатое описание процесса
Разработчик	Проверка кода, работа с агентами, архитектурное мышление	Принимать генерацию без понимания
Тестировщик	Генерация сценариев и проверка полноты требований	Проверять только счастливый путь
Архитектор	Проектирование границ автономности и контекста	Разрешать агенту менять системные решения без контроля
Безопасность	Аудит AI-процессов и защита данных	Подключать корпоративные данные без классификации

Особое внимание нужно уделить данным. Нельзя автоматически передавать внешней модели исходный код, персональные данные, коммерческие секреты, ключи доступа и внутренние документы без разрешённого режима обработки. Для каждого источника следует определить класс чувствительности, допустимый способ передачи, срок хранения и порядок удаления.

Для надёжности полезно установить «красные линии» — действия, которые агент не выполняет автономно. К ним могут относиться изменение прав доступа, удаление данных, публикация в production, изменение финансовых правил, работа с персональными данными и редактирование критичных архитектурных компонентов.

Риски и ограничения

AI-driven подход способен ускорить разработку, но не отменяет инженерные риски. Более того, некоторые риски становятся менее заметными, потому что результат выглядит убедительно и появляется быстро.

Первая проблема — галлюцинации. Модель может сослаться на несуществующую библиотеку, придумать параметр API, неверно интерпретировать бизнес-правило или заявить, что тест прошёл, хотя он фактически не запускался. Чем увереннее сформулирован ответ, тем важнее независимая проверка.

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

Вторая проблема — размывание ответственности. Если функция создана несколькими агентами, а человек только нажал кнопку, всё равно должен существовать конкретный владелец результата. В противном случае при инциденте команда обнаружит, что «решение принял алгоритм», а это нерабочая модель управления.

Риск	Как проявляется	Мера снижения
Галлюцинация	Несуществующий API или неверное правило	Проверка по первоисточникам и автоматические тесты
Утечка данных	Секреты попадают в prompt или логи	Маскирование, изоляция, классификация данных
Разрастание объёма	ИИ меняет лишние файлы и функции	Ограниченная область изменений и контроль diff
Скрытый технический долг	Код работает, но плохо поддерживается	Архитектурные правила, ревью и рефакторинг
Смещение требований	Реализация незаметно меняет замысел	Связь спецификации, тестов и изменений
Рост расходов	Много повторных вызовов и длинный контекст	Бюджеты, лимиты и анализ стоимости задачи
Зависимость от поставщика	Сложно заменить модель или платформу	Абстракции, экспорт артефактов и резервные процессы

Третья проблема — уязвимости. Генеративная модель может предложить небезопасную обработку входных данных, слабую авторизацию или небезопасное хранение секретов. В агентных системах добавляются новые угрозы: prompt injection, подмена документов, выполнение непредусмотренных инструментальных действий и отравление контекста.

Для критичных систем нужен принцип минимальных полномочий. Агент должен иметь только необходимые права, работать в изолированной среде и не получать постоянный доступ к продуктивным секретам. Команды, которые агент может выполнить, следует ограничивать белым списком.

Пример 13. Опасное и безопасное разрешение для агента

Опасно:
«Имеешь доступ ко всему репозиторию и можешь запускать любые команды».

Безопаснее:
Разрешено:
— читать каталог service-orders;
— изменять только ветку feature/discount;
— запускать unit-тесты;
— создавать отчёт о diff.

Запрещено:
— читать production secrets;
— удалять файлы вне каталога;
— публиковать сборку;
— менять схему базы без отдельного подтверждения.

Нужно учитывать и юридические вопросы: права на сгенерированный код, лицензии зависимостей, условия использования моделей, требования к хранению данных и возможность объяснить принятое решение. Для корпоративных систем «модель так предложила» не является достаточным основанием.

Как понять, готова ли компания к AI-driven. Чек-лист

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

Оценивать готовность полезно по нескольким направлениям: данные, архитектура, культура разработки, безопасность, инфраструктура и управление изменениями.

Область	Признак готовности	Тревожный сигнал
Требования	Есть владельцы, версии и критерии приёмки	Решения существуют только в чатах и устных договорённостях
Код	Есть тесты, стандарты и управляемый репозиторий	Никто не знает, какие компоненты можно менять
Данные	Определены классы чувствительности	Сотрудники пересылают секреты в случайные сервисы
Архитектура	Есть границы сервисов и описанные интерфейсы	Система держится на неформальных зависимостях
Качество	Работают CI, тесты и анализ безопасности	Проверка выполняется только перед релизом вручную
Управление	Назначены ответственные за AI-процессы	Невозможно определить владельца результата

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

Пример 14. Быстрый чек-лист перед пилотом

[ ] Есть конкретная задача и владелец результата.
[ ] Определены данные, которые можно передавать модели.
[ ] Сформулированы критерии приёмки.
[ ] Есть тестовый контур и возможность отката.
[ ] Агент работает с ограниченными правами.
[ ] Установлен бюджет токенов и вызовов.
[ ] Все изменения попадают в журнал.
[ ] Есть человек, который принимает итоговое решение.

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

Итоги

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

Модели AI-disrupt SDLC СберТех с двумя контурами — замысла и реализации — и трёхконтурный подход Диасофт с добавленным Discovery Loop показывают разные способы разделить исследование, бизнес-проектирование и техническое исполнение. Digital Q, Platform V и ELMA365 демонстрируют, что рынок движется к платформам, где AI-функции становятся частью более широкого жизненного цикла, а не отдельной кнопкой генерации.

Успешная AI-driven разработка начинается не с самого мощного агента, а с ясного ответа на три вопроса: что мы создаём, по каким правилам и как докажем, что результат корректен.

В центре такого подхода находится спецификация, в том числе SDD: она связывает намерение, ограничения, архитектуру, код и тесты. Вокруг неё строятся управление контекстом, разделение ролей между агентами, контроль доступа и экономика токенов. Чем крупнее система, тем меньше можно полагаться на «магическое понимание» модели и тем больше требуется формальных контрактов.

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

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