Рафаел Тонаканян: «Разработчик становится менеджером над ИИ-агентом»

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

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

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

«Нельзя просто дать агенту доступ к коду и надеяться, что он будет соблюдать правила»

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

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

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

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

– В крупной компании нельзя просто дать агенту доступ к коду и надеяться, что он будет соблюдать правила. Нужен harness (дословно можно перевести как «обвязка» – имеется в виду программная среда для управления работой ИИ-агента. – «Ведомости. Инновации и технологии»), который позволяет контролировать доступ агента к информации и инструментам, а также выполнение обязательных проверок, например, требований информационной безопасности.

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

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

«Рост объема кода не гарантирует появления полезных возможностей в продукте»

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

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

– Мы смотрим на несколько показателей. Первый – объем созданного кода и других артефактов. За девять месяцев 2026 г. в «Сбере», по нашим данным, кода было создано на 70% больше по сравнению с аналогичным периодом 2025 г. Второй показатель – время выполнения задачи от начала работы над ней до внедрения готового решения. Этот цикл у нас сократился примерно на 15%.

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

Для оценки трудоемкости кода, в частности, используется GigaView – инструмент анализа, который помогает сопоставлять объем изменений с трудозатратами. Целевой ориентир на этот год – увеличить на 50% число бизнес-задач, доведенных до промышленного внедрения. Сегодня, по нашей оценке, прирост уже составил 41% с начала года, так что до конца года осталось 9%. Надеюсь, дожмем.

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

– Это одна из самых острых проблем. По нашим данным, объем использования ИИ-инструментов в «Сбере» в месяц уже превысил 10 трлн токенов (единиц текста, на которые ИИ-модель разбивает информацию при ее обработке и генерации ответов. – «Ведомости. Инновации и технологии»). Для такой нагрузки нужны большие вычислительные мощности, в том числе графические процессоры, на которых запускаются модели.

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

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

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

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

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

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

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