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

Натан Роу

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

Предисловие: Революция в области программных продуктов в эпоху ИИ

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

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

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

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

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

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

Это приводит к прямому следствию: традиционные методы разработки программного обеспечения больше не подходят. Раньше мы привыкли сначала определять функционал, затем составлять техническое задание (PRD), после чего планировать разработку, проводить тестирование и запускать продукт в эксплуатацию; однако в случае с ИИ-продуктами многие ключевые возможности невозможно точно описать до проведения экспериментов. Зачастую у команды есть лишь область задачи, набор данных и ряд неопределенных гипотез, и ей необходимо постепенно, путем экспериментов, выявлять возможности, которые действительно можно воплотить в продукте.

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

•

Как найти перспективное направление для разработки продукта на базе ИИ.

•

Как превратить нестабильные возможности ИИ в стабильные возможности продукта.

•

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

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

Основная линия, которой следует эта книга:

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

При этом этап «Определение направления» (Direction) отвечает за формулировку задачи и определение направления, этап «Проведение экспериментов» (Experiment) — за проверку возможностей, этап «Создание системы» (Building) — за техническую реализацию, этап «Аудит и одобрение» (Audit) — за управление и установление границ, а этап «Производственная эксплуатация» (Production) — за обратную связь и развитие после запуска. Это не линейный процесс, а цикл разработки продукта, состоящий из повторяющихся итераций.

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

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

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

Кому предназначена эта книга

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

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

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

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

Глава 1. Возникновение интеллектуальных систем

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

•

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

•

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

•

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

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

•

Rule System: программная система, основанная преимущественно на чётких правилах и фиксированных соотношениях между входными и выходными данными.

•

Workflow System: акцент делается на оркестрации процессов

с участием различных ролей, этапов и систем.

•

Система возможностей (Capability System): акцент делается не на фиксированных процессах, а на наделении системы способностями к пониманию, принятию решений, генерации и планированию.

Понимание содержания этой главы на примере

Возьмём в качестве примера сферу обслуживания клиентов. На ранних этапах программное обеспечение больше напоминало «систему правил» (Rule System): после получения заявки она распределялась в соответствии с фиксированными правилами. Позже оно развилось в «систему рабочих процессов» (Workflow System): в ней процесс обработки заявок, их утверждение, эскалация и поиск знаний были объединены в единый поток. В эпоху искусственного интеллекта система стала «системой возможностей» (Capability System): она не только обрабатывает заявки, но и понимает суть проблемы, объясняет логистику, генерирует варианты ответов и предупреждает о рисках.

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

Описание процесса эволюции

Выполнение по фиксированным правилам -> Организация рабочих процессов -> Использование возможностей для выполнения задач

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

1. От системы правил к системе процессов

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

Система правил -> Система рабочих процессов -> Система возможностей

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

2. Сравнение типичных примеров трех типов систем

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

Сценарий

Система правил (Rule System)

Система рабочих процессов (Workflow System)

Система возможностей (Capability System)

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

Маршрутизация по ключевым словам, фиксированные FAQ, шаблоны стандартных ответов

Обработка заявок, эскалация, SLA, процессы утверждения и поиска знаний

Copilot / Агент службы поддержки: понимание проблемы, поиск заказов, разъяснение логистики, генерация вариантов ответов, предупреждение о рисках

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

Стандартные отчеты, расчет стандартных показателей, стандартный экспорт

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

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

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

Пороговые оповещения, сопоставление по правилам, фиксированные скрипты

Обработка событий, эскалация дежурным, выполнение инструкций по устранению неполадок

Помощник AIOps / агент: агрегирование предупреждений, обобщение журналов, вывод первопричин, предложение рекомендаций по устранению

Эта сравнительная таблица иллюстрирует один очень важный момент: эволюция программного обеспечения заключается не в «увеличении количества функций», а в том, что система берет на себя выполнение задач все более высокого уровня. Система правил (Rule System) решает задачи определения действий, система рабочих процессов (Workflow System) — определения процессов, а система возможностей (Capability System) начинает обрабатывать полуструктурированные суждения, организовывать сложную информацию и выполнять многоэтапные задачи.

3. Пределы системы рабочих процессов

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

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

4. Появление систем способностей

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

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

5. Переход от функционального мышления к мышлению, ориентированному на способности

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

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

6. Взрывной рост применения ИИ-агентов

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

Во-первых, возможности моделей по многошаговому выводу и вызову инструментов начали внедряться в продукты. В марте 2025 года OpenAI запустила Responses API, встроенные инструменты и Agents SDK, интегрировав вызов инструментов, оркестрацию задач и наблюдаемость в официальный набор возможностей, что сделало создание работоспособных агентов возможностью на уровне платформы.

Во-вторых, разработка агентов стала опираться на фреймворки, более близкие к программной инженерии. ADK от Google описывает агента как программную систему и предоставляет структуры рабочих процессов (Sequential, Parallel, Loop), архитектуру с несколькими агентами, а также возможности развертывания и оценки. Это означает, что агент больше не является просто демонстрационным примером, а начинает обладать повторно используемым инженерным каркасом.

В-третьих, подключение к внешним системам начинает стандартизироваться с помощью протокола. MCP абстрагирует данные, инструменты и рабочие процессы приложений ИИ в виде открытого протокола, а OpenAI в обновлении 2025 года также поддерживает удалённые серверы MCP, благодаря чему подключение агентов к корпоративным системам больше не зависит исключительно от разовой кастомизации.

В-четвертых, начали появляться среды выполнения производственного уровня. Foundry Agent Service от Microsoft объединяет среду выполнения агента, триггеры событий, мониторинг и управление в единую платформу, позволяя предприятиям запускать агентов на имеющейся инфраструктуре.

Наконец, экосистема открытого исходного кода начала быстро усиливать эту тенденцию. Например, платформа агентов с открытым исходным кодом OpenClaw быстро стала популярной в начале 2026 года: на GitHub она набрала более 200 000 звездочек и поддерживает множество моделей, каналов и большое количество повторно используемых навыков, что позволяет разработчикам быстро создавать автоматизированные ИИ-агенты.

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

7. Новые проблемы, возникающие в эпоху систем способностей

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

•

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

•

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

•

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

•

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

•

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

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

8. Почему эти проблемы приводят к появлению новой методологии

Именно из-за появления этих новых проблем команды не могут полагаться исключительно на традиционный подход «требования → проектирование → разработка → тестирование → запуск» при создании продуктов искусственного интеллекта.

В эпоху систем правил самое важное — правильно сформулировать правила; в эпоху систем процессов — правильно выстроить последовательность процессов; а в эпоху систем способностей команда должна одновременно ответить на следующие вопросы:

•

Действительно ли поставленная нами задача заслуживает решения с помощью ИИ?

•

Прошла ли эта способность достаточную экспериментальную проверку и действительно ли она работает?

•

Как эту способность превратить в полноценную систему, а не оставить на стадии демо-версии?

•

Какие границы

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

•

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

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