Cursor и ИИ-ассистенты ускоряют разработку — но без нормальных автотестов топят всю команду

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

Как это обычно происходит

Руководство/CTO/кто-то сверху читает твиты про то, как «скорость разработки ×10 за счёт ИИ», проводит собрание и выдаёт директиву: «Теперь весь код пишем через Cursor или другие ИИ-ассистенты».

Первые 2-3 недели — эйфория. Таски закрываются в 2–3 раза быстрее. В Jira зелёный лес, графики вверх, все хлопают в ладоши, бизнес доволен.

3-5 неделя — первые тревожные звоночки. На регрессе всплывает куча багов в ранее стабильных местах. Начинают падать тесты.

6-8 неделя — тестировщики тонут, регресс растягивается с 2 дней до недели, прод-деплой откладывается, потому что «надо всё перепроверить вручную».

Почему так выходит?

Разрабы пишут юнит-тесты (и даже пишут их больше, чем раньше — Cursor генерит их пачками). Проблема не в юнитах. Проблема в том, что юниты проверяют только то, что Cursor только что написал, а не то, что он сломал по пути в соседних модулях, контрактах и интеграциях.

Что именно ломается

1. Cursor любит «поумничать» — переписать старый рабочий код «по-современному». Юнит-тесты на новую функцию зелёные, а интеграция с легаси-модулем или внешним сервисом падает.

2. Ревью больших диффов превращается в «ну выглядит нормально». Никто не готов тратить час на разбор 400–600 строк, из которых 80 % сгенерированы.

3. Интеграционные API-тесты и E2E никто не обновляет автоматически — их пишут люди, а людей на это не выделили.

4. В итоге всё, что раньше ловилось на уровне интеграции, теперь ловится только руками на финальном регрессе. И да, привет, баги в продакшене в пятницу вечером.

Как я считаю, это надо делать с самого начала

1. Юнит-тесты оставляем разработчикам и Cursor’у — это их зона ответственности. Пусть генерит сколько угодно, лишь бы из-за покрытия не падал пайп.

2. Всё остальное — AQA-уровень (API + E2E) — выносим в отдельный репозиторий и отдельный пайплайн. Почему отдельный:

   1. не тормозим сборку основного кода

   2. можем запускать на 50–100 агентах параллельно

   3. можно отдельно считать статистику и видеть регрессы именно от новых фич

3. Структура покрытия, которая реально работает:

   1. 70–80 % — быстрые API-тесты (контракты, статусы, бизнес-логика)

   2. 20–30 % — дымовые E2E по UI только на критичные пользовательские пути

   3. Всё это висит в CI/CD: на каждый MR и на main

   4. Один упавший тест → красная сборка → деплоя нет

4. Правило «большие диффы без AQA-обновлений не мержим». Сделал Cursor 100+ строк изменений → обязан обновить или добавить API-тесты на изменённые эндпоинты. Не обновил → MR висит.

5. Метрика «регрессы от Cursor». Считаем количество багов, найденных на QA, по коммитам с диффом > 50 % сгенерированного кода. Когда цифра уходит в потолок — проводим ретроспективу и правим промпты/процессы.

Почему это работает

Юниты ловят ошибки ^[2] внутри функции. API-тесты ловят, что функция сломала интеграцию. E2E ловят, что всё вместе упало на самом очевидном пути пользователя. Когда эти три уровня разделены и каждый живёт своей жизнью — скорость разработки действительно растёт, а количество багов будет падать.

ИМХО

Cursor и любые другие ИИ-ассистенты — шикарные инструменты. Они реально ×2–3 ускоряют написание кода. Но если не поставить вокруг них нормальные автотесты, ускорение превратится в самоубийство ^[3] на рассрочку.