Как создавать продукты с ИИ. От первых экспериментов до работающей системы

Определение направления -> Проведение экспериментов -> Построение системы -> Аудит и запуск -> Ввод в эксплуатацию

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

Заключение к этой главе

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

Глава 2. Новые проблемы, возникающие в связи с парадигмой «AI Native»

Вопросы, на которые будет дан ответ в этой главе:

•

В чём именно заключается «новизна» программного обеспечения AI Native по сравнению с традиционным программным обеспечением?

•

Почему продукты ИИ больше похожи на системы способностей, а не на функциональные системы?

•

Какие новые проблемы в области продуктов, разработки и управления вызывает эта смена парадигмы?

•

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

Объяснение ключевых концепций и новых терминов

•

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

•

Система способностей: программное обеспечение, в основе которого лежат такие способности, как понимание, анализ, генерация, планирование и выполнение.

•

Контекстная зависимость: поведение системы определяется не только кодом, но и зависит от данных, состояния, ролей и истории.

•

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

Понимание данной главы на примере

Традиционные системы бизнес-аналитики (BI) требуют, чтобы пользователь самостоятельно выбирал поля, временные рамки и условия фильтрации, а затем изучал диаграммы; аналитическая система AI Native же позволяет пользователю просто сказать: «Объясни мне, почему за последний месяц снизился коэффициент повторных покупок». В первом случае пользователь должен адаптироваться к системе, во втором — система должна понять цель и организовать процесс анализа.

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

Описание процесса изменения парадигмы

Функции, управляемые пользователем -> Пользователь формулирует цель -> Система организует выполнение части работы

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

1. Программное обеспечение превращается из инструмента в помощника

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

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

Это означает, что отношения между программным обеспечением и пользователем изменились. Раньше «пользователь учился работать с системой», а сейчас всё чаще «система понимает пользователя».

2. Переход программного обеспечения от функциональных систем к системам на основе способностей

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

Именно поэтому в продуктах искусственного интеллекта часто встречаются такие структуры, как «Agent», «Skill», «Memory» и «Tool». По сути, ни одна из них не является «модулем страницы», а представляет собой базовую единицу, обеспечивающую функционирование системы возможностей.

Другими словами, программное обеспечение AI Native — это не просто добавление слоя «интеллектуального интерфейса» к традиционным системам, а переосмысление определения ключевых компонентов продукта.

3. Сравнение трёх типичных категорий продуктов

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

Сценарий

Традиционная функциональная система

Система возможностей AI Native

Анализ данных

Отчеты, фильтрация, экспорт, запросы с фиксированными критериями

Понимание проблем, объяснение аномалий, построение аналитических цепочек, формулирование выводов

Служба поддержки

Система заявок, база знаний, стандартные шаблоны, ответы операторов

Понимание запросов, инструменты для управления заявками, правила поиска, формирование рекомендаций по ответам, предупреждение о рисках

Техническое обслуживание

Платформа оповещений, платформа журналов, руководства по устранению неполадок, ручное устранение неполадок

Агрегирование предупреждений, обобщение журналов, вывод первопричин, рекомендации по действиям, накопление опыта на основе прецедентов

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

4. Поведение программного обеспечения начинает зависеть от контекста

Поведение систем, основанных на правилах, в основном зависит от программного кода, тогда как поведение программного обеспечения AI Native явно зависит от контекста. На одну и ту же проблему должны даваться разные ответы в зависимости от роли пользователя, истории взаимодействия, корпоративных данных и статуса задачи. Таким образом, контекст перестает быть второстепенным фактором и становится ключевым вкладом, определяющим качество продукта.

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

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

5. Программное обеспечение начинает участвовать в выполнении задач

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

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

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

6. Новые проблемы, возникающие в связи с парадигмой AI Native

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

•

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

•

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

•

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

•

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

•

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

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

7. Почему для этого требуется новая методология разработки продуктов

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

•

Какую именно проблему мы решаем, а не просто накапливаем функции.

•

Действительно ли эта возможность работает, а не только выглядит рабочей в демо-версии?

•

Как эта возможность может превратиться из результатов экспериментов в стабильную функциональность продукта?

•

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

•

Как реальные отзывы после запуска будут учтены в следующем цикле определения задач и экспериментов.

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

Именно по этой причине в дальнейшем тексте будет предложена новая основная линия:

Определение направления -> Проведение испытаний -> Создание системы -> Аудит и разрешение на ввод в эксплуатацию -> Ввод в эксплуатацию

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

Заключение к этой главе

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

Глава 3. Необходимость модернизации методов программной инженерии

Вопросы, на которые будет дан ответ в этой главе:

•

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

•

В чём заключаются границы между DevOps, MLOps и методологией AI Native Product

?

•

Почему методология разработки продуктов также нуждается в обновлении?

•

На каких проверенных практиках в основном основана эта методология?

Объяснение ключевых концепций и новых терминов

•

DevOps: методология, основанная на создании замкнутого цикла непрерывной доставки, охватывающего разработку, развертывание и эксплуатацию.

