Используете ИИ для написания кода? Объясняем, как его правильно тестировать

ИИ теперь пишет код быстрее разработчиков. По данным New Relic, две трети технических лидеров говорят, что нейросети уже создают или улучшают больше половины их еженедельного объёма кода. А 88% компаний разрешили применять ИИ не для тестов, а в реальной работе. Скорость разработки выросла, но главная проблема теперь не в том, чтобы написать код, а в том, чтобы быть уверенным: его можно спокойно запускать в прод.

Исследование Lightrun показало: почти в половине случаев код, который сделал ИИ, приходится править вручную уже после запуска – даже если до этого его проверили и протестировали. А громкий случай с Amazon весной 2026 года (там из‑за изменений от ИИ случились сбои, которые привели к потере миллионов заказов) заставили многих руководителей задуматься: если код всё чаще делает машина, можно ли проверять его так же, как человеческий? Похоже, уже нельзя. 

Мне стало интересно разобраться. В итоге я собрал лонгрид со статистикой, исследованиями и разборами инцидентов. Я тестировщик, которому интересно, что внедрять здесь и сейчас, так что где‑то мог переборщить с выводами. 

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

Часть первая: аналитика

New Relic вместе с Hanover Research опросили американских техлидов. 94% считают ИИ-код качественнее, чем человеческий. Но после релиза картина меняется. 

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

Важное уточнение!

Примерно половина исследований, которые мне удалось найти по теме, продают решение ровно той проблемы, которую измеряют. Sonar продаёт верификацию – и обнаруживает «кризис верификации». New Relic продаёт обсервабилити – и обнаруживает, что обсервабилити стал обязательным минимумом. CodeRabbit продаёт ревью – и доказывет, что ИИ-код надо ревьюить в 1,7 раза внимательнее.

Самый честный пример – в том же отчёте Sonar: пользователи SonarQube, оказывается, на 44% реже сталкиваются с отказами прода из-за ИИ-кода. Может, и правда. Но эту цифру измерял тот, кто продаёт SonarQube.

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

Сколько кода в компаниях пишет ИИ?

Sonar опросил 1149 разработчиков в январе 2026 года: 42% коммитимого кода – это либо генерация ИИ, либо серьёзная помощь от него. К 2027 году этот показатель, по прогнозам, вырастет до 65%. При этом 72% тех, кто пробовал ИИ, используют его каждый день.

По данным New Relic, 67% технических лидеров говорят, что ИИ генерирует или серьёзно перерабатывает от 51% до 75% недельного объёма кода в их организациях.

Мировые IT-гиганты в публичных заявлениях звучат ещё более впечатляюще: Microsoft говорит примерно о 30% кодовой базы, Google – о 75% продакшн‑кода. К такой статистике я отношусь с долей скепсиса: «ИИ коснулся кода» и «ИИ его написал» – это не одно и то же, а в пресс‑релизах эти вещи часто смешивают. Но даже если снизить цифры вдвое, вывод остаётся тем же: процент машинного кода продолжает увеличиваться.

По данным Sonar, проблема звучит особенно чётко: 96% разработчиков не доверяют полной корректности кода, который пишет ИИ, но при этом только 48% всегда проверяют его перед коммитом. Получается разрыв в 48 пунктов между тем, что люди думают, и тем, что реально делают.

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

Вернер Фогельс, CTO AWS, называет это verification debt – это время, которое приходится тратить, чтобы разобраться в коде, который ты сам не писал. Сегодня это фактически главный навык в профессии. Опрос Sonar показал: на первое место среди важнейших умений в эпоху ИИ участники ставят «ревью и валидацию ИИ‑кода» (47%), а не «умение грамотно составлять промпты» (42%).

Что происходит с самим кодом?

Моё любимое исследование, потому что это не опрос. GitClear и GitKraken проанализировали 623 млн реальных изменений кода за 2023–2026.

Вывод. По сравнению с 2023 годом команды чаще дублируют код и используют copy/paste, но значительно реже занимаются рефакторингом, переиспользованием компонентов и улучшением legacy-кода. Это увеличивает технический долг и усложняет сопровождение проектов.

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

