Внедрение ИИ в разработку ПО в команде

Команда постепенно передаёт агентам выбранные работы по производству ПО, осваивает взаимодействие с ними и расширяет автономность по результатам реальных задач. Внедрение развивает три связанные области: люди, процессы и технологии.

Внутри команды сохраняются этапы Подготовка → PoC → Пилот. Они задают порядок внедрения; типы работ и режимы человеческого контроля выбираются для отдельных потоков задач и меняются по подтверждённым результатам.

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

1. Цели

Цель внедрения — сокращение сроков поставки и снижение трудозатрат на производство ПО при сохранении требуемого качества и удержании рисков в допустимых пределах.

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

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

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

Это роли показателей относительно цели, а не три вида целей. Например, дефекты — метрика баланса при ускорении поставки и метрика результата при улучшении качества. Увеличение числа агентских задач или уменьшение HITL само по себе не доказывает полезного эффекта. Разделение на предприятие и команду сохраняется; общая матрица и правила применения раскрывают обе оси.

Команда задаёт область улучшения, срок проверки и критерий успеха, опираясь на исходные данные. Для каждого ожидаемого эффекта выбираются показатели процесса и баланса, нужные для решения. Расчёт трудозатрат и сроков — по определениям и формулам метрик. Выбранные цели, границы и источники фиксируются в плане мониторинга; процедура согласования — в гайде РП.

Типовые метрики

Выбираются показатели, связанные с целями внедрения и условиями продукта; целевые значения и срок наблюдения задаются в плане мониторинга.

2. Принципы внедрения

Автономная работа на платформе

Агент выполняет порученную работу самостоятельно: читает материалы проекта, использует инструменты, изменяет код, запускает проверки и предоставляет результат. Для непрерывного выполнения нужна платформа, подключённая к инференсу и системам проекта. Работа не зависит от открытого персонального сеанса участника команды.

Чат-бот обеспечивает взаимодействие людей с системой: принимает поручения и ответы, доставляет обращения и сообщает результаты. Команда разрешает брать готовые задачи сообщением в установленном чате либо переводом в заданный статус трекера. Конкретные условия допуска, полномочия и защита от повторного запуска задаются маршрутом работы с агентами.

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

Постепенное расширение работ и контроля

Для каждого потока команда отдельно определяет:

1. Какие работы выполняют агенты: например, техническое проектирование, реализацию кода, создание тестов, выполнение тестирования, исправления, ревью или интеграцию в разрешённой области.
2. Как люди проверяют результат каждой работы: HITL, HOTL или без плановой ручной проверки.

Эти параметры изменяются независимо. Можно поручить агентам больше работы, сохранив прежние человеческие проверки. Можно перевести проверенный вид работ с HITL на HOTL, не расширяя область задач. Новый тип задач требует своей проверки применимости прежних навыков и режима контроля.

HITL, HOTL и работа без плановой ручной проверки

Здесь HOTL означает асинхронный контроль человеком. Human-out-of-the-loop обозначает отсутствие такого оперативного участия; для нашей схемы этому соответствует выбранная область без плановой ручной проверки. Различие in/on/out используется в инженерной литературе; конкретный порядок асинхронного контроля ниже задаётся этой методологией.¹

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

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

Любое обращение HITL и сообщение о находке HOTL система направляет через чат с указанием наступившего события и ссылками на задачу и материалы. Различие в том, блокирует ли человеческое действие соответствующий переход. Режим и его область должны быть понятны исполнителям и проверяющим.

Пример постепенного повышения автономности

Ниже показан возможный путь для потока изменений форм и правил продукта. Это пример состава работ и проверок; конкретные типы задач, достаточность контроля и условия переходов определяет команда.

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

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

Как менять режим

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

Для замены ручной регрессии нужна работающая автоматическая регрессия с подтверждённым покрытием заменяемых проверок. Для HOTL дополнительно нужен способ своевременно обнаруживать и исправлять находки после продвижения задачи. Проверки нового или рискованного поведения сохраняются в достаточном объёме.

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

Развитие навыков

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

