Мы пытались заменить QA нейросетью. Не получилось

Вступление

Хочется поговорить о том, что происходит с QA в 2026-м и правда ли, что «нас вот-вот заменит ИИ». Но не в формате очередного треда в духе «всё пропало» или «всё отлично, завтра уволим половину отдела». А по-взрослому: с опытом, цифрами, ограничениями и выводами. То есть попробовать не просто порассуждать, а разобрать тему как небольшое исследование: что реально меняется, где ИИ помогает, а где начинается та самая реальность, которая не влезает в красивую презентацию.

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

«Сейчас наймём SDET, который шарит в ИИ-шке. Он сделает нам умные AI-инструменты, и мы больше не будем нанимать QA-инженеров».

На бумаге — идеально. Почти как «давайте просто перепишем легаси». Немного магии, чуть-чуть “агентов”, и всё само. Только это не стратегия, а магическое мышление ^[1]: когда сложную проблему хочется решить одним модным словом.

Спойлер: SDET мы действительно наняли. Прошел год. Ничего революционного не случилось. QA-инженеров мы как нанимали, так и нанимаем. Гладко было на бумаге, да забыли про овраги. И вот эти «овраги» — самое интересное.

Я расскажу, во что именно мы упёрлись, почему «автономный ИИ-заменитель QA» не взлетел, и какие ограничения оказались не теоретическими, а очень практическими: про контекст, доверие, стоимость ошибок и тот самый момент, когда «о, так это же почти бесплатно» внезапно превращается в «а кто это будет разгребать?».

Изначальная цель звучала красиво и даже немного нагло: сделать MCP-сервер ^[2], которому можно сказать что-то вроде:

«Протестируй мне TASK-1111»

…и дальше он сам:

• создаёт ветку,

• читает спеку,

• находит нужные контракты,

• пишет тесты,

• коммитит,

• открывает MR,

• и, желательно, ещё и чинит, если CI упал.

Ну то есть мечта любого руководителя: «всё как раньше, только без людей».

Сразу важная оговорка: я не против ИИ — совсем наоборот. Я сам делаю инструменты, которые помогают применять его в инженерной работе, например ai-review ^[3]. Просто у меня позиция простая и приземлённая: ИИ — это усилитель и помощник. Он ускоряет механику. Но он не заменяет ответственность, контекст и способность принимать решения.

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

Цена: «о, так это же почти бесплатно»

Начнём с причины, по которой вообще появляется идея «заменить QA ИИ». Не из любви к прогрессу, а из очень простого вопроса:

что дешевле — AQA-инженер или MCP-сервер ^[2], который сам читает спеку и пишет тесты?

Логика кажется железной: если машина может всё сделать сама, зачем платить зарплату человеку? Обычно в этот момент кто-то говорит сакраментальное:

«Давайте сначала посчитаем токены».

Посчитали. Удивились. Обрадовались. И сделали первый неверный вывод.

Потому что токены — это вообще не то, чего боятся компании. Боятся другого: что агент закоммитит баг в прод, что тесты будут зелёные, но бесполезные, или что в логах внезапно утекут секреты. Стоимость таких ошибок сильно выше стоимости любого QA. Но математику всё равно стоит проговорить.

Берём реалистичную задачу. Спека на ~3000 строк, контракты ещё на 500, контекст существующих тестов — около 1500. Даже при очень аккуратной оценке это порядка 75 тысяч токенов на вход и ещё ~20 тысяч на выход (тесты, diff, коммиты). При текущих ценах ^[4] уровень GPT-5.2 это даёт примерно $0.41 за один прогон.

И вот тут обычно звучит радостное:

«О, так это же вообще бесплатно!»

Это и есть ловушка.

Потому что в реальной жизни не бывает «одного прогона». Агент читает спеку, пишет тесты, коммитит — CI падает. Он читает логи, чинит — CI падает ещё раз. Потом ещё раз. И только потом становится зелёным. 10–20 итераций — это не экзотика, а норма.