• Во‑первых, часть популярных данных вообще из другого отчёта. Например, фразы вроде «копипаст вырос с 9,4% до 15,7%» или «перемещённый код упал с 21%» сравнивают показатели с 2022 годом, а он не входит в диапазон 2023–2026 годов. Эти цифры пришли из более раннего отчёта GitClear «Coding on Copilot». Не стоит смешивать их в одном предложении: скажем, снижение рефакторинга на 70% считается от 13% (2023 год), а не от 21% (2022 год). Если считать от 21%, то падение вышло бы уже 82%.
• Во‑вторых, и это важнее, GitClear заявляет, что разработчики теперь «примерно в 5 раз охотнее продублируют код, чем отрефакторят». Но если взять их же цифры – 15,7 разделить на 3,8, – получится 4,1, а не 5. Либо в самом отчёте используется другая метрика, либо это просто округление в удобную сторону. При этом общий тренд реален: в 2022 году, по тем же данным, соотношение было обратным – 2:1 в пользу рефакторинга. Так что всегда проверяйте цифры, даже в исследованиях, которым доверяете.

Билл Хардинг, CEO GitClear, объясняет, как в коде прячутся ошибки: главная цель модели – удовлетворить промпт. Чтобы правильно обработать возможные ошибки, нужно заранее предусмотреть разные варианты входных данных – а это требует времени и токенов. Проще пойти коротким путём и написать код, который никогда не выбросит исключение. Так и появляются пустые catch‑блоки, которые молча «съедают» все проблемы.

И ещё одна цифра, чтобы не завышать ожидания: активные пользователи ИИ пишут в 4–10 раз больше кода, чем те, кто нейросети не использует. Но значительная часть этой разницы существовала ещё до появления нейронок – просто это изначально более продуктивные разработчики. Если сравнивать их с самими собой год назад, реальный прирост составит примерно 25%.

Что происходит с безопасностью ИИ-кода?

Veracode несколько лет подряд проверяет один и тот же набор из 80 задач с потенциальными уязвимостями на более чем 100 моделях. Результаты весны 2026 года говорят сами за себя: синтаксическая корректность выросла с примерно 50% до 95%, а вот уровень безопасности почти не изменился – security pass rate остался на уровне около 55%.

Проще говоря, модели научились писать код, который компилируется, но так и не научились делать его безопасным. И навороченность модели тут почти ни при чём: будь то 20 миллиардов параметров или 400 – результат крутится вокруг тех же 55%.

Детали показательны: если в промпте нет чётких требований по безопасности, в 45% задач ИИ добавляет уязвимость из OWASP Top 10. Хуже всего дела обстоят с Java – там проваливают около 72% тестов. Особенно плохо с XSS: в 86% подходящих случаев защита не срабатывает. Причина проста: чтобы защититься от XSS, нужно понимать контекст всего приложения, а нейронка видит лишь небольшой фрагмент.

Йенс Весслинг, CTO Veracode, точно подмечает суть явления «вайб‑кодинга»: разработчику не приходится специально прописывать требования к безопасности – он просто хочет получить рабочий код. В итоге решение о безопасности по умолчанию ложится на нейросеть, которая опирается на усреднённые данные из интернета.

А что по галлюцинированию нейросетей?

В исследовании «We Have a Package for You!» (USENIX Security 2025) проверили 16 моделей на 2,23 млн примерах кода на Python и JavaScript. Выяснилось, что 19,7% рекомендованных пакетов просто не существуют – всего насчитали 205 474 выдуманных имён.

Самое тревожное: галлюцинации моделей повторяются. Если один и тот же промпт запустить 10 раз, в 43% случаев одни и те же придуманные пакеты появятся во всех десяти попытках. Такие имена можно заранее предсказать, зарегистрировать в npm или PyPI. Это и есть слопсквоттинг . И это не теория: например, пакет‑пустышка huggingface‑cli – без кода, README и SEO – за три месяца скачали больше 30 тысяч раз.

