Обзор

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

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

При наличии комплексной стратегии и надежного управления результаты внедрения ИИ могут обеспечить значительную и измеримую окупаемость инвестиций (ROI). Чтобы построить устойчивый жизненный цикл разработки с поддержкой ИИ, основанный на надлежащем человеческом контроле, оцените пять факторов в сфере разработки перед созданием стратегии внедрения ИИ:

Соответствие стеку
Рабочие процессы разработчиков
Безопасность и состояние данных
Атрибуция затрат
Дисциплина оценки и тестирования

Оцените соответствие стеку перед выбором ИИ-технологий

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

Например, пилотная программа, инициированная одной командой, не является мандатом на внедрение во всей компании. Они находят ИИ-инструмент, который хорошо работает в их текущей среде и дает хорошие результаты, из-за чего пилот кажется успешным. Однако локальный успех не всегда перерастает в успех всей компании. Инструмент, который хорошо справляется с генерацией шаблонного кода для нового микросервиса Node.js, необязательно покажет те же результаты на кодовой базе Java или C++ многолетней давности или вообще будет работать.

Оцените соответствие инструмента стеку на основе пяти критериев:

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

Другим важным шагом является оценка базовой инфраструктуры всех инженерных команд. Если она опирается на конкретного облачного провайдера, ИИ-инструменты должны соответствовать этой конкретной облачной архитектуре. Например, Amazon Q Developer, основанный на обработке естественного языка, функционирует одновременно как плагин для IDE и инструмент интерфейса командной строки (CLI). Поскольку он интенсивно обучен на API AWS и устоявшихся шаблонах сервисов, он отлично подходит по стеку для ISV, работающих в средах, ориентированных на AWS.

Определите рабочие процессы разработчиков

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

Формализуйте, на каком этапе жизненного цикла разработки ПО (SDLC) следует использовать ИИ. Например:

Документация
Генерация кода
Превью кода коллегами
Тестирование
CI/CD
Развертывание
Все вышеперечисленное

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

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

Amazon Q Developer обеспечивает встроенное рецензирование кода и сканирование безопасности, сокращая разрыв при проверке сгенерированного кода и позволяя разработчикам оценивать и исправлять результаты работы моделей перед фиксацией.
AWS CodeBuild позволяет применять предварительно настроенные шлюзы проверки перед слиянием в вашем конвейере CI/CD.
Amazon CodeGuru Profiler предоставляет автоматические рекомендации по производительности кода после развертывания.

Выберите и настройте надежную защиту и состояние данных

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

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

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

Помогите защитить позицию вашего ISV, интегрировав элементы управления доступом AWS в развертывания ИИ:

Используйте уровень Pro для Amazon Q Developer, чтобы гарантировать, что при обучении моделей машинного обучения никогда не используются ваши данные.
AWS Identity and Access Management (IAM): используйте AWS IAM для ограничения доступа инструментов к определенным репозиториям и средам. Соблюдайте принцип наименьших привилегий для ИИ-инструментов точно так же, как вы делаете это для людей-операторов.
AWS Secrets Manager: ссылайтесь на учетные данные программным путем и ротируйте ключи, чтобы предотвратить их случайное попадание в окно контекста ИИ-инструмента.
AWS PrivateLink: исключите трафик ваших ИИ-инструментов из публичного интернета, чтобы помочь защитить конфиденциальные среды разработки.

Атрибутируйте и контролируйте затраты на ИИ-инструменты

Инструменты разработки на базе ИИ по модели SaaS стоят недорого по отдельности, но при масштабировании использования до 50 инженеров, использующих три разных инструмента с перекрывающимися возможностями, и умножении этого на переменные затраты на API для пользовательских интеграций ИИ, результирующая статья расходов становится существенной. К сожалению, многие организации обычно видят эти затраты в агрегированном виде и совершенно не привязанными к какому-либо конкретному продукту, инженерной команде или центру затрат.

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

AWS Cost Explorer: связывайте использование сервисов ИИ на базе API, таких как Amazon Bedrock и Amazon Q, с помощью тегов напрямую с командами, проектами или центрами затрат.
Amazon Bedrock: моделируйте ценообразование как по запросу (on-demand), так и с зарезервированной пропускной способностью (provisioned throughput) для рабочих нагрузок ИИ перед развертыванием в рабочей среде.
AWS Budgets: настраивайте упреждающие пороги оповещений специально для расходов на сервисы ИИ, чтобы всплески вызовов API и бесконечные циклы рабочих процессов вызывали предупреждения.

Встраивайте оценку в рабочие процессы с использованием ИИ

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

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

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

Внедрите «дисциплину оценки» в пайплайн CI/CD и продакшен-окружение с помощью нескольких сервисов AWS:

Amazon Q Developer: автоматическая генерация тестов позволяет быстро создавать наборы тестов, которые можно комбинировать с этапами проверки человеком.
AWS CodeBuild: применяйте пороговые значения покрытия к pull request, сгенерированным ИИ, в качестве обязательного условия для слияния.
Amazon DevOps Guru: разверните обнаружение аномалий в продакшене, чтобы выявлять любые отклонения после деплоя, которые могло упустить автоматизированное предварительное тестирование.

Понимание жизненного цикла разработки на основе ИИ (AI-DLC)

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

Модель AI-DLC работает в три этапа:

Фаза зарождения (Inception): команды ведут диалог между моделью и инженерами. Абстрактные бизнес-цели преобразуются в практические требования и определенные единицы работы (Units of Work вместо Epics) для передачи инструмент ИИ.
Фаза создания (Construction): используя контекст, сформированный на этапе Inception, ИИ генерирует логическую архитектуру, доменные модели и кодовые базы, пока инженеры принимают технические решения в реальном времени и обновляют контекст для завершения кода.
Фаза эксплуатации (Operations): инструмент ИИ использует полный контекст, накопленный в ходе этого процесса, для управления инфраструктурой как кодом (Infrastructure as Code) и пайплайнами развертывания.

Поскольку инструмент ИИ берет на себя рутинную генерацию артефактов, AI-DLC может сократить традиционные многонедельные циклы разработки до высококонцентрированных периодов работы, выполняемых за часы или дни и называемых Bolts.

Методология AI-DLC построена вокруг определенного структурного цикла.

Инструмент ИИ создает черновик первоначального плана проекта и определяет пробелы в собственном контексте
Инженеры предоставляют точные разъяснения и осуществляют контроль
Инструмент ИИ выполняет скорректированный шаг и запрашивает новые уточнения

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

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

Используйте стратегический подход к оценке инструментов разработки ПО на базе ИИ

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

Команды по закупкам и безопасности корпоративных клиентов положительно относятся к ISV, которые могут продемонстрировать комплексное управление ИИ (AI governance), в том числе в своих рабочих процессах разработки на базе ИИ. Для соответствующих требованиям ISV, чьи инженерные практики готовы к корпоративным сделкам, такие программы, как AWS ISV Accelerate, могут помочь извлечь выгоду из этой зрелости, согласовав стратегию выхода на рынок с региональными продавцами AWS.