В итоге одна задача стоит не $0.41, а $4–8. Всё ещё дёшево. Но теперь умножаем. Пусть 200 таких задач в месяц — получается около $1 600, и это только токены. Без инфраструктуры, без поддержки пайплайна и без людей.

А теперь важный момент, который обычно забывают: оператор всё равно нужен. Не «пока ИИ слабый», а структурно. Кто-то должен понять, почему агент упал, решить, что чинить — тест, код или саму спеку, выбрать, какой контекст подкинуть в следующей итерации, и сделать финальное ревью MR. Это не кнопкодав. Это QA или SDET уровня middle+.

В этот момент расчёт «AI vs QA» перестаёт иметь смысл. Реальность — это «AI + оператор + поддержка vs QA». LLM не убирает людей, она просто сдвигает их работу и добавляет ещё один слой сложности. Экономии «по головам» нет, есть лишь потенциальный рост throughput — если всё идёт идеально.

Самая частая ошибка менеджмента в этом месте звучит так:

«Ну оператор же просто перезапускает».

Нет. Он читает CI, понимает нестабильность тестов, видит неверные assertions и принимает риск-решения. Это инженерная работа, а не support.

Итог здесь очень простой. $4–8 за задачу — действительно дёшево. Токены — не проблема. Проблема в контексте, количестве итераций, недетерминизме, ложной уверенности и цене доверия к системе.

Экономически это выглядит привлекательно.

• Инженерно — нестабильно.

• Организационно — рискованно.

• И стратегически — QA это не заменяет.

Контекст: «что тестировать?» — это не чтение текста, это поиск истины

Следующая «яма на дороге», в которую мы красиво въехали, называлась контекст. Точнее — его сбор.

Со стилем тестов всё просто: договорённости команды, фреймворк, фикстуры — это ещё можно зафиксировать в системном промпте. Мол, «пиши тесты вот так, называй файлы вот так, используй такие фикстуры». Казалось бы, победа.

А потом приходит обычная задача из трекера:

«Реализуйте новый эндпоинт GetUserAccounts. Вот ссылка на контракт, вот ссылка на спеку».

В теории всё стерильно. Открываем спеку, читаем. Открываем диаграмму из спеки, читаем. Открываем контракт, читаем. Складываем всё в LLM, получаем тесты, коммитим, пьём чай.

На практике… добро пожаловать в spec hell.

Открываешь «спеку» — а там 20 000 строк текста и куски кода. Часть уже устарела, часть «будет в следующем релизе», часть актуальна, но непонятно какая именно. Внутри — ссылки на другие спеки, а внутри них — ссылки на третьи. Контракты тоже не скучают: одна protobuf-модель состоит из семи других моделей, которые состоят из enum’ов, которые ссылаются на ещё пару моделей. Плюс интеграции: сервисов не два, а, допустим, десять. И у каждого свои контракты и свои «истины».

В этот момент идея «давайте просто соберём контекст и скормим в модель» превращается в инженерный проект под названием:

«Построим монструозный парсер, который работает раз через раз, собирает 30k строк контекста, а потом мы ещё попробуем вычленить из этого нужное».

И самое смешное: в начале мы вообще не учитывали, что так будет. На бумаге всё выглядело как «ну откроем ссылку и прочитаем». На слайде всё сходилось, а в реальности открылся Confluence.

Но главное даже не в объёме. Главная боль в другом: в реальности “что тестировать” — это не чтение текста, это поиск источника правды.

Типовая цепочка выглядит примерно так:

таска → ссылка на спеку → в спеке ссылки → в ссылках MR на протос → потом swagger → потом код → потом внезапно Kafka.

И это нужно не просто «прочитать». Нужно понять три вещи: где правда, что считается успехом, как это верифицировать. Правда может быть в Confluence, а может быть в протосах, а может быть в коде и логах, потому что «спека у нас для красоты». Успех — это что? Ответ 200? Или воркфлоу стартанул? Или событие упало в Kafka топик? А проверять это как: контрактно, интеграционно, e2e, через мок Kafka?

