Эволюция от ручного тестирования к автономному

Как следование стратегии AI PDLC помогает нам создавать ИИ-инструменты для разработчиков.

В практике любой крупной ИТ-организации присутствует категория технического долга, которая редко отражается в отчётности, но сопряжена с существенными издержками, — накопленный объём ручных тест-кейсов, подлежащих автоматизации. Написание каждой такой автоматизированной проверки с нуля требует значительных трудозатрат, а очередь растёт быстрее, чем команда успевает её сокращать. Это отражается и на скорости вывода функциональности, и на полноте тестового покрытия.

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

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

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

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

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

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

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

Одновременно была заменена и ИИ-модель, после чего доля правок снизилась в разы. Существенная оговорка: замена модели сама по себе такого результата не дала бы. Это подтверждает базовый тезис методологии — наиболее ценным активом является не сама модель, а окружение, в котором она работает: контекст, условия, границы и правила. Модель заменяема и приобретаема, окружение организация строит самостоятельно.

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

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

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

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

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

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