The starting point is your repository
Cursor positions its product around coding agents and a development environment. For an existing software project, the practical attraction is working close to code, project context, and the places where changes will be reviewed.
Give the assistant a bounded task
Start with a specific behavior to change and describe how success will be checked. A small bug fix with a reproducible example is easier to review than a broad request to improve an entire application. Repository conventions and instructions help make the result fit the project.
Review behavior as well as the diff
A plausible code change can still miss an edge case. Read the patch, run relevant checks, and exercise the original failure scenario. Treat generated work as a proposal that goes through your normal development process.
When to explore another approach
If your immediate goal is to sketch a new web interface from a product idea, an app builder may be a more direct starting point. If you are changing a mature repository, editor integration and control over existing files may matter more. This is a workflow distinction, not a benchmark ranking.
Sources & editorial note
This introduction draws on the official resources below. It is not a hands-on benchmark. Product capabilities can change; check the linked documentation before implementation.
