Speed up feature delivery by moving a team to Cursor

Posted

May 15, 2025 by Chantal Kapani (LeadDev)

·

Last checked

Oct 16, 2026

·

Method:

How we verify

Evidence: Article or interviewA newsletter, journalist or interview account of what happened.

Outcome

Security startup Jit moved its engineers from JetBrains to Cursor and, according to the article, delivered features 1.8–3x faster.

Agent

Cursor

The source didn't share its exact prompt, so we wrote this from what it describes.

Here's a task I'd like your help with. Read it all the way through before you start.

Goal: Build this feature from start to finish, front end and back end, following my team's coding rules, and open a pull request for review.

Check with me first: ask me what the finished feature should do and the one or two things that matter most, so we agree on what "done" means.

What I'll give you:
- The ticket or a short description of the feature
- My team's coding rules in Cursor (the language, frameworks, style guidelines and folder structure I use)
- Access to the code repository, and permission to commit and open a pull request

Rules:
- Follow the team's coding rules everywhere, so the code looks like a teammate wrote it and not generic code.
- Only change what this feature needs.
- If the ticket or the rules don't answer something, ask me instead of guessing.
- When the work is done, commit it, open a pull request, and update the ticket.
- Don't merge. Stop once the pull request is open and hand it back to me.

Output: the pull request link, a short plain-language summary of what changed, and any open questions.

You'll know it worked when: the feature behaves the way the ticket describes and the pull request is ready for a teammate to review.

Later I may also ask you to: address review comments on an existing pull request, or update or create the ticket for this work.

Works best when: my team's coding rules are already written down in Cursor.

Here's a task I'd like your help with. Read it all the way through before you start.

Goal: Build this feature end to end, following my team's rules, and open a PR for review.

Quick check first: tell me if anything below is missing or unclear.

Inputs (fill in or confirm):
- Ticket or description and acceptance criteria
- Team coding rules file
- Repo, branch and test commands
- Design mockups or screenshots, if any
- Definition of done (tests, docs, screenshots)
- Areas of the codebase that are off-limits

Rules:
- Restate the acceptance criteria and wait for my OK.
- Plan front-end and back-end changes before coding.
- Follow the rules file exactly; add tests for each criterion.
- Keep the PR small and explain trade-offs in the description.
- Reuse existing components and patterns in the codebase before writing new ones.
- Note any database migration and make it reversible.
- Read the team's rules file first and follow it; quote the rule if you deviate and say why.
- Write a short plan (files to change, API changes, data changes) and wait for my OK before coding.
- Build back end first with tests, then front end, then end-to-end checks.
- Keep commits small and focused with clear messages.
- Run the full test suite and linter locally before opening the pull request.
- In the PR description, list what changed, how to test it, screenshots and any open questions.
- Never merge or deploy; leave that to review.

Checkpoint: Don't merge, deploy or change shared config without asking.

If you get stuck: If requirements conflict, stop and ask. If a login, CAPTCHA or two-step code appears, stop and ask me to handle it; never guess or store passwords.

Verify before you finish: Run all tests and linters locally.

Output: PR link with description, test results and screenshots.

Done when: every acceptance criterion has a passing test.

Source

https://leaddev.com/technical-direction/how-jit-overcame-developer-resistance-shift-cursor