Практический гайд: рефакторинг и тесты с Cursor и .cursorrules

Многие разговоры о замене разработчиков искусственным интеллектом устарели. В реальной разработке ИИ не вытесняет full-stack-инженеров, а усиливает их, забирая рутину, повторяющиеся операции и механическую работу. Для тех, кто пишет на JavaScript и работает с MERN-стеком, главный bottleneck — не набор синтаксиса, а распутывание унаследованных Express-контроллеров, понимание чужого кода, написание тестов, обработка граничных случаев, поддержание архитектуры и рефакторинг без поломок. Поэтому цель не в том, чтобы ИИ писал всё приложение, а в том, чтобы встроить его в инженерный процесс. Если просить модель генерировать случайный boilerplate или «vibe code» целыми файлами без ограничений, технический долг растёт быстрее, чем появляются фичи. Но если соединить Cursor и Claude Code с чистой архитектурой, явными ограничениями и строгим тестированием, ИИ становится инженерным вторым пилотом. Первый шаг — заземлить помощника. Для этого в корне проекта создаётся файл .cursorrules. Это постоянный набор инженерных инструкций для Cursor. Без контекста LLM может смешивать CommonJS и ES Modules, придумывать несогласованные названия, подставлять устаревшие Mongoose-паттерны, класть бизнес-логику в обработчики маршрутов, создавать вложенные условные блоки и игнорировать уже существующую структуру кодовой базы. В примере для MERN-приложения задаются Node.js v20 с import/export, Express, Mongoose, React 18 с функциональными компонентами и хуками, Jest и Supertest. Правила требуют строгого разделения слоёв Routes → Controllers → Services → Models, запрещают сырые запросы к базе внутри маршрутов, требуют оборачивать асинхронный код и передавать ошибки через next(error), защищать ввод от NoSQL-инъекций и изолировать бизнес-логику в чистые сервисные функции для тестирования. Важно не дословное содержимое файла, а то, что ИИ получает стабильный контекст до внесения изменений. Дальше автор разбирает типичную проблему — «god function». Это толстый контроллер, который одновременно отвечает за аутентификацию, валидацию, запросы к базе, бизнес-логику, оплату, письма, обработку ошибок и HTTP-ответы. В примере маршрут /checkout проверяет userId и items, ищет пользователя, считает сумму, применяет скидку для premium-пользователей, имитирует платёж, создаёт заказ в MongoDB, отправляет письмо и возвращает ответ. Такой код трудно тестировать, переиспользовать и поддерживать, потому что в одном месте связаны HTTP, пользователи, заказы, цены, скидки, платежи и письма. Вместо расплывчатой просьбы «сделай код лучше» Cursor получает конкретный промпт: следовать паттерну Service-Controller, вынести расчёт скидок и создание заказа в orderService.js, использовать express-async-handler и сделать бизнес-логику тестируемой без MongoDB. Автор подчёркивает, что именно конкретные ограничения — какую архитектуру использовать, какую логику извлечь, в каком файле её разместить, как обрабатывать ошибки и что должно проверяться независимо — дают заметно более полезный результат. После рефакторинга структура становится понятнее: routes, controllers, services, models и utils. Слой orderService.js содержит чистую функцию calculateTotal, которая принимает массив товаров и признак premium-пользователя, а возвращает итоговую сумму. Этой функции не нужны Express, MongoDB или HTTP-запросы, поэтому её можно покрыть unit-тестами отдельно от инфраструктуры. Такой подход снижает связанность и делает изменения безопаснее. Практический вывод для разработчика: не просите ИИ абстрактно улучшать код. Сначала зафиксируйте стандарты проекта в .cursorrules, затем ставьте задачу точечно: какие слои использовать, какую логику выносить, где должны жить функции и как проверять их независимо.