Разработчики начинают массово отказываться от unit-тестов из-за ИИ и вайбкодинга.

Еще недавно правило «пиши больше unit-тестов» было практически универсальным. Тесты считались фундаментом надежного кода: они быстро выполняются, позволяют изолировать ошибки и защищают приложение от регрессий. Теперь эту идею начинают пересматривать!

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

Представим простую задачу. Разработчик просит AI реализовать расчет стоимости заказа. Модель создает функцию, а затем генерирует к ней 20 unit-тестов.

Все тесты проходят. На первый взгляд задача выполнена. Но что произойдет, если AI неправильно понял бизнес-правило?

Допустим, скидка должна составлять 20% только для заказов дороже €100. Модель ошибочно решила, что скидка применяется ко всем заказам. Она напишет функцию с этой логикой и затем вполне способна создать тесты, которые подтверждают именно ее.

Получается неприятная ситуация: тесты зеленые, код работает именно так, как проверяют тесты, но бизнес получает неправильный результат.

В этом и заключается одна из главных претензий к чрезмерной зависимости от unit-тестов в AI-разработке.

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

Раньше написать 20 хороших unit-тестов было заметной частью работы разработчика. Нужно было придумать сценарии, написать код, проверить edge cases, разобраться с ошибками и поддерживать тесты после изменений.

Теперь AI может создать десятки тестов практически мгновенно.

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

Или важнее понять, что именно они способны доказать?

Исследование Checksum, опубликованное в июле 2026 года, показывает масштаб проблемы. Среди 105 руководителей инженерных команд 61% сообщили, что за предыдущие 90 дней сталкивались с production-инцидентом, связанным с AI-generated code. При этом 74,3% заявили, что им приходилось откатывать код после проблем, которые не были обнаружены их unit-тестами.

При этом доверие к AI растет: 78,1% участников исследования сообщили, что доверяют AI-generated code больше, чем годом ранее.

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

Именно здесь в дискуссии снова появляется end-to-end тестирование.

Unit-тест может проверить отдельную функцию:

Но он не проверяет, что происходит с этим расчетом во всей системе.

E2E-тест может пройти полный сценарий:

Такой тест значительно ближе к реальному поведению продукта.

Именно поэтому некоторые разработчики сейчас предлагают сместить баланс в сторону integration и E2E-тестов. Не потому, что unit-тесты стали бесполезными, а потому, что в AI-generated code появляется дополнительный риск: модель может правильно протестировать неправильную реализацию.

При этом полностью отказаться от unit-тестов было бы ошибкой.

Если в приложении есть сложный алгоритм, расчет налогов, обработка платежей, парсинг данных или другая изолированная бизнес-логика, unit-тест остается очень эффективным способом быстро проверить множество вариантов.

Вопрос скорее в другом: что именно мы хотим проверить?

Классическая модель выглядела примерно так: много unit-тестов в основании, меньше integration-тестов посередине и небольшое количество дорогих E2E-тестов наверху.

Логика была понятной: unit-тесты дешевые и быстрые, поэтому ими выгодно покрывать большую часть кода.

Но AI меняет стоимость этой модели.

AI может за секунды создать сотню unit-тестов. Однако он так же быстро может создать сотню тестов, которые проверяют не бизнес-требования, а детали конкретной реализации.

Поэтому новый подход может выглядеть иначе: unit-тесты там, где они действительно дают сигнал, integration и contract tests для взаимодействия компонентов, E2E для критических пользовательских сценариев и отдельная проверка требований человеком.

Это уже не вопрос религии «unit-тесты обязательны».

Это вопрос управления рисками.

Самое интересное изменение заключается в том, что AI не уничтожает unit-тесты. Он уничтожает их дефицит.

Когда разработчик тратил несколько часов на создание тестов, количество тестов само по себе было значимой метрикой.

Теперь AI может создать их сотни.

Поэтому количество тестов становится все менее информативным показателем.

Можно иметь 10 000 зеленых тестов и при этом получить ошибку в продакшене, потому что никто не проверил главный пользовательский сценарий.

Можно иметь гораздо меньше unit-тестов, но хорошо покрыть критические бизнес-процессы интеграционными и E2E-проверками.

И здесь появляется новая роль разработчика.

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

AI очень быстро превращает разработчика из человека, который пишет каждую строчку кода, в человека, который должен понимать, какую систему он вообще строит.

Microsoft, например, уже развивает GitHub Copilot Testing для .NET, который помогает автоматически создавать unit-тесты в Visual Studio. То есть индустрия одновременно движется в двух направлениях: AI делает автоматическую генерацию тестов массовой, а разработчики начинают спорить о том, достаточно ли этих тестов для проверки реального поведения продукта.

Возможно, поэтому главный вопрос эпохи AI будет звучать не так: «Покрыта ли эта функция unit-тестом?»

А гораздо проще: «Как мы доказали, что система делает то, что должен получить пользователь?»

И если ответом на этот вопрос является только «у нас 95% test coverage», возможно, пришло время написать еще один тест. Но уже не обязательно unit.

Если вам близка тема AI, технологий и будущего - добро пожаловать в мой канал обсудить и поделиться апдейтами.