Апдейт 2026 года (arXiv:2605.17062) даёт смешанные новости. С одной стороны, разброс ошибок уменьшился – с 5,2–21,7% до 4,62–6,10%. С другой – выяснилось, что 127 имён пакетов (109 в PyPI и 18 в npm) одинаково «придумывают» все пять протестированных моделей. И вот это по-настоящему опасно. Единый набор выдуманных имён, который видят все модели, – это уязвимая зона, которую не получится выявить, проверяя только одну из них. Даже если взять другую LLM, это не поможет: у моделей схожие слепые зоны.

Ненадёжное исследование, которое обнажило истину

Июль 2025-го, рандомизированное контролируемое испытание от METR. Шестнадцать опытных разработчиков с опенсорс‑проектов решали 246 реальных задач в своих зрелых репозиториях. Оказалось, что с ИИ они тратили на 19% больше времени. При этом до эксперимента разработчики думали, что станут работать быстрее на 24%, а после, уже столкнувшись с замедлением, оценивали свой прирост продуктивности в 20%.

Позже METR признали проблему с методологией. Те разработчики, кому ИИ действительно помогал, не хотели участвовать в экспериментах без него – даже за 50 долларов в час. Из‑за такой выборки результаты исказились. Сейчас METR считают данные за 2025 год историческими, а свою обновлённую позицию формулируют просто: «Мы не знаем, ускоряет ли ИИ разработчиков».

Вывод. Смысл тут не в цифре 19% – она уже не считается надёжной. Важнее разрыв в 39 пунктов между тем, что люди чувствуют, и тем, что показывают замеры. Даже если ИИ и правда ускоряет работу, собственная оценка продуктивности больше не может служить точным ориентиром. Фраза «стало быстрее» теперь – не данные, а просто ощущение.

Чем приходится платить за скорость разработки?

Faros AI проанализировала работу 22 000 разработчиков из 4000 команд (март 2026) и сравнила периоды с низким и высоким использованием ИИ.

С одной стороны объём работы вырос: 

• эпиков стало больше на 66%, 
• задач – на 34%, 
• пул‑реквестов – на 16,2%,
• доля принимаемого ИИ‑кода поднялась с 20% до 60%.

Но есть и минусы. Сильно увеличился «лишний» труд: 

• churn кода – на 861%, 
• число дефектов на разработчика – на 54%, 
• длительность ревью – почти в 5,5 раза,
• размер пул‑реквестов вырос на 51,3%, а доля тех, что мержат без ревью, – на 31,3%.

Это не сознательный отказ от проверок: ревьюеры просто не успевают за потоком. И даже в командах с сильными инженерными практиками ситуация не лучше – процессы не рассчитаны на такой темп.

Данные LinearB (8,1 млн пул‑реквестов) подтверждают проблему: только 32,7% ИИ‑реквестов принимают без серьёзной доработки, тогда как для человеческого кода этот показатель – 84,4%. То есть две трети ИИ‑изменений приходится переделывать или отклонять. Это и есть скрытая цена быстрой генерации кода.

Вывод после первой части:

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

Теперь эта привычная асимметрия буквально перевернулась. ИИ выдаёт тысячу строк за то время, пока вы читаете этот абзац. А скорость, с которой человек читает код, не изменилась с момента создания первого компьютера.

Часть вторая: какие дефекты должен искать QA в ИИ-коде?

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

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

Вот основные типы проблем, которые создаёт ИИ, и как с ними справляться:

