Сбер представил обновленное руководство по агентной разработке

Сбер выпустил обновленную редакцию AI-Disrupt PDLC — стратегии AI-трансформации разработки и бизнеса в новой технологической реальности.

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

В документе отражены важные акценты — среда исполнения агента важнее модели, за человеком остаются намерение, определение правил исполнения (governance) и правил проверки результата (validation). Агент, следуя заданным правилам, реализует намерение. Руководство проводит параллели с Agile-трансформацией, показывает ее развитие — двухконтурная модель и компактные команды, но дает и отличия — агент самостоятельно ищет оптимальное решение. Также в материал вошли новые аспекты управления ИИ — контроль затрат и промышленная эксплуатация. План действий — на чистоте замысла, ступенях зрелости и системе связей.

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

Как показывают исследования, один и тот же разработчик с одной и той же нейросетью показывает разницу в эффективности до 22 п.п. в зависимости от среды исполнения агентов. В то же время разрыв между лучшей и худшей моделью на идентичных задачах не превышает 1–3 пунктов. Это сравнение подчеркивает, что именно среда исполнения (agentic harness) становится определяющим фактором в результате. Вендоро-независимая архитектура остается наилучшим долгосрочным активом, особенно — в условиях ускоряющего темпа выпуска ИИ-моделей, их возникающей специализации.

Центральным элементом AI-Disrupt PDLC является способ обеспечить точное понимание между человеком и агентом, который воплощается через Specification-Driven Development — методологию перехода к написанию кода на базе точных спецификаций. Человек формулирует бизнес-требования в виде спецификации, а мультиагентная система помогает обеспечить их детализацию и консистентность, чтобы затем автономно реализовать их от кода до внедрения. Цель подхода — обеспечить предсказуемую проверку продуктовых гипотез, убрать из производственного процесса все, что может мешать или замедлять достижение бизнес-целей.

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

Сбер прогнозирует повсеместный переход к компактным командам (Tiny Teams) из трёх-шести человек, а их общие функции (формирование контекста, описание продуктовых практик) и обмен знаниями и практиками перейдет в поддерживающие команды (Enabling Teams). В прежней логике крупная команда обеспечивала наличие компетенций и ресурс для проработки. Агентная среда и формализованный контекст является концентрированным знанием многих людей. Лидер продукта может сосредоточиться на продукте, а разработчик – на координации агентов, проектировании системы и верификации решения. Не нужно больше собирать большие команды, можно сделать много малых команд и сосредоточиться на детальном улучшении продукта.