В профессиональном сообществе разработчиков активно обсуждается будущее профессии QA-инженера в связи с распространением ИИ-агентов. Михаил Новотарский, руководящий внедрением ИИ-практик в трайбе внутренних продуктов Workspace в Сбере, опубликовал размышления о том, как меняются команды и роли под влиянием автоматизации. Он вводит понятие «QA-киберагент» — тестировщик, который постоянно развивает навыки и адаптируется к новым условиям. Этот образ используется как отправная точка для анализа четырёх ключевых тем: трансформация команд, появление новых ролей, рост когнитивной нагрузки и подготовка к изменениям. Классический процесс разработки от идеи до выпуска включает исследование, планирование, проектирование, разработку, тестирование и выпуск. На каждом этапе появляется ответственный, а между ними возникает коммуникация, которая часто становится узким местом. Первая интуитивная идея — добавить быстрый ИИ-инструмент на каждый этап — не решает проблему целиком. Даже если каждый шаг ускорится, согласование, передача контекста, проверка и утверждение результата останутся. Узкие места перемещаются из отдельных операций в интеграцию между людьми и инструментами. Поэтому простое добавление ИИ в существующий процесс неэффективно — требуется менять организацию работы.

Исследования McKinsey показывают, что под влиянием ИИ классические продуктовые команды, ограниченные «правилом двух пицц», начинают меняться. В них остаются продукт-менеджер, техлид и разработчики, но каждого усиливают специализированные агенты, а другие роли переходят в разряд сервисных. Возникает новая роль — Product Builder, аналог Full Stack Builder из LinkedIn. Если Full Stack Developer умеет работать с фронтендом, бэкендом и развёртыванием, то Full Stack Builder дополнительно собирает решения из готовых компонентов и активно использует ИИ, реализуя весь процесс самостоятельно. Ключевое отличие — продуктовое мышление, которое смещает фокус с кода на ценность для пользователя. В некоторых компаниях в таких билдеров превращают продуктовых менеджеров, аналитиков и проект-менеджеров, хорошо понимающих бизнес-контекст. Код перестаёт быть главным аспектом разработки, уступая место постановке задачи, спецификациям и проверке результата.

Ещё один тренд — переход к «маленьким командам» (tiny teams), которые отвечают за полный цикл разработки, а значительную часть ручной работы выполняют платформы и агенты. Такие команды могут делать больше без пропорционального увеличения штата. Если раньше для пятикратного роста фич требовалось в пять раз больше людей, то теперь масштабирование идёт за счёт автоматизации и ИИ. Параллельно развивается подход «разработка через намерение», где люди и агенты работают в двух контурах: люди формируют и уточняют спецификацию, а агенты быстро превращают её в результат. Человек может днями обсуждать и переписывать намерение, а агент выдаёт рабочий результат за минуты. Однако скорость генерации — не главное; важнее качество диалога между человеком и агентом: точность формулировки задачи, количество циклов проверки и понимание результата командой. Здесь и возникает неудобный вопрос: где в такой схеме находится QA?

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

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

Сравнение с альтернативами показывает, что полный отказ от выделенной роли тестировщика пока не является мейнстримом. В некоторых методологиях, например в DevOps, тестирование уже интегрировано в процесс разработки, но там речь идёт о сдвиге влево (shift left), а не об устранении специалистов. ИИ-агенты могут взять на себя рутинные проверки, но сложные сценарии, требующие понимания контекста и бизнес-логики, по-прежнему требуют человека. Кроме того, сервисная модель QA для нескольких команд может привести к снижению глубины тестирования и росту рисков. Таким образом, полная замена тестировщиков ИИ в ближайшей перспективе маловероятна, но их роль будет меняться.

В будущем, вероятно, произойдёт разделение на несколько треков. Часть QA-специалистов станет инженерами по качеству, управляющими ИИ-агентами и настраивающими процессы. Другие перейдут в Product Builder, сочетая тестирование с разработкой и аналитикой. Третьи займутся обеспечением качества на уровне платформы, создавая инструменты для автоматической проверки. Открытыми остаются вопросы: как измерять качество работы агентов, кто несёт ответственность за дефекты, как обучать новых специалистов. Ответы на них будут найдены по мере накопления практического опыта. Ясно одно: профессия QA не исчезнет, но её содержание существенно изменится, требуя от специалистов гибкости и готовности к постоянному обучению.