То, как сегодня агентный искусственный интеллект используется в разработке ПО, является предвестником более широких изменений в модели разработки, пишут в корпоративном блоге партнеры McKinsey Джаред Мун и Адам Теллуолл (Лондон), Рори Уолш (Дублин) и Вито Ди Лео (Цюрих).
В 9:00 утра владелец продукта заходит в систему, чтобы проверить прогресс, достигнутый ее командой за ночь. Она видит, что функция перешла от структурированных требований к протестированному коду. Отмечены граничные случаи. Она отмечает, что архитектурные зависимости проверены. Краткое резюме описывает компромиссы и нерешенные вопросы.
Никто не работал допоздна. Работали агенты ИИ.
К середине утра команда проверяет результаты, уточняет контрольные точки и пересматривает приоритеты бэклога. К вечеру следующие структурированные входные данные ставятся в очередь для работы агентов ИИ в течение очередного ночного цикла.
Эта
24-часовой спринт: проектирование для непрерывной производительности
Ведущие компании переходят к модели ежедневного спринта, которая сочетает в себе человеческое суждение с ночным выполнением задач агентами — значительное сокращение типичных двухнедельных циклов спринта. В течение дня люди сосредотачиваются на проверке результатов, разрешении неясностей, укреплении архитектурных ограничений и согласовании с заинтересованными сторонами. Всё чаще их роль сводится не столько к созданию артефактов, сколько к надзору и совершенствованию системы, которая их создаёт.
Ночью агенты выполняют структурированную работу в масштабе. Их задачи включают в себя обогащение требований, проверку архитектуры, генерацию и тестирование кода, а также упаковку результатов для проверки.
Эта модель работает только при наличии нескольких практических основ. Во-первых, у бизнеса должно быть чёткое видение того, что нужно построить (это может быть дорожная карта продукта или стандарт, на основе которого будет строиться), чтобы они могли оценивать требования, сгенерированные агентами, на предмет качества и соответствия этому видению.
Затем базовая технологическая среда должна быть стандартной и согласованной (например, с использованием общих фреймворков и модульных архитектур), чтобы решения могли масштабироваться, а компоненты могли повторно использоваться, а не изобретаться заново каждый раз.
В-третьих, путь от требований к коду должен следовать стандартной структуре, чтобы агенты могли надёжно интерпретировать входные данные и получать предсказуемые результаты в разных проектах.
И в-четвёртых, одни и те же ключевые заинтересованные стороны должны оставаться вовлеченными на протяжении всего потока создания ценности, чтобы избежать несогласованности и постоянных переделок.
Без такого уровня согласованности и ясности результаты работы агентов будут фрагментированными, и им будет трудно доверять.
Главный вывод: непрерывная
Расширьте автоматизацию, чтобы исключить передачу задач от человека к человеку
Традиционная автоматизация непрерывной интеграции и непрерывной доставки (CI/CD) в значительной степени сосредоточена на тестировании и развертывании. Хотя затраты на это варьируются, наш опыт показывает, что они могут составлять до 30% от общих затрат на технологии. Бóльшая часть усилий, сосредоточенных на требованиях и кодировании, остается ручной и требует интенсивной интерпретации. Именно здесь накапливаются трения, и ценность достигает плато.
В большинстве организаций требования, стандарты, архитектурные спецификации и пользовательские истории существуют в разрозненных документах и инструментах. Каждый переход вносит неоднозначность. Люди многократно переводят намерения из одного артефакта в другой.
Агентная модель устраняет эти трения, структурируя артефакты для передачи задач от машины к машине. Функциональные описания, нефункциональные требования, ограничения, диаграммы последовательностей и репозитории кодифицируются в стандартизированных, машиночитаемых форматах. В результате конвейер может выполняться от начала до конца за несколько часов, при этом вмешательство человека происходит только на определенных этапах проверки, а не в качестве посредника.
Главный вывод: масштабирование ИИ требует применения инженерных методов к самой системе разработки, что делает процесс повторяемым и автоматизирует передачу задач.
Создание инфраструктуры знаний для обеспечения автономности агентов
Для получения точных результатов фабрикам агентов необходимы организационный контекст и память. Ведущие компании создают графы знаний, которые функционируют как слой памяти ИИ на протяжении всего жизненного цикла разработки ПО (SDLC) для каждой области. Эти графы связывают элементы, которые агенты должны понимать, такие как отзывы клиентов, архитектурные решения, проектная документация, заявки, активность в GitHub, отчеты об инцидентах и обобщенные правила соответствия нормативным требованиям. В результате получается семантически связанная система (то есть, способ для агентов понимать значение данных, чтобы лучше выполнять свои задачи).
Такое влияние является преобразующим. На вопросы, которые раньше требовали недель интервью с многочисленными экспертами в предметной области, агент-«библиотекарь» может ответить за минуты, используя структурированную институциональную память. Каждое решение становится отслеживаемым. Если заинтересованная сторона спрашивает, почему функция была отложена, ответ может быть напрямую связан с источником, например, данными опросов клиентов или аналитикой использования. Неявные знания, накопленные в рамках сообщества, становятся явными и объяснимыми, сокращая время адаптации для новых членов команды и укрепляя управление.
Важно отметить, что это не должно начинаться с масштабной, нисходящей разработки онтологии. Граф должен органично развиваться вокруг приоритетных областей и действующих программ, накапливая ценность с течением времени. По мере масштабирования знания становятся производственной инфраструктурой, а не статической документацией, и устойчивым источником конкурентного преимущества.
Главный вывод: структурированные, взаимосвязанные знания — это основа автономии агентов. Рассматривайте свою архитектуру знаний как стратегическую инфраструктуру.
Получение выгоды: изменение размеров команд и перепроектирование портфеля
Агентный SDLC может существенно повысить производительность, поскольку теперь меньшие команды могут выполнять бóльшие объемы работы. Первые внедрения показывают, что большие команды из
Для получения выгоды организациям следует сосредоточиться на трех приоритетах. Во-первых, это переквалификация персонала. В то время как центральной команде необходимы навыки для разработки и поддержки фабрик агентов (обеспечение стандартизации и соответствия нормативным требованиям, внедрение передовых методов и т. д.), инженерам-программистам по всей организации необходимо развивать навыки принятия решений, код-ревью и управления агентами, с которыми они работают. Роли смещаются от ручной координации и тестирования к обеспечению согласованности архитектуры, моделированию предметной области и управлению ИИ.
Во-вторых, необходимо обеспечить участие в агентной разработке всех «внешних» звеньев — специалистов по поддержке и соблюдению нормативных требований в отделах рисков, юриспруденции, тестирования и закупок. Без этого ускоренный SDLC не приведет к ускорению прогресса. Агенты и автоматизация (например, с помощью политики как кода) могут помочь гарантировать, что эти механизмы контроля не станут узкими местами, одновременно повышая качество, согласованность, полноту и отслеживаемость. Эти механизмы контроля должны быть заложены в основу проекта, а не становиться препятствием в конце процесса.
И третье — это перепроектирование распределения ресурсов таким образом, чтобы повышение производительности приводило к созданию новой ценности. Освобожденные ресурсы часто реинвестируются для ускорения реализации дорожных карт, модернизации платформ или запуска новых продуктов.
Главный вывод: повышение производительности может быть преобразовано в структурные изменения портфеля. Измените размер команд и сознательно перераспределите ресурсы, чтобы получить максимальную выгоду.
Трансформация должна начинаться там, где ее влияние наиболее велико. В большинстве технологических организаций бóльшая часть общих расходов приходится на небольшое количество крупных программ. Целенаправленное выполнение этих инициатив — будь то модернизация унаследованных систем, переделка существующих объектов или запуск новых продуктов — максимизирует видимый эффект и ускоряет обучение.
Если агенты возьмут на себя выполнение задач в масштабе и будут создавать надежный и стабильно безопасный код, роль человека будет концентрироваться в архитектуре, оценке продукта и проектировании систем, что сделает институциональные знания и техническую согласованность решающими факторами дифференциации. Организации, которые начнут развивать эти возможности в рамках более широких усилий по перестройке своей операционной модели, не просто будут двигаться быстрее; они переосмыслят то, как ПО создает ценность.
