Our read
Treat Cursor as a way to reach a first draft of a change faster, not as the owner of the pull request. The documented strengths are repository context, multi-file edits, parallel and cloud agents, and bot review of PRs. Test judgment, the reading of the diff and the merge decision stay with the developer. Cloud agents and Bugbot start at the Premium plan, so a free-plan trial will not show the full flow.
Start with context: what the indexing claim covers
Cursor is an editor built on VS Code, and the vendor describes it as offering codebase understanding and multi-file context. On the homepage, secure codebase indexing and semantic search appear in a list of published research projects dated 2026. That list gives no detail on what is indexed, how often, or where the index lives. Read it as a direction, not as a specification, and take any data-location question to the security documentation.
For a ticket in an unfamiliar repo, the homepage demo shows a planning step: the agent asks clarifying questions, then lists tasks before building. That is a useful habit to copy. Answer the questions, edit the task list, and open the files the plan names before any code is written. This is an editorial recommendation; the demo does not prove the plan is correct for your code.
Changing several files: three levels of autonomy
The product offers targeted edits, an agent, and cloud agents. A homepage testimonial describes the range from a quick edit command to a fully agentic run. The pricing page lists Agent on every plan, with limited requests on Free, while cloud agents and automations start at Premium. The homepage says cloud agents work on their own machines and in parallel, and its demo shows a run of about fourteen minutes that ends with a screen recording for the reviewer.
Work can also enter from outside the editor. The homepage shows Cursor in the terminal, in Slack (a teammate asks it to take a stab at a change and it replies with a PR link), and reviewing PRs in GitHub. The marketplace lists a template that watches a Slack channel for bug reports, investigates the codebase and opens a PR, and a Slack integration among its featured plugins.
A job post from Inter, which counts only as SIGNAL, describes backend work on Java and Micronaut microservices where engineers use Cursor, agents and MCP integrations for diagnostics, test writing, refactoring and code review. The same post asks candidates to judge the architecture, security and quality of generated code. It shows what the employer expects of the developer, not how the tool performs.
Tests: what is documented, and what Brex learned
The homepage says cloud agents build, test and demo features end to end. The marketplace adds automations such as adding test coverage, fixing CI failures on main and triaging failed GitHub Actions runs. None of this names a test runner, says whether results are attached to the PR, or describes the environment the agent runs in. A short trial settles it: give an agent one real ticket on a repo with working CI and read what it reports.
Brex shows what a tested loop looks like. For a Micronaut 3 to 4 migration, a Linear ticket triggers a generation agent that builds locally and opens a draft PR. A label then triggers a validation agent that deploys to a development environment, runs integration tests and patches failures, up to three attempts, before it stops and leaves a report as a PR comment. Brex reports that one engineer migrated 180 services in a month, which it calls a 32x per-capita gain over an earlier effort of three engineers and about 50 services in a quarter. Those are Brex's own figures for one migration.
Brex also states its limits. Agents never merge to production; a human reviews. And some automated PRs passed every existing test, then caused subtle runtime bugs in production because those services had thin test coverage or monitoring. The lesson for any team: an agent can only be as reliable as the checks behind it.
Review and the pull request
Pricing lists AI code reviews through Bugbot and code hosting through Origin from Premium upward, and the marketplace features a template that reviews PRs for exploitable security issues and flags only validated findings. A canvas plugin renders PR diffs grouped by importance. No source gives false-positive rates or says what the bot misses, so use it as a second reader that points you to files, not as the approver.
One marketplace template assigns reviewers and auto-approves low-risk PRs. Whether that is acceptable depends on a rule only your team can write. Define what low-risk means, in files and in change size, before switching it on. Brex kept human review on every PR for its migration.
Team controls and the plan you need
The security page says Privacy Mode can be enabled by a user or an admin, that new team members inherit the team setting, and that Cursor will not train on data when it is on. It lists AIUC-1, ISO/IEC 27001:2022 and ISO/IEC 42001:2023 certifications plus a SOC 2 Type II attestation, with reports on request through its trust portal. Its developer docs cover agent security, cloud agent network security, hooks, MCP and customer-managed keys.
By plan, Teams ($30 and up per user per month) lists SAML/OIDC SSO, usage analytics and team-wide privacy settings. SCIM, audit logs, and repository, model and MCP access controls appear only under Enterprise. Third-party model usage is billed separately. The pricing page also carries rows about a social network and Grok features, and says the Plus plan offers only Grok models, so read only the Cursor rows. A free plan exists, but cloud agents and Bugbot are not included in it.
Method and limits
2026-10-27
This dated snapshot counts distinct companies in public customer evidence. CONFIRMED means a case study, named testimonial or press source; DECLARED means the company itself told usedby; OBSERVED means a vendor listing; SIGNAL means a job post. All four count, but their strength differs. Removed and unlevelled lines are excluded. Examples are a capped selection verified within 90 days. Vendor facts are sourced records checked within 60 days. Coverage is uneven and missing evidence is unknown. These figures measure neither market share nor product performance; capture dates are not adoption dates.
