Cursor IDE — Best Practices

Привіт!

У цій статті розповім про хороші практики роботи з Cursor IDE.

Використовуйте Rules на рівні проєкту

Cursor під час індексування проєкту в загальних рисах може сам зрозуміти, що в проєкті знаходиться і як має працювати.
Але буде набагато краще, якщо у нього буде опис того, як це має працювати.
Для цього існують Rules, їх можна додати або через

File -> Preferences -> Cursor Settings -> Rules & Commands -> Project Rules -> Add Rule

Але я раджу додавати іншим способом, у корені проєкту створюємо папки

.cursor -> rules -> файл spec_global.mdc

зверху у файлі обов'язково вказуємо

---
alwaysApply: true
---

після цього spec_global має з'явитися в Project Rule у налаштуваннях Cursor

Rules додаються до нових чатів з агентом.

У Rules можна описати:

роль агента
технологічний стек проєкту
структуру проєкту, наприклад що всі сервіси, контролери і так далі мають лежати у відповідних папках, якісь правила, яких ви хочете, щоб дотримувалися, наприклад щоб під час створення екрана для нього в цій же папці створювався viewmodel, щоб екрани знаходилися кожен в окремих папках, щоб базові класи знаходилися на один рівень ієрархії вище, будь-які правила щодо неймінгу і так далі
будь-які специфічні вимоги для проєкту

Використовуйте глобальні Rules

Ви можете додати в Cursor Rules, яких дотримуватимуться для будь-якого проєкту, у яких написати якісь побажання щодо констайлу, якісь загальні практики і так далі, зробити це можна тут

File -> Preferences -> Cursor Settings -> Rules & Commands -> User Rules -> Add Rule

В інтернеті є багато прикладів подібних Rules.

Для різних частин проєкту створюйте специфічні для них Rules

Якщо проєкт складається з різних частин, наприклад backend, frontend і так далі, вам не обов'язково тримати всі частини в одному репозиторії, ви можете додати в Cursor потрібну частину через

File -> Add Folder to Workspace

Для кожної частини проєкту і для будь-яких папок у проєкті ви можете створювати окремі Rules, для цього створюємо файл spec_frontend.mdc у відповідній папці, у ньому ви можете написати наприклад

You act as a Senior Kotlin Multiplatform Engineer with extensive experience in Kotlin Multiplatform (KMP/KMM), clean architecture, modularization,
shared business logic, MVI state management, repository patterns, and platform-specific implementations through expect/actual.

у папці backend ви можете написати

You act as a Senior Kotlin Backend Engineer with extensive experience in Kotlin, Ktor framework, REST API development, authentication and authorization,
session management, encryption, and microservices architecture.

і так далі.

Для різних завдань відкривайте нові чати

У Cursor контекст чату обмежений, тому для кожного нового завдання і підзавдання краще відкривати новий чат, це знижує навантаження на LLM і дозволяє ефективніше працювати в рамках завдання.

Якщо контекст чату закінчився — ви можете використати команду у вікні введення тексту чату

/Summarize

при цьому згенерується summary чату і контекст звільниться.

Використовуйте Auto модель

У Cursor можна обирати LLM моделі вручну, також використовувати свої API Token для OpenAI API, Gemini API і так далі, навіть локально запущені в Ollama або LM Sttudio моделі, але я б не радив цього робити.

У LLM провайдерів є дурні і розумні моделі, наприклад у OpenAI є моделі Pro, звичайні, Mini, Nano, простіші моделі коштують у 10-20 разів дешевше, також вони набагато швидші і для простих завдань краще використовувати їх.

Під час роботи агента в Cursor робота складається з різних кроків на кшталт оцінки завдання, запитів в інтернет, виконання, оцінки результату і багатьох інших проміжних кроків. Далеко не для всіх цих кроків потрібні розумні і дорогі моделі.

За замовчуванням на цей момент Cursor говорить про те, що використання Auto моделі безлімітне в рамках тарифів Pro і вищих.