Человек-QA решает это не парсером. Он решает это опытом и коммуникацией. Пример из жизни выглядит не как «прочитал спеку», а как:

«Привет, а retry by date для Mastercard — это lastUpdate или transactionPeriod?»

И вот эту «социальную часть» контекста LLM обычно не добирает. Она выбирает первое правдоподобное объяснение, пишет тесты, и они даже могут стать зелёными. Просто проверяют не то.

Отсюда неприятный, но очень практичный вывод. Если вы хотите «коробку, которая сама тестирует задачи», она должна уметь не “читать Jira”, а делать почти невозможное: индексировать Confluence/GitLab/репы/протосы/диаграммы, понимать что актуальнее (версии, даты, owner’ы), вытаскивать минимальные релевантные куски под задачу, и при этом не утекать секретами. Это уже не «прикрутим LLM к трекеру». Это продукт уровня «сделаем свой search + governance». То есть отдельная история, отдельная команда и отдельная стоимость владения.

И да, про стиль тестов тоже есть нюанс. Чтобы агент писал «как принято у нас», ему нужно знать не только “pytest”, а ваши конкретные договорённости: как поднимать окружение, как мокать внешнее (партнёров, интеграции, Temporal, Kafka, Redis, PostgreSQL), как именовать кейсы, где лежат фикстуры, какие теги обязательны. Иначе получится классика:

тесты есть → команда их ненавидит → через месяц удалили.

Контекст — это не “много текста”. Контекст — это то, что в голове у команды. И именно здесь идея «заменим QA агентом» начинает трещать по швам.

Качество: когда всё звучит правильно, но проверяется не то

Слово «качество» — это вообще то, с чего начинается любой QA. Мы про баги, про риски и про довольных пользователей. И вот именно здесь у ИИ начинаются самые тонкие и неприятные проблемы.

Представим идеальный день. Спеку мы вычитали, контекст каким-то чудом собрали, тесты сгенерировали, CI зелёный. Красота. И почти всегда в этот момент выясняется одна вещь: тесты проверяют только happy path. Аккуратно, уверенно, с красивыми именами — но ровно то, что и так очевидно.

Проблема в том, что самые важные нюансы почти никогда не живут в спеках. Например: «мы не можем выдать пользователю кредит, если у него нет кредитной карты». Это не баг, не edge case и не “опциональное поведение”. Это глобальное правило продукта. Его все знают, все обсуждали, но в спеке конкретного эндпоинта его, конечно же, нет. Потому что «это и так понятно».

LLM этого «и так понятно» не видит. Она честно проверяет то, что написано, и не проверяет то, что подразумевается. В результате тесты выглядят правильно, но качество при этом не растёт.

С кодом и тестами есть ещё одна неприятная особенность: LLM может звучать уверенно и быть неправой. Для внутреннего эксперимента это терпимо. Для коробочного продукта — смертельно. Если система должна сама коммитить код, бизнес ждёт от неё предсказуемости. А агент вполне может неправильно интерпретировать retry-семантику, написать зелёные тесты, которые не проверяют главное, подменить реальный контракт моками или собрать brittle E2E, падающий от любого чиха.

Формально всё работает. CI зелёный. А доверия нет. А без доверия никакая автоматизация качества не живёт.

И вот здесь проявляется ключевая разница между генерацией тестов и обеспечением качества. Качество — это не «покрыть код». Это умение задать правильный вопрос системе. И пока этот вопрос рождается только в голове человека, ИИ остаётся помощником, а не носителем качества.

Коммуникация: «а точно ли мы это так поняли?»

Есть одна вещь, без которой QA в принципе не существует — умение остановиться и спросить. Даже когда задача описана, спека написана, контракты лежат рядом, опытный QA всё равно периодически задаёт неудобный вопрос:

