ИИ-ассистенты ускоряют разработку, но отсутствие автотестов грозит срывами проектов

В настоящее время на одном из проектов я столкнулся с проблемой, которая заслуживает внимания: внедрение инструмента Cursor для ускорения разработки привело к отсутствию полноценных автоматизированных тестов. Хочу поделиться своим опытом и предложить решение этой проблемы. **Как всё начинается** Руководство, вдохновлённое информацией о возможностях искусственного интеллекта, принимает решение использовать ИИ-ассистенты, такие как Cursor, для повышения эффективности работы. На первых порах, в течение 2–3 недель, продуктивность действительно растёт: задачи выполняются в 2–3 раза быстрее, показатели в Jira выглядят впечатляюще, и все довольны. Однако уже на 3–5 неделе начинают появляться первые проблемы: регрессионные тесты выявляют множество ошибок в ранее стабильных частях системы, и тесты начинают падать. К 6–8 неделе тестировщики оказываются перегружены, регрессионные тесты растягиваются с двух дней до недели, а выпуск новой версии откладывается из-за необходимости ручной перепроверки всего кода. **Почему возникают проблемы** Разработчики продолжают писать юнит-тесты, и их количество даже увеличивается благодаря возможности Cursor генерировать их автоматически. Однако проблема заключается в том, что юнит-тесты проверяют только тот код, который был недавно написан, и не учитывают возможные ошибки в соседних модулях, контрактах и интеграциях. Cursor имеет тенденцию «улучшать» старый код, переписывая его в соответствии с современными стандартами. В результате юнит-тесты на новые функции могут быть успешными, но интеграция с устаревшими модулями или внешними сервисами может нарушиться. Кроме того, обзор больших изменений становится сложным, так как никто не готов тратить много времени на анализ сотен строк кода, большая часть которых сгенерирована автоматически. Интеграционные API-тесты и E2E-тесты не обновляются автоматически, поскольку это требует участия человека, которого не всегда выделяют для этой задачи. В итоге ошибки, которые ранее выявлялись на уровне интеграции, теперь обнаруживаются только на финальном этапе регрессионного тестирования, что приводит к появлению багов в продакшене, особенно в конце рабочей недели. **Как следует действовать с самого начала** Я считаю, что юнит-тесты должны оставаться в зоне ответственности разработчиков и Cursor, при условии что покрытие тестами не приводит к сбоям в пайплайне. Всё остальное, включая API и E2E-тесты, следует вынести в отдельный репозиторий и пайплайн. Это позволит: * не замедлять сборку основного кода; * запускать тесты параллельно на большом количестве агентов; * отдельно отслеживать статистику и выявлять регрессии, связанные с новыми функциями. Оптимальная структура покрытия: * 70–80 % — быстрые API-тесты (контракты, статусы, бизнес-логика); * 20–30 % — дымовые E2E-тесты по пользовательскому интерфейсу для критических путей. Все тесты должны быть интегрированы в CI/CD и запускаться на каждый мердж-реквест и на основную ветку. Если хотя бы один тест не проходит, сборка считается неудачной и деплой не выполняется. Также следует ввести правило: большие изменения без обновления AQA не объединяются. Если Cursor вносит более 100 строк изменений, необходимо обновить или добавить API-тесты на изменённые эндпоинты. Метрика «регрессы от Cursor» позволяет отслеживать количество багов, найденных на этапе QA, по коммитам с диффом более 50 % сгенерированного кода. Если этот показатель достигает критического уровня, проводится ретроспектива и корректируются промпты или процессы.