Нимиша Астхагири, консультант по данным и искусственному интеллекту компании Thoughtworks, рассказала порталу The New Stack о том, почему так много компаний испытывают трудности с переходом своих ИИ-проектов от этапа проверки концепции (PoC) к внедрению в производство. Среди поднятых тем: разрыв между прототипом и внедрением в производство в сфере агентного ИИ, почему возвращаются фундаментальные принципы инженерии, такие как разработка через тестирование и мутационное тестирование, и провокационная идея: большая часть кода, генерируемого ИИ, возможно, вообще не должна существовать.

Разрыв между PoC и внедрением в производство

Gartner прогнозирует, что более 40% проектов в области агентного ИИ будут отменены к концу 2027 г., и тенденция, которую наблюдает Астхагири, совпадает с этим прогнозом. Отчасти это связано с тем, что после стремительного развития генеративного ИИ в 2022 г. компании пережили волну PoC-проектов. И многие застряли в попытках внедрить результаты этих экспериментов в производство.

Проблему, как считает Астхагири, иллюстрирует то, о чем спрашивают руководители. «Вопрос, который мы часто слышим от руководителей и других лиц, звучит так: как нам ускорить процесс? Как нам оставаться актуальными? — говорит она. — Я думаю, что правильный или более подходящий вопрос здесь может звучать так: что мы можем создать, используя новейшие технологии, из того, что мы не могли создать раньше?».

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

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

Основы инженерии возвращаются

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

Астхагири входит в глобальную команду, которая готовит Radar. Точка зрения Thoughtworks такова: при таком большом количестве ИИ-инструментов и Open Source-проектов, появляющихся в сети, никто не может оценить их все. В таких обстоятельствах разумный подход заключается в том, чтобы вернуться ко многим устоявшимся методам — не из ностальгии, а в качестве необходимого противовеса скорости, с которой инструменты ИИ могут создавать сложность.

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

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

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

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

«Тёмный код» и аргументы в пользу эфемерного ПО

Говоря об огромном объёме кода, сгенерированного ИИ, и о создаваемых им узких местах на последующих этапах, Астхагири отмечает, что ответом не должно быть улучшение инструментов проверки. Вместо этого организациям следует задаться вопросом, нужен ли этот код вообще.

«Будет много тёмного кода (dark code), — говорит она, заимствуя концепцию тёмных данных (dark data) — информации, которую организации собирают, но никогда фактически не используют. — Поскольку код станет товаром, который нужно генерировать, вам не обязательно его хранить».

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

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

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