•

MLOps: метод построения замкнутого цикла моделирования, включающий данные, обучение, оценку, развертывание и мониторинг.

•

AI Native Product Methodology: метод построения замкнутого цикла продукта, основанный на проблемах, экспериментах, инжиниринге, управлении и обратной связи от производства.

•

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

Понимание данной главы на примере

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

Этот пример показывает, что существующие методологии не утратили своей актуальности — просто они решают разные задачи. Задача методологии AI Native Product Methodology — дополнить эти методологии продуктовыми решениями.

Описание процесса эволюции методологии

Методы реализации проектов -> Методология непрерывной доставки -> Методология замкнутого цикла модели -> Методология замкнутого цикла для продуктов на базе ИИ

По мере усложнения структуры системы методология также должна эволюционировать от подхода «как создать продукт » к подходу «как постоянно создавать правильные продукты».

1. Методология всегда меняется в соответствии с эволюцией систем

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

Все эти методы важны, но их основным объектом по-прежнему остаются «системы кода» или «системы моделей». Проблемы продуктов AI Native идут еще дальше: команды должны одновременно справляться с неопределенностью продукта, неопределенностью возможностей и неопределенностью бизнес-модели.

2. Откуда берется неопределенность в продуктах на базе ИИ

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

Это означает, что PRD больше не является отправной точкой — отправной точкой становятся эксперименты.

3. От инженерного замкнутого цикла к продуктовому замкнутому циклу

DevOps делает акцент на замкнутом цикле от разработки до эксплуатации, MLOps — на замкнутом цикле от данных до модели, а методология AI Native Product Methodology — на полном замкнутом цикле продукта, включающем проблемы, возможности, инжиниринг, управление и период после запуска. Она объединяет продуктовый, экспериментальный и инженерный подходы в единую цепочку:

Определение направления -> Проведение экспериментов -> Создание системы -> Аудит и одобрение -> Эксплуатация в производственной среде

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

4. Теоретические истоки данной методологии

Эта методология не возникла на пустом месте; на самом деле она вобрала в себя четыре категории проверенных практик, просто перегруппировав их в единую линию, более подходящую для продуктов в области искусственного интеллекта.

•

Lean Startup: предоставляет базовую идею «проверки гипотез посредством экспериментов». Многие возможности продуктов ИИ невозможно определить заранее, поэтому необходимо выявлять границы возможностей с помощью экспериментов, а не сначала формулировать требования, а затем проверять их.

•

DevOps: обеспечивает замкнутый цикл от разработки до развертывания и мониторинга. После запуска продукта ИИ также требуется постоянное наблюдение, постоянный реверс и постоянная оптимизация, а не однократная поставка.

•

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

•

AI Engineering: предлагает концепцию системных компонентов, таких как Prompt, Agent, Tool, Memory, RAG и Workflow. Подход подчеркивает, что модель — лишь часть системы, а истинные возможности продукта обусловлены целостностью цепочки.

Если рассматривать только один из этих подходов, картина будет неполной. Lean Startup уделяет больше внимания проверке инноваций, DevOps — развертыванию и эксплуатации, MLOps — жизненному циклу модели, а AI Engineering — системной архитектуре. Методология AI Native Product Methodology же направлена на решение следующих задач: как продукт обнаруживается, создается, управляется, запускается и затем постоянно поддерживается.

5. Продукт-менеджеры и инженеры должны повысить свою квалификацию

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

Заключение к этой главе

Методология AI Native Product Methodology не призвана заменить DevOps или MLOps, а направлена на заполнение пробела в разработке продуктов на базе ИИ, касающегося того, «как продукт обнаруживается, определяется, стабилизируется и управляется». Это и методология разработки продуктов, и подход к работе, объединяющий продуктовые, экспериментальные, инженерные и коммерческие аспекты.

Глава 4. Методология AI Native Product

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

Вопросы, на которые будет дан ответ в этой главе:

•

Что представляет собой методология AI Native?

•

К каким типам продуктов и сценариям применима эта методология, а в каких ситуациях её нельзя применять напрямую?

•

Почему это не линейный процесс, а система непрерывного цикла?

•

Определение направления → Проведение экспериментов → Построение системы → Аудит и запуск → Производственная эксплуатация → Циклическая обратная связь — за что отвечает каждый из этих этапов?

•

Чем обеспечивается связь между этапами, и как команда должна определять, когда можно переходить к следующему этапу?

•

Какова связь между циклом продукта (Product Loop), циклом обнаружения ценности (Value Discovery Loop), циклом клиента (Customer Loop) и уровнем управления (Governance Layer), уровнем возможностей (Capability Layer)?

1. Это не блок-схема, а подход к работе

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

Это означает, что разработка продуктов на базе ИИ не может опираться исключительно на линейную логику «сначала определить требования, а затем приступить к разработке». Команда должна одновременно справляться с четырьмя видами неопределенности:

•

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

•

Неопределённость возможностей

: на что на самом деле способна комбинация модели, данных, контекста и системы.

•

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

•

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

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