1. Незапрошенное поведение. Нейросеть делает больше, чем просили: например, не просто выводит список, а сразу его сортирует, или чинит баг, попутно меняя три файла. Она стремится к «полноте», а не к точности. Чтобы это ловить, нужно смотреть на дифф и спрашивать не «правильно ли это», а «зачем это здесь». Помогают лимиты на размер PR и чёткие списки файлов, которые агенту разрешено менять.
2. Смещение к «счастливому пути». Код нормально работает на обычных данных, но ломается на крайних значениях: пустом массиве, null, нуле, границе месяца, спецсимволах или при конкурентном доступе. В обучающих данных чаще встречаются примеры «как сделать правильно», а про «что пойдёт не так» пишут реже. Тут выручают property‑based и мутационное тестирование.
3. Галлюцинации с API и пакетами. ИИ вызывает метод, которого вообще нет, или использует существующий метод, но с логикой из другой версии библиотеки. Код компилируется, импортируется, а ведёт себя неправильно. Защититься помогают lock‑файлы с хэшами, списки разрешённых зависимостей, SCA на каждый PR и правило: любой новый импорт в диффе – повод для пристального внимания.
4. Маскировка ошибок. Пустые блоки catch, конструкции вроде except: pass, подмена реального падения на тихий дефолт. Это особенно коварно: система не падает, но выдаёт неверные результаты. При этом алерты молчат, мониторинг показывает норму, а данные постепенно портятся. Бороться с этим нужно жёсткими правилами статического анализа – не рекомендациями, а запретами.
5. Дублирование логики. Появляется несколько похожих, но разных реализаций одной и той же функции. Как точно подметил Хардинг, ИИ каждый раз, когда нужно что‑то сделать, склонен создавать новый пакет. С этим лучше всего справляется порог дублирования в CI – это один из немногих случаев, когда детектор ловит проблему вовремя, когда исправить её ещё дёшево.
6. Архитектурный дрейф. Код формально правильный, но не вписывается в общую систему: заводит свои способы логирования, обработки ошибок, форматы конфигов вместо того, чтобы использовать существующие. Такое почти всегда замечает только человек, который хорошо знает эту часть системы. Нейросеть оценивает уже написанный код, но редко видит неявные требования, которые никто не зафиксировал.
7. Тесты, подогнанные под баг. Агент меняет поведение функции, тест становится красным, а агент «исправляет» тест, переписывая проверку под новое (неверное) поведение. В итоге всё снова зелёное. Это не злой умысел, а поиск самого простого пути к успешному результату. По той же причине агенты могут ослаблять CI: убирать тесты, пропускать линтер или снижать требования к покрытию. Важное правило: диффы тестов нужно проверять даже внимательнее, чем диффы кода. Зелёная галочка после правки двухсот тестов ничего не гарантирует.
8. Интеграционные отказы. Схема ломается, контракт с внешними сервисами нарушается. Нейронка видела ваш сервис, но не видела, как его используют другие системы. Тут помогают контрактные тесты.
9. Целостность данных. Тихая деградация базы: дубли транзакций, необработанные null, дрейф телеметрии. Самое опасное здесь именно то, что всё выглядит нормально: сервис не падает, а данные портятся месяцами и обнаруживаются только тогда, когда не сходятся отчёты или финансы. Защищают инварианты на данных – а не только на функциях.
10. Уязвимости и проблемы с комплаенсом. Ошибки в авторизации, небезопасные токены, инъекции, пробелы в аудит‑трейле, непроверенные лицензии во вложенных зависимостях. Есть и новый тип риска, о котором предупреждает Османи, – prompt injection в функциях, созданных агентом. Если пользовательский текст попадает в запрос к LLM, уязвимость не видна в диффе: она проявится позже, когда придут конкретные данные. Это принципиально новый класс дефектов: нужно учиться тестировать, что произойдёт, если в такое поле ввести инструкцию для модели, – а большинство из нас этого пока не умеет.

Пошаговый гайд для тестирования ИИ-кода

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

Часть третья: восьмиэтапная QA-система

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

Нулевой этап – провенанс

Чтобы правильно работать с кодом, важно сразу понимать, написан ли он человеком или с помощью ИИ. Без этого не выстроить чёткие правила проверки и не собрать корректные метрики. Решить задачу можно простыми средствами: достаточно добавлять в коммиты метки вроде Assisted‑by: или Co‑authored‑by, автоматически проставлять отметку об использовании ИИ на Pull Request и предусмотреть в его шаблоне поле для фиксации того, какой инструмент применялся и какие предложения модели в итоге не взяли.