Для ревьюера закрепляются нужные классы проблем, для тестирующего агента — сценарии и подтверждения, для исполнителя — порядок работы и условия обращения к человеку. Нетиповая задача сначала требует адаптации подхода. Часть ограничений модели компенсируется инструкциями, часть — изменением размера задачи, инструментов, модели или участия человека. Особенности работы с GLM 5.3.

3. Люди

РП, владелец продукта и ИИ-инженер организуют внедрение. Аналитики, разработчики и тестировщики обеспечивают HITL и HOTL в своей зоне ответственности. По мере развития часть плановых проверок заменяется автоматическими; ответственность за правила, решения и качество остаётся у назначенных участников.

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

На PoC ИИ-инженер подбирает калибровочные задачи с командой, ведёт выполнение с агентом и помогает отработать рабочий цикл. Участники продукта дают ответы и проверяют результаты. На Пилоте задачи ставит и ведёт команда продукта; MR и доказательства поступают её проверяющим. ИИ-инженер обеспечивает сопровождение и не становится обязательным промежуточным ревьюером.

Специалист сопровождения постепенно передаёт освоенные инженерные обязанности специалисту клиента. Фактическая передача фиксируется по результатам совместной работы и не является отдельным условием начала Пилота. Подробные обязанности — в гайде команды и гайде ИИ-инженера.

4. Процессы

Группы работ внедрения

Этапы и контрольные точки

Сроки уточняются по условиям продукта. Переход определяется проверенными результатами.

Подготовка

Результат

• Определены цели внедрения.
• Определены и согласованы проект, команда, инфраструктура, правила работы.
• Подготовлены все технические средства: ИИ-платформа, языковая модель, инструменты конвейера (Git, трекер задач, тестовые среды).
• Обеспечены все сетевые связности и доступы.

Что делаем

Работы могут идти параллельно с учётом зависимостей. В общем плане Подготовка остаётся одной строкой; подробная готовность проверяется по её результатам.

Шаблоны и примеры открываются из гайдов и каталога. Каталог ещё требует устранения повторяющихся форм; новый комплект не должен требовать повторного заполнения одних сведений.

Переход к PoC

GATE-01: выполнены применимые условия готовности к PoC. Подтверждены платформа, доступы инженера и интеграции платформы, материалы и условия минимального пути первой задачи. Остаток работ не блокирует этот путь и имеет место в плане.

РП внедрения и РП клиента собирают подтверждения; решение принимают назначенные в проекте участники. Выход: начать PoC либо выполнить конкретные недостающие работы и повторить проверку.

PoC: четыре недели калибровки

Результат

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

Три фазы PoC

Программа применимых кейсов задаёт, что проверить; журнал PoC сохраняет результаты и доказательства. Сейчас шаблон журнала объединяет программу и историю; их разделение предусмотрено планом перестройки. Минимум онбординга — подмножество той же программы, а не второй независимый список возможностей.

Как работаем во всех трёх фазах

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

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

По мере запуска агента внедрения ему передаётся ведение документов: сначала по запросам ИИ-инженера, затем по проверенным событиям и расписанию.

Переход к Пилоту

GATE-02: готовность к Пилоту подтверждена результатами PoC. Проверен выбранный поток и целевой для Пилота контур; назначены участники команды продукта, подготовлены рабочие правила, мониторинг и первый недельный бэклог.

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

Пилот: работа команды продукта

Результат

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

Задачи ставят и ведут участники команды продукта. MR и доказательства поступают назначенным разработчикам, тестировщикам и принимающим. ИИ-инженер сопровождает платформу и помогает в сложных случаях; его постоянное первичное ревью не становится обязательным звеном потока.

Еженедельный цикл

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

Наблюдение на Пилоте

Задачи учитываются в недельных когортах. Рекомендуемое окно оценки — неделя запуска и две следующие недели наблюдения; правила расчёта — в метриках. Ежедневный сбор и недельный разбор описаны в разделе «Мониторинг и цикл улучшения» ниже.

Сопровождение и улучшение

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

Передача инженерных обязанностей

Специалист сопровождения передаёт знания и инженерные обязанности специалисту клиента постепенно. Начало и темп определяются проектом; фактическая передача отражается в журнале. Эта передача не меняет обязанность команды продукта вести задачи на Пилоте и не является отдельным обязательным гейтом.