Також у кабінеті Cursor ви можете обрати політику використання підписки, тут є дуже важлива опція

On-Demand Usage is Off / On

якщо вона увімкнена, Cursor може використовувати дорожчі моделі і потім виставляти вам рахунок за їх використання.

З практики, тарифу Auto у рамках підписки Pro з On-Demand Usage is Off цілком вистачає для роботи.

Немає жодного сенсу додавати для роботи агента якусь кастомну модель і вмикати On-Demand Usage.

Використовуйте MCP сервери

MCP (Model Context Protocol) — це відкритий стандарт для підключення великих мовних моделей (LLM) до зовнішніх інструментів і даних,
що дозволяє їм виконувати завдання, недоступні в їхньому початковому навчанні. Він стандартизує обмін інформацією між моделлю (клієнт)
і сервером (зовнішні системи, такі як CRM, пошта, бази даних) для підвищення їхньої корисності.

У Cursor ви можете підключити в

File -> Preferences -> Cursor Settings -> Tools & MCP -> New MCP Server

але я рекомендую інший спосіб — у папці .cursor створюємо mcp.json, для будь-якого подібного сервера ви можете подивитися потрібний вміст цього json, наприклад:

Ось приклад інструкції і json для mcp сервера для n8n, там же знаходяться Rules для роботи сервера

https://github.com/czlonkowski/n8n-mcp

за допомогою цього сервера Cursor може підключатися до n8n Workflow, дивитися і редагувати його.

Ось один із серверів, за допомогою якого можна підключити до Cursor ваш акаунт на Confluence

https://github.com/sooperset/mcp-atlassian

завдяки цьому Cursor може дивитися описи для різних частин проєкту на Confluence і брати звідти всю необхідну інформацію для завдання.

Погоджуйтеся зі змінами, зробленими Cursor, якщо стало краще, ніж було

Може бути багато різних думок на тему того, коли краще прийняти зроблені Cursor зміни, але моя думка тут така:

Якщо стало краще, ніж було, краще апрувнути зміни.
Часто Cursor виконує частину завдання, щось виконує не правильно, але якщо робити approve тільки коли все повністю готове, можуть бути такі проблеми:

Коли змін занадто багато, їх важко рев'ювити
Cursor щось зіпсував із того, що працювало, і не може зрозуміти, що зламалося, при цьому 90 відсотків коду працює, у цьому випадку ви ризикуєте витратити контекст до того, як проблема буде виправлена

Тому я рекомендую робити Approve змін, якщо стало краще, ніж було, і при цьому нічого не зламалося.

Працюйте з тими IDE, які вам зручні, використовуючи Cursor тільки для генерації коду

Cursor як IDE, а не як агент, не дуже зручний у більшості випадків, у ньому немає дуже багато чого з того, що є в IDEA, PyCharm та інших спеціалізованих IDE.

Якщо проєкт складається з backend, frontend та інших частин, може бути складно запускати все це в Cursor, оскільки різні частини можуть потребувати специфічних плагінів і можливостей, яких немає в Cursor.

Тому ви можете працювати одночасно в Cursor, використовуючи його тільки як агент для генерації коду, при цьому всю іншу роботу робити у відповідних IDE, у яких відкриті потрібні частини проєкту.

Робіть надлишкове логування роботи застосунку

Якщо під час запуску застосунку щось пішло не так, максимально докладні логи дозволять Cursor зрозуміти, що саме пішло не так.

Якщо для людини надмірно перевантажена логами консоль — це суттєвий мінус, у Cursor немає проблем з великою кількістю логів, і порівнюючи вивід з кодом, він може краще зрозуміти, що саме в ході виконання пішло не так.

Робіть можливим незалежний запуск окремих ділянок застосунку або робіть тести, при помилках просіть Cursor запустити відповідний шматок коду в консолі і подивитися stacktrace

Cursor може сам взаємодіяти з консоллю, запускаючи збірку і різні ділянки коду і дивлячись процес виконання за логами і помилками.