Так удаётся закрыть главную проблему. Дело в том, что современные ИИ‑агенты перед выдачей результата подробно рассуждают и перебирают варианты, но вся эта логика пропадает, как только формируется дифф. Раньше при код‑ревью смысл правок был понятен сразу – он как бы шёл вместе с кодом. В случае с ИИ‑кодом ситуация иная: ревьюер фактически становится первым человеком, который видит эти изменения, и вынужден заново восстанавливать логику «зачем это сделано». Именно из‑за этого сильно растёт время на проверку.

Исправить ситуацию несложно: достаточно попросить агента кратко зафиксировать, какую задачу он пытался решить и какие варианты отбросил, а затем приложить эту заметку к PR в виде decision log.

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

Первый этап – распределение тестирования по степени возможного ущерба

Не стоит проверять весь код одинаково. При оценке изменений стоит задать себе три вопроса: 

1. что случится, если этот код сломается;
2. как долго он будет в проекте;
3. скольким людям придётся с ним разбираться.

Для прототипов, внутренних утилит и скриптов хватит линтера и тестов. Для внутреннего продакшена и некритичных функций стоит добавить SAST, контроль дублирования кода и проверку одним ИИ‑ревьюером. Клиентские функции и публичные API требуют более серьёзного подхода: тут пригодятся два разных ИИ‑ревьюера, контрактные тесты и обязательное согласование с владельцем домена. А там, где речь идёт о деньгах, аутентификации, персональных данных или ядре бизнес‑логики, нужен полный набор мер: мутационное тестирование, ручная security‑проверка, канарейка и двойное согласование.

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

Второй этап – верификация кода или входной барьер

Здесь цитирую Саймона Уиллисона: ваша задача – приносить в репозиторий только тот код, в работоспособности которого вы уверены. Он резко критикует ситуацию, когда джун с помощью LLM готовит огромный непротестированный PR и перекладывает разбор на коллег, – это не просто неудобно, а по сути неуважение к чужому времени.

Нужны два обязательных шага, чтобы подтвердить качество кода.

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

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

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

Третий этап – детерминированные ворота

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

Нужен механический контроль: порог дублирования кода, запрет пустых обработчиков исключений, обязательный SAST для каждого PR – без исключений по тому, кто автор. Риски из OWASP Top 10 нельзя принимать выборочно: почти половина задач с такими уязвимостями – это слишком серьёзно.

Чтобы защититься от слопсквоттинга, стоит использовать SCA и lock‑файлы с хэшами: полагаться на бдительность тут бесполезно – она не масштабируется. Порог покрытия кода тестами нельзя снижать в том же PR, где его нарушают: агенты делают это не из вредности, а потому что так проще и быстрее. Ещё важно сканировать каждый коммит на секреты – по данным Apiiro, после внедрения ИИ‑инструментов число утечек выросло на 40%.

Отдельно стоит учесть список проблем, на которые GitHub теперь прямо обращает внимание при ревью агентских PR: удалённые тесты, пропущенный линтер, сниженные пороги покрытия, дублирование уже существующих хелперов, а также попадание недоверенного ввода в промпт. Лучше настроить автоматическую проверку каждого из этих пунктов – так получится ловить риски раньше и надёжнее.

Четвёртый этап – тесты

Мутационное тестирование показывает реальную силу тестов: оно проверяет, заметит ли тест ошибку, а не просто фиксирует, что код выполнился. Это особенно важно, когда тесты пишет ИИ: он легко создаёт тесты с хорошим покрытием, которые по сути ничего не проверяют. Пример Пратика Сингха это подтверждает: при 70% мутационного скора часть багов оставалась незамеченной, а сочетание детерминированных и property‑based тестов дало 100%. Данные NASA JPL тоже говорят, что высокое покрытие не гарантирует выявление дефектов – если не проверены краевые случаи.

Инструменты для мутационного тестирования (Stryker, PIT, mutmut, go‑mutesting) лучше применять точечно – на самых критичных участках и для проверки качества самих тестов.