Завершение Пилота

GATE-03: одно из двух оснований подтверждено:

• Целевые показатели достигнуты; область, качество и ограничения измерений отражены в итогах.
• Цели ещё не достигнуты, но вся рабочая команда клиента и сопровождения, включая стейкхолдера, поддерживает конкретный план их достижения. Поддержка и открытые возражения фиксируются; молчание не считается поддержкой.

Решение и дальнейшие действия записываются в журнале Пилота. Если основания не выполнены, определяется продолжение с планом, приостановка или остановка. Самостоятельность клиента не является критерием; инженерное сопровождение может продолжаться.

Два процесса команды и работа с агентами

В команде описываются два связанных процесса:

• Статусная модель задач: состояния, переходы, готовность, приёмка, завершение и ответственность.
• Ветки, MR и ревью: правила изменения кода, проверок, исправлений и интеграции.

Работа с агентами ссылается на них и определяет способы запуска, полномочия, плановые точки HITL/HOTL и обращения, возникающие по навыкам агента. Любое HITL-обращение доставляется через чат с указанием события и материалов; HOTL-находка также связывается с задачей и проверенной ревизией.

Для каждого выбранного вида работ понятно, что делает агент, какое подтверждение требуется, кто принимает оставшееся решение и что происходит при исключении. Подробные статусы и правила MR ведутся в своих документах; здесь описан порядок их применения при внедрении.

Развитие процессов продукта и тестируемости

Человеческая команда часто компенсирует недостатки процесса вручную: помнит нужные данные, переключает внешний стенд, ждёт несколько дней таймера, исправляет БД или проверяет изменение на своём компьютере. Для автономного выполнения эти действия нужно сделать доступными, явными и воспроизводимыми.

Развитие включает описание требований и сценариев, версионирование изменений БД, подготовку и восстановление данных, управление средами, моками и временем, повторяемый запуск тестов и сохранение доказательств. У процесса есть правила выполнения и ответственности; соответствующие технические инструменты описаны в разделе «Технологии».

Например, для интеграционного сценария определяется, кто задаёт ответ внешней системы и как проверить вызов; инструмент моков делает это программно. Для истечения срока выбирается проверяемый сценарий; управление временем позволяет пройти его без ожидания реальных суток. Для приёмки задаётся правило фиксации версии; DEV/UAT-процесс обеспечивает, что результат не изменится посреди проверки.

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

Мониторинг и цикл улучшения

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

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

Улучшения проверяются короткими циклами PDSA: спланировать → попробовать → изучить → скорректировать. До изменения команда формулирует ожидаемый эффект, выбирает ограниченную область проверки, исполнителя и срок разбора. После проверки сравнивает фактический результат с ожиданием, включая побочные эффекты, и решает: сохранить изменение, доработать или отказаться. Запись ведётся в существующем журнале PoC или Пилота; отдельная форма для каждой задачи не требуется. Правила и пример цикла.

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

5. Технологии

Рабочая инфраструктура автономного агента

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

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

Тестовые среды: минимум — возможность E2E

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

Среда может быть меньше production по мощности и данным, но должна воспроизводить важные для задачи компоненты и связи: приложение, БД, очереди, фоновые операции, настройки и интеграции. Различия, заменённые зависимости и непроверенные свойства перечисляются явно. Иначе локально правильное изменение может скрыть ошибку взаимодействия, которую обнаружат только при интеграции или эксплуатации.

Быстрые unit-, компонентные и API-проверки дополняются сквозными сценариями на таком стенде. Управляемые моки позволяют изолировать внешние зависимости и проверять отказы; совместимость с реальным поставщиком подтверждается отдельным доступным способом. Приёмка по мокам не выдаётся за проверку реального внешнего контура.

DEV и UAT — назначения, а не обязательные названия стендов. Существующая UAT может использоваться при подходящих условиях; число независимых DEV определяется параллелизмом, действующий ориентир — 2–4. Код собирается в артефакт, публикуется и развёртывается по точной версии. Разработчик не должен предварительно вливать незавершённую задачу в общую ветку только ради её проверки.

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

Что обеспечивается на каждом этапе

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

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