«Слушай, а вот этот нейминг точно такой?
А это условие правда должно работать именно так?»

Иногда вопрос занимает пять минут и экономит несколько дней. Иногда выясняется, что спека устарела. Иногда — что аналитик имел в виду совсем другое. Это не «лишняя болтовня», а встроенный механизм защиты качества.

С MCP-сервером ^[2] тут начинается совсем другая история. Он, разумеется, ничего не уточняет. Если что-то неочевидно — он додумывает. Причём делает это уверенно и последовательно, как и положено хорошей модели.

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

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

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

Нестабильность: «а ещё тут интернет, интеграции и реальный мир»

Есть ещё один пункт, который в подобных идеях обычно сильно недооценивают — нестабильность. Мы тоже недооценили. На бумаге всё выглядело аккуратно: MCP ^[2] ходит в Jira, читает спеку из Confluence, берёт код из GitLab, пишет тесты и живёт счастливо. В реальности оказалось, что мы построили систему, которая постоянно общается с внешним миром. А внешний мир, как известно, не любит быть детерминированным.

Где-то не учли пагинацию. Где-то поле внезапно перестало приходить. Где-то коннектор начал падать, потому что у проекта сменился owner или токен протух. Плюс ретраи, таймауты, сетевые ошибки, переезды, обновления схем. В итоге система жила в состоянии перманентного «вроде вчера работало». Очень много bus-factor’а и очень много нестабильных сред.

А дальше начинаются зависимости уровнем глубже. Проверить Temporal? Нужно сходить в API или UI. Проверить данные? Нужен доступ в базу. Взять креды? Идём в Vault. И каждая такая точка — ещё один шанс, что что-то пойдёт не так. Причём не потому что «сломалось», а потому что мир вокруг поменялся.

Кейс «тест триггерит workflow в Temporal» — вообще классика жанра. Чтобы такой тест был хоть сколько-то честным, агенту нужен доступ к стендам, секретам, партнёрским песочницам или мокам, очередям и топикам, логам и самому Temporal. И это ещё не всё. Такие тесты почти всегда имеют побочные эффекты: дубли ретраев, повторную обработку событий, иногда — реальные деньги или кэшбек ^[5].

И вот тут внезапно выясняется, что «коробочный продукт для автотестов» должен уметь не только писать код. Он должен уметь не ломать прод, не флудить партнёров, изолировать данные, чистить за собой и делать rollback. Это огромный слой инженерии вокруг, который вообще не имеет отношения к LLM.

Заключение: «заменить — нет, усилить — да»

Эта история начиналась вполне серьёзно. Мы действительно пытались сделать MCP-сервер ^[2], который мог бы реально заменить AQA-инженера: читать задачи, разбираться в спеках, писать тесты, коммитить код. Роль человека при этом виделась простой — оператор, который иногда нажимает кнопку и смотрит, что получилось.

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

Самый важный вывод, который из этого вылез сам собой:

QA в реальных системах — это не “делатель тестов”, а носитель контекста.

Человек, который понимает, где правда, что важно проверить, где риск, а где просто шум.

Да, MCP-серверы ^[2] и агентные системы могут работать. Мы это видели. Но чем сложнее задача, тем больше вокруг неё инфраструктуры, ручных решений и инженерной поддержки. И в какой-то момент стоимость разработки, стабилизации и эксплуатации такого «чуда» начинает превышать любые разумные пределы — без заметного выигрыша в качестве.

Именно поэтому ответ на вопрос «заменит ли нас нейронка?» довольно прозаичный.
Нет, не заменит. По крайней мере там, где есть сложный продукт, живые интеграции и реальные пользователи. Зато она уже сейчас меняет роль QA: меньше механики, больше мышления ^[1], больше ответственности за решения.

Даже если AI станет в 10 раз умнее, роль QA не исчезнет, потому что проблема не в интеллекте, а в ответственности и выборе.