Ви можете попросити Cursor — запусти збірку проєкту або такий-то файл, подивись вивід у консоль і виправ, роби це в циклі поки не почне працювати.

Ця стратегія може бути набагато ефективнішою, ніж якщо ви запустите код самостійно і скопіюєте агенту Cursor stacktrace помилки.

Для різних частин проєкту ви можете робити незалежний запуск для того, щоб Cursor міг запустити відповідний код і подивитися, що вийшло, наприклад у Python ви можете додавати код

if __name__ == "__main__":
   ...(some method)

і потім просити Cursor запустити цей код і подивитися stacktrace.

Також існує підхід, коли спочатку пишуться тести, потім пишеться код, який їх має проходити, з Cursor такий підхід може бути дуже ефективним.

Для запуску Cursor коду в консолі можна налаштувати політику через

File -> Preferences -> Cursor Settings -> Agents -> Auto-Run -> Auto-Run Mode

тут ви можете обрати, запускати все без approve, чи чекати approve від користувача, останнє безпечніше, оскільки ви можете переглянути команду, яка запускається, але при цьому збільшує час роботи над кодом.

Завжди перевіряйте список змін перед commit

Це правило було дуже важливим ще задовго до появи Cursor, але з появою агентів для генерації коду воно стало ще важливішим.

Будь-які LLM схильні помилятися, і схильні змінювати той код, про який не говорилося, що його потрібно змінювати.

Тут завжди є баланс між самостійністю агента і ризиком зіпсувати те, що вже працювало.

Тому перед commit дуже важливо переглядати повний список усіх змін, які зробив агент, щоб не зламати те, що працювало, не зробити дірку в security і так далі.

Декомпозуйте великі завдання на дрібні від загального до часткового, генеруйте код крок за кроком, контролюйте кожен крок, кроки мають бути самодостатніми і не залежати від наступних кроків

Якщо ви попросите Cursor написати все і одразу, з великою часткою ймовірності вийде некоректно працюючий код, який виглядає зовсім не так, як ви б хотіли.

Щоб такого не вийшло, декомпозуйте завдання на максимально дрібні і докладні кроки, наприклад

Створити базову архітектуру
Додати залежності
Оновити залежності до останніх версій
Створити папки і базові класи
і так далі

У результаті, коли ви контролюєте кожен крок, найімовірніше ви отримаєте те, що очікуєте.

Важливо при цьому, щоб на кожному кроці проєкт збирався і в ньому не було помилок, тобто кожен етап має бути самодостатнім і не залежати від наступних кроків.

Після кожного кроку ви можете робити commit, щоб завжди мати можливість відкотити всі зміни і згенерувати наступний код заново.

Оскільки Cursor може робити одне й те саме різними способами, уточнюйте, який спосіб актуальний для вас

Ви можете давати агенту посилання на офіційні мануали як референс, посилання на статті з реалізаціями, які вам сподобалися, і так далі.

Перед генерацією коду ви можете запитати агент, який спосіб буде найактуальнішим, які плюси і мінуси, щоб обрати відповідний, інакше вибір реалізації буде на боці агента, а він у більшості випадків обирає реалізацію ґрунтуючись на своїх навчальних даних, а як ми знаємо, основне джерело даних для LLM це Reddit, Stackoverflow та інші ненадійні джерела.

При додаванні бібліотек завжди просіть агент використовувати останні версії і враховувати тип ліцензії

За замовчуванням агент Cursor, як і всі LLM, не дивиться в інтернет, яка версія остання, а додає якусь, про яку знає, часто це версія, випущена 2-3 роки тому.

У цьому випадку подальший перехід на актуальну версію може бути пов'язаний з додатковими труднощами і втратою часу.

Тому завжди набагато простіше попросити агент подивитися в інтернеті і використовувати актуальну версію бібліотеки.

Також будьте уважні з типом ліцензії бібліотеки, агент на таке зазвичай не звертає уваги, і ви ризикуєте додати в приватний enterprise проєкт бібліотеку з GPL ліцензією, яка передбачає розкриття вихідного коду.