Property‑based тестирование ищет контрпримеры к общим правилам: вы задаёте свойство, которое должно выполняться всегда, а фреймворк подбирает разные входы. Плюс таких тестов – автоматическое упрощение ошибки (shrinking): вместо сбоя на большом массиве вы сразу видите проблему на минимальном примере. Инструменты: Hypothesis, fast‑check, jqwik, QuickCheck. Такие свойства лучше формулировать вручную – это и есть та самая неявная спецификация, которой у модели нет.

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

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

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

Пятый этап – контракты и данные

По данным New Relic, чаще всего проблемы возникают из‑за интеграционных отказов. Причина простая: ИИ знает про ваш сервис, но не про тех, кто им пользуется.

Тут выручает consumer‑driven contract testing (например, Pact): потребитель заранее говорит, чего ждёт от сервиса, а провайдер следит, чтобы ничего не сломать. Это единственная надёжная защита, когда изменения вносит тот, кто не в курсе всех потребителей – а модель по определению их не знает.

Любое изменение схемы базы данных или API‑контракта сразу относить к уровню T3 – независимо от того, насколько маленький получился дифф. Порой одна строчка в миграции может принести куда больше проблем, чем тысяча строк в интерфейсе.

Проверки целостности данных надо рассматривать как полноценные тесты. Важно не только, чтобы код работал, но и чтобы после его работы данные оставались согласованными.

Шестой этап – перформанс ревью

Самый любопытный показатель в материале – и он не от вендора. Инженер проверил 146 реальных PR с помощью четырёх ИИ‑ревьюеров – CodeRabbit, Sentry Seer, Greptile и Cursor BugBot. За три с половиной недели инструменты сделали 679 находок. Из 617 разных помеченных мест 93,4% отметил ровно один инструмент, 6% – два, почти ничего – три, а все четыре не сошлись ни разу: ни одна строка не была отмечена всеми сразу.

У каждого инструмента была своя сильная сторона: Greptile почти не давал ложных срабатываний по корректности и архитектуре, CodeRabbit охватывал больше всего случаев, а Seer лучше всех выявлял ошибки, способные привести к сбоям в проде.

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

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

И главное правило: любое ИИ‑ревью – это лишь сигнал, а не окончательный вердикт. Когда система уверенно говорит «всё хорошо», она просто делится своей уверенностью – а она далеко не всегда оправдана.

Седьмой этап – прод как испытательный стенд

Если нейронка не видит трейс, его придётся получить самостоятельно.

Всё чаще телеметрию добавляют прямо в промпт: 78% команд регулярно просят ИИ включать в код логи, спаны и метрики. Но тут есть опасность: если каждый инженер будет сам придумывать формулировки про логирование, получится хаотичный набор событий. Лучше сразу заложить чёткие правила – например, семантику OpenTelemetry – в корпоративные шаблоны промптов. Указывайте не просто «добавь логирование», а конкретные атрибуты с примерами.

Для изменений уровня T2+ нужны канарейки и флаги. По данным Lightrun, 43% правок, сделанных с помощью ИИ, потом приходится вручную отлаживать уже в проде – даже после QA и стейджинга. При этом почти никому не удаётся проверить ИИ‑фикс за один цикл редеплоя: большинству нужно два‑три цикла, а некоторым – четыре‑шесть.

Получается, стейджинг уже не даёт полной уверенности: для 43% изменений он не становится финальной проверкой. Поэтому правило такое: если уровень T2+ и код создан с участием ИИ, релиз должен идти под флагом, с канарейкой, понятными метриками для отката и с человеком, который первые несколько минут следит за дашбордом.

Ещё один важный момент: 77% технических руководителей сомневаются, что их система мониторинга справится с автоматическим поиском причин сбоев. Прежде чем внедрять AI SRE, убедитесь, что у вас есть нужные данные – иначе системе просто не на чем будет строить выводы.

Восьмой этап – мержем управляет человек

Нейросеть не разбудишь в три часа ночи и не привлечёшь к ответственности. Кто нажал Merge – тот и отвечает.

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

