В статье, опубликованной в корпоративном потоке «Разработка», Александр Чернышев, занимающийся тестированием мобильных приложений hh.ru, описал, как за последние полгода его рабочий процесс кардинально изменился благодаря внедрению ИИ-инструментов. Основным инструментом стал Claude Code с моделью Opus 5, который, по словам автора, лучше всего справляется с рабочими задачами. У Чернышева подписка Max, поэтому лимитов хватает с запасом, и он подключает агента к большинству своих задач. Ключевая особенность подхода — использование так называемых скиллов: инструкций, которые задают агенту последовательность действий и не дают ему каждый раз импровизировать. Вместе со скиллами применяются MCP-серверы и плагины для взаимодействия с внешними инструментами, например Figma.

Процесс тестирования разбит на несколько этапов, и на каждом из них агент выполняет конкретную роль. Первый шаг — генерация чек-листа на основе кода. В hh.ru нет разделения на ручных и авто-QA: каждый инженер работает с кодом напрямую. При поступлении задачи тестировщик открывает Claude Code CLI или Desktop из фиче-ветки и запускает скилл /generate-test-instructions, который представляет собой markdown-файл с инструкцией для агента. Агент анализирует diff и собирает чек-лист из пяти фиксированных разделов: затронутые модули, что изменилось, регресс, что проверить, аналитика и конфиги. Пошаговые сценарии намеренно не используются, так как тестировщик знает приложение лучше модели, которая видит только diff. Задача агента — показать, что изменилось и где искать потенциальные проблемы. Сейчас скилл автоматически вызывается на уровне CI при создании пулл-реквеста, и тестировщику остаётся только забрать готовый чек-лист.

Второй этап — сверка с техническим заданием и макетами. Агент актуализирует чек-лист, сопоставляя его с ТЗ из Jira и макетом из Figma. За ТЗ отвечает скилл /read-jira, который через MCP-сервер Jira получает данные задачи, включая ключ и описание. С макетами работает Figma MCP: он даёт агенту доступ к структуре нод и скриншоту. В Figma копируется ссылка на конкретный слой через Copy link to selection, чтобы в ней был параметр node-id — без него агент читает фрейм целиком и тратит лишние запросы. Агент читает ноду, подмечает размеры, вложенные блоки, тексты и сравнивает с кодом. В итоге у него три источника: код, ТЗ и макет, что позволяет ещё до ручного тестирования найти расхождения, например баги вёрстки или отсутствующие части флоу. Это сокращает время и повышает качество.

Третий шаг — кросс-платформенная сверка iOS и Android по одной фиче. Скилл /hh-mobile-crossplatform находит реализацию фичи в обоих репозиториях и ищет расхождения по 14 осям: бизнес-логика, состояния экрана, крайние случаи, аналитика, эксперименты, API, кэш, сетевые ошибки, авторизация, оффлайн, конфигурация, навигация, тексты, тесты. На выходе получается саммари с различиями между платформами. Это помогает заметить то, что могли упустить при декомпозиции: например, на одной платформе обработали граничный случай, а на другой нет. QA и разработчики сразу видят такие расхождения и решают, какие из них ожидаемы, а какие требуют проверки. Такой подход снижает риск пропуска ошибок и ускоряет выявление несоответствий.

Четвёртый этап — ручное тестирование с использованием симулятора в Claude Code. В июле 2026 года в Claude Code Desktop встроили iOS Simulator (пока в публичной бете, только на macOS). Агент может собрать iOS-приложение, установить, запустить, прокликать чек-лист и проверить результат. Достаточно команды: «Собери и запусти приложение, проверь его по чек-листу». Однако Чернышев отмечает, что не сильно доволен симулятором: по скорости человек выигрывает в 10–30 раз, агент может «тупить» и быстро съедать лимиты. Кроме того, только человек способен оценить UX: насколько понятен сценарий, удобен ли интерфейс, где пользователь может запутаться. Агент работает только в симуляторе, который использует процессор Mac, а тестировать нужно на реальном устройстве, чтобы выявить проблемы с производительностью и холодной загрузкой.

Контекст: статья опубликована в потоке «Разработка» наряду с другими материалами об ИИ. Например, Сергей Прощаев из FinTech & E-commerce предупреждает, что open-weight модели догоняют закрытые только на бенчмарках, но в продакшене могут быть ненадёжны. Другой материал описывает автоматизацию разбора резюме с помощью LLM, Python и FMC, где LLM составляет техническую выжимку, но финальное решение остаётся за человеком. Третий — о RuntimeNodes, где ML-инженеры Яндекса рассказывают о создании рантайма для LLM-продуктов. Эти примеры показывают, что ИИ-агенты всё глубже проникают в разработку, но требуют осторожного подхода и контроля со стороны человека.

Для российского рынка опыт hh.ru показателен: компания не просто экспериментирует, а встраивает ИИ-агента в регулярный CI-процесс. Это может стать ориентиром для других IT-компаний, особенно в мобильной разработке, где тестирование традиционно трудоёмко. Однако остаются открытые вопросы: насколько масштабируемо решение, как быть с лимитами подписки, как обеспечивать безопасность данных при передаче в сторонние MCP-серверы. Также неясно, насколько агент способен заменить ручное исследовательское тестирование, ведь UX-оценка пока остаётся за человеком. В перспективе можно ожидать развития симуляторов и улучшения моделей, но полностью автономный QA-агент, вероятно, появится нескоро. Пока же hh.ru демонстрирует гибридный подход, где ИИ берёт на себя рутину, а человек — стратегические и творческие задачи.