Саймон Уиллисон обращает внимание на опасную закономерность: когда ИИ несколько раз подряд выдаёт хороший результат, у разработчика растёт самоуверенность – и он начинает меньше проверять. Так незаметно формируется новая «норма»: ошибки становятся чем‑то привычным, на них перестают реагировать. Именно так и появляются ситуации вроде «+31,3% PR без ревью».

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

Часть четвёртая: QA-метрики

Откажитесь от метрик, которые только путают: не следите за количеством коммитов и строк. Не ставьте во главу угла покрытие как показатель качества тестов. И не доверяйте самооценке продуктивности команды.

Часть пятая: что точно не поможет?

Часть шестая. Тот самый кейс Amazon, который неправильно пересказывают

Я оставил его почти на конец намеренно: в пересказах всё сводится к фразе «ИИ положил прод Amazon», а это неправда. Реальная история куда интереснее.

2 марта 2026 года на amazon.com сбились сроки доставки: возникло около 1,6 млн ошибок и 120 тысяч потерянных заказов. 5 марта магазин не работал 6 часов, заказы в Северной Америке упали на 99% – примерно 6,3 млн непроданных покупок. 

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

Amazon отмечает: из разобранных инцидентов лишь один связан с ИИ, и это была ошибка пользователя, а не ИИ‑код. При этом в письме SVP по e‑commerce Дэйва Тредуэлла применение GenAI названо одной из причин роста числа серьёзных инцидентов – для этой технологии ещё нет устоявшихся практик и защит.

Реакция компании: 90‑дневный «сброс безопасности кода» для 335 систем и обязательная подпись сеньора под ИИ‑изменениями от джунов и мидлов. Тредуэлл назвал это controlled friction – намеренным «трением».

Ключевой момент: ранее Тредуэлл требовал, чтобы разработчики делали с помощью ИИ не менее 80% еженедельных задач по коду. Сначала – мандат на объём, потом – на «трение». Между решениями прошёл квартал – и случились миллионные потери. Урок не про качество ИИ‑кода: скорость генерации нарастили директивно, а возможности проверки не усилили.

Ещё пример: 13‑часовой сбой AWS в декабре 2025 года случился, потому что ИИ‑инструменту Kiro разрешили удалить и пересоздать окружение без проверок. Проблема – не в ошибке ИИ, а в избыточных правах. Если сбой произошёл даже у Amazon, вопрос не в том, случится ли такое у других, а в том, когда и насколько незаметно.

Часть седьмая. С чего начать в тестировании ИИ-кода?

Порядок важен: сначала дешёвое и механическое, потом дорогое и человеческое.

А какой вывод?

Писать код стало дешевле, а понимать и проверять его – по‑прежнему дорого. В этом корень всех проблем.

Запомните главное: диффы тестов важнее диффов кода. Выбирайте правильные метрики: мутационный скор вместо покрытия, инварианты вместо примеров. Лучше два разных ревьюера, чем один «идеальный». Стейджинг больше не гарантирует качество для почти половины изменений. Канарейки и флаги теперь обязательны.

Хорошая новость для QA: проверка наконец стала самым важным этапом разработки – не потому, что нас в этом убедили, а потому что без неё реально дальше нельзя. Агенты не поменяли суть работы: надо по‑прежнему доказывать, что код работает. Просто теперь это делают не в последнюю очередь, а с самого начала.

Мы в «Лаборатории качества» помогаем внедрять практики тестирования. На старте больше всего дают три простых шага: провенанс кода, тиринг по blast radius и чтение диффов тестов. Сложные вещи (мутационное тестирование, контрактные тесты и т. п.) окупаются позже – когда база уже налажена.

Для команд с ИИ‑кодом в проде мы:

• проводим аудит по ключевым метрикам;
• проектируем систему проверок под вашу архитектуру (без лишнего);
• внедряем нужные виды тестирования и учим команду;
• настраиваем обсервабилити и канареечные релизы;
• передаём экспертизу – чтобы через квартал команда работала сама.

Нужна помощь с определением узких мест? Приходите на бесплатную консультацию. Посмотрим на ваши цифры и скажем, где реально рискуете.